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.