[PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)

[PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)

[Richard Guenther]

This tries to find a way to prepend explicitly set command-line options
by those implicitly set by the frontend (-fexceptions in this case).
Unfortunately we don't seem to have a good way to extract this information
easily, so for -fexceptions I hope all frontends set that during
init_options_struct.

Another nice flag to preserve would be the complex eval method, as
LTO currently has

static void
lto_init_options_struct (struct gcc_options *opts)
{
  /* By default, C99-like requirements for complex multiply and divide.
     ???  Until the complex method is encoded in the IL this is the only
     safe choice.  This will pessimize Fortran code with LTO unless
     people specify a complex method manually or use -ffast-math.  */
  opts->x_flag_complex_method = 2;
}

But we have multiple flags that influence it(?) and none(!?) seems
to be set by Fortran frontend specific code ... (and Fortran sets
most options during post_options).

Joseph, do you have any advise on how to address frontend specific
options in a more general way?  I'm trying to re-construct a
command-line that when processed frontend agnostic would produce
the same end-result in global_options as if going through the frontend.
Is that even possible (do you have option examples that would show
this is impossible?)

Bootstrap/regtest running on x86_64-unknown-linux-gnu.

Thanks,
Richard.

2011-11-07  Richard Guenther  <rguenther@suse.de>

	PR lto/50999
	* lto-opts.c (append_to_collect_gcc_options): Split out from...
	(lto_write_options): ... here.  Prepend frontend specific flags.

Index: gcc/lto-opts.c
===================================================================
*** gcc/lto-opts.c	(revision 181080)
--- gcc/lto-opts.c	(working copy)
*************** along with GCC; see the file COPYING3.
*** 34,60 ****
  #include "diagnostic.h"
  #include "lto-streamer.h"
  #include "toplev.h"
  
  /* Write currently held options to an LTO IL section.  */
  
  void
  lto_write_options (void)
  {
    struct lto_output_stream stream;
    char *section_name;
    struct obstack temporary_obstack;
    unsigned int i, j;
    char *args;
  
    section_name = lto_get_section_name (LTO_section_opts, NULL, NULL);
    lto_begin_section (section_name, false);
    memset (&stream, 0, sizeof (stream));
  
    obstack_init (&temporary_obstack);
    for (i = 1; i < save_decoded_options_count; ++i)
      {
        struct cl_decoded_option *option = &save_decoded_options[i];
-       const char *q, *p;
  
        /* Skip frontend and driver specific options here.  */
        if (!(cl_options[option->opt_index].flags & (CL_COMMON|CL_TARGET|CL_LTO)))
--- 34,97 ----
  #include "diagnostic.h"
  #include "lto-streamer.h"
  #include "toplev.h"
+ #include "langhooks.h"
+ 
+ /* Append the option piece OPT to the COLLECT_GCC_OPTIONS string
+    set up by OB, appropriately quoted and separated by spaces
+    (if !*FIRST_P).  */
+ 
+ static void
+ append_to_collect_gcc_options (struct obstack *ob,
+ 			       bool *first_p, const char *opt)
+ {
+   const char *p, *q = opt;
+   if (!first_p)
+     obstack_grow (ob, " ", 1);
+   obstack_grow (ob, "'", 1);
+   while ((p = strchr (q, '\'')))
+     {
+       obstack_grow (ob, q, p - q);
+       obstack_grow (ob, "'\\''", 4);
+       q = ++p;
+     }
+   obstack_grow (ob, q, strlen (q));
+   obstack_grow (ob, "'", 1);
+   *first_p = false;
+ }
  
  /* Write currently held options to an LTO IL section.  */
  
  void
  lto_write_options (void)
  {
+   struct gcc_options lang_opts;
    struct lto_output_stream stream;
    char *section_name;
    struct obstack temporary_obstack;
    unsigned int i, j;
    char *args;
+   bool first_p = true;
  
    section_name = lto_get_section_name (LTO_section_opts, NULL, NULL);
    lto_begin_section (section_name, false);
    memset (&stream, 0, sizeof (stream));
  
    obstack_init (&temporary_obstack);
+ 
+   /* Output options enabled by the frontend explicitely.  The C family
+      frontends do that in the init_options_struct langhook.  Eventually
+      we should add a langhook that returns a cl_options array that
+      is processed before the user options.  */
+   memset (&lang_opts, 0, sizeof (lang_opts));
+   lang_hooks.init_options_struct (&lang_opts);
+   if (lang_opts.x_flag_exceptions)
+     append_to_collect_gcc_options (&temporary_obstack, &first_p,
+ 				   "-fexceptions");
+ 
+   /* Output explicitely passed options.  */
    for (i = 1; i < save_decoded_options_count; ++i)
      {
        struct cl_decoded_option *option = &save_decoded_options[i];
  
        /* Skip frontend and driver specific options here.  */
        if (!(cl_options[option->opt_index].flags & (CL_COMMON|CL_TARGET|CL_LTO)))
*************** lto_write_options (void)
*** 82,113 ****
  	  break;
  	}
  
!       if (i != 1)
! 	obstack_grow (&temporary_obstack, " ", 1);
!       obstack_grow (&temporary_obstack, "'", 1);
!       q = option->canonical_option[0];
!       while ((p = strchr (q, '\'')))
! 	{
! 	  obstack_grow (&temporary_obstack, q, p - q);
! 	  obstack_grow (&temporary_obstack, "'\\''", 4);
! 	  q = ++p;
! 	}
!       obstack_grow (&temporary_obstack, q, strlen (q));
!       obstack_grow (&temporary_obstack, "'", 1);
! 
!       for (j = 1; j < option->canonical_option_num_elements; ++j)
! 	{
! 	  obstack_grow (&temporary_obstack, " '", 2);
! 	  q = option->canonical_option[j];
! 	  while ((p = strchr (q, '\'')))
! 	    {
! 	      obstack_grow (&temporary_obstack, q, p - q);
! 	      obstack_grow (&temporary_obstack, "'\\''", 4);
! 	      q = ++p;
! 	    }
! 	  obstack_grow (&temporary_obstack, q, strlen (q));
! 	  obstack_grow (&temporary_obstack, "'", 1);
! 	}
      }
    obstack_grow (&temporary_obstack, "\0", 1);
    args = XOBFINISH (&temporary_obstack, char *);
--- 119,127 ----
  	  break;
  	}
  
!       for (j = 0; j < option->canonical_option_num_elements; ++j)
! 	append_to_collect_gcc_options (&temporary_obstack, &first_p,
! 				       option->canonical_option[j]);
      }
    obstack_grow (&temporary_obstack, "\0", 1);
    args = XOBFINISH (&temporary_obstack, char *);

