This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Factor unrelated declarations out of tree.h (1/2)
- From: Jeff Law <law at redhat dot com>
- To: Diego Novillo <dnovillo at google dot com>, gcc-patches at gcc dot gnu dot org, Andrew Macleod <amacleod at redhat dot com>
- Date: Thu, 14 Nov 2013 15:12:32 -0700
- Subject: Re: Factor unrelated declarations out of tree.h (1/2)
- Authentication-results: sourceware.org; auth=none
- References: <20131114202812 dot GA12236 at google dot com>
On 11/14/13 13:28, Diego Novillo wrote:
Functions in each corresponding .c file got moved to those
headers and others that already existed. I wanted to make this
patch as mechanical as possible, so I made no attempt to fix
problems like having build_addr defined in tree-inline.c. I left
that for later.
This seems backwards to me and just ensures double-churn. Once to move
it now, then again to its final resting spot.
If this change is being made via some automated script, then, well, I
guess it is what it is and we'll have to come back to them. But if
you're doing this by hand it seems to me that leaving it in its original
location, possibly grouped with its friends, with a FIXME would be better.
There were some declarations that I could not move out of tree.h
because of header poisoning. We forbid the inclusion of things
like expr.h from FE files. While that's a reasonable idea, the FE
file *still* manage to at expr.c functionality because the
declarations they want to use were defined in tree.h.
If that functionality is allowed to be accessed from the FEs,
then I will later move those functions out of expr.c into tree.c.
I have moved these declarations to the bottom of tree.h so they
are easy to identify later.
Yea :( Hell, this seems like a no-brainer that ought to go in as is,
right now. The ability to identify these warts quickly I'm sure will be
useful.
There is a namespace collision with libcpp. The file gcc/symtab.c
cannot use gcc/symtab.h because the #include command picks up
libcpp/include/symtab.h first. So I named this file gcc-symtab.h
for now.
Seems reasonable.
- Some header files always need another header file. I chose to
#include that header in the file. At this stage we want to do
the opposite, but this would've added even more bulk to the
change, so I left a FIXME marker for the next pass.
This seems a bit like a mistake. How much of this patch would be
blocked if we didn't allow this right now.
I'm keen to avoid you and Andrew stomping on each other, so I'd rather
not go backwards on something like this.