On 11/15/2013 08:16 AM, Joseph S. Myers wrote:
On Thu, 14 Nov 2013, Andrew MacLeod wrote:
btw, I ran tm.h through the include removal script for the c family front end
files... The attached patch compiles on x64 and removes 37 includes from the
front end files.... those are just the extraneous ones... but it may be
helpful...
When trimming tm.h includes you need to be careful about either the .c
file itself, or headers it includes, referencing target macros in ways
that don't cause build failures when they are missing (that is,
#ifdef etc., rather than if ()). And, I don't think it's helpful to
remove tm.h includes from a file just because some other header implicitly
includes it. For example, in your patch. cp/class.c uses BITS_PER_UNIT,
MAX_FIXED_MODE_SIZE, PCC_BITFIELD_TYPE_MATTERS, STRUCTURE_SIZE_BOUNDARY,
TARGET_VTABLE_DATA_ENTRY_DISTANCE, TARGET_VTABLE_ENTRY_ALIGN and
TARGET_VTABLE_USES_DESCRIPTORS; removing the tm.h include makes things
look cleaner than they are.
Which is why I made the earlier point about flattening everything before
it really means much in analysis terms... The patch was just meant to
show that we can strip a lot of things out. .. when those other files
are flattened, yeah, it may end up back.
(Actually, the C++ front end can't really be usefully cleaned up regarding
tm.h yet because cp-tree.h uses NO_DOLLAR_IN_LABEL and NO_DOT_IN_LABEL in
#if conditionals.)
Regarding the case of headers depending on tm.h in a nonobvious way (#if
rather than anything that will clearly fail if tm.h isn't included): my
inclination would be to put #error directives in such files so they fail
immediately if tm.h hasn't been included first (TM_H isn't defined).
Ah yes, I just suggested this as a way to handle it as well in a
different note.... certainly they all require manual inspection, and
identifying all cases could be interesting, but is something we could
start at least with the ones we know.
Andrew
