https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121268
--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jeff Law <[email protected]>: https://gcc.gnu.org/g:892195ef99cb6cf899f480d13a125bb5bfe62313 commit r17-5506-g892195ef99cb6cf899f480d13a125bb5bfe62313 Author: Jeff Law <[email protected]> Date: Fri Oct 23 06:59:05 2026 -0600 [RISC-V][PR target/121268] Fix splitter for pr121268 This is a mis-compile caught by my LLM checker for machine descriptions. Basically the pattern in question has two operands, one in SI, one in DI that ultimately refer to the same pseudo register. The pattern works fine when bits 32..63 in that register are zero and generates incorrect code if any of those bits are set. Given its a define_split, we can condition splitting on nonzero_bits and get the benefit of the pattern most of the time which is precisely what this patch does. The existing test can't prove the nonzero bits quality we need for 2 of the 24 tests, so the counts are adjusted accordingly. And an execution test is added which trips the bug. Assisted-By: LLM for pattern review and testcase generation Tested on riscv32-elf and riscv64-elf. Bootstrap on K3, K1 and c920 are all queued. Plan is to commit in the AM once I confirm the K3 and c920 bootstrap + regression cycle were happy. PR target/121268 gcc/ * config/riscv/bitmanip.md ((x & -x) - 1 -> (x - 1) & ~x): Ensure input register has zeros in bits 32..63 for extended SI variant. gcc/testsuite * gcc.target/riscv/pr121268.c: Adjust expected output. * gcc.target/riscv/pr121268-2.c: New test.
