https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126667
--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-16 branch has been updated by Jakub Jelinek <[email protected]>: https://gcc.gnu.org/g:887a62fd0fd79cea79c5f292764aa79b1b039859 commit r16-9514-g887a62fd0fd79cea79c5f292764aa79b1b039859 Author: Jakub Jelinek <[email protected]> Date: Fri Aug 7 17:33:53 2026 +0200 s390: Fix ICE in usubc5 [PR126667] The following testcase ICEs on s390x-linux I believe since r15-6791 when usubc<mode>5 named pattern has been introduced. It intentionally uses general_operand predicate for operands[4], so that it can test it against const0_rtx and handle that differently, but otherwise it uses xor<mode>3 insn with operands[4] as first input, which has nonimmediate_operand. So we emit (xor:DI (const1_rtx) (const1_rtx)) and then fail to recognize it. The following patch just forces it into a register in that case, cse or combine can then simplify it. The other option would be to check for CONSTANT_P, force into REG unless it is CONST_INT and if it is CONST_INT, perform the xor at compile time, but then the compare too and unsure what to pass to the subsequent insn. The testcase is simplified from a larger botan real-world testcase (though there isn't usubc with a constant 1 carry in visible in the source). 2026-08-07 Jakub Jelinek <[email protected]> PR target/126667 * config/s390/s390.md (usubc<mode>5): If operands[4] is an immediate operand other than const0_rtx, force it into reg before using it in xor<mode>3 insn. * gcc.dg/pr126667.c: New test. * gcc.target/s390/pr126667.c: New test. Reviewed-by: Andreas Krebbel <[email protected]> (cherry picked from commit 8d0676db179aa31207bc4dd29e1c310823988f4b)
