https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127306
--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-16 branch has been updated by Jeff Law <[email protected]>: https://gcc.gnu.org/g:cbd45683904c8ec6858afec78daf46375ae3f52f commit r16-9655-gcbd45683904c8ec6858afec78daf46375ae3f52f Author: Jeff Law <[email protected]> Date: Fri Sep 11 16:25:27 2026 -0600 [RISC-V][PR target/127306] Fix two bugs in ADDI+AND+CTZ -> CTZ+BCLR optimization for RISC-V So this BZ exposed two problems. First in the case where we find the CTZ after the AND which clears the lowest set bit, we have to make sure to remove the original AND, otherwise we end up clearing two bits at a time, not good. Second, when determining if moving the CTZ is safe, we had an off-by-one error. So we could incorrectly transform a sequence when the AND was setting a value used by the CTZ. Had this been fixed first, it likely would have masked the first problem. I'd left a FIXME comment in the code. I was pretty sure I'd addressed the issue in the FIXME, which thankfully I had (modulo the off-by-one bug mentioned above). So the bogus comment is removed. Tested on riscv32-elf and riscv64-elf. It'll test on the K3 overnight and the K1 over the weekend (assuming the ULEB128 issues don't pop again). Pushing to the trunk. I'll let it simmer for a few days and likely backport to gcc-16 next week. PR target/127306 gcc/ * config/riscv/riscv-bclr-lowest-set-bit.cc (find_later_ctz): Fix off-by-one error for scan to verify ctz input isn't modified. (pass_bclr_lowest_bit_set::execute): Remove original AND in case where the CTZ is found after the AND. gcc/testsuite/ * gcc.target/riscv/pr127306.c: New test. (cherry picked from commit 3b4fd4a3b6e633dd2d2af7d3234bb79ccb61e3c5)
