Re: proposal to make SIZE_TYPE more flexible

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

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