This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] New fold_range_test optimizations (take 2)
On Thu, Jun 17, 2004 at 06:39:36PM -0600, Roger Sayle wrote:
> This is OK for mainline. If its no trouble, could you add an extra
> sentence to the comment above build_range_check mentioning that this
> function can return NULL_TREE (all the callers check for a zero result,
> but this isn't described in the function's documentation).
Will do that.
> 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.
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))))
+ /* FALLTHROUGH */
- case ENUMERAL_TYPE:
if (tree_int_cst_equal (low0,
TYPE_MIN_VALUE (TREE_TYPE (low0))))
low0 = 0;
and similarly for high1.
Without this, the optimization will change behaviour of:
extern "C" void abort ();
test (enum3 x)
if (x == enum3_zero || x == enum3_seven)
foo (unsigned int x)
test ((enum3) x);
I'm aware that the conversion of 8 to enum3 type is unspecified in C++,
though am not sure if this optimization for such cases is worth the trouble.