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).
