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.
