https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529
James Greenhalgh <jgreenhalgh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jgreenhalgh at gcc dot gnu.org
--- Comment #19 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> ---
That this only happens for LTO builds is the key here.
gcc/testsuite/gcc.c-torture/execute/builtins/strcat-chk-lib.c includes
gcc/testsuite/gcc.c-torture/execute/builtins/lib/chk.c which defines a memset.
In an LTO build, that definition of memset is visible, here is what it looks
like after code generation:
memset:
sub x3, x2, #1
cbz x2, .L158
and w1, w1, 255
.p2align 2
.L159:
strb w1, [x0, x3]
sub x3, x3, #1
cmn x3, #1
bne .L159
.L158:
adr x1, .LANCHOR0
ldr w1, [x1, 2096]
ret
Clearly x4 is not going to be clobbered there, so ipa-ra can assume it isn't
used and is safe to clobber.
At final link time, on aarch64-none-elf builds with specs files that are
pulling in start-up and tear-down code which uses a library memset, the linker
may pull in the library memset before it sees the memset from lib/chk.c .
That would be an error:
/tmp/ccpefK3l.ltrans0.ltrans.o: In function `memset':
<artificial>:(.text+0x4a0): multiple definition of `memset'
.../aarch64-none-elf/lib/libc.a(lib_a-memset.o):
.../newlib/libc/machine/aarch64/memset.S:90: first defined here
Were it not for the flag added to resolve PR55994
-Wl,--allow-multiple-definition .
So, in my opinion, the testcase is broken and could always have failed in this
way. The combination of register allocation, LTO and order the linker sees
symbols explains why this is hard to reproduce.
