https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
Bug ID: 111655 Summary: wrong code generated for __builtin_signbit on x86-64 -O2 Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: eggert at cs dot ucla.edu Target Milestone: --- I ran into this bug when testing Gnulib code on Fedora 38 x86-64, which uses gcc (GCC) 13.2.1 20230728 (Red Hat 13.2.1-1). The problem is a regression from gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), which does the right thing. Here is a stripped-down version of the bug. Compile and run the following code with "gcc -O2 t.i; ./a.out". int main () { double x = 0.0 / 0.0; if (!__builtin_signbit (x)) x = -x; return !__builtin_signbit (x); } Although a.out's exit status should be 0, it is 1. If I compile without -O2 the bug goes away. Here's the key part of the generated assembly language: main: pxor %xmm0, %xmm0 divsd %xmm0, %xmm0 xorpd .LC1(%rip), %xmm0 movmskpd %xmm0, %eax testb $1, %al sete %al movzbl %al, %eax ret .LC1: .long 0 .long -2147483648 On the x86-64, the "divsd %xmm0, %xmm0" instruction that implements 0.0 / 0.0 generates a NaN with the sign bit set. I determined this by testing on a Xeon W-1350, although I don't see where the NaN's sign bit is documented by Intel in this situation. It appears that GCC's optimization incorrectly assumes that 0.0 / 0.0 generates a NaN with the sign bit clear, which causes the "if (!__builtin_signbit (x)) x = -x;" to be compiled as if it were merely "x = -x;", which is obviously incorrect.