https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-12-16
CC| |janus at gcc dot gnu.org
Version|4.8.2 |4.9.1
Summary|Memory leak with |[4.9/5 Regression] Memory
|ALLOCATABLE, INTENT(OUT) |leak with ALLOCATABLE,
|dummy arguments. |INTENT(OUT) dummy
| |arguments.
Ever confirmed|0 |1
--- Comment #2 from janus at gcc dot gnu.org ---
Confirmed.
> ==13675== 800 bytes in 40 blocks are definitely lost in loss record 2 of 3
> ==13675== at 0x4A069EE: malloc (vg_replace_malloc.c:270)
> ==13675== by 0x400CF0: __testmodule_MOD_create_mytype
> (test_allocarg.f90:15)
> ==13675== by 0x400B74: __testmodule_MOD_allocate_mytype
> (test_allocarg.f90:24)
> ==13675== by 0x400E47: MAIN__ (test_allocarg.f90:40)
> ==13675== by 0x400E94: main (test_allocarg.f90:33)
This one I see with all gfortran versions I tried (4.4.7, 4.6.4, 4.7.4, 4.8.3,
4.9.1, trunk).
> ==13675== 1,360 (960 direct, 400 indirect) bytes in 1 blocks are definitely
> lost in loss record 3 of 3
> ==13675== at 0x4A069EE: malloc (vg_replace_malloc.c:270)
> ==13675== by 0x4009DA: __testmodule_MOD_allocate_mytype
> (test_allocarg.f90:22)
> ==13675== by 0x400E47: MAIN__ (test_allocarg.f90:40)
> ==13675== by 0x400E94: main (test_allocarg.f90:33)
This one only seems to occur with 4.9 and trunk, i.e. it's a regression.
