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.
Jeff
