Re: RFC: c-common PATCH to allow __int128_t literals

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 12 Feb 2013, Jason Merrill wrote:

> Although __int128_t is technically not an extended integer type because we
> don't want to change intmax_t, it seems appropriate to me to give it the same
> semantics as an extended integer type apart from that one aspect.
> 
> The only thing we weren't implementing is support for numeric literals, which
> is mostly just a matter of setting the libcpp precision option appropriately.
> Then I added definitions of the appropriate limits macros and updated affected
> tests.

Setting the libcpp precision sounds like it would conflict with the C99 
and C11 requirement that preprocessor arithmetic uses exactly the 
precision of intmax_t (C90 requirements were looser).  Thus, for example, 
"2 * UINTMAX_MAX == UINTMAX_MAX - 1" must be true in a #if expression, but 
it sounds like it would be false with this patch.

Similarly, the expected errors in c99-intconst-2.c are correct whenever 
intmax_t is 64-bit, whether or not __int128 is supported; something with 
the lexical form of an integer constant is required by the Constraints (so 
diagnostic required) to have a type and be within the range of that type, 
and the only types permitted are standard and extended integer types of 
the appropriate signedness.

Handling 128-bit constants without breaking standard requirements and 
without making intmax_t 128-bit means still giving appropriate diagnostics 
at least with -pedantic, and would also mean the preprocessor needs to 
handle multiple precisions to deal with such types in preprocessor 
expressions.

-- 
Joseph S. Myers
joseph@codesourcery.com