This is the mail archive of the
mailing list for the GCC project.
Re: RFA: remove tm.h include from function.h
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Joern Rennecke <amylaar at spamcop dot net>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 26 Nov 2010 02:49:27 +0000 (UTC)
- Subject: Re: RFA: remove tm.h include from function.h
- References: <email@example.com>
On Thu, 25 Nov 2010, Joern Rennecke wrote:
> I generate a new header file, tm-holdover.h, for BITS_PER_UNIT.
Creating the file through grep is a really ugly way of doing things.
There's a case for having multiple tm.h variants for different uses. For
example, completing the toplevel libgcc transition will involve some
headers in libgcc/config for those cases where target macros really are
appropriate rather than built-in macros and functions and other similar
approaches. And when the driver starts to use a target structure, the
macros filling in that structure will probably continue to go in headers
(given that they tend to depend on both target OS and target architecture,
unlike many macros in the core compiler) but it would be good to have a
separation of those relevant to the driver from those relevant to the rest
of the compiler - a driver/config/ tree, say. (This is certainly
nontrivial; many specs depend on other macros defined in tm.h.)
But doing things through grep isn't reliable (macros may be conditionally
defined or defined over more than one line) and doesn't achieve logical
separation of the different areas of compiler configuration. If there is
a set of macros you believe are appropriately defined for files in the
compiler that should not use other macros, work out a logical way to tell
whether a macro is in that class, then create a separate set of
configuration headers for them in the source tree.
Such changes should *definitely* not be mixed in with any other patch like
you have done here. Regarding the main aim of the present patch, my only
comment is that splitting up function.h into two separate headers would
seem cleaner than making what it declares depend on what headers have been
included first - but at least for CUMULATIVE_ARGS it would be better to
remove all variables and fields of that type from target-independent code,
instead using a target-independent type and having targets responsible in
some way for allocating and deallocating values of that type.
Joseph S. Myers