Re: Target deprecation, round three

[Nathanael Nerode <neroden@twcny.rr.com>]

>Now, cpplib, c-lex.c, and c-parse.in all make extensive use of
>character constants to designate members of the basic source character
>set.  The actual values of these constants are defined by the
>execution character set of the host compiler.  If that set is ASCII or
This sounds wrong.  Shouldn't the values be defined by the execution set 
of the *build* compiler?  In a Canadian cross, that should be the 
compiler which is used to compile these files.

>any superset thereof, there is no problem -- ASCII corresponds exactly
>to the portion of ISO10646 containing the basic source character set.
>But if the execution character set of the host compiler is EBCDIC,
>the character constants will have inappropriate values for working
>with text encoded in UTF8.

Again, *build* compiler.  I suspect HOST_EBCDIC may be misnamed.

Suppose we require that the *build* compiler work in ASCII, and require 
that GCC operate in an encoding of ISO10646 internally.  We can then 
still make a native GCC for an EBCDIC host by causing all files input to
be translated from EBCDIC to ISO10646 before the rest of GCC operates, 
and likewise on output.  However, this native GCC can't be *built* on an 
EBCDIC machine; it has to be built on an ASCII machine.

In other words, you can make GCC target EBCDIC machines, you can have 
EBCDIC machines as hosts running GCC, but you can't actually build GCC 
on an EBCDIC machine.

I think that's a reasonable, low-gunk solution.  Are the users of EBCDIC 
environments wedded to the ability to bootstrap on their machines, or 
would being able to run GCC (built elsewhere) on their machines be 
sufficient?

--Nathanael