[PATCH 1/2] Fix -fno-lto (PR lto/46905)

Andi Kleen andi@firstfloor.org
Mon Dec 20 05:05:00 GMT 2010


On Sat, Dec 18, 2010 at 09:24:39PM +0100, Richard Guenther wrote:
> On Thu, Dec 16, 2010 at 5:56 PM, Andi Kleen <andi@firstfloor.org> wrote:
> > On Thu, Dec 16, 2010 at 03:39:33PM +0000, Joseph S. Myers wrote:
> >> On Thu, 16 Dec 2010, Richard Guenther wrote:
> >>
> >> > > I also tried to do it without opts.c, but setting an 0 initialization
> >> > > value for the -fno-lto entry, but that didn't work either.
> >> >
> >> > Huh, that's strange.  Joseph, do you have any idea why?  Is it because
> >> > of how flags get passed to collect2?
> >>
> >> Having both flto and fno-lto in common.opt seems dodgy.  Try making the
> >> code in opts.c that handles OPT_flto check "value" (value == 0 meaning
> >> -fno-lto) instead.
> >
> > That worked. Here's an updated version. Ok now?
> 
> Ok.

Committed.

> 
> Can you check if you also need to update the linker plugin to not
> claim object files if -fno-lto is in effect?

When -fuse-linker-plugin is specified the plugin will be unconditionally
called and always claim independent of any other options.

> 
> Btw, what happens with -flto -fno-lto -flto?

Does LTO on a simple test.

-Andi



More information about the Gcc-patches mailing list