Comments

Hi all,
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.
Using it, I also found that there is a rather common class of
expressions, related to scaling, array addition or complex conjugation,
where the same array is on the LHS and RHS. In that case, gfortran
should avoid inserting the reallocation. (Cf. PR 52243.) Fortunately,
-O0 is often sufficient to remove the reallocation code. In turn, the
warning might be printed even if at the end no realloc code is generated
or present with -O1. Nevertheless, it can help to aid optimizing the
code, though, blindly adding "(:,:)" everywhere doesn't make sense - but
it also doesn't harm either. (At least for code which doesn't use
realloc on assignment on purpose ;-)
Build and regtested on x86-64-linux.
OK for the (4.8?) trunk?
Tobias

Hello,
On Tuesday 14 February 2012 12:42:21 Tobias Burnus wrote:
> Fortunately, -O0 is often sufficient to remove the reallocation code. >
I guess you mean -O1 here...
> 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 codimension/coindexed
condition guarding the warning if I compare to the flag_realloc_lhs conditions
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.
Mikael