https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934
--- Comment #20 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to jos...@codesourcery.com from comment #16) > I don't think this bug is anything to do with -fsignaling-nans, for the > same reason as applies to bug 58416 and bug 71460. The situation is hopeless from the beginning. Please consider this testcase: --cut here-- #include <cpuid.h> #include <fenv.h> double __attribute__((noinline,noipa)) foo (double a, double b, char c) { return c ? a : b; } int main () { double a = __builtin_nans (""); double b = 42.0; feclearexcept (FE_INVALID); foo (a, b, 0); if (fetestexcept (FE_INVALID)) __builtin_abort (); return 0; } --cut here-- $ gcc -O2 -m32 -march=i686 -lm fcmov.c $ ./a.out Aborted (core dumped) $ gcc -O2 -m32 -march=i386 -lm fcmov.c $ ./a.out Aborted (core dumped) Because the compiler generates: foo: cmpb $0, 20(%esp) fldl 12(%esp) fldl 4(%esp) fcmove %st(1), %st fstp %st(1) ret in the former case and: foo: fldl 4(%esp) fldl 12(%esp) cmpb $0, 20(%esp) jne .L4 fstp %st(1) jmp .L2 .L4: fstp %st(0) .L2: ret in the later. Since the ABI specifies the operand size on the stack, the above code will always trap.