On 10/14/2015 08:05 AM, Andrew MacLeod wrote:
On 10/12/2015 04:04 AM, Jeff Law wrote:
Oh, you must be looking at the original combined patch?
Possibly :-)
fold-const.h is indirectly included by cp-tree.h, which gets it from
including c-common.h. some of the output from show-headers on
objc-act.c (indentation represents levels of including. The number in
parenthesis is the number of times that include has been seen so far in
the files include list. As you can see, we include ansidecl.h a lot
:-) Most of the time there isn't much we can do about those sorts of
things. :
cp-tree.h
tm.h (2)
hard-reg-set.h
function.h (1)
c-common.h
splay-tree.h
ansidecl.h (4)
cpplib.h
symtab.h (2)
line-map.h (2)
alias.h
tree.h (2)
fold-const.h
diagnostic-core.h (1)
bversion.h
I guess It could be a useful addition to show-headers to specify a
header file you are looking for and show you where it comes from if its
included...
Yea. Though I think it's probably easy enough to get it from the
current output.
I any case, there is some indirection here because none of the front end
files were flattened that much
And I think that's probably some source of the confusion on my part. I
thought we'd flattened the front-end .h files too. So I didn't look
deeply into the .h files to see if they were doing something undesirable
behind my back.
incidentally, you may notice this is the second time tree.h is
included. The first occurrence of tree.h is included directly by
objc-act.c, but it needs to be left because something between that and
cp-tree.h needs tree.h to compile. This sort of thing is resolved by
using the re-order tool, but I did not run that tool on most of the objc
and objcp files as they have some complex conditionals in their include
list:
#include "tree.h"
#include "stringpool.h"
#include "stor-layout.h"
#include "attribs.h"
#ifdef OBJCPLUS
#include "cp/cp-tree.h"
#else
#include "c/c-tree.h"
#include "c/c-lang.h"
#endif
#include "c-family/c-objc.h"
#include "langhooks.h"
Its beyond the scope of the reorder tool to deal with re-positioning
this automatically... and happens so rarely I didn't even look into it.
So they are not optimal as far as ordering goes.
Understood. This unholy sharing had me concerned as well.
So you can not worry about that. It builds fine.
OK. I think the major source of confusion was the lack of flattening
for the front-ends. I'll go back to it with that in mind and probably
start using the tools when I get a WTF moment.
I'm slightly concerned about the darwin, windows and solaris bits. The
former primarily because Darwin has been a general source of pain, and
in the others because I'm not sure the cross testing will exercise
that code terribly much.
Its easy enough to NOT do this for any of those files if were too
worried about them. Its also easy to revert a single file if it
appears to be an issue. Thats why I wanted to run as many of these
on the compile farm natively as I could... but alas, powerPC was the
only thing the farm really offered me.
I'll go ahead and approve all the config/ bits. Please be on the
lookout for any fallout.
even darwin, windows and solaris? :-)
Yup. The changes are straighforward enough that if there's fallout (and
to some degree I expect minor fallout from native builds) it can be
easily fixed.
Jeff
