[hjl@gnu-cfl-3 pr31482-a]$ cat y.c #include <stdio.h> #include <stdlib.h> void * foo (size_t n) { printf ("hello\n"); return malloc (n); } [hjl@gnu-cfl-3 pr31482-a]$ gcc -flto -c y.c [hjl@gnu-cfl-3 pr31482-a]$ nm y.o 00000000 T foo [hjl@gnu-cfl-3 pr31482-a]$ lto-dump -list y.o Type Visibility Size Name function default 0 puts function default 0 malloc function default 4 foo [hjl@gnu-cfl-3 pr31482-a]$ This doesn't work with libraries which provide alternative implementations for standard functions, like jemalloc, since linker doesn't know the builtin functions are referenced. Unless GCC can inline these builtin functions, these symbols should be in LTO symbol table.
Maybe linker can deal with it.
Without -ffat-lto-objects, the compiler doesn't really know if the builtins will be expanded inline and not require any symbol from other objects, or if they will need some library function (and which exact one).
The linker needs to re-scan for new references to libc and libgcc functions anyway. For example a structure copy might be expanded as memcpy. We probably don't introduce new calls to memcpy so maybe for a subset of builtins that are never expanded inline or those that are never automatically generated by the compiler we can put them into the symbol table. Note we can introduce calls to things like stpcpy as well, so it's a bit non-obvious how to classify builtins here. Keying on just whether the decl is built-in is probably too coarse. We could simply include all built-ins in the symbol table. Honza?
Will fix it in linker.