https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #2 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Confirmed. Funny, we shouldn't vectorize that but really optimize to "return
0". Costing might be questionable but we also haven't optimized away the loop
when comparing costs.
Disregarding that, of course the vectorization should be correct.
The vect output doesn't really make sense to me but I haven't looked very
closely yet:
_177 = .SELECT_VL (2, POLY_INT_CST [16, 16]);
vect_patt_82.18_166 = (vector([16,16]) unsigned short) { 17, 18, 19, ... };
vect_patt_84.19_168 = MIN_EXPR <vect_patt_82.18_166, { 15, ... }>;
vect_patt_85.20_170 = { 32872, ... } >> vect_patt_84.19_168;
vect_patt_87.21_171 = VIEW_CONVERT_EXPR<vector([16,16]) short
intD.12>(vect_patt_85.20_170);
_173 = _177 + 18446744073709551615;
# RANGE [irange] short int [0, 16436] MASK 0x7fff VALUE 0x0
_174 = .VEC_EXTRACT (vect_patt_87.21_171, _173);
vect_patt_85.20_170 should be all zeros and then we'd just vec_extract a 0 and
return that. However, 32872 >> 15 == 1 so we return 1.
