Hi Karl, > -----Original Message----- > From: via Sourceware Forge <[email protected]> > Sent: 30 September 2025 13:05 > To: gcc-patches mailing list <[email protected]> > Cc: [email protected] > Subject: [PATCH v1 1/2] aarch64: Fix condition accepted by mov<GPF>cc > > > From: Karl Meakin <[email protected]> > > Apply the same fix from bc11cbff9e648fdda2798bfa2d7151d5cd164b87 > ("aarch64: Fix condition accepted by mov<ALLI>cc") to `MOV<GPF>cc`. > Fixes ICEs when compiling code such as `cmpbr-4.c` with `+cmpbr`. > > gcc/ChangeLog: > > * config/aarch64/aarch64.md(mov<GPF>cc): Accept MODE_CC > conditions directly; reject QI/HImode conditions. > > gcc/testsuite/ChangeLog: > > * gcc.target/aarch64/cmpbr-4.c: New test.
Would we not have the same problem with the other expanders that seem to have the same boilerplate code? Like "<neg_not_op><mode>cc" and "mov<GPF:mode><GPI:mode>cc"? These patterns look weird in that they accept a wide range of values and then restricts them in the expand pattern. I think instead the checks should be moved into a new predicate "aarch64_comparison_operator_cc" and then validation done there similarly to how we do with aarch64_comparison_operation. Then the predicate can be used in the other functions and also simplifies the expand patterns. Thanks, Tamar > --- > gcc/config/aarch64/aarch64.md | 16 +++++++++++----- > gcc/testsuite/gcc.target/aarch64/cmpbr-4.c | 12 ++++++++++++ > 2 files changed, 23 insertions(+), 5 deletions(-) > create mode 100644 gcc/testsuite/gcc.target/aarch64/cmpbr-4.c
