repeat initialization of local variable

[jayb]

I found a forum topic similar to this, from 2009.  Notwithstanding the Fortran standard: ""A variable, or part of a variable, shall not be explicitly initialized more than once in a program", there is a method to the following madness.

This legacy program defined an array for which the "default" value was 0, and some elements were then assigned non-zero values.  A trivial example:

integer a(2,2,2)
data a/8*0/
data a(2,2,2)/1/

The second data statement is ignored.  My colleague commented out the first data statement, and it "works".  But it "works" only because Intel Fortran initializes values to 0.

Is there a compiler switch that will tolerate multiple assignment or data statements?  This is a large application, and finding all of these non-standard instances will be tricky.

Jay

[jayb]

Careless wording on my part:  Is there a compiler switch that will allow multiple *initializations* of the same variable?  I said "assignment", and of course, we can assign as many times as we want.  

Jay

[TimP]

You depend on the implied SAVE with data.

why not initialize the entire array in a single data (if you like f77 so much) ?

[Steven_L_Intel1]

It is not correct to say that Intel Fortran initializes the variable to zero. If you get that, it's accidental and you should not depend on it.

Intel Fortran tolerates the multiple initializations, but the results are unpredictable. You will get a standards warning if you do this. You could replace the two DATA statements with:

data a/7*3,1/

I suggest compiling with -std to find the places you need to change.

[jayb]

Steve,

I will try to find all instances of this non-standard use with the technique that you recommended -- though I think I'll find a million other non-standard usages!  I was also thinking of a well-patterned grep -- though I can certainly grep the compiler output.

The presumption about initialization to zero was a red herring.  The problem was repeat initialization, which the original authors of the code were not aware of as a violation of standards.

Note to Tim:  I do not "like" f77 "so much".  Some of my past posts explain my role on this project, its history, and why I have recommended Intel Fortran over g77, for the present and a hoped-for future.

Jay

[TimP]

g77 hasn't been maintained since gfortran came out, and the latter supports all Fortran standards well, as does ifort.  I certainly wouldn't use g77 just because it fails to flag such usage, even if it weren't more difficult to install nowadays.  You would never know when a compiler accepted multiple DATA statements referring to the same array how it would be interpreted (maybe only one of them has effect), which may be one of the reasons for requiring (since 25 years ago!) the option to flag the violation.

[jayb]

I ain't goin' back to g77.  But I might have to convince someone else that we ain't. :--)

There is, thankfully, only one other instance in the application of warning #6527:  This object has been initialized more than once.

According to my colleague, "Data statements are preferred over assignment statements because values are set at compile time rather than run time."  I disagree.  Ultimately, the value is assigned at run time.  And with all of our local variables being saved, it is assigned once.

Is there *any* validity to his statement?

Jay

[Steven_L_Intel1]

No, he is correct. With DATA, the compiler initializes the values in the storage it lays out for the linker. 

[jayb]

What advantages does this provide?  I ask because I am recommending that we leave in the first DATA statement that initializes everything to 0, and then assign the other values via assignment statements.

j

[jimdempseyatthecove]

And implicit in Steve's post #8. If multiple sources initialize the same data, this initialization is not executable code, rather it is in the .obj (.o) file which the linker users in constructing the executable. With multiple initialization, it then becomes a case of last object file linked wins. You may then run into a nasty surprise as you make changes to your program.

Jim Dempsey

[Steven_L_Intel1]

Jim describes a different issue - when multiple program units initialize the same data (in COMMON, usually). Windows simply doesn't allow that - the linker will complain.

Here, we have two DATA statements in the same program unit initializing the same location. That's not legal and the results are unpredictable.