This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, fortran] PR66079 - [6 Regression] memory leak with source allocation in internal subprogram


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.
> 
Agreed.

Mikael


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]