Initialization of local variables in subroutines

[grosguth]

I am porting a large application from IBM MVS to IBM PC using the Intel FORTRAN compiler in batch mode, alsoIntel FORTRAN compiler forwindows mode. On the IBM MVS initialized local variable values within a subroutine are preserved upon subsequent calls to that subroutine, and on the IBM PC initialized local variable values are not preserved and are set to zero upon subsequent calls to that subroutine. Sample illustrative code is listed below. My question is the following: Is there a run time option to save the initialized local variable values for subsequent calls to a subroutine? The local varibles that need their values preserved should probably be placed into a COMMON statement.

Geoff Grosguth

 PROGRAM TEST
C 1 2 3 4 5 6 7
C23456789012345678901234567890123456789012345678901234567890123456789012
C TEST TO SEE IF LOCAL VARIABLES WITHIN A SUBROUTINE ARE INITIALIZED
C EACH TIME THE SUBROUTINE IS CALLED WHEN USING THE INTEL FORTRAN 
C COMPILER
 INTEGER*4 I
 INTEGER*4 GCCMD
 COMMON /FLAG/ GCCMD
 OPEN (UNIT=6) 
C
 CALL CALC()
C
 STOP
 END

 SUBROUTINE CALC()
 INTEGER*4 NUM
 INTEGER*4 GCCMD
 COMMON /FLAG/ GCCMD
C
 GCCMD = 1
 CALL CALC2()
C
 GCCMD = 2
 DO 10 I = 1, 10
 CALL CALC2()
 10 CONTINUE
C
 RETURN
 END

 SUBROUTINE CALC2()
 INTEGER*4 NUM
 INTEGER*4 GCCMD
 COMMON /FLAG/ GCCMD
C
 IF (GCCMD .EQ. 1) THEN
 NUM = 89
 WRITE(UNIT=6,FMT='(A,I5)') ' NUM21=', NUM
 ELSEIF (GCCMD .EQ. 2) THEN 
 WRITE(UNIT=6,FMT='(A,I5)') ' NUM22=', NUM
 ENDIF
C
 RETURN
 END

[Steven_L_Intel1]

Local variables that need to be preserved should be named in a SAVE statement. You can use the /Qsave command line option (in Visual Studio, this is under Fortran..Data..Default storage for local variables - All variables SAVE, but I consider this a poor substitute for correcting the bug in the code that failed to properly SAVE local variables.

[grg99]

I don't quite follow your problem.

Any variable you initialize with a DATA statement, or any variable in COMMON, or any variable explicitly mentioned in a SAVE statement, it will be saved from call to call.


Any other variable is liable to lose its value, as per the standard I think.

Now IVF tends to lean toward making variables AUTOMATIC, which saves on memory but tosses variable values. Such is the price of progress.

So as you hinted, you can add SAVE statements, or put the variables in COMMON, or use the compiler option to force static variables as a temprary resort.

[Steven_L_Intel1]

Correction - COMMON variables, if you want to be standard conforming, need SAVE. Most implementations don't require this, but if the common isn't always "active" in the call chain, the standard allows the values to become undefined. Same with module variables.

[TimP]

Under the f77 standard, IBM MVS Fortran took advantage of the option to not automatically SAVE variables defined in DATA.In fact, such variables would be reset automatically to the DATA values. So, even back then, it was necessary to use SAVE on all local variables where your program requires it according to the standard. Only with extreme luck would an incorrect program have run the same on IBM MVS Fortran and on compilers with default SAVE. I can't see how a newer IBM Fortran would have eliminated the requirement for correct use of SAVE.

So, in this situation, the recommendation to avoid relying on compile flags for default SAVE would have even more force than usual.

Not to mention the requirement for an optimizing or parallelizing compiler to detect weird dependencies arising from standard violations, and disable optimizations accordingly.

[Steven_L_Intel1]

Note that in Fortran 90 and later, variables initialized with DATA (and in most cases initialization in the declaration) have the SAVE attribute implied by the language standard.

[g_f_thomas]

I've seen initializations done as in

:

real x

:

x = x ! first reference to x

Is this OK andhow does a compilerhandle it? How about x=sin(x)? Is this guaranteed toinitialize x to 0 (or +/- pi, 2pi, etc ) or what?

[Jugoslav_Dujic]

No, it does nothing of a sort. The X is still uninitialized.

Actually, I've seen the "x=x" trick only in the contexts where x is a dummy argument required by the environment (e.g. of a callback routine) but the routine does not want to use it. In that case, "x=x" is a nice try to stop compiler warning about "unused variable" (which doesn't work in e.g. release version with some IVF versions, where the compiler first optimizes out "x=x" and then proceeds to complain about the unused variable ). I don't know the current status of such "feature" in IVF.

[g_f_thomas]

Ah, wherever I saw x = x had nothing to do with initializing. Good, I wouldn't do it either. It's use to not use is cute.

Thanks

[jimdempseyatthecove]

G,

x = x may be a convient spot to place a break point in the Debug configuration, easy to eyeball in the source file, gets optimized out in the Release version. No need for "uggly" conditional compilation directives. Personally I prefer to use the preprocessor and #define statements to "sparkle" the code with diagnostics.

Jim Dempsey