[Bug tree-optimization/115669] New: [15 Regression] rv64gcv -fwrapv miscompile since r15-1006-gd93353e6423

[Bug tree-optimization/115669] New: [15 Regression] rv64gcv -fwrapv miscompile since r15-1006-gd93353e6423

[patrick at rivosinc dot com]

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

            Bug ID: 115669
           Summary: [15 Regression] rv64gcv -fwrapv miscompile since
                    r15-1006-gd93353e6423
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
int a = 10;
unsigned b;
long long c[100];
int main() {
  long long *d = c;
  for (short e = 0; e < a; e++)
    b += ~(d ? d[e] : 0);
  __builtin_printf("%d\n", b);
}

Commands:
>  /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc red.c -march=rv64gcv -O3 -o red.out -fwrapv
> QEMU_CPU=rv64,vlen=256,v=true,vext_spec=v1.0,zve32f=true,zve64f=true timeout --verbose -k 0.1 4 /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/qemu-riscv64 red.out
-8

>  /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc red.c -march=rv64gcv -O2 -o red.out -fwrapv
> QEMU_CPU=rv64,vlen=256,v=true,vext_spec=v1.0,zve32f=true,zve64f=true timeout --verbose -k 0.1 4 /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/qemu-riscv64 red.out
-10

First bad commit: r15-1006-gd93353e6423

Found via fuzzer but Vineet bisected the 502.gcc_r benchmark breakage in
spec2017 for the riscv target to the same commit so this _might_ be the same
issue.

[Bug tree-optimization/115669] [15 Regression] rv64gcv -fwrapv miscompile since r15-1006-gd93353e6423

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=115450

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Patrick O'Neill from comment #0)
> Found via fuzzer but Vineet bisected the 502.gcc_r benchmark breakage in
> spec2017 for the riscv target to the same commit so this _might_ be the same
> issue.

So the 502.gcc_r miscompile might be PR 115450 since that is for aarch64 SVE
even.

[Bug tree-optimization/115669] [15 Regression] rv64gcv -fwrapv miscompile since r15-1006-gd93353e6423

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |15.0
                 CC|                            |pinskia at gcc dot gnu.org

