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.