https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
Alexander Monakov <amonakov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amonakov at gcc dot gnu.org
Ever confirmed|0 |1
Summary|wrong code generated for |[11/12/13/14 Regression]
|__builtin_signbit and 0./0. |wrong code generated for
|on x86-64 -O2 |__builtin_signbit and 0./0.
| |on x86-64 -O2
Resolution|DUPLICATE |---
Status|RESOLVED |NEW
Last reconfirmed| |2023-10-02
--- Comment #9 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
It's true that the sign of 0./0 is unpredictable, but we can fold it only when
the division is being eliminated by the folding.
It's fine to fold
t = 0./0;
s = __builtin_signbit(t);
to
s = 0
with t eliminated from IR, but it's not OK to fold
t = 0./0
s = __builtin_signbit(t);
to
t = 0./0
s = 0
because the resulting program runs as if 0./0 was evaluated twice, first to a
positive NaN (which was used for signbit), then to a negative NaN (which fed
the following computations). This is not allowed.
This bug was incorrectly classified as a dup. The fix is either to not fold
this, or fold only when we know that the division will be eliminated (e.g. the
only use was in the signbit). Reopening.
