https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114979
Bug ID: 114979
Summary: Spurious eax clears
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jacereda at gmail dot com
Target Milestone: ---
Created attachment 58122
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58122&action=edit
Code to reproduce the problem.
This is the version I'm using (although I've checked in several versions and
it's the same):
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/gnu/store/vjjk375kysja1jz0837lypd09rdgs47c-gcc-13.2.0/libexec/gcc/x86_64-unknown-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
When compiled with -O2, the attached program generates what I'd consider normal
code on clang, MSVC and even MinGW gcc, that is, something that looks like:
0000000000000040 <test>:
40: e8 eb ff ff ff call 30 <twodup>
45: e8 e6 ff ff ff call 30 <twodup>
4a: e8 e1 ff ff ff call 30 <twodup>
4f: e8 dc ff ff ff call 30 <twodup>
54: e8 d7 ff ff ff call 30 <twodup>
59: eb d5 jmp 30 <twodup>
Instead, it will generate:
0000000000000040 <test>:
40: 31 c0 xor %eax,%eax
42: e8 e9 ff ff ff call 30 <twodup>
47: 31 c0 xor %eax,%eax
49: e8 e2 ff ff ff call 30 <twodup>
4e: 31 c0 xor %eax,%eax
50: e8 db ff ff ff call 30 <twodup>
55: 31 c0 xor %eax,%eax
57: e8 d4 ff ff ff call 30 <twodup>
5c: 31 c0 xor %eax,%eax
5e: e8 cd ff ff ff call 30 <twodup>
63: 31 c0 xor %eax,%eax
65: eb c9 jmp 30 <twodup>
Declaring the functions as taking void will fix the problem. Same goes for
compiling with g++. I know void is the right thing in C, but I can't see any
reason to perform those clears.
Regards,
Jorge Acereda
