https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123040
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, so we value-number
vect__15.21_63 = MEM <vector(16) char> [(char *)&bu];
find
vect_prephitmp_51.33_82 = VEC_COND_EXPR <mask__9.29_78, vect__50.32_81, { 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }>
which is of wrong type (signed vs. unsigned char), build + simplify
a V_C_E around this resulting in
.COND_NEG (mask__9.29_78, vect__2.30_79, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0 })
that's from
vect_iftmp.31_80 = -vect__2.30_79;
vect__50.32_81 = VIEW_CONVERT_EXPR<vector(16) signed char>(vect_iftmp.31_80);
vect_prephitmp_51.33_82 = VEC_COND_EXPR <mask__9.29_78, vect__50.32_81, { 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }>;
showing a missed .COND_NEG recognition as well. And yes,
vn_nary_op_lookup_stmt
does not handle calls because a NARY is never a call. But we really
always expect a NARY from this whole process given it's called
vn_nary_build_or_lookup ...
Testing fix.