Re: [Valgrind-users] Uninitialized values with fortran

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

On 07/04/2013 12:35 PM, Norman Goldstein wrote:
> I am using valgrind-3.8.1 on Fedora 18, 32 bit x86, and
> am linking fortran libraries to my main C++ code.
> It seems that when malloc'd values end up being initialized
> in fortran code, that this is still tagged by valgrind as
> uninitialized data.  I have worked around (avoided) this problem
> by initializing new memory to 0.  I have seen related posts on the
> net, but am not sure if this is already flagged as a bug, or if I
> am not using valgrind correctly with fortran.
>

Here is an update to the problem I am experiencing.

While preparing a simplified build & source code example, I found
that my link line was causing the problem, but I do not understand
why.  Here is a stylized link line that results in an executable with
the described problem.

gcc tsvd3.o -o tsvd3 -l:/libHigh.so -l:/libblasB.a -l:/libblas.so 
-l:/liblapack.so

I am using  -l:  rather than  -l  because I was using debug versions
of  libraries in different locations, but I was not able to get the
debug-info packages to work in the intended seamless way.

Removing either the High or blasB library ( or both) from the link
line results in no errors being reported by valgrind.
This raises the following questions:

-- The High library is not being referenced by the tsvd3 executable, so
why  does the map file show that the blasB library is being used to
resolve references in the High library?

-- In the above link line, the lapack library comes at the end.  I thought
that this would cause the lapack library not to see the blas symbols
earlier in the link line i.e. the linker should be complaining about
unresolved symbols.  Why is the linker not so complaining?

-- Why is the linker not complaining about doubly defined symbols
in the  blasB.a  and  blas.so  libraries?

Of course, how does all this trick valgrind into flagging uninitialized
memory locations?  The output of the svd3 program is correct with
both versions of the tsvd3 executable.