-flto causes `undefined reference` for gcc builtins

[Tobias Schramm via Gcc-help <gcc-help@xxxxxxxxxxx>]

Hey everyone,

I'm currently wondering about some peculiar behaviour of -flto.

Compiling the following code test.c

#include <string.h>

static char strbuf[32] __attribute__((used));

void reset_handler(void) {
        memset(strbuf, 0, sizeof(strbuf));
}

using the boilerplate linker script test.lds

ENTRY(reset_handler)
MEMORY
{
 ram (rwx) : ORIGIN = 0x20000000, LENGTH = 8K
 rom (rx) : ORIGIN = 0x08000000, LENGTH = 64K
}
SECTIONS
{
 .text : {
  *(.text*)
  *(.rodata*)
 } >rom
 .noinit (NOLOAD) : {
  *(.noinit*)
 } >ram
 .data : {
  *(.data*)
  *(.ramtext*)
 } >ram AT >rom
 .bss : {
  *(.bss*)
  . = ALIGN(4);
 } >ram
}

via

arm-none-eabi-gcc -flto -c test.c -o test.o
arm-none-eabi-gcc-ar -flto r test.a test.o
arm-none-eabi-gcc -flto -nostartfiles -Wl,-\( -Wl,-lc -Wl,-lgcc -Wl,-lnosys
test.a -Wl,-\) -o test.elf -T test.lds

gives me the error

/usr/lib/gcc/arm-none-eabi/12.1.0/../../../../arm-none-eabi/bin/ld:
/tmp/ccsFzvhr.ltrans0.ltrans.o: in function `reset_handler':
<artificial>:(.text+0x14): undefined reference to `memset'
collect2: error: ld returned 1 exit status

To my surprise this does not happen when linking test.o directly without
wrapping it into an archive first:

arm-none-eabi-gcc -flto -nostartfiles -Wl,-\( -Wl,-lc -Wl,-lgcc -Wl,-lnosys
-Wl,-\) test.o -o test.elf -T test.lds

This behaviour does only show up when using link time optimization. If I
run above commands without -flto memset is found and linked correctly. Also
this does not seem to happen on x86, I was not able to reproduce it there.
Additionally the problem also disappears while still using LTO when adding
-fno-builtin to the gcc command line, making me suspect that this is
somehow related to gcc's substitution of builtins.
Is this expected behaviour and am I misunderstanding how symbol lookup at
link time works? I would expect ld to find memset in libc at link time
since it is contained in a group together with test.a.

The version of GCC I'm using is

Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/12.1.0/lto-wrapper
Target: arm-none-eabi
Configured with: /build/arm-none-eabi-gcc/src/gcc-12.1.0/configure
--target=arm-none-eabi --prefix=/usr --with-sysroot=/usr/arm-none-eabi
--with-native-system-header-dir=/include --libexecdir=/usr/lib
--enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libssp --disable-libstdcxx-pch
--disable-nls --disable-shared --disable-threads --disable-tls
--with-gnu-as --with-gnu-ld --with-system-zlib --with-newlib
--with-headers=/usr/arm-none-eabi/include
--with-python-dir=share/gcc-arm-none-eabi --with-gmp --with-mpfr --with-mpc
--with-isl --with-libelf --enable-gnu-indirect-function
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='Arch Repository' --with-bugurl=
https://bugs.archlinux.org/ --with-multilib-list=rmprofile
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Arch Repository)

Any input on why I'm seeing this behaviour will be highly appreciated, I
suspect I'm just missing something here, though I was unable to find
anything in particular on this issue online.

Cheers,
Tobias