On 05/14/2010 03:40 PM, Richard Guenther wrote:
On Fri, May 14, 2010 at 3:34 PM, Toon Moenet...@moene.org wrote:
On 04/25/2010 01:24 PM, Toon Moene wrote:
Richard Guenther wrote:
[ Concerning this assert ]
It is checking that for one symbol we only have one definition.
You are using
On 04/25/2010 01:24 PM, Toon Moene wrote:
Richard Guenther wrote:
[ Concerning this assert ]
It is checking that for one symbol we only have one definition.
You are using -fuse-linker-plugin?
Indeed, I do (all of our code ends up in libraries - .a files - so I
have to, to make -flto
On Fri, May 14, 2010 at 3:34 PM, Toon Moene t...@moene.org wrote:
On 04/25/2010 01:24 PM, Toon Moene wrote:
Richard Guenther wrote:
[ Concerning this assert ]
It is checking that for one symbol we only have one definition.
You are using -fuse-linker-plugin?
Indeed, I do (all of our code
On Thu, Apr 29, 2010 at 10:57 AM, Richard Guenther
richard.guent...@gmail.com wrote:
Yes - that would be basically a linker plugin without plugin support.
And I'd go even further and have LD provide a complete symbol
resolution set like we get from the gold linker-plugin.
That wouldn't help
On Thu, Apr 29, 2010 at 11:19 AM, Steven Bosscher stevenb@gmail.com wrote:
On Thu, Apr 29, 2010 at 10:57 AM, Richard Guenther
richard.guent...@gmail.com wrote:
Yes - that would be basically a linker plugin without plugin support.
And I'd go even further and have LD provide a complete
Well, we'd then need to re-architect the symbol merging and
LTO unit read-in to properly honor linking semantics (drop
a LTO unit from an archive if it doesn't resolve any unresolved
symbols). I don't know how easy that will be, but it shouldn't
be impossible at least.
We also should keep
Richard Guenther richard.guent...@gmail.com writes:
Well, we'd then need to re-architect the symbol merging and
LTO unit read-in to properly honor linking semantics (drop
a LTO unit from an archive if it doesn't resolve any unresolved
symbols). I don't know how easy that will be, but it
2010/4/29 Jan Hubicka hubi...@ucw.cz:
Well, we'd then need to re-architect the symbol merging and
LTO unit read-in to properly honor linking semantics (drop
a LTO unit from an archive if it doesn't resolve any unresolved
symbols). I don't know how easy that will be, but it shouldn't
be
2010/4/29 Jan Hubicka hubi...@ucw.cz:
Well, we'd then need to re-architect the symbol merging and
LTO unit read-in to properly honor linking semantics (drop
a LTO unit from an archive if it doesn't resolve any unresolved
symbols). I don't know how easy that will be, but it shouldn't
be
On Mon, Apr 26, 2010 at 4:25 AM, Dave Korn
dave.korn.cyg...@googlemail.com wrote:
On 25/04/2010 23:16, Steven Bosscher wrote:
On Mon, Apr 26, 2010 at 12:27 AM, Dave Korn wrote:
Is there a PR open about this, or any notes anywhere? Being as I use a
non-ELF platform and so gold is not an
Richard Guenther wrote:
On Sat, Apr 24, 2010 at 3:28 PM, Toon Moene t...@moene.org wrote:
lto-symtab.c:549:
524
525 /* Helper to process the decl chain for the symbol table entry *SLOT.
*/
526
527 static int
528 lto_symtab_merge_decls_1 (void **slot, void *data
On Sun, Apr 25, 2010 at 1:24 PM, Toon Moene t...@moene.org wrote:
Richard Guenther wrote:
On Sat, Apr 24, 2010 at 3:28 PM, Toon Moene t...@moene.org wrote:
lto-symtab.c:549:
524
525 /* Helper to process the decl chain for the symbol table entry
*SLOT.
*/
526
527 static int
On Sun, Apr 25, 2010 at 9:26 PM, Richard Guenther
richard.guent...@gmail.com wrote:
No, gold should choose a single prevailing definition. The issue is that
gold and the linker-plugin seem to be unmaintained.
Looking at the binutils list, there seems to be a lot of gold patching
going on. Why
On Sun, Apr 25, 2010 at 9:37 PM, Steven Bosscher stevenb@gmail.com wrote:
On Sun, Apr 25, 2010 at 9:26 PM, Richard Guenther
richard.guent...@gmail.com wrote:
No, gold should choose a single prevailing definition. The issue is that
gold and the linker-plugin seem to be unmaintained.
On 25/04/2010 21:41, Richard Guenther wrote:
I'm somewhat uncomfortable that we have the two paths into LTO,
by using collect2 or the linker plugin. Unfortunately the linker-plugin
is currently the only path that supports LTOing static libs. As soon
as that issue is solved we should IMHO
On Mon, Apr 26, 2010 at 12:27 AM, Dave Korn
dave.korn.cyg...@googlemail.com wrote:
Is there a PR open about this, or any notes anywhere? Being as I use a
non-ELF platform and so gold is not an option, I'd be pleased to help with
making this work.
See
On 25/04/2010 23:16, Steven Bosscher wrote:
On Mon, Apr 26, 2010 at 12:27 AM, Dave Korn wrote:
Is there a PR open about this, or any notes anywhere? Being as I use a
non-ELF platform and so gold is not an option, I'd be pleased to help with
making this work.
See
While compiling our Weather Forecasting code with the latest trunk, I
got the following (don't know how long this has been a problem, as I
haven't tried -flto recently):
lto1: internal compiler error: in lto_symtab_merge_decls_1, at
lto-symtab.c:549
Please submit a full bug report
On Sat, Apr 24, 2010 at 3:28 PM, Toon Moene t...@moene.org wrote:
While compiling our Weather Forecasting code with the latest trunk, I got
the following (don't know how long this has been a problem, as I haven't
tried -flto recently):
lto1: internal compiler error
19 matches
Mail list logo
