[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[rguenth at gcc dot gnu.org]

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.