I'm not very familiar with valgrid, but all those reports seem not
relevant to me.
It seems to complain about all allocated arrays, which are not set to
zero globally. But this does NOT mean that one uses uninitialized
variables or assumes that the compiler sets them to zero.
PS: I don't have a variable "WS" in dergl.f
WS=0.0D0 in dergl.f
We can verify this also with ifort by setting -C in the flags, and in
fact doing so would result in an error in f7splt due to the mistake you
mentioned before.
So the only problem was in f7splt.f and that should be fixed as
previously mentioned.
(PS: I was wrong with my first reply that you need ISPLIT=15 (this
relates to an older version). The present if statement is intentional,
but still, no result from f7splt will be used (except for ISPLIT=15).
On 10/09/2013 01:18 PM, Pavel Ondračka wrote:
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
_______________________________________________
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
--
P.Blaha
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: bl...@theochem.tuwien.ac.at WWW:
http://info.tuwien.ac.at/theochem/
--------------------------------------------------------------------------
_______________________________________________
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
