This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Pre-Patch RFC: proposed changes to option-lookup
- From: Marek Polacek <polacek at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: David Malcolm <dmalcolm at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 31 Oct 2013 08:02:46 +0100
- Subject: Re: Pre-Patch RFC: proposed changes to option-lookup
- Authentication-results: sourceware.org; auth=none
- References: <1383165583 dot 29677 dot 97 dot camel at surprise> <5271F58D dot 2060703 at redhat dot com>
On Thu, Oct 31, 2013 at 12:15:41AM -0600, Jeff Law wrote:
> On 10/30/13 14:39, David Malcolm wrote:
> >[Sending this to gcc-patches to double-check that the idea is sound
> >before continuing to work on this large patch. [1] ]
> >
> >I want to eliminate hidden use of the preprocessor in our code, in favor
> >of using block caps to signal to people reading the code that macro
> >magic is happening.
> >
> >As a specific example, consider this supposedly-simple code:
> >
> > static bool
> > gate_vrp (void)
> > {
> > return flag_tree_vrp != 0;
> > }
> >
> >where "flag_tree_vrp" is actually an autogenerated macro to
> >"global_options.x_flag_tree_vrp"
> >
> >This is deeply confusing to a newbie - and indeed still to me after two
> >years of working with GCC's internals, for example, when stepping
> >through code and trying to query values in gdb.
> >
> >My idea is to introduce a GCC_OPTION macro, and replace the above with:
> >
> > static bool
> > gate_vrp (void)
> > {
> > return GCC_OPTION (flag_tree_vrp) != 0;
> > }
> >
> >thus signaling to humans that macros are present.
> >
> >Is such a patch likely to be accepted? Should I try to break the
> >options up into logical groups e.g. with separate macros for warnings vs
> >optimizations, or some other scheme?
> So what's the advantage of GCC_OPTION over just explicitly
> referencing it via global_options? (I would agree that GCC_OPTION
> or an explicit reference are better than the magic that happens
> behind our back with the flags right now)
>
> I'm definitely in favor of removing hidden macro magic, so I think
> we want to go forward with something here. I just want to know why
> GCC_OPTION over the fully explicit version.
If we'd go with GCC_OPTION, could we drop then the flag_ prefix? That
is, GCC_OPTION (tree_vrp) instead of GCC_OPTION (flag_tree_vrp).
Marek