Ian Lance Taylor writes:
> 2011-01-18 Ian Lance Taylor
>
> * plugin.cc (class Plugin_rescan): Define new class.
> (Plugin_manager::claim_file): Set any_claimed_.
> (Plugin_manager::save_archive): New function.
> (Plugin_manager::save_input_group): New function.
>
>> I'm not sure if with your patch the add_input_library or
>> add_input_file plugin hooks are completely useless (and thus
>> gold could simply ignore those at all).
>
> The plugin does need to use the add_input_file callback. In any case
> I'm not sure it's a great idea for gold to ignore a hook
> On Wed, Jan 19, 2011 at 1:27 AM, Ian Lance Taylor wrote:
> > After some discussion on IRC, here is another approach to resolving the
> > issue with static linking and LTO.
> >
> > In this approach, the linker keeps track of all archives found after the
> > first file claimed by the plugin. If t
Richard Guenther writes:
> Nice. Can we on the GCC side somehow identify Gold versions
> that support this and avoid -pass-through handling in that case?
Sure. The LDPT_GOLD_VERSION tag, which lto-plugin currently ignores,
will return the version of gold. I can bump that version when I commit
On Wed, Jan 19, 2011 at 1:27 AM, Ian Lance Taylor wrote:
> After some discussion on IRC, here is another approach to resolving the
> issue with static linking and LTO.
>
> In this approach, the linker keeps track of all archives found after the
> first file claimed by the plugin. If the plugin ad
On Tue, Jan 18, 2011 at 4:27 PM, Ian Lance Taylor wrote:
> After some discussion on IRC, here is another approach to resolving the
> issue with static linking and LTO.
>
> In this approach, the linker keeps track of all archives found after the
> first file claimed by the plugin. If the plugin ad
After some discussion on IRC, here is another approach to resolving the
issue with static linking and LTO.
In this approach, the linker keeps track of all archives found after the
first file claimed by the plugin. If the plugin adds any object files,
and the object files refer to any symbols whic
> Here is an alternative proposal, with a patch for gold.
>
> We add a new plugin vector: LDPT_REGISTER_RESCAN_ARCHIVE_HOOK. Like
> LDPT_REGISTER_CLAIM_FILE_HOOK, this gives the plugin the address of a
> function which can register a plugin function: rescan_archive.
>
> typedef
> enum ld_plugin_st
Alan Modra writes:
> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
>> Personally, I think 2 stage linking is one way to fix this issue.
>
> Ian has stated that he thinks this is a really bad idea. I haven't
> approved the patch because I value Ian's opinion, and can see why he
> think
On Tue, Dec 7, 2010 at 12:12 PM, H.J. Lu wrote:
> On Mon, Dec 6, 2010 at 9:20 AM, H.J. Lu wrote:
>> On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote:
>>> On 06/12/2010 02:20, H.J. Lu wrote:
>>>
BTW, the new linker passed bootstrap-lto with all default languages.
I am planning to
On Mon, Dec 6, 2010 at 9:20 AM, H.J. Lu wrote:
> On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote:
>> On 06/12/2010 02:20, H.J. Lu wrote:
>>
>>> BTW, the new linker passed bootstrap-lto with all default languages.
>>> I am planning to include this patch in the next Linux binutils.
>>>
On 07/12/2010 08:33, Tristan Gingold wrote:
> On Dec 6, 2010, at 6:23 PM, Dave Korn wrote:
>> Tristan, sorry, you must be sick of hearing from me by now,
>
> No, not really :-)
>
>> but I notice the branch was still labile a couple of hours ago... it
>> would be really good if we could get HJ's p
On Dec 6, 2010, at 6:23 PM, Dave Korn wrote:
> Tristan, sorry, you must be sick of hearing from me by now,
No, not really :-)
> but I notice the
> branch was still labile a couple of hours ago... it would be really good if we
> could get HJ's patch approved and backported before you spin the re
On Mon, Dec 6, 2010 at 5:19 PM, Cary Coutant wrote:
I see no particular reason why that should be the case. The issues are
conceptually simple.
>>>
>>> I'd like to a gold implementation which works on all known cases.
>
> You'd like to what?
I'd like to see gold implementation which wo
>>> I see no particular reason why that should be the case. The issues are
>>> conceptually simple.
>>
>> I'd like to a gold implementation which works on all known cases.
You'd like to what?
> BTW, gold LTO plugin miscompiled 416.gamess in SPEC CPU 2006:
>
> http://www.sourceware.org/bugzilla/s
On Mon, Dec 6, 2010 at 5:02 PM, H.J. Lu wrote:
> On Mon, Dec 6, 2010 at 4:08 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> On Mon, Dec 6, 2010 at 3:54 PM, Ian Lance Taylor wrote:
Alan Modra writes:
> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
>> Person
On Mon, Dec 6, 2010 at 4:08 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Mon, Dec 6, 2010 at 3:54 PM, Ian Lance Taylor wrote:
>>> Alan Modra writes:
>>>
On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
> Personally, I think 2 stage linking is one way to fix this issu
"H.J. Lu" writes:
> On Mon, Dec 6, 2010 at 3:54 PM, Ian Lance Taylor wrote:
>> Alan Modra writes:
>>
>>> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
Personally, I think 2 stage linking is one way to fix this issue.
>>>
>>> Ian has stated that he thinks this is a really bad ide
On Mon, Dec 6, 2010 at 3:55 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> I don't have such programs at hand. Will timings from gccgo, which is
>> written in C++, help?
>
> gccgo by itself is not really a large C++ program. It's only about
> 50,000 lines of C++.
>
> Building gcc with --en
On Mon, Dec 6, 2010 at 3:54 PM, Ian Lance Taylor wrote:
> Alan Modra writes:
>
>> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
>>> Personally, I think 2 stage linking is one way to fix this issue.
>>
>> Ian has stated that he thinks this is a really bad idea. I haven't
>> approved th
"H.J. Lu" writes:
> I don't have such programs at hand. Will timings from gccgo, which is
> written in C++, help?
gccgo by itself is not really a large C++ program. It's only about
50,000 lines of C++.
Building gcc with --enable-build-with-cxx would get you a large C++
program, but of course i
Alan Modra writes:
> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
>> Personally, I think 2 stage linking is one way to fix this issue.
>
> Ian has stated that he thinks this is a really bad idea. I haven't
> approved the patch because I value Ian's opinion, and can see why he
> think
On Mon, Dec 6, 2010 at 3:29 PM, Alan Modra wrote:
> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
>> Personally, I think 2 stage linking is one way to fix this issue.
>
> Ian has stated that he thinks this is a really bad idea. I haven't
> approved the patch because I value Ian's opini
On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
> Personally, I think 2 stage linking is one way to fix this issue.
Ian has stated that he thinks this is a really bad idea. I haven't
approved the patch because I value Ian's opinion, and can see why he
thinks it is the wrong way to go. O
On Mon, Dec 6, 2010 at 10:19 AM, Dave Korn wrote:
> On 06/12/2010 17:44, H.J. Lu wrote:
>> On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote:
>>> Well, I reckon this patch is great (but don't have the approval rights).
>>> It's passed an lto-bootstrap of gcc on i686-pc-cygwin and the tests are wel
On 06/12/2010 17:44, H.J. Lu wrote:
> On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote:
>> Well, I reckon this patch is great (but don't have the approval rights).
>> It's passed an lto-bootstrap of gcc on i686-pc-cygwin and the tests are well
>> underway without anything abnormal showing up.
>>
>
On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote:
>
> Well, I reckon this patch is great (but don't have the approval rights).
> It's passed an lto-bootstrap of gcc on i686-pc-cygwin and the tests are well
> underway without anything abnormal showing up.
>
Can we close
http://gcc.gnu.org/bugzill
On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote:
> On 06/12/2010 02:20, H.J. Lu wrote:
>
>> BTW, the new linker passed bootstrap-lto with all default languages.
>> I am planning to include this patch in the next Linux binutils.
>>
> I missed the IR object in an archive:
>
>
On 06/12/2010 02:20, H.J. Lu wrote:
> BTW, the new linker passed bootstrap-lto with all default languages.
> I am planning to include this patch in the next Linux binutils.
>
I missed the IR object in an archive:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690#c34
On Sun, Dec 5, 2010 at 4:11 PM, H.J. Lu wrote:
> On Sun, Dec 5, 2010 at 10:22 AM, H.J. Lu wrote:
>> On Sat, Dec 4, 2010 at 4:43 PM, H.J. Lu wrote:
>>> On Sat, Dec 4, 2010 at 9:34 AM, H.J. Lu wrote:
On Fri, Dec 3, 2010 at 10:07 PM, H.J. Lu wrote:
> On Fri, Dec 3, 2010 at 6:34 PM, H.J.
On Sun, Dec 5, 2010 at 10:22 AM, H.J. Lu wrote:
> On Sat, Dec 4, 2010 at 4:43 PM, H.J. Lu wrote:
>> On Sat, Dec 4, 2010 at 9:34 AM, H.J. Lu wrote:
>>> On Fri, Dec 3, 2010 at 10:07 PM, H.J. Lu wrote:
On Fri, Dec 3, 2010 at 6:34 PM, H.J. Lu wrote:
> On Fri, Dec 3, 2010 at 6:23 PM, Dave
On Sat, Dec 4, 2010 at 4:43 PM, H.J. Lu wrote:
> On Sat, Dec 4, 2010 at 9:34 AM, H.J. Lu wrote:
>> On Fri, Dec 3, 2010 at 10:07 PM, H.J. Lu wrote:
>>> On Fri, Dec 3, 2010 at 6:34 PM, H.J. Lu wrote:
On Fri, Dec 3, 2010 at 6:23 PM, Dave Korn
wrote:
> On 04/12/2010 01:24, H.J. Lu w
On Sat, Dec 4, 2010 at 9:34 AM, H.J. Lu wrote:
> On Fri, Dec 3, 2010 at 10:07 PM, H.J. Lu wrote:
>> On Fri, Dec 3, 2010 at 6:34 PM, H.J. Lu wrote:
>>> On Fri, Dec 3, 2010 at 6:23 PM, Dave Korn
>>> wrote:
On 04/12/2010 01:24, H.J. Lu wrote:
> I checked in a patch to implement stag
On Fri, Dec 3, 2010 at 10:07 PM, H.J. Lu wrote:
> On Fri, Dec 3, 2010 at 6:34 PM, H.J. Lu wrote:
>> On Fri, Dec 3, 2010 at 6:23 PM, Dave Korn wrote:
>>> On 04/12/2010 01:24, H.J. Lu wrote:
>>>
I checked in a patch to implement stage 2 linking. Everything
seems to work, including "gcc -
On Fri, Dec 3, 2010 at 6:34 PM, H.J. Lu wrote:
> On Fri, Dec 3, 2010 at 6:23 PM, Dave Korn wrote:
>> On 04/12/2010 01:24, H.J. Lu wrote:
>>
>>> I checked in a patch to implement stage 2 linking. Everything
>>> seems to work, including "gcc -static ... -lm".
>>
>> Any chance you could send a comp
35 matches
Mail list logo
