diff mbox

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

Message ID 20101216165611.GE26663@basil.fritz.box
State New
Headers show

Commit Message

Andi Kleen Dec. 16, 2010, 4:56 p.m. UTC
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?

From: Andi Kleen <ak@linux.intel.com>
Date: Wed, 15 Dec 2010 20:10:22 +0100
Subject: [PATCH] Fix -fno-lto (PR lto/46905)

This fixes PR lto/46905.

It's sometimes convenient in large Makefiles to globally enable LTO
in CFLAGS, but disable it again for specific files. The simplest
way to do that is appending -fno-lto, but that didn't work.
Add explicit code to handle this case.

gcc/

2010-12-15  Andi Kleen	<ak@linux.intel.com>

	PR lto/46905
	* collect2.c (main): Handle -fno-lto.
	* common.opt (fno-lto): Add.
	* opts.c (common_handle_option): Handle OPT_fno_lto.

Comments

Richard Biener Dec. 18, 2010, 8:24 p.m. UTC | #1
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.

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

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

Thanks,
Richard.

> From: Andi Kleen <ak@linux.intel.com>
> Date: Wed, 15 Dec 2010 20:10:22 +0100
> Subject: [PATCH] Fix -fno-lto (PR lto/46905)
>
> This fixes PR lto/46905.
>
> It's sometimes convenient in large Makefiles to globally enable LTO
> in CFLAGS, but disable it again for specific files. The simplest
> way to do that is appending -fno-lto, but that didn't work.
> Add explicit code to handle this case.
>
> gcc/
>
> 2010-12-15  Andi Kleen  <ak@linux.intel.com>
>
>        PR lto/46905
>        * collect2.c (main): Handle -fno-lto.
>        * common.opt (fno-lto): Add.
>        * opts.c (common_handle_option): Handle OPT_fno_lto.
>
> diff --git a/gcc/collect2.c b/gcc/collect2.c
> index 89b21d5..77f794f 100644
> --- a/gcc/collect2.c
> +++ b/gcc/collect2.c
> @@ -1211,6 +1211,8 @@ main (int argc, char **argv)
>         else if ((! strncmp (argv[i], "-flto=", 6)
>                  || ! strcmp (argv[i], "-flto")) && ! use_plugin)
>          lto_mode = LTO_MODE_WHOPR;
> +       else if (!strncmp (argv[i], "-fno-lto", 8))
> +         lto_mode = LTO_MODE_NONE;
>         else if (! strcmp (argv[i], "-plugin"))
>          {
>            use_plugin = true;
> diff --git a/gcc/opts.c b/gcc/opts.c
> index 2c8e767..cc4181e 100644
> --- a/gcc/opts.c
> +++ b/gcc/opts.c
> @@ -1670,7 +1670,7 @@ common_handle_option (struct gcc_options *opts,
>       break;
>
>     case OPT_flto:
> -      opts->x_flag_lto = "";
> +      opts->x_flag_lto = value ? "" : NULL;
>       break;
>
>     case OPT_w:
>
Andi Kleen Dec. 19, 2010, 7:37 p.m. UTC | #2
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
diff mbox

Patch

diff --git a/gcc/collect2.c b/gcc/collect2.c
index 89b21d5..77f794f 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -1211,6 +1211,8 @@  main (int argc, char **argv)
         else if ((! strncmp (argv[i], "-flto=", 6)
 		  || ! strcmp (argv[i], "-flto")) && ! use_plugin)
 	  lto_mode = LTO_MODE_WHOPR;
+	else if (!strncmp (argv[i], "-fno-lto", 8))
+	  lto_mode = LTO_MODE_NONE;
         else if (! strcmp (argv[i], "-plugin"))
 	  {
 	    use_plugin = true;
diff --git a/gcc/opts.c b/gcc/opts.c
index 2c8e767..cc4181e 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1670,7 +1670,7 @@  common_handle_option (struct gcc_options *opts,
       break;
 
     case OPT_flto:
-      opts->x_flag_lto = "";
+      opts->x_flag_lto = value ? "" : NULL;
       break;
 
     case OPT_w: