Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
29282 Discussions

How do I identify non-SAVEd local variables in legacy code?

timmy-ray
Beginner
669 Views
I am working with an old program with a few hundred routines and have identified a couple instances of localarrays (of unknown size at compile time)thatare not SAVEd.The original programmer assumedthe array values would be retained across routine calls (andusing older compilers, the values ARE retainedacross calls). But compiled on IVF (using /Qsave), these arrays are losing one or two values (for some reason no matter how large the array is, it's always just one or two values that gets lost).

Just got done reading Steve Lionel's "Better SAVE than sorry!" article from 1999 so I know this is a rather common "gotcha" in FORTRAN programming and I know how to fix it going forward.

My problem is there are probably many instances of this type of error throughout the program and I'm wondering if anyone might know a fast way to identify such non-SAVEdlocal arrays of unknown size in subroutines that are called more than once? Can IVF do this type of error checking during compilation?
0 Kudos
5 Replies
bmchenry
New Contributor II
669 Views
Are you using the Diagnostic to 'Warn for undeclared Symbols'.
Fortran->Diag->Warn for Undelclared Symbols
Yes (/warn:declarations)

And when you say you are 'losing one or two variable' one must wonder 'how are you declaring these arrays?
since it is an older routine do you have 'local' arrays passed declared as ARRAY(1) vs ARRAY(*)?
and since you state 'of unknown size' are these dynamically allocated? (ot sure if it is old code that is the case?)

perhaps posting up some sample code (with the calling sequence/declaration and the subroutine and declarations, etc) will assist in understanding what is going on and how you are passing these routines and then why they may be not retaining all their values (or if it is maybe a debugger issue?).




0 Kudos
Steven_L_Intel1
Employee
669 Views
If you enable run-time uninitialized variable checking (/check:uninit), it should catch many of these, though it won't detect uninitialized scalars. Static Analysis, a feature of Intel Fortran Studio XE, catches these and other problems at build-time.
0 Kudos
timmy-ray
Beginner
669 Views
Much thanks for the quick responses. Here is some sample code to illustrate the problem. Here is the main program:

PROGRAM myprogram
INTEGER x,a
a = 1
READ (*,*) x
CALL sub1(x,a)
a = 2
CALL sub1(x,a)
END PROGRAM myprogram

And saved in a separate file I have the following subroutine.

SUBROUTINE sub1 (x,a)
DIMENSION myarray(x)

IF (a.EQ.1)
DO I=1,x
myarray(I) = 0.0
END DO
DO J = 1,x
myarray(J) = J*2.0
END DO
END IF

write (*,*) myarray

RETURN
---------------------------------------------------------
So 'myarray' is initialized at the first call to sub1. On the second call to sub1 I get garbage values forone or two entries in 'myarray', but the rest of the entries retain the correct value. Note that 'myarray' is local and not passed back and forth to the main program. Obviously, the program should not be expected to retain its values; I'm just hoping there is a quick way to identify arrays such as 'myarray' throughout the entire program.

Steve, now that I've hopefully explained the situation a little better, doyou think Intel Fortran Studio XE wouldidentify these issues?

Thanks again.

0 Kudos
bmchenry
New Contributor II
669 Views
if they are ALL like that declaration, using DIMENSION without any type, you can catch them using
Implicit NONE

Unfortunately you will probably need to look at each subroutines to determine the INTENT of the local arrays?
Since in that situation you describe the main routine wants the subroutine to create and retain an allocatable array which can/may vary on subsequent calls?

i doubt any compiler tool will be able to ascertain the INTENT of original programmer in setting up those routines as your example illustrates.
You will have to do some detective work to see what it was they were trying to do and update it to more efficient (and error condition checking) code.


0 Kudos
Steven_L_Intel1
Employee
669 Views
Unfortunately, no, Static Analysis doesn't catch this error. I think it should and I will ask the developers to look into it.
0 Kudos
Reply