[Patch, fortran] PR56008 (and PR47517) [F03] wrong code with lhs-realloc on assignment with derived types having allocatable components

[Paul Richard Thomas]

Dear All,

This patch is sufficiently straightforward that the ChangeLog entry
describes it completely.  The fix for both bugs lay in the
nullification of the allocatable components of the newly (re)allocated
array.  The deallocation of allocatable components plugged the
massive(10Mbytes) memory leak in the PR47517 testcase, flagged up by
Dominique (thanks!).

There is still a memory leak of about 1.8kbytes for
realloc_on_assign_17.f90.  This is PR38319 - ***sigh*** its assigned
to me.  I'll finally have a stab at it after a few more regression
fixes.

I believe that this patch is consistent with the release schedule
since it is a more or less 'obvious' fix to a bad code problem.  I
have included the release managers to get an OK from them.

Bootstrapped and regtested on x86_64/FC17 - OK for trunk?

Paul

2013-01-22  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/56008
    PR fortran/47517
    * trans-array.c (gfc_alloc_allocatable_for_assignment): Save
    the lhs descriptor before it is modified for reallocation. Use
    it to deallocate allocatable components in the reallocation
    block.  Nullify allocatable components for newly (re)allocated
    arrays.

2013-01-22  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/56008
    * gfortran.dg/realloc_on _assign_16.f90 : New test.

    PR fortran/47517
    * gfortran.dg/realloc_on _assign_17.f90 : New test.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: submit.diff
Type: application/octet-stream
Size: 5163 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20130122/850b71aa/attachment.obj>