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