https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107709
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
IVOPTs is usually quite careful with this and the infer of non-NULL from
ptr + CST is new - that introduced a new undefinedness in GIMPLE. The
workaround would be to avoid the POINTER_PLUS_EXPR here and perform the
increment in an unsigned type.
You can see it creates
<Invariant Expressions>:
inv_expr 1: (signed int) (unsigned long) (pretmp_4 + 1) + 5
inv_expr 2: (signed int) (unsigned long) pretmp_4 + 5
inv_expr 3: (signed int) pretmp_4 + 5
inv_expr 4: (signed long) pretmp_4 + 1
and only the pretmp_4 + 1 somehow slips through here.
This is built in aff_combination_to_tree via
may_eliminate_iv and there cand_value_at which adds
iv->base as pointer. IIRC that was done on purpose to help
association and optimization. So this new undefined behavior hurts here.
The following fixes this
diff --git a/gcc/tree-ssa-loop-ivopts.cc b/gcc/tree-ssa-loop-ivopts.cc
index a6f926a68ef..0f180f70ff6 100644
--- a/gcc/tree-ssa-loop-ivopts.cc
+++ b/gcc/tree-ssa-loop-ivopts.cc
@@ -5233,7 +5233,7 @@ cand_value_at (class loop *loop, struct iv_cand *cand,
gimple *at,
aff_combination_add (&delta, &step);
tree_to_aff_combination (iv->base, type, val);
- if (!POINTER_TYPE_P (type))
+ //if (!POINTER_TYPE_P (type))
aff_combination_convert (val, steptype);
aff_combination_add (val, &delta);
}
but we for example still see pretmp_4 + 1 in the SCEV analysis result:
(get_scalar_evolution
(scalar = _2)
(scalar_evolution = {pretmp_4 + 1, +, 1}_1))
it basically means the compiler can nowhere build a POINTER_PLUS_EXPR
without being sure the pointer is not NULL. There same issue is already
existing for building signed arithmetic (that may not overflow).
I was last changing the above code to fix the signed arithmetic issue with
r0-129164-gd6adff07f12460 but exempted pointer types there.
Now, do we really want to introduce this new undefined behavior without
seriously auditing the code base?
