This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, Fortran] PR 52196 add -Wrealloc-lhs(-all)
- From: Mikael Morin <mikael dot morin at sfr dot fr>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: fortran at gcc dot gnu dot org, gcc patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 24 Apr 2012 21:25:41 +0200
- Subject: Re: [Patch, Fortran] PR 52196 add -Wrealloc-lhs(-all)
- References: <4F3A489D.email@example.com> <firstname.lastname@example.org> <4F8FFECF.email@example.com>
On 19/04/2012 14:02, Tobias Burnus wrote:
> Updated patch enclosed.
> On 02/14/2012 12:42 PM, Tobias Burnus wrote:
>> in order to gain an overview for our code whether the recent RESHAPE
>> (and friends) bug affects us and to determine for which assignment a
>> reallocation happens, useful to mitigate performance issues, I added
>> -Wrealloc-lhs and -Wrealloc-lhs-all.
>> The flag -Wrealloc-lhs is the more useful flag: It's about arrays of
>> intrinsic types, which are more likely to appear in hot loops than
>> other types of reallocatable variables such as derived types or
>> (scalar) character variables with deferred length.
> On 02/27/2012 09:59 PM, Mikael Morin wrote:
>>> In turn, the warning might be printed even if at the end no realloc
>>> code is
>>> generated or present with -O1.
>> Can it be caused by the frontend not going in the realloc-lhs
>> functions in
>> some cases? Especially, it seems that there is a missing
>> condition guarding the warning if I compare to the flag_realloc_lhs
>> in trans-expr.c I would rather move the warnings to a function and
>> call it in the places where we really generate the extra code, like
>> it's done for -Warray-temporaries.
> Two months later I have finally worked on the patch again and followed
> the suggestion and added the checks to trans-expr.c.
> Build and regtested on x86-64-linux.
> OK for the trunk?
Looks good. OK. Thanks.