https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109573
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #11) > The testcase fails for me in gcc 11 on both x86_64-linux and i686-linux > (--enable-checking=yes,rtl,extra): > +FAIL: g++.dg/vect/pr109573.cc -std=c++20 (internal compiler error) > +FAIL: g++.dg/vect/pr109573.cc -std=c++20 (test for excess errors) > +FAIL: g++.dg/vect/pr109573.cc -std=c++2b (internal compiler error) > +FAIL: g++.dg/vect/pr109573.cc -std=c++2b (test for excess errors) > /usr/src/gcc-11/gcc/testsuite/g++.dg/vect/pr109573.cc:81:6: internal > compiler error: in vectorizable_live_operation, at tree-vect-loop.c:8876 > 0x89f86d vectorizable_live_operation(vec_info*, _stmt_vec_info*, > gimple_stmt_iterator*, _slp_tree*, _slp_instance*, int, bool, > vec<stmt_info_for_cost, va_heap, vl_ptr>*) > ../../gcc/tree-vect-loop.c:8876 Yep, I decided to backport the assert -> checking-assert change. There's no "good" way to handle the case we are running into. On the branch we run into an ADDR_EXPR. As said with the original patch to trunk an option would be to remove the assert alltogether, but not sure how important that would be. It's still interesting to see other cases we run into with this "FIXME" code path (but as said, there's no good way to capture this particular case within the assert).
