Bug 112363 - GCN: 'FAIL: gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c execution test'
Summary: GCN: 'FAIL: gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c execution test'
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 14.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: testsuite-fail
Depends on:
Blocks:
 
Reported: 2023-11-03 07:52 UTC by Thomas Schwinge
Modified: 2024-06-25 18:43 UTC (History)
4 users (show)

See Also:
Host:
Target: GCN
Build:
Known to work:
Known to fail:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Schwinge 2023-11-03 07:52:10 UTC 
For GCN target (tested '-march=gfx90a'), the 'gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c' recently added with PR111401 commit r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec608c7 "ifcvt/vect: Emit COND_OP for conditional scalar reduction" FAILs its execution test:

    '[...]/build-gcc/gcc/gcn-run' './vect-cond-reduc-in-order-2-signed-zero.exe'; echo XYZ$?ZYX
    GCN Kernel Aborted
    Kernel aborted
    XYZ134ZYX
    OK> 
    Elapsed time: 199 ms
    FAIL: gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c execution test

As that commit and test case does mention "signed zero", maybe that's where the problem lies?
Comment 1 Robin Dapp 2023-11-03 08:42:38 UTC 
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?
Comment 2 Thomas Schwinge 2023-11-03 09:31:50 UTC 
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.
Comment 3 Thomas Schwinge 2024-06-25 11:15:52 UTC 
Something in the last few weeks' worth of commits made this go back to PASS:

    PASS: gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c (test for excess errors)
    [-FAIL:-]{+PASS:+} gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c execution test
Comment 4 Thomas Schwinge 2024-06-25 18:43:42 UTC 
(In reply to Thomas Schwinge from comment #3)
> Something in the last few weeks' worth of commits made this go back to PASS:
> 
>     PASS: gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c (test for
> excess errors)
>     [-FAIL:-]{+PASS:+} gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c
> execution test

For posterity: it was commit r15-1187-g2b438a0d2aa80f051a09b245a58f643540d4004b "vect: Merge loop mask and cond_op mask in fold-left reduction [PR115382]" that fixed this for GCN target, too.