Depending on the size of the code and the number of variables used in it, scanning the code for initializations can take an unacceptably long time. If so, use a compiler that provides facilities for trapping variables that are used before being initialized.
integer :: i
real :: x(2)
end program main
compiling on WSL2 with the gfortran command above gives at run time
Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.
Backtrace for this error:
#0 0x7fdda118d700 in ???
#1 0x7fdda118c8a5 in ???
#2 0x7fdda0fc020f in ???
#3 0x55a02f2b2287 in MAIN__
#4 0x55a02f2b2302 in main
Floating point exception
The NAG compiler (nagfor) has an option -C=undefined that does extensive run-time checking for uses of uninitialized variables. It has a couple of caveats (no inter-operating with C and no coarray features), and a few bugs I’ve been reporting, but I’ve found it quite helpful in finding some subtle bugs even beyond your run-of-the-mill oops.
You might want to add -g so you get symbol names on tracebacks, and mention
-Wuninitialized on gfortran, particularly making note that -Wuninitialized and -finit-real=snan are mutually exclusive (well, actually I think using -finit-real=snan defines variables so -Wuninitialized has nothing left to find). A lot of users of gfortran just do “man gfortran” or “gfortran --help” and often are not aware of the many other options available, many of which are displayed with “gfortran -v --help”, so it is easy to miss options llike -Wuninitialized, as it does not show with a simple “gfortran --help”. When we used to make local compiler changes we always set negative indefinite as the default where available, and use to create a universal config file for the Intel compiler to help detect uninitialized variables; particularly since we had a number of codes that had originated on VAX/VMS where (if I remember correctly) the Fortran compiler initialized everything to zero; so I am all for users using those options during development; but if you have large arrays there can be a significant cost to initializing them that you might want to avoid in a production release.
A footnote. There seems to be a regresssion on a bug reported long ago with -Wuninitialized and I/O. If you do a “gfortran -Wuninitialized” on
end program testit
it produces a warning, but
end program testit
produces no warning. Thought that was fixed a VERY long time ago.
That one covers it. The bug I was referring to is not that incorrect executables are generated, but that the -Wuninitialized option does not warn about uninitialized variables that appear in I/O statements; which your link reports. Thanks for the link; that saves me from searching for/reporting the same bug.