https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122297
--- Comment #4 from jchrist at linux dot ibm.com --- (In reply to Richard Biener from comment #3) > Created attachment 62573 [details] > patch > > Can you test this? With it we generate > > <bb 16> [local count: 81467477]: > # vect_last_29.19_72 = PHI <vect_last_29.19_71(12)> > # adjusted_loop_len_96 = PHI <adjusted_loop_len_69(12)> > _73 = adjusted_loop_len_96 + 1; > _74 = _73 >> 2; > _75 = _74 + 18446744073709551615; > _76 = .VEC_EXTRACT (vect_last_29.19_72, _75); > > should be double-checked on other len-vectorized targets. I wonder why > this didn't show up as issue on RISC-V? Are we maybe not using byte-based > lens everywhere? No, we are not. See the modified version of nodump-vecextract-1.c where we use element-sized len. We only fall back to byte-based lens if we actually use .LEN_LOAD and the backend only supportes this on QI mode. If we .VEC_EXTRACT from a vector that never was influenced by a .LEN_LOAD, we track element-based. That was exactly the point where I could not figure out how to fix this and decided to create this PR to ask for help. I tested your patch. As I suspected, it fixes the reproducer, but now the modified nodump-vecextract-1.c crashes.
