http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Status|NEW |ASSIGNED
Summary|[4.5/4.6/4.7/4.8 |[4.5/4.6/4.7/4.8
|Regression] Zero-byte |Regression] Memory leak
|"memory leak" with |with zero-sized array
|zero-sized array |constructor
|constructor (valgrind |
|warning) |
--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-05-31
08:12:09 UTC ---
(In reply to comment #6)
> needs 25Gb of memory after a while (notice the endless loop around CALL T2).
I had tried it with a finite loop and valgrind, but the latter then only
showed:
==32236== definitely lost: 0 bytes in 10,000 blocks
However, I could reproduce it, when looking at the memory consumption in "top".
(In reply to comment #5)
> That is clearly a bug in the Fortran FE.
> D.1888 = __builtin_realloc (atmp.0.data, D.1887);
...
> if (D.1887 == 0)
> D.1888 = 0B;
> means that D.1888 isn't freed.
Well spotted! I got distracted by the valgrind result of 0 bytes - and by the
later FREE check, which should be okay.
The problem is in gcc/fortran/trans.c's gfc_call_realloc.
