https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91351

--- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #3)
> Switch lowering produces things like
> 
>   _6 = e_2(D) + 4294967285;
>   if (_6 > 2)
> 
> for range checking, where _6 has type enum E, and VRP2 later takes advantage
> of strict enum to assume that _6 cannot be large. It seems like the range
> check should use a type that is not an enum.
> 
> (the bisection result makes little sense to me)

The bisection point is correct, if I apply following patch:

diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 716d7397b49..321d3d7db66 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -7174,7 +7174,7 @@ fold_plusminus_mult_expr (location_t loc, enum tree_code
code, tree type,
   if (!same)
     return NULL_TREE;

-  if (! ANY_INTEGRAL_TYPE_P (type)
+  if (! INTEGRAL_TYPE_P (type)
       || TYPE_OVERFLOW_WRAPS (type)
       /* We are neither factoring zero nor minus one.  */
       || TREE_CODE (same) == INTEGER_CST)
diff --git a/gcc/tree.c b/gcc/tree.c
index efa49e99d65..33edbe7b374 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -11926,7 +11926,7 @@ int_cst_value (const_tree x)
 tree
 signed_or_unsigned_type_for (int unsignedp, tree type)
 {
-  if (ANY_INTEGRAL_TYPE_P (type) && TYPE_UNSIGNED (type) == unsignedp)
+  if (TREE_CODE (type) == INTEGER_TYPE && TYPE_UNSIGNED (type) == unsignedp)
     return type;

   if (TREE_CODE (type) == VECTOR_TYPE)
@@ -11940,17 +11940,6 @@ signed_or_unsigned_type_for (int unsignedp, tree type)
       return build_vector_type (inner2, TYPE_VECTOR_SUBPARTS (type));
     }

-  if (TREE_CODE (type) == COMPLEX_TYPE)
-    {
-      tree inner = TREE_TYPE (type);
-      tree inner2 = signed_or_unsigned_type_for (unsignedp, inner);
-      if (!inner2)
-       return NULL_TREE;
-      if (inner == inner2)
-       return type;
-      return build_complex_type (inner2);
-    }
-
   unsigned int bits;
   if (INTEGRAL_TYPE_P (type)
       || POINTER_TYPE_P (type)

the issue is gone.
For the problematic condition vrp really does folding:

Folding statement: e_8 = ASSERT_EXPR <e_7, e_7 < 14>;
Not folded
Folding statement: _6 = e_8 + 4294967285; // 4294967285 == -11
Not folded
Folding statement: if (_6 > 2)
Folding predicate _6 > 2 to 0
Folded into: if (0 != 0)

It does not look correct to me, I use an unsigned type with precision 5 bits
and the expression should be true for e_8 == 11 for example.
Marc?

Reply via email to