This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Converting tm.h macros to functions
- To: Neil Booth <neil at daikokuya dot demon dot co dot uk>
- Subject: Re: Converting tm.h macros to functions
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Date: Tue, 19 Jun 2001 22:03:08 +0100 (BST)
- cc: <gcc at gcc dot gnu dot org>, Mark Mitchell <mark at codesourcery dot com>, mike stump <mrs at windriver dot com>
On Tue, 19 Jun 2001, Neil Booth wrote:
> How far do we want to go with putting stuff in structures? For
> example, should the target escapes like TARGET_FF go in? Or do we
> just leave that as a macro? If we leave it as a macro, we would
For TARGET_FF, simply putting a default value in defaults.h and removing
all the places that define it as the default would be an improvement.
(Similarly for all places where a default definition is included in many
targets - and removing commented out definitions where the default
suffices would also help greps.)
The main value of the target structure is for all the macros that either
call functions or have large definitions, not so much for simple constants
like that. (Though it could always go in target.target_ff if you want.)
> Another issue: how do stand-alone executables other than the front
> ends access this information? At present, we're defining the target
> structures in config/cpu/cpu.c. However, those files aren't linked
> against tradcpp and cpp0, for example. We're going to want cpp0 to
> have information about the target word sizes for doing CPP arithmetic,
> at least when we get this stuff right in the future. How do we handle
> that?
Follow my suggestion of getting rid of the cpp0 executable, giving
cc1/cc1plus/cc1obj a mode in which they preprocess only, deprecating then
removing -traditional and restricting tradcpp to be a preprocessor for
non-C code only :-). I still think doing this would help reap the full
benefits of integrated CPP, if we know that C code is only ever
preprocessed with the CPP integrated with the compiler.
(People wanting to link cpplib into other programs, such as GDB, would
then need to provide their own versions of the target arithmetic functions
- which only need to do arithmetic in target intmax_t/uintmax_t. If we
move to a general multiple precision library for handling target integers,
then the code for handling arithmetic on target integers could reasonably
be made independent of the rest of GCC, so the users need only extract the
type size information somehow.)
--
Joseph S. Myers
jsm28@cam.ac.uk