http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P5
Status|UNCONFIRMED |NEW
Known to work| |4.1.2
Keywords| |wrong-code
Last reconfirmed| |2012-05-30
CC| |burnus at gcc dot gnu.org
Ever Confirmed|0 |1
Summary|Memory leak with zero sized |[4.3/4.4/4.5/4.6/4.7/4.8
|array constructor |Regression] Zero-byte
| |memory leak with zero-sized
| |array constructor
Target Milestone|--- |4.6.4
Known to fail| |4.3.4, 4.4.0, 4.5.3, 4.6.3,
| |4.7.0, 4.8.0
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-05-30
08:30:39 UTC ---
Confirmed. Valgrind shows with GCC 4.1 "no leaks are possible" while for GCC
4.3 to 4.8, it shows:
==25714== HEAP SUMMARY:
==25714== in use at exit: 0 bytes in 1 blocks
That's not much memory, but I concur that it clutters the valgrind output. With
--leak-check=full:
0 bytes in 1 blocks are definitely lost in loss record 1 of 1
at 0x4C2ABED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4C2AD6F: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x400876: __test_MOD_t2 (test.f90:10)
by 0x400999: MAIN__ (test.f90:14)
by 0x4009CF: main (test.f90:13)
>From the dump:
atmp.0.data = 0B;
D.1888 = __builtin_realloc ((void *) atmp.0.data, D.1887);
atmp.0.data = (void * restrict) D.1888;
...
D.1883 = (void *) atmp.0.data;
if (D.1883 != 0B)
__builtin_free (D.1883);
One possibility would be to simply remove the "if": First, free also handles
the case of "freeing" NULL, secondly, for temporary variables "NULL" is a rare
(or nonexisting) special case (i.e. it hampers rather than helps optimization),
and, thirdly, this PR shows that also zero-sized NULL-pointers should be freed.
