Implicit save attribute in debug mode?

[Rob_v_]

Based on a flaw in my program, I began to wonder if the MVS2013 Debug mode is based on implicit save attributes of the var's, and if so, what compiler option is causing this behaviour?

The case:

After re-entering the subroutine, the var's value (not being reassigned a new value during execution since the condition was not met), turned out to be using the value of the previous call. This behaviour could only be demonstrated based on debug mode compiles. Release mode compiles reset the var's value to zero.

The Question:

Is this a WAD behaviour or a bug? I have always believed debug compiled code does implicit initialize the value if not explicit by user code (from the Microsoft Visual Studio environment), but in this case it is the other way around. Release compiled resets the var, debug compiled does not.

[Arjen_Markus]

I think that is purely coincidence. I have noticed too that the behaviour of a program may be different between Debug and Release mode or when running under the debugger if variables are not correctly initialised or do not have the SAVE attribute when the code does assume that. I have always thought that it had to with the different environment, not so much a deliberate difference in the SAVE attribute as such.

[mecej4]

Local variables without the SAVE attribute (or when the /Qsave compiler option is not specified) are allocated on the stack. If the local variable is used without initialization, the value received by your program is whatever junk was put into that stack location earlier. If you call the same subprogram a second time, and that memory was not written into between the two calls, the old value will be retained. This is the way in which stack-based programs work, and not because of anything specific that the compiler did.

In general, a program that uses uninitialized variables behaves in an "undefined" fashion. That undefined behavior can include your program running and yielding "correct" results, launching the invasion of Earth by Martians, etc. These things happen for external reasons, and you should not attribute them to the Fortran compilation system.

[Rob_v_]

OK, so the explanantion of the stack explains why the debug mode compiled version does not suffer from the flaw, but why isn't the Release mode? Both versions walk through the code in the same way, don't they?

[Lorri_M_Intel]

Not necessarily.   Some optimizations will cause procedures to be inlined - that is, all their code is "copied" into the caller, and then other optimizations may apply. 

Stack layout in general can vary between programs built with debug and ones built optimized.

I agree, it's "interesting" to debug these things.  

                --Lorri