This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/39233] [4.4 Regression] ivopts + vrp miscompilation
- From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 18 Feb 2009 18:47:32 -0000
- Subject: [Bug tree-optimization/39233] [4.4 Regression] ivopts + vrp miscompilation
- References: <bug-39233-87@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-18 18:47 -------
This patch fixes it, with unknown side-effects. It should be ok for
the common sizetype extensions due to POINTER_PLUS_EXPR (sizetype is
unsigned for sane languages).
Index: tree-scalar-evolution.c
===================================================================
--- tree-scalar-evolution.c (revision 144265)
+++ tree-scalar-evolution.c (working copy)
@@ -2799,6 +2799,14 @@ simple_iv (struct loop *loop, gimple stm
|| chrec_contains_symbols_defined_in_loop (iv->base, loop->num))
return false;
+ /* If we folded casts and the result is a type where overflow is
+ undefined the IV may not be simple as it can have introduced
+ undefined overflow that wasn't there before. */
+ if (folded_casts
+ && (TYPE_OVERFLOW_UNDEFINED (type)
+ || POINTER_TYPE_P (type)))
+ return false;
+
iv->no_overflow = !folded_casts && TYPE_OVERFLOW_UNDEFINED (type);
return true;
The following patch would be slightly less intrusive (only affects IVOPTs),
but possibly other passes might be affected by the same bug. OTOH it
doesn't affect number-of-iterations analysis, which the above does.
Index: tree-ssa-loop-ivopts.c
===================================================================
--- tree-ssa-loop-ivopts.c (revision 144265)
+++ tree-ssa-loop-ivopts.c (working copy)
@@ -887,6 +887,14 @@ determine_biv_step (gimple phi)
if (!simple_iv (loop, phi, name, &iv, true))
return NULL_TREE;
+ /* If the IV may overflow and the result is a type we know does not
+ overflow we may have introduced undefined overflow. Do not use
+ that induction variable. */
+ if (!iv.no_overflow
+ && (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (name))
+ || POINTER_TYPE_P (TREE_TYPE (name))))
+ return NULL_TREE;
+
return integer_zerop (iv.step) ? NULL_TREE : iv.step;
}
@@ -992,6 +1000,15 @@ find_givs_in_stmt_scev (struct ivopts_da
if (!simple_iv (loop, stmt, lhs, iv, true))
return false;
+
+ /* If the IV may overflow and the result is a type we know does not
+ overflow we may have introduced undefined overflow. Do not use
+ that induction variable. */
+ if (!iv->no_overflow
+ && (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (lhs))
+ || POINTER_TYPE_P (TREE_TYPE (lhs))))
+ return false;
+
iv->base = expand_simple_operations (iv->base);
if (contains_abnormal_ssa_name_p (iv->base)
in the end someone finally should sit down and make overflowing/non-overflowing
arithmetic explicit in the IL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233