On 05/14/2010 03:40 PM, Richard Guenther wrote:
On Fri, May 14, 2010 at 3:34 PM, Toon Moene 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-pl
On Fri, May 14, 2010 at 3:34 PM, Toon Moene 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
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 -fwho
> 2010/4/29 Jan Hubicka :
> >> 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
> >> b
2010/4/29 Jan Hubicka :
>> 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
Richard Guenther 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 shouldn't
> be impossible a
> 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 ke
On Thu, Apr 29, 2010 at 11:19 AM, Steven Bosscher wrote:
> On Thu, Apr 29, 2010 at 10:57 AM, Richard Guenther
> 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 g
On Thu, Apr 29, 2010 at 10:57 AM, Richard Guenther
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 for old or non-gnu LDs
On Thu, Apr 29, 2010 at 6:11 AM, Dave Korn
wrote:
> On 26/04/2010 10:46, Richard Guenther wrote:
>> On Mon, Apr 26, 2010 at 4:25 AM, Dave Korn wrote:
>
>>> If I understand correctly, what we farm out to gold/lto-plugin is the task
>>> of identifying a) which archive members are required to be pul
On Mon, Apr 26, 2010 at 4:25 AM, Dave Korn
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 option, I'd be pleased to
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 http://gcc.gnu.
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 http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00015.html for some
firs
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 Sun, Apr 25, 2010 at 9:37 PM, Steven Bosscher wrote:
> On Sun, Apr 25, 2010 at 9:26 PM, Richard Guenther
> 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
On Sun, Apr 25, 2010 at 9:26 PM, Richard Guenther
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 do you believe it is un
On Sun, Apr 25, 2010 at 1:24 PM, Toon Moene wrote:
> Richard Guenther wrote:
>
>> On Sat, Apr 24, 2010 at 3:28 PM, Toon Moene wrote:
>
>>> lto-symtab.c:549:
>>>
>>> 524
>>> 525 /* Helper to process the decl chain for the symbol table entry
>>> *SLOT.
>>> */
>>> 526
>>> 527 static int
>>>
Richard Guenther wrote:
On Sat, Apr 24, 2010 at 3:28 PM, Toon Moene 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 ATTRIBUTE_UNUSED)
On Sat, Apr 24, 2010 at 3:28 PM, Toon Moene 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: in lto
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 re
20 matches
Mail list logo
