https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692
--- Comment #21 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #20)
> (In reply to anlauf from comment #19)
> > Will wait some time before considering backports.
>
> Hi Harald,
>
> In spite of my nervousness about the patch, I wouldn't wait very long to
> backport. You are much more likely to uncover regressions with 13- and
> 14-branches. After all, it took more than 6 years for this bug to emerge. I
> cannot help but think that users of production, legacy code are likely to be
> very careful about compiler updates.
Hi Paul,
with the patch we trade a wrong-code bug by a potential missed-optimization,
see Tobias' example. If HPC users already have workarounds in their codes,
then they might see at most a (very minor) slowdown due to the reload,
if any. Otherwise, the patch should be harmless.
I often do see missed optimizations for situations that make me scratch my
head, which is the reason I sometimes sprinkle VOLATILE or just simple SAVE
statements as an aid for tracing down things.
Example:
```
subroutine s
implicit none
integer :: j
save :: j ! <<< commenting this ...
j = 0
print *, "j =", j ! <<< or this allows optimizing else branch below
if (j == 0) then
print *, "j is zero"
else
print *, "j is non-zero"
stop 99
end if
end
```
The else-branch is not optimized away even at -O3 unless one of the marked
lines is commented. We might track cases like this in some other PR for
further discussion and potential future improvements, and collect input
from experts in the middle-end.
But I agree that it does not make sense to wait to long for the backports.
If there is silence, I'll start with 14-branch in a week. Any fallout
will then be a new PR about a missed optimization.
