http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #13 from Jan Hubicka <hubicka at ucw dot cz> 2011-02-15 18:49:15 UTC --- > A quick summary to see if got this right: Yes, the summary seems right. Note that GCC plays now games with not putting COMDATs into LTO symbol table unless they really need to be unique. So if you have simple inline functions with no address taken things the function is never put into LTO symbol table and linker doesn't care. GCC then merge the different copies itself and promote the function into static function. This worlsf well except for possibility of having two instances of the function (one in LTO world that is promoted to static function and one in non-LTO code staying as comdat). This works well for Firefox ;)) Things gets ugly with variables and stuff that has address taken. This is less common in C++ code but still worrysome. > On LLVM land I think this translates to > > *) If given PREVAILING_DEF, linkonce gets upgrade to weak and linkonce_odr to > weak_odr > *) If given PREVAILING_DEF_IRONLY_EXP, likages stay as they are > *) If given PREVAILING_DEF_IRONLY the symbol gets internalized > > I think this should work, thanks. I am not sure if you are allowed to change COMDAT into weak. The plugin spec explicitely speaks of comdat symbol staying and I am not sure if Gold/GNU ld are ready for symbol changing their type. Taking PREVAILING_DEF is silently accepted by both gold and GNU ld, but in gold it results in stale dynamic symbol table entries. GCC originally behaved on PREVAILING_DEF as if it was PREVAILING_DEF_IRONLY_EXP and it did result in massive dynamic symbol table section increases. Honza
