diff options
author | Mikael Morin <mikael@gcc.gnu.org> | 2025-07-27 17:11:58 +0200 |
---|---|---|
committer | Mikael Morin <mikael@gcc.gnu.org> | 2025-07-27 17:25:51 +0200 |
commit | 0f61284eae6365e77b28af8fa4bc3dc7e5e0fac9 (patch) | |
tree | 8ac49c9638d27138c1cc5793c0b71d64700d03a1 /gcc/diagnostics/text-sink.cc | |
parent | 1800ac20f66812c72b144848f7ec8e66156f06f8 (diff) | |
download | gcc-master.zip gcc-master.tar.gz gcc-master.tar.bz2 |
This is a follow-up to:
r16-2248-gac8e536526393580bc9a4339bab2f8603eff8a47
fortran: Delay evaluation of array bounds after reallocation
That revision delayed the evaluation of array bounds, with changes in
two places: in the scalarizer where we save expressions without
evaluating their values to variables, and in the reallocation code where
we evaluate to variables the expressions previously saved. The effect
should not have been visible in scalarized code, as the saving to a
variable was only delayed after reallocation.
Unfortunately, it's actually not the case, and there are cases where
expressions that were saved to variables before the change, are no
longer after it. The reason for that is differing conditions guarding
the omission of the evaluation to variables in the scalarizer on one
hand, and the emission of reallocation code with the saving to variables
on the other hand. There is an additional check that avoids the
emission of reallocation code if we can prove at compile time that both
sides of the assignment are conformable.
This change moves up the reallocation code condition definition, so that
it can be used as well to flag the left hand side array as
reallocatable, and omit the evaluation of expressions in the exact same
conditions where the reallocation code would catch those unevaluated
expressions.
An explicit call to gfc_fix_class_refs is added before the evaluation of
the reallocation code condition. It was implicit before, by the call to
gfc_walk_expr.
This is not a correctness issue, but PR #121185, that made the problem
apparent, exhibited wrong code examples where the lack of an
intermediary variable was making visible a class container at the
beginning of an array reference, causing the non-polymorphic array
reference to be evaluated in a polymorphic way.
The preceding commits have already fixed the PR #121185 test, so I
haven't found any addition to the testsuite that would reliably test
this change.
PR fortran/121185
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_trans_assignment_1): Use the same condition
to set the is_alloc_lhs flag and to decide to generate
reallocation code. Add explicit call to gfc_fix_class_refs
before evaluating the condition.
Diffstat (limited to 'gcc/diagnostics/text-sink.cc')
0 files changed, 0 insertions, 0 deletions