https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115936
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |15.0
--- Comment #2 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Looks like IVopts has generated an invalid gimple:
ivtmp.39_65 = ivtmp.39_59 + 0B;
where the IVs are DI mode and the offset is a pointer.
This comes from this weird candidate:
Candidate 8:
Var befor: ivtmp.39_59
Var after: ivtmp.39_65
Incr POS: before exit test
IV struct:
Type: sizetype
Base: 0
Step: 0B
Biv: N
Overflowness wrto loop niter: No-overflow
Looks like this invalid candidate was always generated, but was not selected
before as the old constant_multiple_of bailed out due to the operand_equal_p
constraining the type of the arguments.
Question is why this invalid candidate was generated at all, and that's due to:
/* Record common candidate with initial value zero. */
basetype = TREE_TYPE (iv->base);
if (POINTER_TYPE_P (basetype))
basetype = sizetype;
record_common_cand (data, build_int_cst (basetype, 0), iv->step, use);
which for the case the type is a pointer changes the base but not the step.
this makes base + step no longer valid gimple.
So I believe fix is:
diff --git a/gcc/tree-ssa-loop-ivopts.cc b/gcc/tree-ssa-loop-ivopts.cc
index 5fc188ae3f8..d590d6a9b78 100644
--- a/gcc/tree-ssa-loop-ivopts.cc
+++ b/gcc/tree-ssa-loop-ivopts.cc
@@ -3547,7 +3547,8 @@ add_iv_candidate_for_use (struct ivopts_data *data,
struct iv_use *use)
basetype = TREE_TYPE (iv->base);
if (POINTER_TYPE_P (basetype))
basetype = sizetype;
- record_common_cand (data, build_int_cst (basetype, 0), iv->step, use);
+ record_common_cand (data, build_int_cst (basetype, 0),
+ fold_convert (basetype, iv->step), use);
which fixes the ICE. Will regtest and submit.
