https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66082
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-05-23
CC| |pault at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Paul Thomas <pault at gcc dot gnu.org> ---
Confirmed.
Oddly, the memory leak goes away at any level of optimization. What makes this
odd is that the assumed shape array case has all the code for deallocation of
the allocatable component after the call to foo_1d:
foo_1d (&C.3401, &atmp.3);
if ((struct foo_t[1] * restrict) atmp.3.data != 0B)
{
D.3411 = (atmp.3.dim[0].ubound - atmp.3.dim[0].lbound) + 1;
D.3412 = atmp.3.dim[0].stride * D.3411;
D.3413 = D.3412 + -1;
S.6 = 0;
while (1)
{
if (S.6 > D.3413) goto L.3;
if ((*(struct foo_t[1] * restrict) atmp.3.data)[S.6].bigarr
!= 0B)
{
__builtin_free ((void *) (*(struct foo_t[1] * restrict)
atmp.3.data)[S.6].bigarr);
}
(*(struct foo_t[1] * restrict) atmp.3.data)[S.6].bigarr = 0B;
S.6 = S.6 + 1;
}
L.3:;
}
and this disappears completely for the automatic array dummy. I am pretty sure
that ther problem lies in trans-array.c(gfc_conv_array_parameter), where the
deallocation of allocatable components appears after the return for g77 style
dummies. I cannot check this right now because I am doing a fresh bootstrap
with a clean tree.
Paul
