This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Further baby steps toward standalone cpplib
- From: "Joseph S. Myers" <jsm at polyomino dot org dot uk>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sun, 13 Jul 2003 19:24:54 +0100 (BST)
- Subject: Re: Further baby steps toward standalone cpplib
- References: <877k6m5o5e.fsf@egil.codesourcery.com>
On Sun, 13 Jul 2003, Zack Weinberg wrote:
> * cppchar_t is now limited to 32 bits wide. There are a few targets
> for which wchar_t can be 64 bits wide - MIPS in certain
> configurations - but there is no meaningful interpretation for a
> wchar_t value larger than 2^31, so I do not think this is an issue.
> The value will still be properly sign- or zero-extended to the full
> width of a INTEGER_CST node upon being handed back from cpplib.
Someone is working on support for a target with 64-bit bytes
<http://gcc.gnu.org/ml/gcc/2003-06/msg01130.html>. While such DSP or
similar targets clearly aren't a primary consideration for GCC at present,
a conforming implementation for them does require that char and wchar_t
work properly as integer types of the appropriate width, with escape
sequences specifying integers up to that width handled properly. Perhaps
a --enable-64-bit-cpplib configure option, enabled automatically by
toplevel configure for particular targets needing it? (Not something to
block this patch, since there are plenty of other areas where targets with
wide bytes don't work properly.)
(Is the 64-bit wchar_t for those MIPS targets actually correct for the ABI
being implemented? If so, what were the ABI designers thinking?)
--
Joseph S. Myers
jsm@polyomino.org.uk