https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112363
--- Comment #2 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
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 80000000
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.
