http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789
Tobias Burnus <burnus at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2012-12-22 CC| |burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-12-22 18:24:45 UTC --- (In reply to comment #0) > In trying to understand some memory leak reported by mtrace (which turns out, > I think, to be a bug in glibc > http://sourceware.org/bugzilla/show_bug.cgi?id=14981) Using GLIBC 2.17, no memleak is reported here for neither the C program nor this PR's Fortran code. > I noticed that the following code > performs both an allocate and a reallocate in cp_1d_i4_sort. Confirmed. With GCC 4.5, only a simple malloc is done; ltrace shows: malloc(4) but starting from GCC 4.6 both malloc and realloc are invoked; ltrace has: malloc(4) realloc(0xafbf90, 8) With 4.8, one has (slightly simplified): ubound.0 = (arr->dim[0].ubound - arr->dim[0].lbound) + 1; atmp.4.dim[0].lbound = 0; atmp.4.dim[0].ubound = ubound.0-1; D.1907 = ubound.0 <= 0 ? 0 : ubound.0 * 4; atmp.4.data = __builtin_malloc (MAX_EXPR <D.1907, 1>); ... D.1919 = MAX_EXPR<(D.1918->dim[0].ubound - D.1918->dim[0].lbound) + 1, 0>; shadow_loopvar.7 = 1; atmp.4.dim[0].ubound = atmp.4.dim[0].ubound + MAX_EXPR <(D.1919 - shadow_loopvar.7) + 1, 0>; atmp.4.data = __builtin_realloc (atmp.4.data, (atmp.4.dim[0].ubound + 1) * 4); while (1) { if (shadow_loopvar.7 > D.1919) goto L.1; (*atmp.4.data)[offset.5] = shadow_loopvar.7; offset.5 = offset.5 + 1; shadow_loopvar.7 = shadow_loopvar.7 + 1; } L.1:;