https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925
--- Comment #22 from Steve Ellcey <sje at gcc dot gnu.org> --- (In reply to Christophe Lyon from comment #21) > I think this change caused regressions on armeb-none-linux-gnueabihf > --with-cpu=cortex-a9 --with-fpu=neon-fp16 (works OK > --with-fpu=vfpv3-d16-fp16) Ranier Orth reported a failure on SPARC64 as well, here was my reply to him. I don't know if your problem is the same without seeing the specific failure. -- Looking at the checks at the end, I also see that SPARC does include the 'Alignment' message and Aarch64 does not and that is handled by a conditional check. I think the fix is to check for 'vectorized 4 loops' when we support unaligned vector instructions (vect_hw_misalign is true) and check for 'vectorized 3 loops' otherwise. Does that sound reasonable to you? I think the reason this worked before is that that loop got vectorized due to being peeled and my change turned off the peeling and thus it could not be vectorized on machines that do not support unaligned vectorization.