On Thu, 18 Aug 2022, Kito Cheng wrote: > OK, thanks for tweaking this!
Committed now, thanks for your review! Would you mind sharing your opinion on my previous observation here: <https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598542.html>? I have since realised we have a `-mbranch-cost=' option letting the user set the threshold for choosing branches over alternative code sequences, so my concern is valid even for our tree unchanged and without the change just committed here applied. Consequently the test case may fail. E.g. with: RUNTESTFLAGS="--target_board remote-unmatched/-mbranch-cost=1 riscv.exp=pr105314.c" I get: PASS: gcc.target/riscv/pr105314.c -O0 (test for excess errors) FAIL: gcc.target/riscv/pr105314.c -O0 scan-assembler-not \tbeq\t PASS: gcc.target/riscv/pr105314.c -O1 (test for excess errors) FAIL: gcc.target/riscv/pr105314.c -O1 scan-assembler-not \tbeq\t [...] === gcc Summary === # of expected passes 9 # of unexpected failures 9 because GCC legitimately chooses to emit branches as less costly in this case. I think we need to pacify the test case somehow if it does not match the criteria for PR105314, either by excluding the case from testing in that situation or by forcing it via command-line options to make it match the criteria (or indeed by verifying a branch is produced regardless). Sadly Jakub chose not to chime in and it's not clear to me which approach would be the most appropriate here. Maciej
