This is the mail archive of the
mailing list for the GCC project.
Re: Pre-Patch RFC: proposed changes to option-lookup
- From: Jeff Law <law at redhat dot com>
- To: 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 00:15:41 -0600
- 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>
On 10/30/13 14:39, David Malcolm wrote:
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)
[Sending this to gcc-patches to double-check that the idea is sound
before continuing to work on this large patch.  ]
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:
return flag_tree_vrp != 0;
where "flag_tree_vrp" is actually an autogenerated macro to
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:
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?
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.