Re: proposal to make SIZE_TYPE more flexible

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

On Tue, 10 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,
> 
> My thought here was that, since each __intN is specified by the
> target, they'd know to only do so if it doesn't match an existing (for
> that target) type.  But what if it does?  What if the standard types
> changed based on command line options, and the target wanted to offer
> an __intN as a "this will always work" alternative to standard types?

If you have such alternative types, you have extra complications: either 
they are the same as a standard type (and you need to define what the 
order of preference is and keep it constant, to avoid __intN changing from 
int to long at random), or they are distinct (and you need to define 
integer promotion ranks and ensure the front end code handles promotions 
for types the same size as int correctly).  Not having such alternatives 
avoids such complications.  Thus, I'd rather any possibility of such types 
came later after the basic support for types not matching the standard 
types.

(For the types you do have, there's a need to define C++ name mangling.  
There are various other issues for such extended types - see PR 50441 
comment 3, and PR 43622 - but you can safely ignore such issues for now as 
pre-existing problems with __int128.  Whereas __int128 does have mangling 
defined in cp/mangle.c, and targets can already define their own mangling 
for target-specific types through a hook.)

-- 
Joseph S. Myers
joseph@codesourcery.com