On Thu, 14 Nov 2013, Andrew MacLeod wrote: > On 11/14/2013 05:16 PM, Joseph S. Myers wrote: > > On Thu, 14 Nov 2013, Diego Novillo wrote: > > > > > This patch contains the mechanical side-effects from > > > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01663.html > > There are rather a lot of "Include tm.h" changes here - especially in > > front ends, where we've tried to eliminate tm.h calls, and put comments on > > some of those remaining saying exactly what target macros are used to make > > clear what's needed to eliminate them. Putting in these includes, without > > clear comments explaining how to eliminate them, seems a step backwards. > The problem is larger than that... function.h includes tm.h as well... and > something like 140ish files include function.h, not to mention another 5 > include files bring it in... basic-block.h, cfgloop.h, cgraph.h, expr.h, and > gimple-streamer.h > > so pretty much every file in existence gets tm.h one way or another :-P
Front end and GIMPLE optimizer files should avoid including all of those where possible - and if needed, the bits requiring tm.h should be separated from the bits not requiring it. > 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. (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). The following headers appear to use target macros (there might be some false positives in this list). This does *not* mean such #error should be added to all of them; it should be added only after investigation of whether it's actually needed to ensure an obvious failure, and only if it doesn't mean adding lots of tm.h includes to files without them. In the case of tree.h, for example, the BITS_PER_UNIT uses will cause obvious failures if any of the affected macros are used without tm.h, while the other three target macros uses - NO_DOLLAR_IN_LABEL NO_DOT_IN_LABEL TARGET_DLLIMPORT_DECL_ATTRIBUTES - only affect a few users and so the relevant bits should probably be split out of tree.h. ada/gcc-interface/gigi.h ada/gcc-interface/lang-specs.h addresses.h bb-reorder.h builtins.h cfgloop.h collect2-aix.h conditions.h cp/cp-tree.h cp/lang-specs.h dbxout.h dwarf2out.h expmed.h flags.h fortran/gfortran.h function.h gcse.h hard-reg-set.h hosthooks-def.h ira-int.h ira.h libfuncs.h lower-subreg.h lra-int.h machmode.h objcp/lang-specs.h optabs.h output.h real.h regrename.h regs.h reload.h rtl.h target-def.h target-globals.h target.h tree-dfa.h tree.h -- Joseph S. Myers jos...@codesourcery.com
