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: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 30 Oct 2013 22:55:45 +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>
On Wed, Oct 30, 2013 at 9:39 PM, David Malcolm wrote:
> 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.
Good idea. In the past this kind of change would be sort-of
controversial (large number of changes for small gain) but if the
whole source code base is being overhauled anyway, it's a good time to
get rid of this black magic at the same time...
> 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?
Why not just expose the different "classes" of options in some struct or object?
struct {
unsigned tree_vrp : 1;
...
} opt_flags;
struct {
...
} warn_flags;
static bool gate_vrp (void) { return opt_flags.tree_vrp != 0; }
This would also make streaming the flags settings easier for LTO.
Ciao!
Steven