https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|wrong-code |
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, it's really down to valid simplifications with -ffast-math and
conditional equivalences again. From
if (one == a) {
...
if (x == 1) {
...
if (one == 0)
we're turning the last compare to if (a == 0) and that "simplifies" from
(1 + opaque(0x1p-60) == x) == 0
again via conditional equivalences x == 1
(1 + opaque(0x1p-60) != 1)
to
opaque(0x1p-60) != 0
at -O1 printing
one = 1
one = 1
where we still print a and at -O2
one = 1
one = 0
where we figured to constant-prop the one == 0 constant before substituting
the one == a equivalence in evrp.
I think the patch enabled the x == 1 conditional equivalence to be used.
with -funsafe-math-optimizations you get the 1 + x != 1 -> x != 0
optimization which is unsafe because a rounding step is removed.
But you asked for that. So no "wrong-code" here, just another case
of "instabilities" or how you call that via conditional equivalence
propagation.
