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

[Jason Merrill <jason@redhat.com>]

On 09/30/2014 07:14 PM, DJ Delorie wrote:
> Could one of you two please review the remaining C++ parts (cp/*) ?
>
>    https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02360.html

> +      for (i = 0; i < NUM_INT_N_ENTS; i ++)
>  	{
> +	  if (int_n_enabled_p [i]
> +	      && (same_type_p (TYPE_MAIN_VARIANT (t1),
> +			       int_n_trees[i].signed_type)
> +		  || same_type_p (TYPE_MAIN_VARIANT (t2),
> +				  int_n_trees[i].signed_type)))
> +	    {
> +	      tree t = ((TYPE_UNSIGNED (t1) || TYPE_UNSIGNED (t2))
> +			? int_n_trees[i].unsigned_type
> +			: int_n_trees[i].signed_type);
> +	      return build_type_attribute_variant (t, attributes);
> +	    }
>  	}

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.

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.

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.

> -  '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.

Jason