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
