[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" <gcc-bugzilla@gcc.gnu.org>]

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.