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: Sat, 23 Nov 2013 00:41:27 +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> <201310301917 dot r9UJHxg7028662 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1310302035190 dot 29408 at digraph dot polyomino dot org dot uk> <201310302219 dot r9UMJg9e001309 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1310302249250 dot 29408 at digraph dot polyomino dot org dot uk> <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>
On Fri, 22 Nov 2013, DJ Delorie wrote:
> > Does the target with __int20 actually have __int128 (i.e. pass
> > targetm.scalar_mode_supported_p (TImode))? But you should indeed be able
> > to have an arbitrary number of such types.
>
> It doesn't support it, but it does *have* it. In that the compiler
> correcly parses the __int128 keyword and knows to tell you it isn't
> supported. So, it needs at least two keywords. Which implies "it
> needs two..." in other places.
Making __int20 and __int128 exactly similar indicates __int128 *not* being
a keyword on targets not supporting it.
> And it's reasonable to expect that *someone* will want int16, int32,
> etc types once a general solution is in place.
As previously noted, it's best only to define such types where (a) there
is an integer mode passing targetm.scalar_mode_supported_p and (b) no
standard C type matches, to avoid issues with whether __int32 is the same
as int or not.
> > (d) I don't think the standard C types are particularly relevant to your
> > project.
>
> Should we be pulling the int128 support out of the integer_types[]
> list and put it in the global_trees[] (or some table) list? Because
> most of the int128 support is tied in with the standard C type
> handling, not the target-specific handling.
My guess is that the int128 support doesn't belong in any of the existing
global arrays, but in some new arrays supporting whatever set of intN
types the target has. That's just a guess; whether you follow or don't
follow it, your analysis of the code needs to justify your choice.
--
Joseph S. Myers
joseph@codesourcery.com