Notes: 1. This may not be a bug. 2. This may be a duplicate. 3. I don't have MRE. Brief: -finline-small-functions may invert FP arguments breaking FP bit accuracy in case of NaNs Demo: $ gcc t1.c -O1 -std=c11 && ./a r nan 7fe5ed65 r_ref nan 7fe5ed65 $ gcc t1.c -O1 -std=c11 -finline-small-functions && ./a r -nan fffffffe r_ref nan 7fe5ed65 Description: In my code I add two FP values (represented in "raw hex"): 0x7fa5ed65 (sNaN) with 0xfffffffe (qNaN). x86_64 instruction addss returns 0x7fe5ed65 (sNaN). However, under -finline-small-functions gcc, I guess, rewrites A+B to B+A, resulting in 0xfffffffe (qNaN), which breaks FP bit accuracy. I examined generated assembly code: -O1: add(x, y) x => ecx => ebp => xmm0 y => edx => edi => xmm1 addss xmm1, xmm0 (at&t syntax) -O1 -finline-small-functions: add(x, y) x => ecx => esi => xmm1 y => edx => ebx => xmm0 addss xmm1, xmm0 (at&t syntax) Here we see that in case of -finline-small-functions x and y are inverted. Notes: 1. Some software may rely on FP bit accuracy in case of NaNs (NaN boxing, etc.). 2. I'm not sure which "Component:" to select: rtl-optimization or tree-optimization.
0x7fe5ed65 is a quiet NaN, not signaling (it differs from the input 0x7fa5ed65 sNaN by the leading mantissa bit 0x00400000). IEEE-754 does not pin down which of the two payloads should be propagated when both operands are NaNs, and neither do language standards, so for GCC floating-point addition and similar operations are commutative. Observed NaN payloads are not predictable and may change depending on optimization level, choice of x87 vs. SSE instructions, etc. This is not a bug.