[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[jgreenhalgh at gcc dot gnu.org]

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.