[Patch, fortran] PR80477 - [OOP] Polymorphic function result generates memory leak

[Paul Richard Thomas]

Hi Janus,

Yes, you are correct about the need to call the _final component. OK -
will do :-)

PR86481? This seems to be the same problem in a different place.

I am starting to wonder if the gfc_se structure doesn't need an
additional block component; se.final, in addition to se.post. This
kind of difficulty in sequencing has come up many times before. If the
deallocations were available in the final block, this could be added
to the post block of the caller. This would be a neat solution to the
cases where finalization should be implemented but is not....

Thanks

Paul
On Sat, 28 Jul 2018 at 17:37, Janus Weil <janus@gcc.gnu.org> wrote:
>
> Hi Paul,
>
> 2018-07-28 9:32 GMT+02:00 Paul Richard Thomas <paul.richard.thomas@gmail.com>:
> > Several attempts, including mine, were made to fix this bug since it
> > was posted. They were all attacking the wrong place. Instead of
> > providing the free of the class _data as part of the call to
> > 'add_a_type' it should be included in the post block of the argument
> > processing in the call to 'assign_a_type'. The comment in the patch
> > says the rest.
> >
> > Bootstrapped and regtested on FC28/x86_64 - OK for trunk?
>
> great that you managed to solve this one! The patch looks very good to
> me, but I'm afraid two details may be missing:
>
> 1) If the type has allocatable components, those need to be freed first.
> 2) If the type has a finalizer, that needs to be called as well.
>
> I believe that both points can be fixed by calling the _final
> component of the vtab before freeing the class data. Should not be
> hard to add, I hope (gfc_add_finalizer_call might be useful).
>
> Thanks for your efforts ...
>
> Cheers,
> Janus



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein