https://sourceware.org/bugzilla/show_bug.cgi?id=23935
--- Comment #5 from Vladislav Ivanishin <vlad at ispras dot ru> --- (In reply to H.J. Lu from comment #4) > (In reply to Vladislav Ivanishin from comment #3) > > GCC does not tell it needs the printf symbol, because it's a builtin > > function > > (prog.c is compiled without -fno-builtin). > > > > Although printf is a builtin function, it doesn't mean that GCC doesn't > need an external symbol, which doesn't have to be printf, to implement > the builtin function. GCC should put that external symbol in the LTO > symbol table. The compiler would then add a superset of references compared to what will actually be needed. The decision whether to emit a call or inline code for a builtin is made during LTO. Not to mention that this would be hard to track in the compiler: say, builtin_strcpy might be folded to builtin_memcpy. So in the end either of the libc functions might be called, or none at all if the builtin is emitted completely as inline code. In the approach you suggest files containing both functions will always be extracted from libc. AFAIK the rescanning functionality was added to support exactly this use case, namely "to ensure that any previously unseen undefined symbols introduced by the compiler are handled correctly" (quoting [1]). Why rescan anything at all if we know the symbol tables beforehand? [1]: https://sourceware.org/ml/binutils/2011-01/msg00270.html -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
