This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran] PR 80121: Memory leak with derived-type intent(out) argument
- From: Janus Weil <janus at gcc dot gnu dot org>
- To: gfortran <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Thomas Koenig <tkoenig at netcologne dot de>
- Date: Sun, 23 Apr 2017 10:51:31 +0200
- Subject: Re: [Patch, Fortran] PR 80121: Memory leak with derived-type intent(out) argument
- Authentication-results: sourceware.org; auth=none
Hi Thomas,
>> the patch in the attachment fixes a memory leak by auto-deallocating
>> the allocatable components of an allocatable intent(out) argument.
>>
>> Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
>
> OK for trunk.
thanks for the review! Committed as r247083.
> Also (because this is a quite serious bug)
> OK for gcc 7 after the release of 7.1.
I tend to be a bit hesitant with backporting non-regression-fixes, but
in this case I agree that it might make sense. (Will commit to
7-branch once it's open again, if no one objects.)
At least the patch fixes the leak in the least invasive way I could
find, although I was thinking out loudly about ways to refactor the
intent(out) handling:
> My feeling is that it would be a good idea to handle allocatable derived types inside
> of the callee as well. I can see at least two advantages:
> * It would avoid code duplication if the procedure is called several times.
> * It would take some complexity out of gfc_conv_procedure_call, which is quite a
> monster.
>
> From the technical side a treatment in the callee should be possible AFAICS. I wonder
> why it is being done in the caller at all?
Any feedback is welcome here (possibly I'm missing some reason why
this needs to be done by the caller?) ...
Cheers,
Janus