[Bug fortran/53521] [4.3/4.4/4.5/4.6/4.7/4.8 Regression] Zero-byte memory leak with zero-sized array constructor

["burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.