[Bug rtl-optimization/79901] ICE in prepare_cmp_insn, at optabs.c:3904

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Mar 6 14:20:00 GMT 2017


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79901

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
On the middle-end side, I see dom3 changing:
-  vect_patt_1.22_94 = VEC_COND_EXPR <vect__13.21_90 <= vect_cst__92,
vect__13.21_90, vect_cst__93>;
-  vect_patt_1.22_95 = VEC_COND_EXPR <vect__13.21_91 <= vect_cst__92,
vect__13.21_91, vect_cst__93>;
+  vect_patt_1.22_94 = MIN_EXPR <vect__13.21_90, { 4294967295, 4294967295,
4294967295, 4294967295, 4294967295, 4294967295, 4294967295, 4294967295 }>;
+  vect_patt_1.22_95 = MIN_EXPR <vect__13.21_91, { 4294967295, 4294967295,
4294967295, 4294967295, 4294967295, 4294967295, 4294967295, 4294967295 }>;
without actually verifying there is an optab for that (dunno where exactly, if
it is match.pd (which has some rule for something like that) or something
else),
or the problem is that MIN/MAX_EXPR expansion if there is no optab available
for it should attempt to expand it as a corresponding VEC_COND_EXPR (it ICEs
because it attempts to expand it as a condition followed by jump, which
obviously can't work).  Trying to fix this up in the veclower pass is not
possible, because dom3 comes after veclower2.


More information about the Gcc-bugs mailing list