Commit Message

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.
I also constrained C++11 user-defined literals to stay at unsigned long
long, since they're being passed to a function with a parameter of that
type. If you'd prefer, I could handle that in the front end instead.
Does this make sense to you for 4.9?

Comments

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.