Re: [PATCH] Add target hook in C front end

[Zack Weinberg <zack at codesourcery dot com>]

On Tue, Dec 18, 2001 at 12:40:09AM +0000, Joseph S. Myers wrote:
> On Mon, 17 Dec 2001, Zack Weinberg wrote:
> 
> > Here's an alternate idea.  What if we add an option-processing hook to
> > libcpp?  It would be as simple as "all -m switches are handed to this
> > callback routine."  The MIPS back end could then define this hook to
> > calculate the appropriate value for __SIZE_TYPE__ and pass it to
> > cpp_define.  If properly written it would work correctly both with the
> > standalone and integrated preprocessors.
> 
> That would be preferable to the patch making __SIZE_TYPE__ a typedef, in
> that it doesn't break anything depending on the form of __SIZE_TYPE__ and
> doesn't complicate the front end - though I'd still prefer cpp0 to be a
> mode of cc1, to avoid duplication of option parsing in any way and to
> reduce the risk that cpp0 and cc1 parse the options differently.

In the long run, yes, we do want to make preprocessing be a mode of
cc1, but I don't see that happening in time for 3.1.  In fact, the
changes that it would require are just the sorts of structural changes
we're not supposed to make for the next couple of months.

> > Keep in mind that we will be removing traditional mode compilation
> > in 3.2, which means the only remaining use for tradcpp is to
> > macro-process things which are not C and therefore do not care
> > what size_t is.
> 
> The deprecation is of -traditional compilation - I didn't know that it 
> also covered compiling C with the traditional preprocessor (though I'd 
> prefer if it did, or at least if we can declare compiling C with the 
> traditional preprocessor may not work properly, so as to avoid this 
> problem with merging cpp0 into cc1).

Oh, -traditional-cpp?  I don't believe that will work with glibc any
more than plain -traditional will.  For instance, bits/string2.h
unconditionally uses ISO C token concatenation.  (And I'm surprised to
discover that math.h doesn't.)

zw