[Bug tree-optimization/115669] [15 Regression] rv64gcv -fwrapv miscompile since r15-1006-gd93353e6423

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Target|riscv*-*-*                  |riscv*-*-*
                   |                            |aarch64-linux-gnu
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-06-26

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. Also reproduced for aarch64:
[apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc -O3
-march=armv9-a+sve2 -fno-vect-cost-model t67.c -static -O0
[apinski@xeond2 upstream-full-cross]$ ./install-qemu/bin/qemu-aarch64 a.out
-10
[apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc -O3
-march=armv9-a+sve2 -fno-vect-cost-model t67.c -static -fwrapv
[apinski@xeond2 upstream-full-cross]$ ./install-qemu/bin/qemu-aarch64 a.out
-16

[Bug tree-optimization/115669] [15 Regression] rv64gcv/aarch64+sve -fwrapv miscompile since r15-1006-gd93353e6423

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I will have a look.

[Bug tree-optimization/115669] [15 Regression] rv64gcv/aarch64+sve -fwrapv miscompile since r15-1006-gd93353e6423

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I can reproduce on aarch64 with -O2 -march=armv8.3-a+sve -fno-vect-cost-model
-fwrapv.  The reduction is

  <bb 3> [local count: 955630224]:
  # b_lsm.9_11 = PHI <_9(7), pretmp_42(6)>
  _4 = *_3;
  _5 = (signed int) _4;
  b.2_7 = (signed int) b_lsm.9_11;
  _15 = b.2_7 + -1;
  _8 = _15 - _5;
  _9 = (unsigned int) _8;

with -fwrapv and

  # b_lsm.9_11 = PHI <_7(7), pretmp_40(6)>
  _4 = *_3;
  _5 = (unsigned int) _4;
  _15 = b_lsm.9_11 + 4294967295;
  _7 = _15 - _5;

without.  So it seems the support for singed/unsigned converted reductions
is somehow broken.  At least for VLA vectors.

The epilog does

  # vect__9.22_59 = PHI <vect__9.22_58(3)>
  _60 = (vector([4,4]) signed int) vect__9.22_59;
  _61 = .REDUC_PLUS (_60);

I don't see where it goes wrong yet.

[Bug tree-optimization/115669] [15 Regression] rv64gcv/aarch64+sve -fwrapv miscompile since r15-1006-gd93353e6423

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think we use a wrong ELSE value:

  vect_b.19_54 = VIEW_CONVERT_EXPR<vector([4,4]) signed int>(vect_b_lsm.18_53);
  vect__15.20_56 = .COND_ADD (loop_mask_55, { -1, ... }, vect_b.19_54, { -1,
... });
^^^
  vect__8.21_57 = .COND_SUB (loop_mask_55, vect__15.20_56, vect__5.17_51,
vect__15.20_56);
  vect__9.22_58 = VIEW_CONVERT_EXPR<vector([4,4]) unsigned int>(vect__8.21_57);

I'll see how that happens.  Possibly an operand order issue.

[Bug tree-optimization/115669] [15 Regression] rv64gcv/aarch64+sve -fwrapv miscompile since r15-1006-gd93353e6423

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so the issue is the SLP child order is different than the scalar stmt
operand order and inconsistent with what we have recorded in reduc_idx.
Likely because we do

t.c:6:23: note:   pre-sorted chains of plus_expr
plus_expr -1 plus_expr b.2_7 minus_expr _5 

and that requires -fwrapv.  I think this is a latent issue possibly triggerable
with a masked SLP reduction.

[Bug tree-optimization/115669] [15 Regression] rv64gcv/aarch64+sve -fwrapv miscompile since r15-1006-gd93353e6423

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:7886830bb45c4f5dca0496d4deae9a45204d78f5

commit r15-1694-g7886830bb45c4f5dca0496d4deae9a45204d78f5
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Jun 27 11:26:08 2024 +0200

    tree-optimization/115669 - fix SLP reduction association

    The following avoids associating a reduction path as that might
    get STMT_VINFO_REDUC_IDX out-of-sync with the SLP operand order.
    This is a latent issue with SLP reductions but now easily exposed
    as we're doing single-lane SLP reductions.

    When we achieved SLP only we can move and update this meta-data.

            PR tree-optimization/115669
            * tree-vect-slp.cc (vect_build_slp_tree_2): Do not reassociate
            chains that participate in a reduction.

            * gcc.dg/vect/pr115669.c: New testcase.

[Bug tree-optimization/115669] [15 Regression] rv64gcv/aarch64+sve -fwrapv miscompile since r15-1006-gd93353e6423

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed (verified on aarch64).

[Bug tree-optimization/115669] [12/13/14 Regression] rv64gcv/aarch64+sve -fwrapv miscompile since r15-1006-gd93353e6423

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |15.0
             Status|RESOLVED                    |ASSIGNED
           Priority|P3                          |P2
   Target Milestone|15.0                        |12.5
         Resolution|FIXED                       |---
            Summary|[15 Regression]             |[12/13/14 Regression]
                   |rv64gcv/aarch64+sve -fwrapv |rv64gcv/aarch64+sve -fwrapv
                   |miscompile since            |miscompile since
                   |r15-1006-gd93353e6423       |r15-1006-gd93353e6423

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Let me re-open for backports, the issue is latent with a true SLP reduction.
Unfortunately getting a SLP reduction like the following to work seems
difficult.

int a = 10;
unsigned b, f;
long long c[100];
int main() {
  long long *d = c;
  for (short e = 0; e < a; e++)
    {
      b += ~(d ? d[2*e] : 0);
      f += ~(d ? d[2*e+1] : 0);
    }
  __builtin_printf("%d %d\n", b, f);
}