[Bug fortran/53521] [4.5/4.6/4.7/4.8 Regression] Zero-byte "memory leak" with zero-sized array constructor (valgrind warning)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521 --- Comment #6 from Joost VandeVondele 2012-05-30 14:37:09 UTC --- (In reply to comment #4) > You say not doing free (0) leaks memory? What OS is this on? I'm observing on a Linux box that : MODULE TEST IMPLICIT NONE CONTAINS SUBROUTINE T(n1) INTEGER :: n1(:) END SUBROUTINE T SUBROUTINE T2(n) INTEGER :: n INTEGER :: k CALL T((/(k,k=1,n-1)/)) END SUBROUTINE END MODULE USE TEST DO CALL T2(1) ENDDO END needs 25Gb of memory after a while (notice the endless loop around CALL T2).
[Bug fortran/53521] [4.5/4.6/4.7/4.8 Regression] Zero-byte "memory leak" with zero-sized array constructor (valgrind warning)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek 2012-05-30 13:49:51 UTC --- That is clearly a bug in the Fortran FE. D.1888 = (integer(kind=4)[0] * restrict) __builtin_realloc ((void *) atmp.0.data, D.1887); if (D.1888 == 0B && D.1887 != 0) { _gfortran_os_error (&"Allocation would exceed memory limit"[1]{lb: 1 sz: 1}); } if (D.1887 == 0) { D.1888 = 0B; } means that D.1888 isn't freed. POSIX says that realloc (x, 0) acts as free only if x is not NULL, realloc (NULL, 0) acts as malloc (0), which can either return NULL, or a unique pointer that needs to be freed.
[Bug fortran/53521] [4.5/4.6/4.7/4.8 Regression] Zero-byte "memory leak" with zero-sized array constructor (valgrind warning)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521 --- Comment #4 from Richard Guenther 2012-05-30 12:46:53 UTC --- You say not doing free (0) leaks memory? What OS is this on? Note that we fold such calls away: case BUILT_IN_FREE: if (integer_zerop (arg0)) return build_empty_stmt (loc);
[Bug fortran/53521] [4.5/4.6/4.7/4.8 Regression] Zero-byte "memory leak" with zero-sized array constructor (valgrind warning)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521 --- Comment #3 from Joost VandeVondele 2012-05-30 12:31:18 UTC --- (In reply to comment #2) > Well, I think this is a valgrind issue and not a real "leak". Whether you > want to "optimize" code for the non-NULL case by omitting the NULL check is > another question of course. It's definitely not wrong-code IMHO. No, definitely a real bug... not a valgrind issue. If you put a loop around 'CALL T2' the process memory usage is a >1Gb in a few seconds. This is a real issue which causes our simulation code to crash after 24h of running.