[patch] moving macro definitions to defaults.h
Mon Sep 22 16:26:00 GMT 2014
After being reminded of the tm.h issues brought up last november (here:
https://gcc.gnu.org/ml/gcc-patches/2013-11/msg01731.html ), I started
looking back into it.
The general summary is the any header file which has a conditional on a
target macro could be affected by include file reordering... ie, if a
header file has
and we move the header files around a bit, it wouldn't be immediately
obvious if the order where changes and BLAH was define later in the
include structure. The results for this header files would be different
because <whatever> would no longer be in the preprocess source, and it
may take a long time to discover the difference.
Josephs solution was to identify these and instead put a default
definition in default.h ... then change all the uses to #if instead.. ie,
This way we can ensure that the definition has been seen and it will be
a compile error if not.
I looked at all the target macros listed by Joseph, and decide to start
with the ones which are used *only* in an "if defined" situation in a .h
files of some sort.
or #if define()
If this happens in a .c file, then changing the order of .h's shouldn't
matter. (Unless the .c file is doing something really screwy. So for
the moment, ignoring that.)
So looking at only .h files, I found a number of default definitions in
rtl.h, which this patch moves to defaults.h. I was going to #error if
defaults.h wasn't included, but found that to be unnecessary since it
uses some of those macros and would cause a compile failure anyway if it
wasn't included. All the other uses of these particular macros use the
#if model, so no further adjustment is required for them.
This patch bootstraps on x86_64-unknown-linux-gnu, and regressions are
running. Assuming no issues show up, OK for mainline?
The remaining macros I will have a closer look at and most will likely
need the full treatment moving from #ifdef to the #if model. I plan to
do these next. The macros which fit this category for potential header
trouble (along with their usage count) are:
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7604 bytes
Desc: not available
More information about the Gcc-patches