[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

["burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827

--- Comment #14 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-09-30 13:48:15 UTC ---
(In reply to comment #13)
> But I have run valgrind now. It was the first time, so I don't understand the
> result. Is it somehow the fault of my hardware/OS? Here is the output:

> valgrind --leak-check=full /opt/gcc-trunk/bin/gfortran -ffree-form
> -ffree-line-length-0 -I. -L.  -c common.f03 -o common.o

You did not do what I wrote. I wrote:

  valgrind `gfortran -v 2>&1 <other commandline options> | grep f951`

you did

  valgrind gfortran ...

Thus you are testing a completely different program! "gcc", "gfortran" etc. are
only "drivers" which call the actual compiler, which is named "cc1", "f951",
... (That is also the reason why C programs can be compiled with "gfortran
foo.c" as this then calls "cc1" rather than "f951".)

To find out the command line arguments to the real compiler 'f951', one can
compile using the option "-v" which shows the parts which are called. The line
of interest is the one which is calling "f951".


> ==31832== 1 bytes in 1 blocks are definitely lost in loss record 2 of 70   
> ==31832== 4 bytes in 1 blocks are possibly lost in loss record 4 of 
etc.

That only tells that some memory has not been freed and is possibly/definitely
lost. That should not happen, but usually just means that gfortran uses more
memory as it should (and which is then only freed by the operating system if
one returns). -- In some cases  (cf. e.g. Bug 45793) those indicate a true
error which have to be fixed. (But one usually should also try to fix normal
memory issues.)

I was more looking for warnings such as:
  ==27731== Invalid read of size 8
which indicate that there is an error (e.g. uninitialized variable or pointer).