+2005-04-05 Eric Botcazou <ebotcazou@libertysurf.fr>
+ Sebastian Pop <sebastian.pop@cri.ensmp.fr>
+
+ PR tree-optimization/19903
+ * tree-chrec.c (chrec_convert): Return chrec_dont_know for constants
+ that don't fit in their type after conversion.
+
2005-04-05 Uros Bizjak <uros@kss-loka.si>
PR target/20421
\f
-/* Convert the initial condition of chrec to type. */
+/* Convert CHREC to TYPE. The following is rule is always true:
+ TREE_TYPE (chrec) == TREE_TYPE (CHREC_LEFT (chrec)) == TREE_TYPE
+ (CHREC_RIGHT (chrec)). An example of what could happen when adding
+ two chrecs and the type of the CHREC_RIGHT is different than
+ CHREC_LEFT is:
+
+ {(uint) 0, +, (uchar) 10} +
+ {(uint) 0, +, (uchar) 250}
+
+ that would produce a wrong result if CHREC_RIGHT is not (uint):
+
+ {(uint) 0, +, (uchar) 4}
+
+ instead of
+
+ {(uint) 0, +, (uint) 260}
+*/
tree
chrec_convert (tree type,
TREE_OVERFLOW (res) = 0;
if (CONSTANT_CLASS_P (res))
TREE_CONSTANT_OVERFLOW (res) = 0;
+
+ /* But reject constants that don't fit in their type after conversion.
+ This can happen if TYPE_MIN_VALUE or TYPE_MAX_VALUE are not the
+ natural values associated with TYPE_PRECISION and TYPE_UNSIGNED,
+ and can cause problems later when computing niters of loops. Note
+ that we don't do the check before converting because we don't want
+ to reject conversions of negative chrecs to unsigned types. */
+ if (TREE_CODE (res) == INTEGER_CST
+ && TREE_CODE (type) == INTEGER_TYPE
+ && !int_fits_type_p (res, type))
+ res = chrec_dont_know;
+
return res;
}
}