[Bug target/112363] GCN: 'FAIL: gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c execution test'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112363

--- Comment #2 from Thomas Schwinge  ---
Right, that's what I suspected (see my "signed zero" comment).  And indeed, the
first check in 'main' instrumented as follows:

--- gcc/testsuite/gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c
+++ gcc/testsuite/gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c
@@ -74,8 +74,11 @@ main ()
   double res4 = reduc_minus_double (a, -0.0, cond1, n);
   double ref4 = reduc_minus_double_ref (a, -0.0, cond1, n);

+  __builtin_printf("L0\n");
+  __builtin_printf("eq %d, SBres 0x%x, SBref 0x%x\n", res1 == ref1,
signbit (res1), signbit (ref1));
   if (res1 != ref1 || signbit (res1) != signbit (ref1))
 __builtin_abort ();
+  __builtin_printf("L1\n");

..., I see:

L0
eq 1, SBres 0, SBref 8000
GCN Kernel Aborted
Kernel aborted

..., so unexpected 'signbit' difference of '-0.0' '+' reduction, and thus
'abort'.  Thus, likely, a GCN target issue -- for Andrew/Julian to take over.

[Bug target/112363] GCN: 'FAIL: gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c execution test'

[rdapp at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112363

--- Comment #1 from Robin Dapp  ---
This test was introduced in order to check that we correctly "reduce" with -0.0
as neutral element, i.e. a reduction preserves an intial -0.0 and doesn't turn
it into 0.0 by adding 0.0.  Kernel aborted means an assertion failed?  Or
something else?