[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 Carlos O'Donell changed: What|Removed |Added Status|NEW |ASSIGNED Component|core

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #36 from Matt Godbolt --- Ok; with a GCC 6 snapshot build (20160221) there's no crash when I link with -fdump-ipa-all I will tar up the results and send you an email with the link. -- You are receiving this mail because: You

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #35 from Matt Godbolt --- Hi Honza, I checkout the branch of my code where the problem exists and confirmed I could reproduce. Then I re-linked with =-save-temps -fdump-ipa-all and sadly I get an ICE: GNU GIMPLE

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #34 from Cary Coutant --- I've been trying to come up with a small repro for this, but so far have not been successful. I've tried deepening the inline stack, adding register pressure, and even fiddled with inlining parameters,

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #33 from Matt Godbolt --- Yes, I can do that. I'll get back to you with the relevant information as soon as I can. On Wed, Mar 30, 2016 at 10:23 AM hubicka at ucw dot cz < sourceware-bugzi...@sourceware.org> wrote: >

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #32 from hubicka at ucw dot cz --- > Hi all, > > Just following up on this as it seems to have stalled: @honza, do you concur > this may be a bug in GCC? If so shall I file something, or are you happy to > capture it

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #31 from Matt Godbolt --- Hi all, Just following up on this as it seems to have stalled: @honza, do you concur this may be a bug in GCC? If so shall I file something, or are you happy to capture it appropriately? Thanks, Matt

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #30 from Cary Coutant --- > The LTO symbols are of course not the > final symbols but only tentative definitions. When merging symbols, if we > see a weak symbol in a non-LTO object after seeing the tentative definition > from an

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #28 from Alan Modra --- I was just trying to answer comment #21. In that narrow context I didn't understand your mention of "non-LTO object", and thought you must mean a -ffat-lto-objects file. So let's forget that, and ignore

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #27 from Cary Coutant --- > The case where this came up is when we are merging the optimised object, and > were given a weak symbol. The non-LTO object (from -ffat-lto-objects) isn't > loaded if the plugin claims the object.

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #26 from Alan Modra --- > What's your reasoning? If the prevailing definition is in the IR, the > compiler will (theoretically) supply a more-optimized version of that > function than the one in the non-LTO object. Why

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #25 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Cary Coutant : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=648c5cbbf34dcbf96bde7e07b14868777fd5d635 commit

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #24 from Cary Coutant --- > If _bfd_elf_merge_symbol sets *skip, then the new symbol will be ignored. We > don't want to do that with a new real weak symbol if we currently have an > IR-only definition (either strong or weak).

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #23 from Alan Modra --- If _bfd_elf_merge_symbol sets *skip, then the new symbol will be ignored. We don't want to do that with a new real weak symbol if we currently have an IR-only definition (either strong or weak). -- You

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #22 from Cary Coutant --- > Hmmm. Unless this was part of an attempt to preserve existing behavior while > moving from a separate hash table to using the new flags, it looks like an > unrelated change that was slipped into this

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #21 from Cary Coutant --- >/* Skip weak definitions of symbols that are already defined. */ >if (newdef && olddef && newweak) > { > - *skip = TRUE; > + /* Don't skip new non-IR weak syms. */ > + if

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #20 from H.J. Lu --- (In reply to Cary Coutant from comment #19) > > commit 3a5dbfb2502e7a49422f13c9cec2becfd46f44f1 > > Author: Alan Modra > > Date: Tue Jun 21 14:55:26 2011 + > > > > * elflink.c

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #19 from Cary Coutant --- > commit 3a5dbfb2502e7a49422f13c9cec2becfd46f44f1 > Author: Alan Modra > Date: Tue Jun 21 14:55:26 2011 + > > * elflink.c (_bfd_elf_merge_symbol): Allow type changes for >

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 H.J. Lu changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #18

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #17 from Cary Coutant --- > For ld, non-LTO definition takes precedence over LTO one. What symbol resolution does ld tell the compiler for the LTO definition? The LTO design was intended to preserve the same binding order that

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #16 from H.J. Lu --- For ld, non-LTO definition takes precedence over LTO one. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #15 from H.J. Lu --- Here is the difference between gold and ld: [hjl@gnu-6 test]$ cat foo.c #include void foo () __attribute__ ((weak)); void foo () { printf ("Non-LTO\n"); } void bar () { } [hjl@gnu-6 test]$ cat foo1.c

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #14 from Matt Godbolt --- I've sent my full results to H.J.Lu and Cary directly. Thanks both. -- You are receiving this mail because: You are on the CC list for the bug. ___

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #13 from Matt Godbolt --- Thanks, I will do. grepping the -v output: $ grep '_ZNSt8functionIFvvEED[12]Ev' gcc_verbose_output /tmp/gcc/bin/../lib/gcc/x86_64-linux-gnu/5.2.0/../../../../x86_64-linux-gnu/bin/ld:

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #12 from H.J. Lu --- (In reply to Matt Godbolt from comment #11) > Hi H.J. Lu, > > I've made a build of your binutils, supplied -Wl,-plugin-save-temps and kept > all the files generated. I will share the files with you over

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #11 from Matt Godbolt --- Hi H.J. Lu, I've made a build of your binutils, supplied -Wl,-plugin-save-temps and kept all the files generated. I will share the files with you over email. Looking at the ltrans1.o file generated with

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #10

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #9 from Matt Godbolt --- Hi H.J.Hu, Cary already made a patched binutils (users/ccoutant/gold-record) which does a similar thing: that's how Cary was able to debug further. Would it be useful for me to build your branch too and

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #8 from H.J. Lu --- users/hjl/lto-mixed/master branch implemented -plugin-save-temps linker option. It can be used together with GCC -save-temps to figure out what ld does. -- You are receiving this mail because: You are on the

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 Markus Trippelsdorf changed: What|Removed |Added CC||hubicka at ucw dot cz,

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #6 from Matt Godbolt --- I just tried with a snapshot build of GCC I had around (6.0.0 20160221), and the problem persists: Dump of assembler code for function std::_List_node::~_List_node(): 0x0077434c

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #5 from Matt Godbolt --- Wow! What an awesome diagnosis: thank you so much for digging in to this! I've tried with GCC 5.3.0 but not any GCC 6+ snapshots. The GCC guys on the mailing list didn't seem to think it was a GCC bug

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Cary

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #2 from Cary Coutant --- > Please attach the complete stdout and stderr from running gcc with "-v > --save-temps -Wl,--no-demangle". Look through that output for lines > that say "[Leaving ...]", and tar up all the .ltrans.s files

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #3 from Matt Godbolt --- Hi Cary, The output of even the compiled files is somewhat sensitive. Would it be possible to email them directly to you instead of placing them here? Also; the process you described left some .o files

[Bug gold/19842] LTO build fails to write call address for weak symbol reference

https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #1 from Cary Coutant --- Please attach the complete stdout and stderr from running gcc with "-v --save-temps -Wl,--no-demangle". Look through that output for lines that say "[Leaving ...]", and tar up all the .ltrans.s files