https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102634
Bug ID: 102634
Summary: Optimization in dom2 pass makes wrong signed integer
overflow inference
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mk.aard.gcc at gmail dot com
Target Milestone: ---
Created attachment 51563
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51563&action=edit
Sample code which fails. Integer with 'NaN' handling user type using min
integer value as NaN
Compiled using GCC 10.2.1 on Debian 11 Bullseye, amd64:
g++ -c -O2 -std=c++17 example.cpp
This generates the following assembly for strange_code() (see attached .ii)
00000000000000d0 <strange_code()>:
d0: 55 push %rbp
d1: 48 83 ec 10 sub $0x10,%rsp
d5: 48 c7 44 24 08 00 00 movq $0x0,0x8(%rsp)
dc: 00 00
de: 48 8d 6c 24 08 lea 0x8(%rsp),%rbp
e3: 48 89 ef mov %rbp,%rdi
e6: e8 00 00 00 00 callq eb <strange_code()+0x1b>
eb: 48 89 ef mov %rbp,%rdi
**ee: 48 be 00 00 00 00 00 movabs $0x8000000000000000,%rsi
f5: 00 00 80
f8: e8 00 00 00 00 callq fd <strange_code()+0x2d>
fd: 48 83 c4 10 add $0x10,%rsp
101: b8 01 00 00 00 mov $0x1,%eax
106: 5d pop %rbp
107: c3 retq
The use of 0x8000000000000000 as the argument for the second call we believe is
an incorrect optimization.
Although -fwrapv resolves this issue for us, and bug reporting guidelines
indicate that -fwrapv fixes are likely user error, I and several teammates have
been unable to find any signed integer overflow issues in the example provided.
As far as we can tell, each usage of the problematic value avoids any operation
which could cause overflow.
I apologize that the example isn't smaller, changing virtually anything in it
causes the issue to go away.
