Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Character string initialization

bbeyer
Novice
1,438 Views

Hello, I have a question concerning the initialization of character strings in a subroutine. I am porting legacy code from CVF 6.6B to Intel 12.0 and the following sample "worked correctly" in CVF with variable CTITLE having the intended values specified in the DATA statements. However, I am not sure if this was bad programming and worked by accident!

I have found with the Intel solution the data is messed up, apparently due to the initialization CTITLE(8) = ' ', and found that by removing the initialization the new solution works. I read that the DATA statement pads the end of the strings with blank characters so I am assuming that everything in CTITLE is initialized, as I have had bad experiences with uninitialized data in the past. My question is why would the initialization specified with CTITLE have an effect on the data specified in the DATA statements? Thank you.

37875-Image2.jpg

0 Kudos
6 Replies
Steven_L_Intel1
Employee
1,438 Views
Can you attach a compilable source that demonstrates the problem? I can't reproduce it based on the screenshot.

When you DATA initialize a local subroutine variable, that gives it the SAVE attribute and it will be allocated statically. My guess is that there's more going on than what has been shown here so far.
0 Kudos
bbeyer
Novice
1,438 Views

Steve,
I attached a sample program that replicates the question. The source looks like this:

IMPLICIT NONE
!
INTEGER*4 J
CHARACTER*50 :: CTITLE(8) = ' ' !THIS DOES NOT WORK CORRECTLY
! CHARACTER*50 CTITLE(8) !THIS WORKS

DATA CTITLE(1) /'POINT DESIGN'/
DATA CTITLE(2) /'ACTUAL DESIGN'/
DATA CTITLE(3) /'ACTUAL RATING'/
DATA CTITLE(4) /'RECALC ACTUAL RATING DUE TO RESET USE APPENDIX A6'/
DATA CTITLE(5) /'NON-PRISMATIC MINIMUM LTB CALCULATIONS FOR DESIGN'/
DATA CTITLE(6) /'NON-PRISMATIC RECALCULATED, APPENDIX A6 SET FALSE'/
DATA CTITLE(7) /'MOVING LEFT TO RIGHT, RIGHT SIDE OF PIER'/
DATA CTITLE(8) /'MOVING RIGHT TO LEFT, LEFT SIDE OF PIER'/
!
DO J = 1,8
WRITE(*,*) CTITLE(J)
ENDDO
CONTINUE
END

0 Kudos
TimP
Honored Contributor III
1,438 Views
The compiler is enforcing a requirement of the standard that you don't effectively give multiple DATA initializations for the same array. Apparently, CVF allowed this, presumably giving the last one effect. So it looks like the compiler has led you to correct the code.
0 Kudos
Steven_L_Intel1
Employee
1,438 Views
The source you attached demonstrates a quite different issue. Tim is correct that you are not allowed to initialize the same part of the variable more than once. If I use the "this works" version, the code works correctly.

What did you do to show the results you presented in the original post?
0 Kudos
bbeyer
Novice
1,438 Views

For the original post I used the original statement of the legacy code that worked in CVF:
CHARACTER*50 :: CTITLE(8) = ' '
This sounds like it is now working correctly per the standard, but honestly I liked the way CVF handled this situation from auser friendlyperspective, although it may not have been per the standard. Maybe a compiler warning would be beneficial to alert users of the double initialization occurring and that this can apparently scramble up the data so that neither initialization is working. Thank you Steve and Tim for the insight into this.

0 Kudos
Steven_L_Intel1
Employee
1,438 Views
Oh, now I understand. The compiler does give a standards warning if you ask for it. We do currently have an issue where the results, when there is overlap, is unpredictable. It's on our list to look at but has low priority, as it is a user error.
0 Kudos
Reply