'The variable is being used without being defined' error

[fourreal]

Hi. I m fairly new to Intel FORTRAN. My team is maintaining a FORTRAN library (.lib) project that has been in production for years. When we converted the Visual Studio project to 2010, from 2008, we upgraded to the Visual Fortran Composer XE 2011 compiler. After that, when we compiled the FORTRAN code with the new compiler, we started experiencing a runtime error that says, "The variable varname is being used without being defined." There is no compile-time error, and the runtimeerror does notoccur everytime the code is executed.When an error does occur, it is always within the same subroutine, but it can be any variable within that subroutine.
I can fix the problem by declaring the offending variable with the SAVE attribute, like this:

integer, SAVE:: i

The problem is that this is a local variable and should not need to be persisted from one invocation of the subroutine toanother. Has anyone else seen this problem? Is there a compiler setting I am missing?

Thanks for your help!

[mecej4]

First of all, it is a little unusual to compile a mature library with checking enabled for undefined variable references.

Using SAVE to make the error go away is wrong. So would using a compiler option to make error messages go away. In such situations, there is an error and that error may sometimes affect the output results. You should find out why your subroutine is using the value of the variable i before it has been defined.

[Steven_L_Intel1]

I agree with everything mecej4 says, but will comment that run-tine uninitialized variable checking was added a few versions back. It is the default in a debug configuration.

What worries me is that you say that the error does not occur every time you run the program. This suggests an even worse problem exists - data corruption. The run-time checking uses a separate flag that gets set when a local, scalar variable and then gets tested when such a variable is referenced. If that flag is getting corrupted, you could get this effect. Adding SAVE will disable the check, but memory corruption may still be occurring.

It would be interesting to see if removing the SAVE and adding a statement to initialize the variable to zero (or whatever is appropriate) at the beginning of the routine makes the problem go away. My theory is that if it is data corruption, such an assignment would not change the behavior.

[fourreal]

Thanks! I guess I am confused what is meant by using the variable before it has been defined. Doesn't the variable declaration define the variable?

[fourreal]

Thanks! I have already tried initializing the variable, and that does not stop the error from occuring. Although the error does not occur everytime the subroutine is executed, it is consistent in the sense that it responds to input the same way everytime. In other words, if I run the program against the same input file, I get the same results. I can run it against another input file that executes the same code, but does not cause the same error.

If I understand you correctly, you are saying that we could, for example, have an array somewhere that is overflowing its bounds, and corrupting adjacent memory?

[mecej4 · Accepted solution]

Fortran terminology can be confusing to users familiar with other languages. "Defined" means that the variable has been given a valid value by executing an assignment, reading from a file or device, or otherwise. In Fortran, declaration and definition are distinct.

In current versions of Fortran, in contrast with CVF, local variables are not saved unless the SAVE attribute is specified. Therefore, a variable in a subprogram can become undefined upon a second or subsequent call even if a value was assigned to it during the first call.

Array overrun is a different kind of error.

If possible, please post a complete example that exhibits the same kind of problems when run.

[fourreal]

Thanks for your help. I am currently not in a position to post the specific code, since it is the main routine in some company-protected code, and I would need to include a large portion of code in order to give you enough to examine. I think the two of you have given me enough information to point me in the right direction. I will repost if needed.

Again, thanks! You have both been quite helpful.