https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113035
--- Comment #3 from Dusan Stojkovic <dusan.stojko...@rt-rk.com> --- Upon further investigation into the bug related to the vsetvl-*.c tests (specifically vsetvl-13.c, vsetvl-15.c, and vsetvl-23.c), we found the following: When using the mtune=sifive-7-series tuning, tests fail due to a different number of vsetvli instructions, with the expected format, in the compiler assembly output compared to mtune=rocket. For example, the test vsetvl-13.c has the following pattern: /* { dg-final { scan-assembler-times {vsetvli\s+zero,\s*[a-x0-9]+,\s*e32,\s*m1,\s*tu,\s*m[au]} 2 { target { no-opts "-O0" no-opts "-g" no-opts "-funroll-loops" } } } } */ This pattern expects two vsetvli instructions in the given format. With mtune=rocket, and -O2 optimization, the test passes because it generates the following instructions: vsetvli zero,a6,e32,m1,tu,ma vsetvli zero,a7,e32,m1,tu,ma However, with mtune=sifive-7-series, the compiler generates only one instruction (since it uses the movcc transformation): vsetvli zero,a6,e32,m1,tu,ma Since the pattern requires two instructions to match, the test fails for sifive-7-series. If we assume that the generated code works correctly as is, a reasonable solution would be to have two separate tests: one for sifive-7-series, where the expected number of matches is 1, and the original test for other mtune settings. Here’s the generated assembly code for reference: - With mtune=sifive-7-series: https://godbolt.org/z/hPcT7e3Gd - With mtune=rocket: https://godbolt.org/z/v59TYTfPa Configurations: riscv-sim/-march=rv64gcv/-mabi=lp64d/-mtune=rocket/-mcmodel=medlow riscv-sim/-march=rv64gcv/-mabi=lp64d/-mtune=sifive-7-series/-mcmodel=medlow