This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: proposal to make SIZE_TYPE more flexible
- From: DJ Delorie <dj at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: richard dot guenther at gmail dot com, gcc at gcc dot gnu dot org
- Date: Wed, 8 Jan 2014 22:22:53 -0500
- Subject: Re: proposal to make SIZE_TYPE more flexible
- Authentication-results: sourceware.org; auth=none
- References: <201310300422 dot r9U4M6Mx002568 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1311212258320 dot 26755 at digraph dot polyomino dot org dot uk> <201311220828 dot rAM8Ss0q011135 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1311221231510 dot 5029 at digraph dot polyomino dot org dot uk> <201311221933 dot rAMJXDUt031382 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1311222046100 dot 12354 at digraph dot polyomino dot org dot uk> <201311222118 dot rAMLIxag003002 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1311230039030 dot 12354 at digraph dot polyomino dot org dot uk> <201312100334 dot rBA3YwMq017441 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1312101709200 dot 15324 at digraph dot polyomino dot org dot uk> <201312201947 dot rBKJlgKS003922 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1312202151510 dot 29339 at digraph dot polyomino dot org dot uk> <201312202159 dot rBKLxmIZ007173 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1312202215280 dot 29339 at digraph dot polyomino dot org dot uk> <201312202240 dot rBKMeVfM008400 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1312210100330 dot 29339 at digraph dot polyomino dot org dot uk > <201401090031 dot s090VGm9003938 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1401090214160 dot 8625 at digraph dot polyomino dot org dot uk>
> I don't see constants in that test.
// Test for int128 enums.
// { dg-do compile { target int128 } }
// { dg-options "" }
enum E {
e1 = 0xffffffffffffffff,
e2, e3
} e = e3;
#define SA(I,X) int a##I[(X)? 1 : -1]
SA(1, sizeof(E) == sizeof(__int128));
> 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?
It would have to be (1) sorted, and (2) kept in signed/unsigned pairs,
unless we take out the logic that uses it and replace it with
something that doesn't need that pattern. The table exists only for
finding "smallest matching type" etc.
> 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.
So... OK if __int20 and __int128 keywords exist always (for ports that
request them, which for __int128 would be all of them), but still be
"unsupported" if for some reason the port doesn't support them because
of command line options?