Created attachment 30520 [details] Example program I'm experiencing a problem with: Using built-in specs. COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/lto-wrapper Target: x86_64-apple-darwin11.4.2 Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0' --build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk --with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk --with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.9.0 20130404 (experimental) (GCC) The attached example program demonstrates the problem. When f is deallocated, it seems that f%x is not getting deallocated, causing the memory footprint of the program (as reported by the ps syscall) to grow without bound.
On x86_64-unknown-linux-gnu, I can confirm the problem with 4.7 and 4.8. However, the leak seems to be gone in the latest trunk version: gcc version 4.9.0 20130718 (experimental) [trunk revision 201038] (GCC)
(In reply to janus from comment #1) > On x86_64-unknown-linux-gnu, I can confirm the problem with 4.7 and 4.8. > However, the leak seems to be gone in the latest trunk version: Which is not very surprising as the finalization code should also take care of this. See PR37336. I believe r199643 was the enabling commit.
(In reply to Tobias Burnus from comment #2) > (In reply to janus from comment #1) > > On x86_64-unknown-linux-gnu, I can confirm the problem with 4.7 and 4.8. > > However, the leak seems to be gone in the latest trunk version: > > Which is not very surprising as the finalization code should also take care > of this. See PR37336. I believe r199643 was the enabling commit. Right. Although the test case does not actually deal with finalization, but rather involves polymorphic deallocation (i.e. PR 46321). Anyway, closing as fixed.