Re: [PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)

[Eric Botcazou]

> This tries to find a way to prepend explicitly set command-line options
> by those implicitly set by the frontend (-fexceptions in this case).
> Unfortunately we don't seem to have a good way to extract this information
> easily, so for -fexceptions I hope all frontends set that during
> init_options_struct.

That's wrong for Ada: it is set in gnat_init_gcc_eh and cannot be set earlier 
because we support run time selection of the EH scheme.

-- 
Eric Botcazou

Re: [PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)

[Iain Sandoe]

On 7 Nov 2011, at 12:17, Richard Guenther wrote:

>
> This tries to find a way to prepend explicitly set command-line  
> options
> by those implicitly set by the frontend (-fexceptions in this case).
> Unfortunately we don't seem to have a good way to extract this  
> information
> easily, so for -fexceptions I hope all frontends set that during
> init_options_struct.

It would also be nice to preserve the Objective-C flavor (GNU/NeXT),  
since we have to make a guess for this in darwin.c when in lto.

>
> Another nice flag to preserve would be the complex eval method, as
> LTO currently has
>
> static void
> lto_init_options_struct (struct gcc_options *opts)
> {
>  /* By default, C99-like requirements for complex multiply and divide.
>     ???  Until the complex method is encoded in the IL this is the  
> only
>     safe choice.  This will pessimize Fortran code with LTO unless
>     people specify a complex method manually or use -ffast-math.  */
>  opts->x_flag_complex_method = 2;
> }
>
> But we have multiple flags that influence it(?) and none(!?) seems
> to be set by Fortran frontend specific code ... (and Fortran sets
> most options during post_options).
>
> Joseph, do you have any advise on how to address frontend specific
> options in a more general way?  I'm trying to re-construct a
> command-line that when processed frontend agnostic would produce
> the same end-result in global_options as if going through the  
> frontend.
> Is that even possible (do you have option examples that would show
> this is impossible?)
>
> Bootstrap/regtest running on x86_64-unknown-linux-gnu.
>
> Thanks,
> Richard.
>
> 2011-11-07  Richard Guenther  <rguenther@suse.de>
>
> 	PR lto/50999
> 	* lto-opts.c (append_to_collect_gcc_options): Split out from...
> 	(lto_write_options): ... here.  Prepend frontend specific flags.
>
> Index: gcc/lto-opts.c
> ===================================================================
> *** gcc/lto-opts.c	(revision 181080)
> --- gcc/lto-opts.c	(working copy)
> *************** along with GCC; see the file COPYING3.
> *** 34,60 ****
>  #include "diagnostic.h"
>  #include "lto-streamer.h"
>  #include "toplev.h"
>
>  /* Write currently held options to an LTO IL section.  */
>
>  void
>  lto_write_options (void)
>  {
>    struct lto_output_stream stream;
>    char *section_name;
>    struct obstack temporary_obstack;
>    unsigned int i, j;
>    char *args;
>
>    section_name = lto_get_section_name (LTO_section_opts, NULL, NULL);
>    lto_begin_section (section_name, false);
>    memset (&stream, 0, sizeof (stream));
>
>    obstack_init (&temporary_obstack);
>    for (i = 1; i < save_decoded_options_count; ++i)
>      {
>        struct cl_decoded_option *option = &save_decoded_options[i];
> -       const char *q, *p;
>
>        /* Skip frontend and driver specific options here.  */
>        if (!(cl_options[option->opt_index].flags & (CL_COMMON| 
> CL_TARGET|CL_LTO)))
> --- 34,97 ----
>  #include "diagnostic.h"
>  #include "lto-streamer.h"
>  #include "toplev.h"
> + #include "langhooks.h"
> +
> + /* Append the option piece OPT to the COLLECT_GCC_OPTIONS string
> +    set up by OB, appropriately quoted and separated by spaces
> +    (if !*FIRST_P).  */
> +
> + static void
> + append_to_collect_gcc_options (struct obstack *ob,
> + 			       bool *first_p, const char *opt)
> + {
> +   const char *p, *q = opt;
> +   if (!first_p)
> +     obstack_grow (ob, " ", 1);
> +   obstack_grow (ob, "'", 1);
> +   while ((p = strchr (q, '\'')))
> +     {
> +       obstack_grow (ob, q, p - q);
> +       obstack_grow (ob, "'\\''", 4);
> +       q = ++p;
> +     }
> +   obstack_grow (ob, q, strlen (q));
> +   obstack_grow (ob, "'", 1);
> +   *first_p = false;
> + }
>
>  /* Write currently held options to an LTO IL section.  */
>
>  void
>  lto_write_options (void)
>  {
> +   struct gcc_options lang_opts;
>    struct lto_output_stream stream;
>    char *section_name;
>    struct obstack temporary_obstack;
>    unsigned int i, j;
>    char *args;
> +   bool first_p = true;
>
>    section_name = lto_get_section_name (LTO_section_opts, NULL, NULL);
>    lto_begin_section (section_name, false);
>    memset (&stream, 0, sizeof (stream));
>
>    obstack_init (&temporary_obstack);
> +
> +   /* Output options enabled by the frontend explicitely.  The C  
> family
> +      frontends do that in the init_options_struct langhook.   
> Eventually
> +      we should add a langhook that returns a cl_options array that
> +      is processed before the user options.  */
> +   memset (&lang_opts, 0, sizeof (lang_opts));
> +   lang_hooks.init_options_struct (&lang_opts);
> +   if (lang_opts.x_flag_exceptions)
> +     append_to_collect_gcc_options (&temporary_obstack, &first_p,
> + 				   "-fexceptions");
> +
> +   /* Output explicitely passed options.  */
>    for (i = 1; i < save_decoded_options_count; ++i)
>      {
>        struct cl_decoded_option *option = &save_decoded_options[i];
>
>        /* Skip frontend and driver specific options here.  */
>        if (!(cl_options[option->opt_index].flags & (CL_COMMON| 
> CL_TARGET|CL_LTO)))
> *************** lto_write_options (void)
> *** 82,113 ****
>  	  break;
>  	}
>
> !       if (i != 1)
> ! 	obstack_grow (&temporary_obstack, " ", 1);
> !       obstack_grow (&temporary_obstack, "'", 1);
> !       q = option->canonical_option[0];
> !       while ((p = strchr (q, '\'')))
> ! 	{
> ! 	  obstack_grow (&temporary_obstack, q, p - q);
> ! 	  obstack_grow (&temporary_obstack, "'\\''", 4);
> ! 	  q = ++p;
> ! 	}
> !       obstack_grow (&temporary_obstack, q, strlen (q));
> !       obstack_grow (&temporary_obstack, "'", 1);
> !
> !       for (j = 1; j < option->canonical_option_num_elements; ++j)
> ! 	{
> ! 	  obstack_grow (&temporary_obstack, " '", 2);
> ! 	  q = option->canonical_option[j];
> ! 	  while ((p = strchr (q, '\'')))
> ! 	    {
> ! 	      obstack_grow (&temporary_obstack, q, p - q);
> ! 	      obstack_grow (&temporary_obstack, "'\\''", 4);
> ! 	      q = ++p;
> ! 	    }
> ! 	  obstack_grow (&temporary_obstack, q, strlen (q));
> ! 	  obstack_grow (&temporary_obstack, "'", 1);
> ! 	}
>      }
>    obstack_grow (&temporary_obstack, "\0", 1);
>    args = XOBFINISH (&temporary_obstack, char *);
> --- 119,127 ----
>  	  break;
>  	}
>
> !       for (j = 0; j < option->canonical_option_num_elements; ++j)
> ! 	append_to_collect_gcc_options (&temporary_obstack, &first_p,
> ! 				       option->canonical_option[j]);
>      }
>    obstack_grow (&temporary_obstack, "\0", 1);
>    args = XOBFINISH (&temporary_obstack, char *);

