https://sourceware.org/bugzilla/show_bug.cgi?id=19842
gubbins changed:
What|Removed |Added
CC||dave.gittins at gmail dot com
--- Comment #
https://sourceware.org/bugzilla/show_bug.cgi?id=19842
Carlos O'Donell changed:
What|Removed |Added
Status|NEW |ASSIGNED
Component|core
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 are
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 (DRW-internal-bui
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, but
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:
> https://sour
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 appropriately?
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
--
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
https://sourceware.org/bugzilla/show_bug.cgi?id=19842
--- Comment #29 from hubicka at ucw dot cz ---
> /* Skip weak definitions of symbols that are already defined. */
> if (newdef && olddef && newweak)
> {
> /* Don't skip new non-IR weak syms. */
> if (!(oldbfd != NULL
>
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 my
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.
Sorr
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 deliberately
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 648c5cbbf34dcbf96bde7e07b1
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).
Wh
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 ar
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 pat
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 (!
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 (_bfd_elf_merge_symbo
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
> plugin symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=19842
H.J. Lu changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #18 fro
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 wou
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
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
#in
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-binutil
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:
out/haswell/main/Sy
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 email.
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
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
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 g
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
https://sourceware.org/bugzilla/show_bug.cgi?id=19842
Markus Trippelsdorf changed:
What|Removed |Added
CC||hubicka at ucw dot cz,
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 <+0>: push
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 init
https://sourceware.org/bugzilla/show_bug.cgi?id=19842
Cary Coutant changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Cary Cout
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
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 as
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
mentio
38 matches
Mail list logo