https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124128
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index e96b1dc8391..9954894f1ec 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -1818,7 +1818,7 @@ ipa_vr_intersect_with_arith_jfunc (vrange &vr,
if (!ipa_vr_operation_and_type_effects (op_res, src_vr, operation,
operation_type, src_type))
return;
- if (src_type == dst_type)
+ if (range_compatible_p (vr.type (), op_res.type ()))
{
vr.intersect (op_res);
return;
fixes the ICE by replicating the intersect() test. Would be nice to
understand whether src_type/dst_type are "wrong" though or whether
the jump function encodes two ops, ABSU_EXPR plus conversion back to
int. In that case the guard was indeed wrong I'd say, but not sure
what range 'vr' then encodes? That of the target I guess. So why
intersect twice? We're intersecting again after applying a NOP_EXPR.
So like the following which avoids the issue as well:
diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index e96b1dc8391..cf8ff06c84e 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -1818,11 +1818,6 @@ ipa_vr_intersect_with_arith_jfunc (vrange &vr,
if (!ipa_vr_operation_and_type_effects (op_res, src_vr, operation,
operation_type, src_type))
return;
- if (src_type == dst_type)
- {
- vr.intersect (op_res);
- return;
- }
inter_vr = &op_res;
src_type = operation_type;
}
@@ -1830,9 +1825,10 @@ ipa_vr_intersect_with_arith_jfunc (vrange &vr,
inter_vr = &src_vr;
value_range tmp_res (dst_type);
- if (ipa_vr_operation_and_type_effects (tmp_res, *inter_vr, NOP_EXPR,
- dst_type, src_type))
- vr.intersect (tmp_res);
+ if (!ipa_vr_operation_and_type_effects (tmp_res, *inter_vr, NOP_EXPR,
+ dst_type, src_type))
+ return;
+ vr.intersect (tmp_res);
return;
}
