On Wed, 8 Jan 2014, DJ Delorie wrote: > > I think a patch is more useful once believe feature-complete, which > > means replacing the __int128 support with the new mechanism. > > One of the side-effects of taking out the existing __int128 support is > that __int128 isn't in the integer_type_kind list, so isn't a type > that is usable for constants. This breaks int128-4.C, which assumes a > 128-bit integer constant. If I add generic support for intN types in
I don't see constants in that test. It's not possible to write constants of type __int128 anyway. It *is* possible to build them up using expressions casting narrower constants to __int128. If you write a constant with a large value (with or without a suffix) that won't fit in target intmax_t / uintmax_t (or target long / unsigned long for C90), then you should get a pedwarn (and some larger type, maybe widest_integer_literal_type_node / widest_unsigned_literal_type_node, will be used if available). > i_t_k[], then we'll get (for example) 20-bit constants, which might > not be what we want. The only other option is to special-case > __int128 if we find it in the __intN list. Integer constant types should be taken from the int / long / long long (and unsigned variants) list. If a constant can't fit in any type ISO C allows for it, then it's reasonable to go on the extended types wider than long long, in increasing order of size, but __int20 is never relevant for constants as it's always narrower than long. > Thoughts? It's desirable anyway to have a way of representing what might be a standard type from integer_type_kind, or an extended type, given that it would be good for macros such as SIZE_TYPE to evaluate to enumerated values not magic strings. Maybe a reserved space of itk_* values just like reserving RID_* values? > Also, I noted a few tests check for the int128-specific error message > when the type is not supported, but as per our previous discussion, > the __int128 keyword just doesn't exist if the type isn't supported. > Do we need to discern between "not supported with these options" and > "not supported ever" ? I don't think there's a need to distinguish, although I don't think it would be particularly harmful to have an __int128 keyword present without a corresponding type for targets not supporting __int128, if that helps diagnostics, as long as nothing else special-cases __int128. (Draft TS 18661-3 has the interesting peculiarity that the keywords _FloatN for N = 16, 32, 64 or >= 128 and a multiple of 32, _DecimalN for N >= 32 and a multiple of 32, and _Float32x, _Float64x, _Float128x, _Decimal64x, _Decimal128x always exist as keywords whether or not the corresponding types are supported. Implementing that would I suppose require special checks to handle arbitrary _FloatN and _DecimalN (for valid N) as keywords - an infinite number of keywords - much as we handle _Imaginary as a keyword without otherwise implementing it.) -- Joseph S. Myers jos...@codesourcery.com
