http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589
--- Comment #10 from Rich Townsend <townsend at astro dot wisc.edu> --- (In reply to Dominique d'Humieres from comment #9) > > So it's actually a regression. > > Marking as a regression, even if I am not fully convinced. Further support from valgrind on x86_64-pc-linux-gnu: ==28614== HEAP SUMMARY: ==28614== in use at exit: 40,000,000 bytes in 10 blocks ==28614== total heap usage: 57 allocs, 47 frees, 40,004,263 bytes allocated ==28614== ==28614== 8,000,000 bytes in 2 blocks are possibly lost in loss record 1 of 2 ==28614== at 0x4C2C66D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==28614== by 0x400E7F: MAIN__ (in /home/townsend/test_leak) ==28614== by 0x401153: main (in /home/townsend/test_leak) ==28614== ==28614== 32,000,000 bytes in 8 blocks are definitely lost in loss record 2 of 2 ==28614== at 0x4C2C66D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==28614== by 0x400E7F: MAIN__ (in /home/townsend/test_leak) ==28614== by 0x401153: main (in /home/townsend/test_leak) ==28614== ==28614== LEAK SUMMARY: ==28614== definitely lost: 32,000,000 bytes in 8 blocks ==28614== indirectly lost: 0 bytes in 0 blocks ==28614== possibly lost: 8,000,000 bytes in 2 blocks ==28614== still reachable: 0 bytes in 0 blocks ==28614== suppressed: 0 bytes in 0 blocks townsend@chell ~ $ gfortran -v Using built-in specs. COLLECT_GCC=/home/townsend/madsdk/bin/gfortran.exec COLLECT_LTO_WRAPPER=/home/townsend/madsdk/bin/../libexec/gcc/x86_64-pc-linux-gnu/4.9.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure CC=gcc --build=x86_64-pc-linux-gnu --prefix=/root/madsdk --with-gmp=/root/madsdk --with-mpfr=/root/madsdk --with-mpc=/root/madsdk --enable-languages=c,c++,fortran --disable-multilib --disable-nls --disable-libsanitizer Thread model: posix gcc version 4.9.0 20131223 (experimental) (GCC)
