Compile-time checking of uninitialized variables

[ereisch]

Hi all.  I'm extensively utilizing the "-check uninit" feature of the compiler, however with thousands of routines and seemingly infninte code paths (including some which are rarely executed), it would be much more helpful if the compiler had a compile-time check for use of uninitialized variables.  What I'm looking for is something similar to gcc's "-Wuninitialized" option.

Our program currently uses the -save and -zero compilation flags, but we are looking to reduce the memory footprint by switching over to -auto mode instead, so we need to review each routine to be sure that nothing depends on local variables being initialized to zero.  This would be much easier if the compiler would find these locations for us at build-time, since it would take us forever to try to execute every possible line of code to find them at runtime.

Thanks

[TimP]

While ifort has static analysis options for this purpose, I don't doubt that gfortran -O -Wuninitialized might give you useful results on a smaller effort.  You must remove options like -zero and -save for this purpose, and allow the compiler optimizer to kick in (e.g. -O).  Any findings, regardless of tool, would be valid for any compiler, and any tool may be expected to miss a few.

I think you can assure that everything uses -auto by RECURSIVE procedure declaration in case you don't want to depend on setting -auto or an option which implies it.

[Izaak_Beekman]

I will also point out the -check uninit can only find certain types of uninitialized variables, and in general is unreliable for finding all uninitialized variables. Additionally one can think of cases, say a variable declared in a module or a common block but initialized in code which is compiled in a separate object file (module procedure, external procedure, etc.) which the compiler could not reliably check for at compile time.

Finally I'm going to link to an interesting talk which explores this further and the authors have developed some tools to help with this. They may be able to share them with you if you get in touch with them directly. http://www.nas.nasa.gov/hecc/support/kb/news/Training-Materials-for-UnInit-Fix-your-code-Finding-computation-with-uninitialized-data-Now-Availabl_82.html

[Martyn_C_Intel]

We're aware of the interest in improved checking for uninitialized variables and have seen the presentation that you quote. Run-time checking has advantages for variables that are global or are passed as arguments, but as you and Tim point out, the current implementation of -check uninit is very restricted. I've added your comments to an existing feature request in an internal database. Stay tuned, we'll let you know if we are able to make any enhancements in this area.

[Izaak_Beekman]

Cool! Also, just to be clear, I was in no way criticizing Intel, I just wanted the OP to be aware of the limitations of check uninit so that he wasn't surprised if some uninitialized variables remained even though -check uninit came up empty handed. It would definitely be great to be able to catch all the uninitialized variables, even if it has to be at run time. The procedure outlined in the presentation I linked to above is quite involved.

[ereisch]

Thanks all.  Unfortunately, we are unable to use gfortran due to our syntax, and also use of directives like UNION, MAP, COMMON, etc, which that doesn't support.  We have already verified that all of our COMMON elements are initialized before use, but as I originally noted, our primary concern is we want to move away from "-save", however since we also utilize the "-zero" argument, we want to ensure that we don't encounter a problem with uninitialized local variables (which would have previously been initialized to zero at program start).

Also, Intel: there appears to be some extraneous info in the manpage for "ifort" regarding the "-zero" flag.  Version 12.0.4 has:

"-zero

-nozero

[...]

Use -save (Linux and Mac OS X) or [........]

Alternate Options:

None

This is an alternate option name for option -align recnbyte or /align:recnbyte. For more information, see option align."

I think the last line shouldn't be there; "-align recnbyte" doesn't seem as though it pertains at all to the behavior of the "-zero" flag.  If it does, then the manpage section for "-align" flag should probably be updated to cover this.

Thanks

[Martyn_C_Intel]

Thanks for pointing out that strange last sentence in the user guide. As you surmised, it shouldn't be there. I checked in the latest compiler version and confirmed that this has already been fixed.

You could also try -ftrapuv. I don't normally recommend this, because 0xCCCCCCCC, to which local variables are initialized, is itself a legal floating-point number, but it might help to recognize some cases that -check does not catch, e.g. when a variable is passed to another subroutine before it is accessed. -ftrapuv has side effects: it unmasks floating-point invalid exceptions, and changes the default optimization level to -O0. If you set the optimization level explicitly to -O2, you should turn on -fp-speculation safe (see http://software.intel.com/en-us/articles/dont-optimize-when-using-ftrapuv-for-uninitialized-variable-detection ).

[Martyn_C_Intel]

There aren't plans for compile time checking. However, run-time detection of uninitialized floating-point variables is greatly improved in the version 16.0 and later compilers. Please see the article and example at https://software.intel.com/articles/detection-of-uninitialized-floating-point-variables-in-intel-fortran .