Ramdom intialization of logical variables

[mats_goldberg]

I recently upgraded from an old version of Compaq Fortran compiler to Intel Visual Fortran Compiler XE 12.0. With this versionI experiece that logical variables that are not explicitly initialized are randomly initialized to either tru or false, with no systematic pattern behind it.

This is a printout from the command prompt from writing the value of 5 declared but not initializes logical variables before any value is asigned to any of them:

Bool1 = F

Bool2 = F

Bool3 = F

Bool4 = F

Bool5 = T


This is when I run in debug mode. In the test code I use they are all initialized to "F" in release mode, however in the program where I first discovered the issue that is not the case, the variables are randomly initialized in release mode aswell.

I have tried to switch on and off the "Initialize local saved scalars to zero" option(/Qzero) and it does not have an impact on the outcome.

How can I make sure all variables are initialized to zero if not explicitly initialize?


Thanks
Mats

[Arjen_Markus]

I do not know if there is a compiler switch for this, but you should be aware that the Fortran standard
does not guarantee that variables are initialised to any predefined value. If your program relies on it,
by way of a compiler switch or implicit behaviour of the compiler, then it is bound to that compiler.

In other words: always initialise/explicitly assign values toyour variables, before using them.

Regards,

Arjen

[mats_goldberg]

Thanks for the tip Arjen.

I actually found an answer that seems to work in this thread:

http://software.intel.com/en-us/forums/showthread.php?t=79426&o=a&s=lr

In short, combine the /Qzero optionwith the /Qsave option.


Cheers
Mats

[mecej4]

There are more ways in which CVF and IFort differ, and you should read Migrating from CVF before attempting a conversion unless you know all the issues.

For Logical variables, there is a tricky question that the Fortran Standard does not answer: What is the bit pattern that represents .TRUE. ? Is it a unique pattern? In old Fortran code where you could have EQUIVALENCE specified between LOGICAL and non-LOGICAL variables, how do you initialize both views of the variable properly?

Fortran 2xxx allows you to specify default initialization for user-defined types.

Given all these complications, I think that you should decide to make your code honest and initialize variables before using them, unless you can be sure that the program execution is unaffected by random initialization.

[Steven_L_Intel1]

I agree with mecej4. Neither CVF nor Intel Fortran give you default initialization of variables. What you are more likely seeing is a result of the Intel compiler choosing to allocate most scalar variables on the stack rather than in static memory.

Do not use switches to compensate for incorrect code. Add the explicit initialization to your source, either with initialization expressions at the declaration, DATA, or explicit assignments.

[jarvusluntatintel]

When I think about the hours and hours I have lost tracking down logical flags, logical flags that seem to be intialized to false 99% of the time, or logical flags that were initialized to false in debug mode but not release mode (and I have to start adding write statements all over my code like I am still programming back in the 80's), is there any good reason that the Fortran standard couldn't have decided, I don't know, maybe thirty years or so ago, to initialize flags to false and variables to zero?

Or, more important,any chance of this happening sometime in the next thirty years???

[TimP]

The trend away from all arrays with SAVE status, regardless of specification, began over 20 years ago, and seems only likely to accelerate with the increasing requirement for multiple levels of parallelization. The SAVE facility has been in all compilers for 25 years; use it, if you need it, but recognize how it conflicts with parallel optimizations.
If you do that, it's still not desirable to depend on /Qzero, but it has a chance of working.
If you had issues with undefined values, maybe you could have saved some effort simply by adding loops to initialize them, or, when applicable, DATA (which has implied SAVE, for all compilers, since 20 years ago).

[mecej4]

is there any good reason that the Fortran standard couldn't have decided (..) to initialize flags to false and variables to zero?

Yes (speaking for myself). It is the programmer's responsibility to initialize variables.

Zero and .FALSE. are not always appropriate initial values (examples: real:: SPEED_OF_LIGHT and logical::DIVERGED). What is a reasonable initial value for character variables? Arrays? User defined types?

How would automatic initialization work if that odious declaration, EQUIVALENCE, is used to overlay different types on the same memory block?

Automatic initialization to an inappropriate value makes it harder to debug code.

That said, I have no objection to the compiler allowing the user to specify default initial values for each intrinsic type. In fact, some compilers allow the user to set bit patterns for integer, real, ... types that are to be treated as 'UNDEFINED' at run-time. Even then, one would hope that the programmer would note that the use of options such as /Qzero may be equivalent to sweeping dirt under the carpet.

I have experienced the terrible effects of zero-initialization: bugs going undetected in software used by thousands of people over decades.

Even when it works correctly, zero initialization can be undesirable. Many old Fortran programs declared

COMMON A(10000000)

and parcelled out pieces of A in a rudimentary memory management scheme. Requiring zero initialization can change the size of the EXE file from 8 kb to 80 Mb, since the .DATA section is now huge.