This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Wide characters and GCC
- To: Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>
- Subject: Re: Wide characters and GCC
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Date: Sat, 9 Jun 2001 11:39:38 +0100 (BST)
- cc: <gcc at gcc dot gnu dot org>
On Sat, 9 Jun 2001, Michael Hayes wrote:
> Joseph S. Myers writes:
> > What should the formats of both narrow and wide STRING_CSTs be when the
> > target byte size (either hardware or C-level) is not the same as the host
> > byte size? The only vaguely active ports for which this is the case are I
> > think the C4X and PDP-10 ports; I've CC:ed their maintainers.
>
> I'm not sure you are getting at here. Can you be more specific?
The C and C++ front ends (at least) presume that a STRING_CST contains a
series of host bytes, each of which corresponds to exactly one target
byte. This is inappropriate; you can specify \x12345678 in a string
constant and this should represent a target byte with that value, if
target bytes are wide enough.
So, how should target bytes be stored in a STRING_CST when they are wider
than host bytes? (But for some targets, e.g. a cross from a common host
to pdp10, not necessarily an exact multiple of host bytes.) Similarly,
when the STRING_CST represents a wide string, should target bytes be
serialised in this manner (whatever manner is chosen to split them up to
fit in host bytes), or should target wide characters be split up as a
whole? (Also, if we support target char different from the target
hardware byte - and no-one has answered my question on this - is it bytes
or chars that we work by?)
Some arbitrary convention is needed to document in c-tree.texi. Then, new
code can follow it, as can old code when it is rewritten for whatever
reason.
> > What
> > testcases from the GCC testsuite fail on such targets because of problems
> > with GCC's support for different sizes of char?
>
> There are a number of testcases that fail with the C4x target due to
> an assumption that 4 chars fit in an integer. This has been too low a
> priority for me to worry about.
Given C4x testresults posted to gcc-testresults, maintainers of other
parts of the compiler might always look at some of the testcases they see
fail on C4x only, and try to fix them.
--
Joseph S. Myers
jsm28@cam.ac.uk