This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs
- From: "hjl.tools at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 10 Jan 2011 18:26:11 +0000
- Subject: [Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs
- Auto-submitted: auto-generated
- References: <bug-47247-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> 2011-01-10 18:26:00 UTC ---
(In reply to comment #6)
> The plugin specification says that once the COMDAT is marked PREVAILING, it has
> to be output.
> "Any symbol marked PREVAILING_DEF must be defined in one object file added to
> the link after WPA is done, or an undefined symbol error will result. Any
> symbol marked PREVAILING_DEF_IRONLY may be left undefined (provided all
> references to the symbol have been removed), and the linker will not issue an
> error."
>
> GCC will optimize it out only if it is set PREVAILING_IRONLY, but I think we
> conlcuded earlier that this can not be used for symbols visible to dynamic
> linking (and GCC would use this info to bring the COMDAT symbol static).
>
What undesirable things may happen if we mark a COMDAT symbol
PREVAILING_DEF? Is that we won't know which one will be used
if both LTO and non-LTO objects define the same COMAT symbol?