https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:a27c534794dbe3530acae3427d2c58f937f1b050 commit r10-7472-ga27c534794dbe3530acae3427d2c58f937f1b050 Author: Jakub Jelinek <ja...@redhat.com> Date: Tue Mar 31 11:08:22 2020 +0200 aarch64: Fix up aarch64_compare_and_swaphi pattern [PR94368] The following testcase ICEs in final_scan_insn_1. The problem is in the @aarch64_compare_and_swaphi define_insn_and_split, since 9 it uses aarch64_plushi_operand predicate for the "expected value" operand, which allows either 0..0xfff constants or 0x1000..0xf000 constants (i.e. HImode values which when zero extended are either 0..0xfff or (0..0xfff) << 12). The problem is that RA doesn't care about predicates, it honors just constraints and the used constraint on the operand is n, which means any HImode CONST_SCALAR_INT. In the testcase LRA thus propagates the -1 value into the insn. This is a define_insn_and_split which requires mandatory split. But during split2 pass, we check the predicate (and don't check constraints), which fails and thus we don't split it and during final ICE because the mandatory splitting didn't happen. The following patch fixes it by adding a matching constraint to the predicate and using it. 2020-03-31 Jakub Jelinek <ja...@redhat.com> PR target/94368 * config/aarch64/constraints.md (Uph): New constraint. * config/aarch64/atomics.md (cas_short_expected_imm): New mode attr. (@aarch64_compare_and_swap<mode>): Use it instead of n in operand 2's constraint. * gcc.dg/pr94368.c: New test.
