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