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.
