On 10/12/2015 04:04 AM, Jeff Law wrote:
<...>
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423
../gcc-interface/Makefile:311: recipe for target 's-regpat.o' failed
However, the tool has been run, and I've made the minor adjustments
required to the source files to make it work. (ie, a few multi-line
comments and the fact that mul-tables.c is generated on the tile*
targets.
So this is what it should look like. I used -cp. Other languages are
bootstrapping, and I have yet to build all the targets... that'll just
take a day. Be nice if ada worked tho.
I can run the reduction tool over the weekend (its a long weekend here
:-) on this if you want... the other patch is a couple of weeks out of
date anyway now.
I find myself looking at the objc stuff and wondering if it was built.
For example objc-act.c calls functions prototyped in fold-const.h, but
that header is no longer included after your patch.
wait, what? I don't see any differences to objc-act.c in the
reordering patches....
Oh, you must be looking at the original combined patch?
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...
I any case, there is some indirection here because none of the front end
files were flattened that much
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.
Similarly in objcp we remove tree.h from objcp-decl.c, but it uses
TREE macros and I don't immediately see where those macros would be
coming from if tree.h is no longer included.
Again, thanks to no flattening of the front end files :-) It also comes
from cp-tree.h. The objcp source files don't specify the full patch of
cp/cp-tree.h like objc does, so the simplistic show-headers tool doesn't
know where to look for cp-tree.h to show you what it included like in
the above example. Maybe I'll tweak the tool to look in common header
directories.
In general, I'm worried about the objc/objcp stuff. That in turn
makes me wonder about the other stuff in a more general sense.
Regardless, I think I can take a pretty good stab at the config/ changes.
So you can not worry about that. It builds fine.
A pattern that seems to play out a lot in the target files is they
liked to include insn-config.h, insn-codes.h, & timevar.h. I can see
how those typically won't be needed. The first two are amazingly
common. A comment in the nds32 port indicates that ii may have been
needed by recog.h in the past. nds32 actually included insn-config
twice :-)
Interestingly enough m32r, mcore & pdp11 still need insn-config....
most ports get insn-config.h from optabs.h:
optabs.h
optabs-query.h
insn-opinit.h (1)
optabs-libfuncs.h
insn-opinit.h (2)
insn-config.h
I think those ports that still include it do not include optabs.h
The strangest thing I saw was rs6000 dropping an include of
emit-rtl.h. But presumably various powerpc targets were built, so I
guess it's really not needed.
It gets emit-rtl.h from ira.h:
regs.h
ira.h
emit-rtl.h
recog.h
insn-codes.h (2)
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? :-)
Im going to tweak the show-headers tool to look in a few common places,
and look for requested headers, and then repost the tools change with
most of the documentation changes Bernd pointed out. I didn't do lot
to the code itself, but I did comment a few more things.
Perhaps using the tool when you have the above questions would show its
usefulness :-) Its particularly useful when combined with
included-by, so you can see how many files include specific ones, and it
does point out some silly things, but we cant fix all of them without
flattening EVERYTHING... I tried to just do the main parts in the
backend we were likely to care about. Of course, the tool is useless
unless the patch is applied :-P However, I can continue to answer
questions easily enough :-)
Andrew
