[Bug lto/114337] New: LTO symbol table doesn't include builtin functions

[Bug lto/114337] New: LTO symbol table doesn't include builtin functions

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337

            Bug ID: 114337
           Summary: LTO symbol table doesn't include builtin functions
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[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.

[Bug lto/114337] LTO symbol table doesn't include builtin functions

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
Maybe linker can deal with it.

[Bug lto/114337] LTO symbol table doesn't include builtin functions

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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).

[Bug lto/114337] LTO symbol table doesn't include builtin functions

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
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?

[Bug lto/114337] LTO symbol table doesn't include builtin functions

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |MOVED

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
Will fix it in linker.

[Bug lto/114337] LTO symbol table doesn't include builtin functions

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amonakov at gcc dot gnu.org

--- Comment #5 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Gold handles such rescanning correctly. BFD ld regressed in 2.27, this
bugreport contains references to previous discussions about rescanning:
https://sourceware.org/bugzilla/show_bug.cgi?id=23935

(in the above bug there's a patch for ld.bfd that seemingly went nowhere)