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 jos...@codesourcery.com
