[Bug lto/63215] LTO causes symbols for builtin functions to be omitted from object files
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
[Bug lto/63215] LTO causes symbols for builtin functions to be omitted from object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-10 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org --- At the moment it is not supported to LTO runtime symbols (i.e. functions and variables whose use may be synthetized by the compiler). Doing so would be quite tricky, since we will need to recognize them and keep for possible use later. It would however make sense.
[Bug lto/63215] LTO causes symbols for builtin functions to be omitted from object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- As an ugly workaround, marking them __attribute__ ((externally_visible, used)) should work. They will however be added into every binary that is linked with them no mater if they are used or not.
[Bug lto/63215] LTO causes symbols for builtin functions to be omitted from object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215 --- Comment #3 from Patrick Oppenlander patrick at motec dot com.au --- Thanks for the information! Is there a list of these functions somewhere? Is this somehow related to bug 60395? Thanks, Patrick
[Bug lto/63215] LTO causes symbols for builtin functions to be omitted from object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Hmm, we can easily distinguish them by seeing whether a definition is available. That is, symbols with a definition should _always_ be output? I don't see any difficulties with builtin handling in general (though we probably should stop streaming builtins specially so we retain as builtin what was a builtin during compile-time). tree merging should happily merge equal builtin decls (and we compare them by function code anyway).
[Bug lto/63215] LTO causes symbols for builtin functions to be omitted from object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215 --- Comment #5 from Jan Hubicka hubicka at ucw dot cz --- 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. 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... Honza
