This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: remove tm.h include from function.h


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
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]