[Wien] Possible bugs from use of uninitialized variables

[Pavel Ondračka]

Dear WIEN2k list,

so after I found out, that ifort by default initializes all variables to
0, I got quite paranoid, since this could hide bugs and easily lead to
changes in behavior with compilers that doesn't do that. So I fired up
valgrind, to see if there are some other occurrences.

This is what I found in in the main cycle programs, however I'm not a
valgrind expert so I'm hopping someone familiar with the code might have
a look. Basically I could just set all the uninitialized variables to 0
manually to mimic ifort behavior, however it would be nice if someone
familiar with the code could just check if initialization to 0 is indeed
the intended behavior?  

Lapw2: Here we got a lot of:

==9250== Conditional jump or move depends on uninitialised value(s)
==9250==    at 0x30DE027230: cexp (s_cexp.c:57)
==9250==    by 0x471758: l2main_ (l2main_tmp_.F:817)
==9250==    by 0x48A1AD: MAIN__ (lapw2_tmp_.F:605)
==9250==    by 0x48AF6F: main (lapw2_tmp_.F:5)
==9250==  Uninitialised value was created by a heap allocation
==9250==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==9250==    by 0x411215: __xa3_MOD_init_xa3 (modules_tmp_.F:496)
==9250==    by 0x46F9C4: l2main_ (l2main_tmp_.F:642)
==9250==    by 0x48A1AD: MAIN__ (lapw2_tmp_.F:605)
==9250==    by 0x48AF6F: main (lapw2_tmp_.F:5)

and

==9250== Conditional jump or move depends on uninitialised value(s)
==9250==    at 0x4AFAB0: ylm_ (ylm.f:190)
==9250==    by 0x4714EA: l2main_ (l2main_tmp_.F:812)
==9250==    by 0x48A1AD: MAIN__ (lapw2_tmp_.F:605)
==9250==    by 0x48AF6F: main (lapw2_tmp_.F:5)
==9250==  Uninitialised value was created by a heap allocation
==9250==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==9250==    by 0x411215: __xa3_MOD_init_xa3 (modules_tmp_.F:496)
==9250==    by 0x46F9C4: l2main_ (l2main_tmp_.F:642)
==9250==    by 0x48A1AD: MAIN__ (lapw2_tmp_.F:605)
==9250==    by 0x48AF6F: main (lapw2_tmp_.F:5)

Caused by uninitialized values of kx, ky and kx, that later propagate
all over.
Can be fixed by adding
kx = 0
ky = 0
kz = 0
to init_xa3 subroutine

Lapw0:

==9849== Use of uninitialised value of size 8
==9849==    at 0x30DE012FC1: __ieee754_log_sse2 (e_log.c:159)
==9849==    by 0x45CF5F: corpbe_ (pbe1.f:337)
==9849==    by 0x45F7BE: pbe2_ (pbe2.f:141)
==9849==    by 0x480C09: vxclm2_ (vxclm2.f:154)
==9849==    by 0x495F34: xcpot1_ (xcpot1.f:382)
==9849==    by 0x44A506: MAIN__ (lapw0.F:1875)
==9849==    by 0x455122: main (lapw0.F:10)
==9849==  Uninitialised value was created by a heap allocation
==9849==    at 0xD39887C: malloc (vg_replace_malloc.c:270)
==9849==    by 0x40C8DB: dergl_spline_ (dergl.f:134)
==9849==    by 0x40BDB2: dergl_ (dergl.f:32)
==9849==    by 0x40E42C: drho_ (drho.f:38)
==9849==    by 0x493AF4: xcpot1_ (xcpot1.f:195)
==9849==    by 0x44A506: MAIN__ (lapw0.F:1875)
==9849==    by 0x455122: main (lapw0.F:10)

Can be fixed by initializing
WS=0.0D0 in dergl.f


Mixer:

==4495== Conditional jump or move depends on uninitialised value(s)
==4495==    at 0x41F4E3: MAIN__ (mixer.F:1504)
==4495==    by 0x424FB5: main (mixer.F:23)
==4495==  Uninitialised value was created by a heap allocation
==4495==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==4495==    by 0x4160CE: MAIN__ (mixer.F:851)
==4495==    by 0x424FB5: main (mixer.F:23)

uninitialized variable is ROKMIX (well at least the imaginary part)
and we later do stuff like this:
mixer.F:1504  if(abs(ROKMIX(J,I)).gt.1D-12)then
can also be fixed by initializing to 0 right after allocation
(mixer.F:853)
ROKMIX = (0.0D0, 0.0D0)

And another one in mixer:
==10137== Conditional jump or move depends on uninitialised value(s)
==10137==    at 0x45386D: limitdmix8n_ (LimitDMIX8n.F:135)
==10137==    by 0x43B2C2: qmix8_ (qmix8.F:631)
==10137==    by 0x41D0BB: MAIN__ (mixer.F:1313)
==10137==    by 0x42502B: main (mixer.F:23)
==10137==  Uninitialised value was created by a stack allocation
==10137==    at 0x433A37: qmix8_ (qmix8.F:1)

Sadly here I was not able to track down the issue as the function
prototype at line qmix8.F:1 where the uninitialised value was tracked to
contains over 20 parameters.


lapw1: just a small memory leak I found while running in valgrind,
probably harmless

==11953== 240,000 bytes in 1 blocks are definitely lost in loss record
71 of 72
==11953==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==11953==    by 0x453256: nn_ (nn.f:42)
==11953==    by 0x438708: inilpw_ (inilpw.f:405)
==11953==    by 0x43AC3F: MAIN__ (lapw1_tmp_.F:42)
==11953==    by 0x43B322: main (lapw1_tmp_.F:2)

We are leaking memory in nn.f
Can probably be fixed by calling 
deallocate( NR,nnat,dists,pnn ) at line nn.f:145 (before RETURN
statement)

Best regards
Pavel Ondračka