This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/51175] Memory Leak with Transfer intrinsic
- From: "burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 16 Nov 2011 17:15:31 +0000
- Subject: [Bug fortran/51175] Memory Leak with Transfer intrinsic
- Auto-submitted: auto-generated
- References: <bug-51175-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51175
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed| |2011-11-16
CC| |burnus at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-16 17:15:31 UTC ---
(In reply to comment #0)
> I am using gfortran 4.6.2 on MacOSX 10.7.
> It appears that this code involving transfer generates a memory leak
Indeed, valgrind shows:
==3168== 20 bytes in 1 blocks are definitely lost in loss record 1 of 1
==3168== at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==3168== by 0x4009BF: __leakmodule_MOD_leaking (test.f90:14)
==3168== by 0x400889: __leakmodule_MOD_foo (test.f90:26)
==3168== by 0x400A5B: MAIN__ (test.f90:34)
==3168== by 0x400A91: main (test.f90:32)
> print *, outstring
Use:
print *, outstring(1:3)
otherwise you access uninitialized memory.
> According to the produced assembler, malloc gets called inside the Leaking
> routine, but the asm of the caller never issues a free of that allocated
> memory.
Easier than studying the assembler: Use -fdump-tree-original (or
-fdump-tree-optimized) which creates a file of the internal representation with
C-like syntax. [Note: The dump does not contain all details.]