[Bug rtl-optimization/111101] New: -finline-small-functions may invert FP arguments breaking FP bit accuracy in case of NaNs

[Bug rtl-optimization/111101] New: -finline-small-functions may invert FP arguments breaking FP bit accuracy in case of NaNs

[pavel.morozkin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111101

            Bug ID: 111101
           Summary: -finline-small-functions may invert FP arguments
                    breaking FP bit accuracy in case of NaNs
           Product: gcc
           Version: 11.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pavel.morozkin at gmail dot com
  Target Milestone: ---

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.

[Bug rtl-optimization/111101] -finline-small-functions may invert FP arguments breaking FP bit accuracy in case of NaNs

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111101

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID
                 CC|                            |amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
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.