Re: [patch] moving macro definitions to defaults.h

[Andrew MacLeod <amacleod at redhat dot com>]

On 09/22/2014 01:02 PM, Joseph S. Myers wrote:
> On Mon, 22 Sep 2014, Andrew MacLeod wrote:
>
> > Josephs solution was to identify these and instead put a default definition in
> > default.h ...  then change all the uses to #if instead.. ie,
> > #if BLAH
> >
> > This way we can ensure that the definition has been seen and it will be a
> > compile error if not.
> No, my suggestion was that whenever possible we should change preprocessor
> conditionals - #ifdef or #if - into C conditionals - "if (MACRO)".
>
> Changing from #ifdef to #if does nothing to make a missing tm.h include
> produce an error - the undefined macro simply quietly gets treated as 0 in
> preprocessor conditionals.  To get an error from #if in such cases, you'd
> need to build GCC with -Wundef (together with existing -Werror), and I'd
> guess there are plenty of places that are not -Wundef clean at present.

really...  I've always just assumed #if  XXX  would be like  #if  xx > 
YY  and that would give you an error if there was a problem with the 
expression.  How incredibly  lame :-). Me too for not knowing that I 
suppose.
> Now, I think moves of defaults to defaults.h are generally a good idea,
> and that moving from defined/undefined to true/false semantics are also a
> good idea - even if the way the macro is used means you can't take the
> further step of converting from #if to if ().  They don't solve the
> problem of making a missing tm.h include immediately visible, but they
> *do* potentially help with future automatic refactoring to convert target
> macros into hooks.
>
> Obviously such moves do require checking the definitions and uses of the
> macros in question; you need to make sure you catch all places that use
> #ifdef / #if defined etc. on the macro (and make sure they have the same
> default).  And if you're changing the semantics of the macro from defined
> / undefined to true / false, you need to watch out for any existing
> definitions with an empty expansion, or an expansion to 0, etc.
>
> and turning target macros into a C "if ()"  isn't always an option...

if() and target hooks arent exactly easy either..

if redefine the macro in terms of a target hook, but then you are 
pushing the resolution out to run time... ie:

#ifndef NO_DOT_IN_LABEL
#define AUTO_TEMP_NAME "_.tmp_"
#else
#ifndef NO_DOLLAR_IN_LABEL
#define AUTO_TEMP_NAME "__$tmp_"
#else
#define AUTO_TEMP_NAME "__tmp_"
#endif

becomes something like:
#define AUTO_TEMP_NAME (!no_dot_in_label_hook() ? "_.tmp_" : 
(!no_dollar_in_label_hook() ? "_$tmp_" : "__tmp_"))

a C if () has similar issues, but at least can be optimized
#define AUTO_TEMP_NAME (!NO_DOT_IN_LABEL ? "_.tmp_" : 
(!NO_DOLLAR_IN_LABEL ? "_$tmp_" : "__tmp_"))


I'm not crazy about most of the options we have...   Slightly orthogonal 
to this, but more related to what I'm actually trying to accomplish in 
the short term... (man there are a lot of rat holes one can descend...)

maybe we can provide a fe-tm.h which is generated from tm.h and contains 
a #define for each of macro that the front ends consume...
so during a build, we have a generator something like:

#include "tm.h"
<...>
fprintf (fe_defaults, "#define NO_DOLLAR_IN_LABEL   %s\n", 
properly_reformat_macro_string (#NO_DOLLAR_IN_LABEL));

or something like that, and define all the macros that are required by 
the front end this way.  Then there are no backeend include dependencies 
to compile the front ends (as far as target macros go) Everywhere that 
includes tm.h in the front ends would instead include fe-tm.h.


I've been struggling with exactly how to separate the front end in a 
practical way. I'm currently experimenting with providing a 
fe-interface.[ch] files which contain copies of the prototypes for 
whatever backend routines are needed, as well as prototypes for wrappers 
to access BE structures so that we don't need to expose all the gory 
bits to the front end.   I have managed to remove function.h by 
providing just a few access routines and a couple of prototypes from 
function.h

If I continue to pursue that, we would end up with fe-interface.h which 
contains a list of all the back end data structures and routines which 
are used.
(ignoring tree.[ch]  for the moment since it's a beast of its own...)   
a "fe-tm.h" or the equivalent would fit  with that model.

we could then look at all these interface requirements as a whole and 
perhaps figure out a better way of structuring them...

Andrew