https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101506
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Richard Sandiford <rsand...@gcc.gnu.org>: https://gcc.gnu.org/g:1ef9b135793a528c05c4a3e22649744955aa2dfb commit r12-2414-g1ef9b135793a528c05c4a3e22649744955aa2dfb Author: Richard Sandiford <richard.sandif...@arm.com> Date: Tue Jul 20 15:42:02 2021 +0100 aarch64: Tweak old vect-* tests to avoid new FAILs I'm not sure what these test were originally designed to test. vaddv and vmaxv seem to be testing for vectorisation, with associated scan-assembler tests. But they use arm_neon.h functions to test the results, which would presumably also trip many of the scans. That was probably what the split into vect-fmax-fmin.c and vect-fmaxv-fminv-compile.c was supposed to avoid. Anyway, the tests started failing after the recent change to allow staged reductions for epilogue loops. And epilogues came into play because the reduction loops iterate LANES-1 rather than LANES times. (vmaxv was trying to iterate LANES times, but the gimple optimisers outsmarted it. The other two explicitly had a count of LANES-1.) Just suppressing epilogues causes other issues for vaddv and vmaxv. The easiest fix therefore seemed to be to use an asm to hide the initial value of the vmaxv loop (so that it really does iterate LANES times) and then make the others match that style. gcc/testsuite/ PR testsuite/101506 * gcc.target/aarch64/vect-vmaxv.c: Use an asm to hide the true initial value of the reduction from the vectorizer. * gcc.target/aarch64/vect-vaddv.c: Likewise. Make the vector loop operate on exactly LANES (rather than LANES-1) iterations. * gcc.target/aarch64/vect-fmaxv-fminv.x: Likewise.
