aboutsummaryrefslogtreecommitdiff
path: root/libstdc++-v3/include/std/condition_variable
diff options
context:
space:
mode:
authorMikael Morin <mikael@gcc.gnu.org>2025-07-27 17:11:58 +0200
committerMikael Morin <mikael@gcc.gnu.org>2025-07-27 17:25:51 +0200
commit0f61284eae6365e77b28af8fa4bc3dc7e5e0fac9 (patch)
tree8ac49c9638d27138c1cc5793c0b71d64700d03a1 /libstdc++-v3/include/std/condition_variable
parent1800ac20f66812c72b144848f7ec8e66156f06f8 (diff)
downloadgcc-master.zip
gcc-master.tar.gz
gcc-master.tar.bz2
fortran: Consistently use the same assignment reallocation condition [PR121185]HEADtrunkmaster
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 'libstdc++-v3/include/std/condition_variable')
0 files changed, 0 insertions, 0 deletions