[patch] for PRs 27639 and 26719

[Zdenek Dvorak]

Hello,

> > > I do not see anything principially wrong with the code that ivopts
> > > produces; I think this is simply a VRP bug.
> > 
> > I disagree: IVOPTs should preserve the semantics of subtypes, that is to say 
> > the arithmetics operations are performed in the base type and the result is 
> > casted to the subtype.  IOW, it should not generate IVs in subtypes.  IIUC 
> > it's Jeff's position too: http://gcc.gnu.org/ml/gcc/2006-02/msg00590.html
> 
> OK, I was not aware of this (I was cced in the mail, but with a typo in
> the address).  I will prepare the patch to fix the problem.

here is the patch I'd consider correct.  I still need to test it (I
forgot to include ada in regtesting this time).

Zdenek

Index: tree-chrec.c
===================================================================
*** tree-chrec.c	(revision 115007)
--- tree-chrec.c	(working copy)
*************** nb_vars_in_chrec (tree chrec)
*** 1096,1101 ****
--- 1096,1116 ----
      }
  }
  
+ /* Returns true if TYPE is a type in that we cannot directly perform
+    arithmetics, even though it is a scalar type.  */
+ 
+ static bool
+ nonarithmetic_type_p (tree type)
+ {
+   /* Ada frontend uses subtypes -- an arithmetic cannot be directly performed
+      in the subtype, but a base type must be used, and the result then can
+      be casted to the subtype.  */
+   if (TREE_CODE (type) == INTEGER_TYPE && TREE_TYPE (type) != NULL_TREE)
+     return true;
+ 
+   return false;
+ }
+ 
  static tree chrec_convert_1 (tree, tree, tree, bool);
  
  /* Converts BASE and STEP of affine scev to TYPE.  LOOP is the loop whose iv
*************** convert_affine_scev (struct loop *loop, 
*** 1116,1121 ****
--- 1131,1141 ----
    bool must_check_src_overflow, must_check_rslt_overflow;
    tree new_base, new_step;
  
+   /* If we cannot really perform arithmetics in TYPE, avoid creating a scev
+      in this type.  */
+   if (nonarithmetic_type_p (type))
+     return false;
+ 
    /* In general,
       (TYPE) (BASE + STEP * i) = (TYPE) BASE + (TYPE -- sign extend) STEP * i,
       but we must check some assumptions.
*************** chrec_convert_aggressive (tree type, tre
*** 1305,1310 ****
--- 1325,1335 ----
    if (TYPE_PRECISION (type) > TYPE_PRECISION (inner_type))
      return NULL_TREE;
  
+   /* If we cannot really perform arithmetics in TYPE, avoid creating a scev
+      in this type.  */
+   if (nonarithmetic_type_p (type))
+     return false;
+ 
    left = CHREC_LEFT (chrec);
    right = CHREC_RIGHT (chrec);
    lc = chrec_convert_aggressive (type, left);
*************** chrec_convert_aggressive (tree type, tre
*** 1313,1339 ****
    rc = chrec_convert_aggressive (type, right);
    if (!rc)
      rc = chrec_convert (type, right, NULL_TREE);
! 
!   /* Ada creates sub-types where TYPE_MIN_VALUE/TYPE_MAX_VALUE do not
!      cover the entire range of values allowed by TYPE_PRECISION.
! 
!      We do not want to optimize away conversions to such types.  Long
!      term I'd rather see the Ada front-end fixed.  */
!   if (INTEGRAL_TYPE_P (type))
!     {
!       tree t;
! 
!       t = upper_bound_in_type (type, inner_type);
!       if (! TYPE_MAX_VALUE (type)
! 	  || ! operand_equal_p (TYPE_MAX_VALUE (type), t, 0))
! 	return NULL_TREE;
! 
!       t = lower_bound_in_type (type, inner_type);
!       if (! TYPE_MIN_VALUE (type)
! 	  || ! operand_equal_p (TYPE_MIN_VALUE (type), t, 0))
! 	return NULL_TREE;
!     }
!   
    return build_polynomial_chrec (CHREC_VARIABLE (chrec), lc, rc);
  }
  
--- 1338,1344 ----
    rc = chrec_convert_aggressive (type, right);
    if (!rc)
      rc = chrec_convert (type, right, NULL_TREE);
!  
    return build_polynomial_chrec (CHREC_VARIABLE (chrec), lc, rc);
  }