This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

> 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))
> +		      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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]