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)