Re: [PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)

[Richard Guenther]

On Mon, 7 Nov 2011, Iain Sandoe wrote:

> 
> On 7 Nov 2011, at 12:17, Richard Guenther wrote:
> 
> > 
> > This tries to find a way to prepend explicitly set command-line options
> > by those implicitly set by the frontend (-fexceptions in this case).
> > Unfortunately we don't seem to have a good way to extract this information
> > easily, so for -fexceptions I hope all frontends set that during
> > init_options_struct.
> 
> It would also be nice to preserve the Objective-C flavor (GNU/NeXT), since we
> have to make a guess for this in darwin.c when in lto.

How is the default selected (that's not obvious to me).  flag_next_runtime
doesn't use options mechanisms it seems, that's bad.  Both
-fgnu-runtime and -fnext-runtime are frontend-only flags, they should
be at least also enabled for LTO, otherwise LTO cannot do anything
about the flag (and if it were LTO supported it would already be
saved properly).

Please provide a patch to move flag_next_runtime to properly
use the new option mechanism to avoid the need to handle it
in c-opts.c explicitely (and thus avoid the need to handle it
in lto explicitely).

Thanks,
Richard.

Re: [PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)

[Iain Sandoe]

On 7 Nov 2011, at 12:40, Richard Guenther wrote:

> On Mon, 7 Nov 2011, Iain Sandoe wrote:
>
>> It would also be nice to preserve the Objective-C flavor (GNU/ 
>> NeXT), since we
>> have to make a guess for this in darwin.c when in lto.
>
> How is the default selected (that's not obvious to me).   
> flag_next_runtime
> doesn't use options mechanisms it seems, that's bad.  Both
> -fgnu-runtime and -fnext-runtime are frontend-only flags, they should
> be at least also enabled for LTO, otherwise LTO cannot do anything
> about the flag (and if it were LTO supported it would already be
> saved properly).

for some reason it wasn't shifted to the new scheme - perhaps Joseph  
recalls why.
IIRC it's defined in toplev.c

> Please provide a patch

will try to do this (was kinda on my to-do anyway)

> to move flag_next_runtime to properly
> use the new option mechanism to avoid the need to handle it
> in c-opts.c explicitely (and thus avoid the need to handle it
> in lto explicitely).

one would still need deal with how to handle the case of inputs some  
compiled with -flag_next_runtime and some with -flag_gnu_runtime  
options (as far as I think at the moment - that's an error).

Iain

Re: [PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)

[Richard Guenther]

On Mon, 7 Nov 2011, Eric Botcazou wrote:

> > This tries to find a way to prepend explicitly set command-line options
> > by those implicitly set by the frontend (-fexceptions in this case).
> > Unfortunately we don't seem to have a good way to extract this information
> > easily, so for -fexceptions I hope all frontends set that during
> > init_options_struct.
> 
> That's wrong for Ada: it is set in gnat_init_gcc_eh and cannot be set earlier 
> because we support run time selection of the EH scheme.

That's called from gigi () - where is that called from?  Is that from
before post_options?  Where does Ada arrange for properly initializing
the backed EH?

We do have too many option related langhooks ... we do

  lang_hooks.init_options_struct ()
  /* decode options to cl_options */
  lang_hooks.init_options ()
  /* process decoded options.  */
  lang_hooks.post_options ().

why can't gigi set flag_exceptions from lang_hooks.init_options ()?

I can trivially change the patch to use global_options.x_flag_exceptions,
but then we get redudnant -fexception flags (not that I would care).

Just looking for a more general solution (but I note that Ada lacks
some conversion to the new cl_decoded_options facility anyways ...)

Richard.

Re: [PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)

[Richard Guenther]

On Mon, 7 Nov 2011, Iain Sandoe wrote:

> 
> On 7 Nov 2011, at 12:40, Richard Guenther wrote:
> 
> > On Mon, 7 Nov 2011, Iain Sandoe wrote:
> > 
> > > It would also be nice to preserve the Objective-C flavor (GNU/NeXT), since
> > > we
> > > have to make a guess for this in darwin.c when in lto.
> > 
> > How is the default selected (that's not obvious to me).  flag_next_runtime
> > doesn't use options mechanisms it seems, that's bad.  Both
> > -fgnu-runtime and -fnext-runtime are frontend-only flags, they should
> > be at least also enabled for LTO, otherwise LTO cannot do anything
> > about the flag (and if it were LTO supported it would already be
> > saved properly).
> 
> for some reason it wasn't shifted to the new scheme - perhaps Joseph recalls
> why.
> IIRC it's defined in toplev.c
> 
> > Please provide a patch
> 
> will try to do this (was kinda on my to-do anyway)
> 
> > to move flag_next_runtime to properly
> > use the new option mechanism to avoid the need to handle it
> > in c-opts.c explicitely (and thus avoid the need to handle it
> > in lto explicitely).
> 
> one would still need deal with how to handle the case of inputs some compiled
> with -flag_next_runtime and some with -flag_gnu_runtime options (as far as I
> think at the moment - that's an error).

You can complain about this in lto-wrapper.c and reject the link.  That
said, you probably want to pass down either option to the link-stage
which then hopefully complains about -fgnu-runtime -fnext-runtime.

Richard.

Re: [PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)

[Richard Guenther]

On Mon, 7 Nov 2011, Richard Guenther wrote:

> On Mon, 7 Nov 2011, Eric Botcazou wrote:
> 
> > > This tries to find a way to prepend explicitly set command-line options
> > > by those implicitly set by the frontend (-fexceptions in this case).
> > > Unfortunately we don't seem to have a good way to extract this information
> > > easily, so for -fexceptions I hope all frontends set that during
> > > init_options_struct.
> > 
> > That's wrong for Ada: it is set in gnat_init_gcc_eh and cannot be set earlier 
> > because we support run time selection of the EH scheme.

Btw, I doubt the patch would break anything for Ada - it at most
adds -fexceptions, so if Ada doesn't set flag_exceptions in
init_options_struct then it is a no-op for Ada.

Richard.

Re: [PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)

[Joseph S. Myers]

On Mon, 7 Nov 2011, Richard Guenther wrote:

> Joseph, do you have any advise on how to address frontend specific
> options in a more general way?  I'm trying to re-construct a
> command-line that when processed frontend agnostic would produce
> the same end-result in global_options as if going through the frontend.
> Is that even possible (do you have option examples that would show
> this is impossible?)

Reconstructing command lines is never going to be particularly reliable.  
I think the short-term fix will be saving these particular options 
explicitly, and the longer-term fix will be representing them (anything 
affecting IR semantics rather than just what IR gets generated) in the IR 
so that once the front end is finished the global settings never get used.  
(That doesn't mean moving them all to the individual GIMPLE operations, 
although for complex-method that would be the best location; moving them 
to struct function, with appropriate code to stream the new fields and do 
whatever's appropriate when inlining between functions with different 
settings, would still be useful.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)

[Joseph S. Myers]

On Mon, 7 Nov 2011, Richard Guenther wrote:

> Just looking for a more general solution (but I note that Ada lacks
> some conversion to the new cl_decoded_options facility anyways ...)

Full conversion may be hard because of things done in Ada code not C/C++, 
but it is indeed the case that it would be better to pass something closer 
to decoded options to the Ada code than the present reconstruction in 
gnat_init_options, and the kludges involving

#undef optimize
#undef optimize_size
#undef flag_compare_debug
#undef flag_stack_check

should definitely be replaced by naming the Ada versions of those 
variables differently from the C macros (gnat_optimize, for example) so 
there is no need for the #undef or for gnat_post_options to refer to 
global_options.x_* when setting the Ada versions.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)

[Joseph S. Myers]

On Mon, 7 Nov 2011, Iain Sandoe wrote:

> > How is the default selected (that's not obvious to me).  flag_next_runtime
> > doesn't use options mechanisms it seems, that's bad.  Both
> > -fgnu-runtime and -fnext-runtime are frontend-only flags, they should
> > be at least also enabled for LTO, otherwise LTO cannot do anything
> > about the flag (and if it were LTO supported it would already be
> > saved properly).
> 
> for some reason it wasn't shifted to the new scheme - perhaps Joseph recalls
> why.

In general I was concerned with options of relevance to multilib selection 
(although the actual changes to multilib selection didn't get 
implemented), meaning back-end and middle-end options; front-end options 
were less relevant.  Making similar cleanups to front-end options (i.e. 
making as much use of .opt features as possible instead of ad hoc code) is 
certainly still worthwhile as a cleanup.  (And there is still scope for 
more cleanup of some back-end options: moving some handling of enumeration 
options in override hooks to use Enum in particular.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)

[Richard Guenther]

On Tue, 8 Nov 2011, Joseph S. Myers wrote:

> On Mon, 7 Nov 2011, Richard Guenther wrote:
> 
> > Joseph, do you have any advise on how to address frontend specific
> > options in a more general way?  I'm trying to re-construct a
> > command-line that when processed frontend agnostic would produce
> > the same end-result in global_options as if going through the frontend.
> > Is that even possible (do you have option examples that would show
> > this is impossible?)
> 
> Reconstructing command lines is never going to be particularly reliable.  
> I think the short-term fix will be saving these particular options 
> explicitly, and the longer-term fix will be representing them (anything 
> affecting IR semantics rather than just what IR gets generated) in the IR 
> so that once the front end is finished the global settings never get used.  
> (That doesn't mean moving them all to the individual GIMPLE operations, 
> although for complex-method that would be the best location; moving them 
> to struct function, with appropriate code to stream the new fields and do 
> whatever's appropriate when inlining between functions with different 
> settings, would still be useful.)

Ok, yes - that's the general direction.

I've modified the patch to use global_options again and checked in
the following.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

Richard.

2011-11-08  Richard Guenther  <rguenther@suse.de>

	PR lto/50999
	* lto-opts.c (append_to_collect_gcc_options): Split out from...
	(lto_write_options): ... here.  Prepend frontend specific flags.

Index: gcc/lto-opts.c
===================================================================
*** gcc/lto-opts.c	(revision 181150)
--- gcc/lto-opts.c	(working copy)
*************** along with GCC; see the file COPYING3.
*** 35,40 ****
--- 35,63 ----
  #include "lto-streamer.h"
  #include "toplev.h"
  
+ /* Append the option piece OPT to the COLLECT_GCC_OPTIONS string
+    set up by OB, appropriately quoted and separated by spaces
+    (if !*FIRST_P).  */
+ 
+ static void
+ append_to_collect_gcc_options (struct obstack *ob,
+ 			       bool *first_p, const char *opt)
+ {
+   const char *p, *q = opt;
+   if (!first_p)
+     obstack_grow (ob, " ", 1);
+   obstack_grow (ob, "'", 1);
+   while ((p = strchr (q, '\'')))
+     {
+       obstack_grow (ob, q, p - q);
+       obstack_grow (ob, "'\\''", 4);
+       q = ++p;
+     }
+   obstack_grow (ob, q, strlen (q));
+   obstack_grow (ob, "'", 1);
+   *first_p = false;
+ }
+ 
  /* Write currently held options to an LTO IL section.  */
  
  void
*************** lto_write_options (void)
*** 45,60 ****
    struct obstack temporary_obstack;
    unsigned int i, j;
    char *args;
  
    section_name = lto_get_section_name (LTO_section_opts, NULL, NULL);
    lto_begin_section (section_name, false);
    memset (&stream, 0, sizeof (stream));
  
    obstack_init (&temporary_obstack);
    for (i = 1; i < save_decoded_options_count; ++i)
      {
        struct cl_decoded_option *option = &save_decoded_options[i];
-       const char *q, *p;
  
        /* Skip frontend and driver specific options here.  */
        if (!(cl_options[option->opt_index].flags & (CL_COMMON|CL_TARGET|CL_LTO)))
--- 68,97 ----
    struct obstack temporary_obstack;
    unsigned int i, j;
    char *args;
+   bool first_p = true;
  
    section_name = lto_get_section_name (LTO_section_opts, NULL, NULL);
    lto_begin_section (section_name, false);
    memset (&stream, 0, sizeof (stream));
  
    obstack_init (&temporary_obstack);
+ 
+   /* Output options that affect GIMPLE IL semantics and are implicitely
+      enabled by the frontend.
+      This for now includes an explicit set of options that we also handle
+      explicitly in lto-wrapper.c.  In the end the effects on GIMPLE IL
+      semantics should be explicitely encoded in the IL or saved per
+      function rather than per compilation unit.  */
+   /* -fexceptions causes the EH machinery to be initialized, enabling
+      generation of unwind data so that explicit throw() calls work.  */
+   if (global_options.x_flag_exceptions)
+     append_to_collect_gcc_options (&temporary_obstack, &first_p,
+ 				   "-fexceptions");
+ 
+   /* Output explicitely passed options.  */
    for (i = 1; i < save_decoded_options_count; ++i)
      {
        struct cl_decoded_option *option = &save_decoded_options[i];
  
        /* Skip frontend and driver specific options here.  */
        if (!(cl_options[option->opt_index].flags & (CL_COMMON|CL_TARGET|CL_LTO)))
*************** lto_write_options (void)
*** 82,113 ****
  	  break;
  	}
  
!       if (i != 1)
! 	obstack_grow (&temporary_obstack, " ", 1);
!       obstack_grow (&temporary_obstack, "'", 1);
!       q = option->canonical_option[0];
!       while ((p = strchr (q, '\'')))
! 	{
! 	  obstack_grow (&temporary_obstack, q, p - q);
! 	  obstack_grow (&temporary_obstack, "'\\''", 4);
! 	  q = ++p;
! 	}
!       obstack_grow (&temporary_obstack, q, strlen (q));
!       obstack_grow (&temporary_obstack, "'", 1);
! 
!       for (j = 1; j < option->canonical_option_num_elements; ++j)
! 	{
! 	  obstack_grow (&temporary_obstack, " '", 2);
! 	  q = option->canonical_option[j];
! 	  while ((p = strchr (q, '\'')))
! 	    {
! 	      obstack_grow (&temporary_obstack, q, p - q);
! 	      obstack_grow (&temporary_obstack, "'\\''", 4);
! 	      q = ++p;
! 	    }
! 	  obstack_grow (&temporary_obstack, q, strlen (q));
! 	  obstack_grow (&temporary_obstack, "'", 1);
! 	}
      }
    obstack_grow (&temporary_obstack, "\0", 1);
    args = XOBFINISH (&temporary_obstack, char *);
--- 119,127 ----
  	  break;
  	}
  
!       for (j = 0; j < option->canonical_option_num_elements; ++j)
! 	append_to_collect_gcc_options (&temporary_obstack, &first_p,
! 				       option->canonical_option[j]);
      }
    obstack_grow (&temporary_obstack, "\0", 1);
    args = XOBFINISH (&temporary_obstack, char *);

Re: [PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)

[Iain Sandoe]

On 8 Nov 2011, at 00:21, Joseph S. Myers wrote:

> On Mon, 7 Nov 2011, Iain Sandoe wrote:
>
>>> How is the default selected (that's not obvious to me).   
>>> flag_next_runtime
>>> doesn't use options mechanisms it seems, that's bad.  Both
>>> -fgnu-runtime and -fnext-runtime are frontend-only flags, they  
>>> should
>>> be at least also enabled for LTO, otherwise LTO cannot do anything
>>> about the flag (and if it were LTO supported it would already be
>>> saved properly).
>>
>> for some reason it wasn't shifted to the new scheme - perhaps  
>> Joseph recalls
>> why.
>
> In general I was concerned with options of relevance to multilib  
> selection
> (although the actual changes to multilib selection didn't get
> implemented), meaning back-end and middle-end options; front-end  
> options
> were less relevant.  Making similar cleanups to front-end options  
> (i.e.
> making as much use of .opt features as possible instead of ad hoc  
> code) is
> certainly still worthwhile as a cleanup.  (And there is still scope  
> for
> more cleanup of some back-end options: moving some handling of  
> enumeration
> options in override hooks to use Enum in particular.)

I'm looking at doing this - but have a question about the meaning of  
"LTO" in the options file (I've built doc from trunk and read gccint  
section 8).

Does "LTO" mean that lto1 should respond to the flag?
- or does it mean that the flag should be preserved within the object  
(for resurrection by lto)?

(or something else, of course ;-)

Iain

Re: [PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)

[Richard Guenther]

On Tue, 8 Nov 2011, Iain Sandoe wrote:

> 
> On 8 Nov 2011, at 00:21, Joseph S. Myers wrote:
> 
> > On Mon, 7 Nov 2011, Iain Sandoe wrote:
> > 
> > > > How is the default selected (that's not obvious to me).
> > > > flag_next_runtime
> > > > doesn't use options mechanisms it seems, that's bad.  Both
> > > > -fgnu-runtime and -fnext-runtime are frontend-only flags, they should
> > > > be at least also enabled for LTO, otherwise LTO cannot do anything
> > > > about the flag (and if it were LTO supported it would already be
> > > > saved properly).
> > > 
> > > for some reason it wasn't shifted to the new scheme - perhaps Joseph
> > > recalls
> > > why.
> > 
> > In general I was concerned with options of relevance to multilib selection
> > (although the actual changes to multilib selection didn't get
> > implemented), meaning back-end and middle-end options; front-end options
> > were less relevant.  Making similar cleanups to front-end options (i.e.
> > making as much use of .opt features as possible instead of ad hoc code) is
> > certainly still worthwhile as a cleanup.  (And there is still scope for
> > more cleanup of some back-end options: moving some handling of enumeration
> > options in override hooks to use Enum in particular.)
> 
> I'm looking at doing this - but have a question about the meaning of "LTO" in
> the options file (I've built doc from trunk and read gccint section 8).
> 
> Does "LTO" mean that lto1 should respond to the flag?
> - or does it mean that the flag should be preserved within the object (for
> resurrection by lto)?
> 
> (or something else, of course ;-)

It means the option is valid for lto1.

Richard.