http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489
--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-12-20 15:43:37 UTC --- On Mon, 20 Dec 2010, amylaar at gcc dot gnu.org wrote: > When using gcc, using -dD, I can auto-generate a headerfile tm-poison.h which > poisons all macros that including tm.h defines, which are not defined > by frontend-premissible headers like coretypes.h / tree.h . > The fallback would be to have tm-poison.h be empty. > This file can be included instead of tm.h in files that are hoped / believed > to been freed of target macros uses . > This can safe a lot of manual checking. This sounds like a nice approach for making sure it is safe to remove a tm.h include from a particular source file - if combined with generating a list of every target (every triplet with significant differences in how config.gcc / libgcc/config.host configure it, whether in the set of headers or the set of tm_defines) so you can run tests automatically for all targets - it may avoid the need to check for every macro with one of the properties I identified as meaning a target macro, that is used anywhere in that source file or any header it includes. I'd be more doubtful about actually checking in a #include of tm-poison.h on trunk (the code to generate it, however, might be useful to check in). Your approach also catches target macros such as TARGET_64BIT that are meant to be purely internal to a port but may nevertheless be used, incorrectly, in target-independent code, by treating such macros identically to those that are expected to be used in target-independent code but only in those source files allowed to include tm.h. (Which anything based on looking at documented macros in tm.texi.in, for example, would not catch.)
