public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rafael.espindola at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs Date: Wed, 16 Feb 2011 04:04:00 -0000 [thread overview] Message-ID: <bug-47247-4-85AlHhvAeq@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-47247-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #16 from Rafael Avila de Espindola <rafael.espindola at gmail dot com> 2011-02-16 04:03:36 UTC --- > The problem is with dropping linkonce_odr that has been previously reported. > This way gold will allocate entry in the dynamic symbol table (you can see it > in > nm of the final binary) with no definition/use. > Once something is given PREVAILING_DEF, it can not be optimized away. I see. Even with PREVAILING_DEF_IRONLY_EXP we still have to update gold to drop those, no? Gold doesn't know the language semantics to know which visible symbols can or cannot be dropped, so it can only assume the plugin knows what it is doing when it drops one. > > We produce IL for a.cc and a ELF for b.cc. Gold decides to use the IL version, > > gives the plugin a PREVAILING_DEF. LLVM optimises the use away and drops the > > vtable. We now have an undefined reference to the vtable. > > Yes, that is problem, too, but I didn't see it in practice. Yes, the common case is to try to put as much as possible in the IL :-) Now that I can build firefox in LTO I will try to create a testcase for this next week. > > > > With both PREVAILING_DEF_IRONLY_EXP and PREVAILING_DEF llvm would be able to > > tell the difference. If there was no use of the vtable from an ELF file, gold > > would give a PREVAILING_DEF_IRONLY_EXP and llvm would be allowed to drop it. If > > there is, gold gives a PREVAILING_DEF and llvm must upgrade the vtable from > > linkonce_odr to weak_odr which causes it to say in the final .o even if it > > optimises out all uses. > > Yes, that seems right except that GCC makes difference in between comdat > symbols that must stay even if they are optimized out and weak symbols since > both are handled bit differently. I am not sure if updating comdat symbol to > weak is safe in ELF world, probably Iant would know. Well, since we know this is the symbol being used, llvm can just upgrade it all the way to a regular symbol. > Honza Thanks, Rafael
next prev parent reply other threads:[~2011-02-16 4:03 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-01-10 16:51 [Bug lto/47247] New: " hubicka at gcc dot gnu.org 2011-01-10 17:02 ` [Bug lto/47247] " hubicka at gcc dot gnu.org 2011-01-10 17:11 ` hjl.tools at gmail dot com 2011-01-10 17:12 ` hjl.tools at gmail dot com 2011-01-10 17:13 ` hubicka at ucw dot cz 2011-01-10 17:19 ` hjl.tools at gmail dot com 2011-01-10 18:20 ` hubicka at gcc dot gnu.org 2011-01-10 18:36 ` hjl.tools at gmail dot com 2011-01-10 19:06 ` ccoutant at gcc dot gnu.org 2011-01-10 19:08 ` ccoutant at gcc dot gnu.org 2011-01-10 21:27 ` hubicka at gcc dot gnu.org 2011-01-10 21:27 ` hjl.tools at gmail dot com 2011-02-14 20:34 ` rafael.espindola at gmail dot com 2011-02-15 18:51 ` hubicka at ucw dot cz 2011-02-15 19:45 ` rafael.espindola at gmail dot com 2011-02-16 0:23 ` hubicka at ucw dot cz 2011-02-16 4:04 ` rafael.espindola at gmail dot com [this message] 2011-02-16 7:59 ` hubicka at ucw dot cz 2011-02-16 16:23 ` rafael.espindola at gmail dot com 2011-02-16 23:13 ` Jan Hubicka 2011-02-16 23:18 ` hubicka at ucw dot cz 2011-02-16 23:37 ` ccoutant at google dot com 2011-02-17 1:25 ` rafael.espindola at gmail dot com 2011-08-27 18:16 ` hubicka at gcc dot gnu.org 2011-09-26 21:47 ` ccoutant at gcc dot gnu.org 2011-09-27 0:23 ` ccoutant at gcc dot gnu.org 2011-09-28 13:09 ` hubicka at gcc dot gnu.org 2011-10-02 10:42 ` hubicka at gcc dot gnu.org 2012-05-10 7:32 ` vincenzo.innocente at cern dot ch 2012-05-10 7:54 ` rguenth at gcc dot gnu.org 2012-05-10 8:52 ` vincenzo.innocente at cern dot ch 2012-05-10 16:06 ` vincenzo.innocente at cern dot ch 2012-05-10 17:10 ` hubicka at ucw dot cz 2012-05-10 17:17 ` vincenzo.innocente at cern dot ch 2012-05-12 14:37 ` hubicka at gcc dot gnu.org 2012-05-14 8:13 ` vincenzo.innocente at cern dot ch
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-47247-4-85AlHhvAeq@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).