[patch 0/3] Header file reduction.

[Andrew MacLeod]

OK, newly regenerated patches to remove header files from the latest 
version of the tools.

The patches are generated by a pair of tools.
* gcc-order-includes goes through the headers and canonically reorders 
some of our more common/troublesome headers and removes any duplicates.  
This includes headers which are included by other headers. (ie, 
obstack.h can be removed as a duplicate if bitmap.h is included already.)
* remove-includes is the tool which tries to remove each non-conditional 
header file and does the real work.

I'll have a patch shortly to add these and some other useful tools to a 
header-tools directory in contrib.

There are 3 patches which follow:  backend.a files, fe files, and config 
files.. Effecting 547 files total

These were generated from a  trunk snapshot taken about 2 weeks ago. The 
tools ran, and once I finished some minor tweaking, I reapplied them to 
a 9/28 branch. Anything which didn't apply cleanly due to intervening 
changes, was simply re-reduced.  I then reapplied them to a snapshot 
from this morning for these patches.

The tool also monitor what macros are defined and conditionally 
consumed, and wont remove a header which still compiles if it may define 
a macro which is used in conditional compilation (tm.h is frequently 
affected by this). The tool spits out messages like these:

* Passed host and target builds, but must keep target.h because it 
provides ASM_OUTPUT_DEF Possibly required by ipa-icf.c
* Passed host and target builds, but must keep insn-attr.h because it 
provides DELAY_SLOTS Possibly required by toplev.c

note my host arch doesn't define DELAY_SLOTS in insn-attr-common.h 
(included by insn-attr.h) , but some other target archs do, and this is 
caught this during some of the target builds. (toplev.c has the 
following lines:)

    #ifndef DELAY_SLOTS
       if (flag_delayed_branch)
         warning (0, "this target machine does not have delayed branches");
    #endif

So as far as I can tell I'm catching all those conditional compilation 
cases.  The only ones I might have missed would be macros which some 
host build defines on the command line and which doesn't show up in a 
config-list.mk target build.. I guess.

Everything bootstraps on x86_64-pc-linux-gnu and 
powerpc64le-unknown-linux-gnu.  All targets in config-list.mk still 
build. Regressions tests also came up clean.

OK for trunk?

I will make minor tweaks as needed when applying to trunk for 
check-in..  I know that the new requirement for cgraph.h in builtins.c 
is no longer required in trunk. 
(https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00102.html)   Going 
forward, we'll know when we are adding new dependencies, as this thread 
so timely shows :-).

Andrew

PS.  Then keep an eye for anything funny. I'm not expecting much, but if 
a file causes an issue, simple reverting the change for that one file 
should be sufficient until we figure out why it is an issue,.  No change 
in any of these files is dependent on any other..  it simple include 
reduction, and there should be no functional change in code.