Re: [PATCH] New fold_range_test optimizations (take 2)

[Roger Sayle <roger at eyesopen dot com>]

On Fri, 18 Jun 2004, Jakub Jelinek wrote:
> > Thanks also to Alex for catching the INT_MAX + 1 != INT_MIN issue,
> > presumably for types narrower than their mode.  With those changes
> > it looks like your use of lang_hooks.types.unsigned_type is safe
> > even when the C++ front-end returns a "utype" of different width to
> > the original "etype", such that fold_convert performs an implicit
> > sign extension, c.f. PR middle-end/15069 and
> > http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00060.html
>
> Well, it was meant primarily for the hypothetical target using
> sign + absvalue encoding for signed integers.

I believe that its a requirement of GCC that the target supports signed
two's complement arithmetic for integers, and that several of the
language standards for GCC's front-ends mandate this.  I suspect that
we gave up trying to handle a "hypothetical" integer minus zero a long
time ago.  Your test would however prevent problems for C++'s bitfield
enumerals.


> But, concerning C++ enumerals, I wonder if I shouldn't add:
>               if (low0 && TREE_CODE (low0) == INTEGER_CST)
>                 switch (TREE_CODE (TREE_TYPE (low0)))
>                   {
> +		  case ENUMERAL_TYPE:
> +		    if (TYPE_PRECISION (TREE_TYPE (low0))
> +			!= GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (low0))))
> +		      break;
> +		    /* FALLTHROUGH */
>                   case INTEGER_TYPE:
> -                 case ENUMERAL_TYPE:
>                   case CHAR_TYPE:
>                     if (tree_int_cst_equal (low0,
>                                             TYPE_MIN_VALUE (TREE_TYPE (low0))))
>                       low0 = 0;
>                     break;
> and similarly for high1.


I agree that this would be safer.  Its best to assume that requesting
an unsigned or signed variant of a type is undefined for types that are
narrower than their modes (atleast until their semantics are straightened
out consistently across front-ends).  Ok for mainline with this change,
after the usual testing.


Roger
--