This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Pre-Patch RFC: proposed changes to option-lookup


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]