https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a27c534794dbe3530acae3427d2c58f937f1b050
commit r10-7472-ga27c534794dbe3530acae3427d2c58f937f1b050
Author: Jakub Jelinek
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
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): Use it instead of n in operand
2's
constraint.
* gcc.dg/pr94368.c: New test.
