https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Yuri Rumyantsev from comment #12) > Created attachment 38367 [details] > modified patch The loop->aux flagging looks redundant to me. Why is ->safelen only valid before vectorization? I suppose we're lucky that no pass before vectorization applies any unrolling (like predictive commoning for example) as such pass must adjust ->safelen accordingly. But as LIM only cares for safelen > 0 _this_ property shouldn't change, not even by vectorization, no? That said, if vectorization makes ->safelen invalid then the vectorizer should adjust ->safelen properly (like any other passes invalidating it). I suppose most of the testsuite fallout you see is from the pass re-ordering (I didn't bootstrap/test that yet). The fails need to be investigated, but let's handle the pass-reordering separately and converge on a way to use ->safelen from LIM first.