Bin Cheng <bin.ch...@arm.com> writes: > Hi, > This simple patch fixes the ICE by adding LTGT in > vec_cmp<mode><v_cmp_result> pattern. > I also modified the original test case into a compilation one since > -fno-wrapping-math > should not be used in general. > Bootstrap and test on AArch64, test result check for x86_64. Is it OK? > I would also need to > backport it to gcc-7-branch. > > Thanks, > bin > 2017-07-27 Bin Cheng <bin.ch...@arm.com> > > PR target/81228 > * config/aarch64/aarch64-simd.md (vec_cmp<mode><v_cmp_result>): Add > LTGT. > > gcc/testsuite/ChangeLog > 2017-07-27 Bin Cheng <bin.ch...@arm.com> > > PR target/81228 > * gcc.dg/pr81228.c: New. > > diff --git a/gcc/config/aarch64/aarch64-simd.md > b/gcc/config/aarch64/aarch64-simd.md > index 011fcec0..9cd67a2 100644 > --- a/gcc/config/aarch64/aarch64-simd.md > +++ b/gcc/config/aarch64/aarch64-simd.md > @@ -2524,6 +2524,7 @@ > case EQ: > comparison = gen_aarch64_cmeq<mode>; > break; > + case LTGT: > case UNEQ: > case ORDERED: > case UNORDERED: > @@ -2571,6 +2572,7 @@ > emit_insn (comparison (operands[0], operands[2], operands[3])); > break; > > + case LTGT: > case UNEQ: > /* We first check (a > b || b > a) which is !UNEQ, inverting > this result will then give us (a == b || a UNORDERED b). */ > @@ -2578,7 +2580,8 @@ > operands[2], operands[3])); > emit_insn (gen_aarch64_cmgt<mode> (tmp, operands[3], operands[2])); > emit_insn (gen_ior<v_cmp_result>3 (operands[0], operands[0], tmp)); > - emit_insn (gen_one_cmpl<v_cmp_result>2 (operands[0], operands[0])); > + if (code == UNEQ) > + emit_insn (gen_one_cmpl<v_cmp_result>2 (operands[0], operands[0])); > break;
AFAIK this is still a grey area, but I think (ltgt x y) is supposed to be a trapping operation, i.e. it's closer to (ior (lt x y) (gt x y)) than (not (uneq x y)). See e.g. the handling in may_trap_p_1, where LTGT is handled like LT and GT rather than like UNEQ. See also: https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00583.html Thanks, Richard
