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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: <richard dot guenther at gmail dot com>, <gcc at gcc dot gnu dot org>
- Date: Fri, 20 Dec 2013 21:53:38 +0000
- 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> <201311140158 dot rAE1wCkg006136 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1311141318300 dot 21407 at digraph dot polyomino dot org dot uk> <201311152338 dot rAFNc9CJ007961 at greed dot delorie dot com> <b69fa903-a837-4d4e-aa00-c2a22b06c1c4 at email dot android dot com> <Pine dot LNX dot 4 dot 64 dot 1311161211240 dot 32731 at digraph dot polyomino dot org dot uk> <201311212241 dot rALMf15B028014 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>
On Fri, 20 Dec 2013, DJ Delorie wrote:
> > This seems mostly plausible, though I don't see anything to ensure that
> > __intN does not exist at all if the size matches one of the standard C
> > types, or if the mode fails targetm.scalar_mode_supported_p.
>
> What do we check against for this? Is there some table of standard
> types we can read the bitsize of in toplev.c, or should we use the
> macros as below? What about float/vector/complex types? I assume we
> don't check those since the __intN types are integer types.
I think using the macros for type sizes is fine, and float / vector /
complex types are completely irrelevant to this (so standard_type_bitsize
should maybe be standard_integer_type_bitsize).
> Also, should we special-case the int128 case so we always get __int128
> if the backend supports TImode?
No, the (TImode, __int128) pair should be handled the same way as all the
other __intN types rather than special-cased (of course you should ensure
the patch does not end up changing the set of configurations for which
__int128 is available).
--
Joseph S. Myers
joseph@codesourcery.com