This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Add target hook in C front end
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Eric Christopher <echristo at redhat dot com>
- Cc: Zack Weinberg <zack at codesourcery dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 17 Dec 2001 01:14:06 +0000 (GMT)
- Subject: Re: [PATCH] Add target hook in C front end
On 16 Dec 2001, Eric Christopher wrote:
> > Joseph Myers has proposed that -save-temps cause cc1 to write out an
> > .i file as a side effect. If that change were made, then a patch
> > along these lines would be fine; until then, handling of __SIZE_TYPE__
> > must remain in the specs.
On further discussion it was concluded that reliably handling ICEs
(without producing an incomplete or mangled .i file) means that cc1 should
be run twice when -save-temps is used, once to produce the .i file and
once to process it.
> I don't think you see what the problem is, as I was mentioning to Neil,
> take a look at gcc/config/mips/isa3264.h for the handling of this. That
> spec file is absolutely unmaintainable and doesn't work either. :) This
> makes multilibs that set pointer size untenable. I'm willing to look at
> making cc1 spit out a .i file, but it seems that it makes more sense to
> do this than not.
There would still be nothing much MIPS-specific about it. Once the
command-line options have been parsed, in an appropriate language hook
shared between C and C++ and used whether compilation or just
preprocessing is taking place, the sizes of all types, and the type names
for size_t, etc., would be computed. cpp_define would be used to define
the macros used by header files; similarly, it would define various macros
for the use of a more reliable <limits.h>. (The existing macros would
presumably expand to a function or variable that gives the correct name
for the type, given the command line options, that will be used to create
the tree nodes.) All the existing architectures would have the now
unnecessary specs handling of these matters removed at the same time.
If we want headers such as <stddef.h> still to work with traditional
preprocessing, tradcpp would also need integrating with cc1 so that these
defines can affect it as well.
Joseph S. Myers