Hi!
The following testcase ICEs, because for TFmode the particular subtraction
pattern (*subtf3) is not enabled with the given options. Using
expand_simple_binop instead of emitting the subtraction by hand just moves
the ICE one insn later, NEG of ABS is not then recognized, etc., but
ultimately the problem is that when rs6000_emit_cmove is called for floating
point operand mode (and earlier condition ensures that in that case
compare_mode is also floating point), the expander makes sure the
operand mode is SFDF, but for the comparison mode nothing checks it, yet
there is just one *fsel* pattern with 2 separate SFDF iterators.
The following patch fixes it by giving up if compare_mode is not SFmode or
DFmode.
Bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk (and later for
release branches)?
2020-01-20 Jakub Jelinek <ja...@redhat.com>
PR target/93073
* config/rs6000/rs6000.c (rs6000_emit_cmove): Punt for compare_mode
other than SFmode or DFmode.
* gcc.target/powerpc/pr93073.c: New test.
--- gcc/config/rs6000/rs6000.c.jj 2020-01-12 11:54:36.399413620 +0100
+++ gcc/config/rs6000/rs6000.c 2020-01-20 15:02:38.872433115 +0100
@@ -14934,6 +14934,11 @@ rs6000_emit_cmove (rtx dest, rtx op, rtx
return 0;
}
+ /* Don't allow compare_mode other than SFmode or DFmode, for others there
+ is no fsel instruction. */
+ if (compare_mode != SFmode && compare_mode != DFmode)
+ return 0;
+
is_against_zero = op1 == CONST0_RTX (compare_mode);
/* A floating-point subtract might overflow, underflow, or produce
--- gcc/testsuite/gcc.target/powerpc/pr93073.c.jj 2020-01-20
15:04:50.480450797 +0100
+++ gcc/testsuite/gcc.target/powerpc/pr93073.c 2020-01-20 15:04:36.747657648
+0100
@@ -0,0 +1,16 @@
+/* PR target/93073 */
+/* { dg-do compile { target powerpc_vsx_ok } } */
+/* { dg-options "-mvsx -O1 -ffinite-math-only -fno-trapping-math" } */
+
+void bar (void);
+
+void
+foo (long double x, double y, double z)
+{
+ for (;;)
+ {
+ double a = x > 0.0 ? y : z;
+ if (a == 0.0)
+ bar ();
+ }
+}
Jakub
