http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Memory leak with assignment |[4.6/4.7 Regression] Memory
|of extended derived types |leak with assignment of
| |extended derived types
--- Comment #4 from janus at gcc dot gnu.org 2011-06-19 17:52:35 UTC ---
(In reply to comment #3)
> I see (with valgrind on x86_64-apple-darwin10) the memory leak for gcc 4.6
> (revision 166102) and trunk, but not for gcc 4.5.2 or 4.6 revision 162456.
Ok, I can also reproduce the memory leak with gfortran 4.7 on
x86_64-unknown-linux-gnu, which means that it is a regression.
Here is a reduced test case:
program evolve_aflow
implicit none
type :: state_t
real, allocatable :: U(:)
end type state_t
type, extends(state_t) :: astate_t
end type astate_t
type(astate_t) :: a,b
allocate(a%U(1000))
b = a
b = a
end program
In the first assignment b.U is allocated, in the second assignment it is not
freed, before being allocated again.
In fact, the dump does not contain a single "__builtin_free", while with 4.5 it
has six.
valgrind says:
==27163== 4,000 bytes in 1 blocks are definitely lost in loss record 3 of 3
==27163== at 0x4C2683D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==27163== by 0x4009BC: MAIN__ (test.f90:16)
==27163== by 0x400B9D: main (test.f90:19)
