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.

Reply via email to