Re: [Wien] Possible bugs from use of uninitialized variables

2013-10-14 Thread Laurence Marks
I was travelling so did not have access to the source. You are correct and it is technically a bug which apparently neither -ftrapuv nor gfortran picked up. I have added ROKMIX = 0.D0 ; ROKSC = 0.D0 ; ROKVL = 0.D0 ; ROKOLD = 0.D0 KVECVL = 0 ; KVECSC = 0 ; KVCOLD =

Re: [Wien] Possible bugs from use of uninitialized variables

2013-10-14 Thread Pavel Ondračka
Laurence Marks píše v Po 14. 10. 2013 v 08:46 -0500: I was travelling so did not have access to the source. You are correct and it is technically a bug which apparently neither -ftrapuv nor gfortran picked up. I have added ROKMIX = 0.D0 ; ROKSC = 0.D0 ; ROKVL = 0.D0 ; ROKOLD

Re: [Wien] Possible bugs from use of uninitialized variables

2013-10-14 Thread Laurence Marks
Thanks. The line PM1=min(1.D0,PM1) should be commented out, it is a legacy of when I moved some code around and does nothing. N.B., A=0.D0 is the same as A=(0.D0,0.D0) -- there is an implicit conversion at least for ifort and gfortran (and I believe always), e.g. test complex a

Re: [Wien] Possible bugs from use of uninitialized variables

2013-10-11 Thread Peter Blaha
It could be that IBMs xlf compiler does speculative execution. (I seem to remember, that I read that long time ago), causing these problems. What we often do is something like allocate (A(1000)) do i=1,N (where N is less than 1000 !!!) a(i)=b(i) ... and later we use do i=1,N something =

Re: [Wien] Possible bugs from use of uninitialized variables

2013-10-10 Thread Peter Blaha
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

Re: [Wien] Possible bugs from use of uninitialized variables

2013-10-10 Thread Pavel Ondračka
Peter Blaha píše v Čt 10. 10. 2013 v 12:22 +0200: 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

Re: [Wien] Possible bugs from use of uninitialized variables

2013-10-10 Thread Laurence Marks
Sorry, but I agree with Peter I am 99.9% certain that this is not a bug in the mixer. The way to test this is (with ifort) to use -ftrapuv ; the arrays are not set in mixer.F but elsewhere within some complicated subroutines. This flag forces a fault if an undefined variable is used.

Re: [Wien] Possible bugs from use of uninitialized variables

2013-10-10 Thread Pavel Ondračka
Laurence Marks píše v Čt 10. 10. 2013 v 09:40 -0500: Sorry, but I agree with Peter I am 99.9% certain that this is not a bug in the mixer. The way to test this is (with ifort) to use -ftrapuv ; That is not true. According to ifort docs: -ftrapuv The option sets any uninitialized local

[Wien] Possible bugs from use of uninitialized variables

2013-10-09 Thread 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