Re: __intN patch 3/5: main __int128 -> __intN conversion.

[DJ Delorie <dj at redhat dot com>]

> It seems like the int128 code here was broken and this is continuing 
> that brokenness.  Extended integer types have integer conversion rank 
> corresponding to their bitsize, so int128 should have higher rank than 
> long long, but here it was being checked after long long, and your code 
> also follows the long long code.  Also, we should be checking for both 
> signed and unsigned variants.

In this case, we know that the two types are the same bitsize.  We
also know that no __intN type has the same size as a standard type
(__int128 being an exception).  So in any case where other __intN
types match, they won't match any of the other tests in this area
anyway.  Aside from choosing unsigned vs sighed (which the code does),
there are no other conversions within those bitsizes.

So if you think the __int128 case should be elsewhere in that logic
(and it seems to me that "long long" *should* be preferred over
__int128 if they're ths same bitsize) I can move it, but I don't think
there's any need to worry about other __intN types here.

> If you plan to allow __intN with sizes between those of int and long 
> long, they need to have the appropriate intermediate conversion rank for 
> their size.

But... we don't know the bit sizes at the gcc source level, we only
know them by iterating the array.  We'd have to iterate the array at
evey step to see if it's between bitsize N and M, or add the standard
types to some array, or add the __intN variants to integer_types[] and
re-sort i_t[].  However, doing that introduces the __intN types to
*everything* that uses integer_types[].  I was hesitant to add
nonstandard types to the standard promotion rules.

> Basically I think the integral conversion code in cp_common_type ought 
> to be rewritten to work on integer_types rather than naming specific types.

That would be the "re-sort it" option.

> > -  'n',  /* itk_int128 */
> > -  'o',  /* itk_unsigned_int128  */
> > +  /* __intN types are handled separately */
> 
> Where are they mangled now?  I also don't see any mangling tests.

They mangle as Inn like I20 or I128 (that might be the wrong letter,
but the syntax is like that).  It surprised me that there was a case
for "other unknown types", but there's a case for it :-)

The NULs are there just to ensure the array access works, and to tell
the code that there isn't a special case for those types.