Re: [Valgrind-users] Uninitialized variable detection in Fortran

[John R. <jr...@bi...>]

On 10/24/24, Daniel Feenberg via Valgrind-users wrote:
> Is there an option or other way to ask 
> Valgrind to be a little stricter, and flag the use of an unidentified 
> variable in an assignment, not just in a condition?

No.  You (and many other new users) have stumbled onto *the* colossal 
deficiency of valgrind.  Namely: despite the supreme importance of
the *OPTION* to request that valgrind behave this way, valgrind cannot.
"If a tree falls in the forest but there is no one to hear it fall,
then does it make a sound?"  Memcheck says, "No, there is no sound."
Or perhaps Memcheck would say, "There are so many trees which fall
that very probably you will give up trying to identify the one that
matters to you."

Your best bet is to find a compiler option which generates code
to check for any use of an uninit variable, and a runtime support
library that is compiled with such checking.  For the sake of
efficiency, then such a check must be heuristic, but in practice
it can be very good.  In gcc or clang for C or C++, then the
compiler option   -fsanitize=undefined   (or related) can be
effective in many cases.

Because you are working in Fortran, then having the compiler and
runtime system initialize everything to the bit pattern for some
flavor of denorm or NaN (and check for it!) might work, even
for integer variables.  A 32-bit pattern flavored like
    (0xFFF8 << 16) | (0xFFFF & (address >> 3)) ,
repeated to fill all otherwise-uninit space, comes to mind.
[Some 50+ years ago the Michigan Terminal System for IBM
System 360 model 67 initialized all bytes to 0x80 (or 0x81),
and this was quite helpful in identifying uninits.]

Then there is the problem of uninit local (on-stack) variables.
The gcc option  -mfentry  generates extra code to call a subroutine
immediately upon entry to every function, and with a little hacking
it is possible to identify the sizeof the local frame, then act.
Unfortunately, zeroing the entire local stack frame (or setting
the bytes to another known value) immediately upon allocation
tends to be very expensive: a factor of 2X, 3X, or more
in total run time.

--