[Bug lto/63215] LTO causes symbols for builtin functions to be omitted from object files

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #5)
> > Hmm, we can easily distinguish them by seeing whether a definition is
> > available.
> 
> Well, what happens in this testcase is that we see ABS at LTO time, we
> promote
> it to static (because no one uses it outside) and we optimize out.  Later in
> queue we pattern match ABS and we are screwed.  To fix this, we need to keep
> builtin function definitions around specially and see after all the function
> bodies are produces what builtin functions are used.
> 
> This is just part of problem. Consider case where ABS is provided by LTO
> compiled
> static library. Because the use of ABS appears at link time, the linker will
> not see
> any use of ABS and willnot bring it in.  Later we synthetize it and we are
> screwed.

Well, that's the same issue as with linking with -lm/-lc statically.
I believe the linker re-scans the objects at final link-time.  Not sure
what it does with LTO static libs there though ;)

> For this we need linker plugin to know what functions we can possibly
> syntehtize in the backend and pretend them to be used by every LTO body. This
> however may be quite bad thing, since we can synthetize quite fancy things
> like
> STDIO functions.  So ful handling of those seems bit difficult to me.
> 
> I think it may need iteration - i.e. if linker discovers that use of function
> provided by LTO symbol tables was introduced during linktime it will repreat
> the
> whole circus to get object file implementing that function...

Or we don't remove the function but put it into a separate section and let
the linker delete it...

Yeah - it's a tricky area.

Richard.

> Honza