https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121758
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> --- So the issue is that in pattern detection we have t.c:4:10: note: over_widening pattern recognized: patt_27 = (int) patt_17; t.c:4:10: note: extra pattern stmt: patt_17 = patt_19 & 99; t.c:4:10: note: failed to update reduction index. and that is because when determining the first operand to look for when updating we fail to consider that this operand might be defined by a pattern or is possibly folded. We have _20 = _2 & g_3320_lsm.10_7; _5 = _20 & 611; with patterns patt_33 = (unsigned char) g_3320_lsm.10_7; patt_19 = _1 & patt_33; patt_4 = (int) patt_19; and patt_17 = patt_19 & 99; patt_27 = (int) patt_17; where the 2nd pattern also wipes the pattern def sequence of the earlier one but not the ->related_stmt on _20. But we search for _20 in the 2nd sequence and even if we fix that to look for patt_4 we won't find that. That can happen when pattern recog goes via its vect_get_internal_def. This makes the auto-fixup of STMT_VINFO_REDUC_IDX for pattern stmts break.
