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
"Joseph S. Myers" <jsm@polyomino.org.uk> writes:
> 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.
Ugh, yeah, hex escape sequences do need to work, silly as that may be.
> 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.)
It's probably better to use the cpp_num functionality for this. I
don't want cpplib to have any compiled-in knowledge of the target.
> (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?)
I can't say this with 100% certainty because of the twisty maze that
is config/mips/*.h, but it appears to be a "feature" specific to irix
5.x, and to be more or less an accident -- the underlying type of wchar_t
is "int", and there exists an -m switch that makes int 64 bits wide.
zw