This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, fortran] PR66079 - [6 Regression] memory leak with source allocation in internal subprogram
- From: Mikael Morin <mikael dot morin at sfr dot fr>
- To: Andre Vehreschild <vehre at gmx dot de>, Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- Cc: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 27 May 2015 18:24:25 +0200
- Subject: Re: [Patch, fortran] PR66079 - [6 Regression] memory leak with source allocation in internal subprogram
- Authentication-results: sourceware.org; auth=none
- Authentication-results: sfrmc.priv.atos.fr; dkim=none (no signature); dkim-adsp=none (no policy) header dot from=mikael dot morin at sfr dot fr
- References: <CAGkQGiJ66iHS3J9d9H+f6e=ZeSO60ktDat-4e5TAjeO9W8oZFg at mail dot gmail dot com> <20150523195252 dot 22647b46 at vepi2> <CAGkQGiJzt4y7n4KMgO+Z9ooh2HPgj=SG5Vm9wanJeGMZoxePbg at mail dot gmail dot com> <CAGkQGiK9toG47ywxaWYOWpvHOEA98btpYPXFTx8HN4=82kzW2g at mail dot gmail dot com> <20150525122447 dot 5aafa2da at vepi2> <CAGkQGiLo=KCd8qkvC7OgmWWjjChGYA_7h1KOKv62HwgvUXvpMg at mail dot gmail dot com> <20150527160733 dot 0880b1d2 at vepi2>
Le 27/05/2015 16:07, Andre Vehreschild a écrit :
> Hi Paul, hi Mikael,
> about renaming the identifier emitted: I would like to keep it short. Remember,
> there is always a number attached to it, which makes it unique. Furthermore
> does "alloc_source_tmp" sound unnecessarily long to me. It tastes like we do
> not trust the unique identifier mechanism established in gfortran. But that is
> just my personal taste.
Then let's go with "source", which seems to get the majority of the
votes. It remains an improvement over "expr3" and "atmp".
> about missing expr->rank == 0) in the extended patch: I just wanted to present
> an idea here. The patch was not meant to be commited yet. I think it
> furthermore is just half of the rent (like we say in Germany). I think we can
> do better, when we also think about the preceeding two if-blocks (the ones
> taking care about derived and class types). It should be possible to do
> something similar there. Furthermore could one think about moving e3rhs for
> array valued objects, too. But then we should not move to the last element, but
> instead to the first element. Nevertheless in the array valued case one might
> end up still having to deallocate the components or e3rhs, when the object
> allocated is zero sized. I wonder whether the bother really pays.
> What do you think about it?
I don't want to review monster patches. ;-)
More seriously, I think there are more important things than this, but
the patch was there and seemed reasonable.
One can add support for the other if-blocks. About the rest, I'm not
sure I understand. Or rather, I'm sure I don't.
Does it make a difference first or last element?
What is so specific about "array valued case"?
We can try to add support for this in more and more cases, but please
let's not make the code impossible to understand.
> Paul: I would recommend you commit with symbol rename, but without the move
> optimization. We can do that later.