[Bug target/113073] New: [14] RISC-V: segfault from out of bounds memory access in gcc.dg/torture/pr112736.c

[Bug target/113073] New: [14] RISC-V: segfault from out of bounds memory access in gcc.dg/torture/pr112736.c

[ewlu at rivosinc dot com]

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

            Bug ID: 113073
           Summary: [14] RISC-V: segfault from out of bounds memory access
                    in gcc.dg/torture/pr112736.c
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

The testcase from pr112736

#include <sys/mman.h>
#include <unistd.h>

int a, c[3][5];

void __attribute__((noipa))
fn1 (int * __restrict b)
{
  int e;
  for (a = 2; a >= 0; a--)
    for (e = 0; e < 4; e++)
      c[a][e] = b[a];
}

int main()
{
  long pgsz = sysconf (_SC_PAGESIZE);
  void *p = mmap (NULL, pgsz * 2, PROT_READ|PROT_WRITE,
                  MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
  if (p == MAP_FAILED)
    return 0;
  mprotect (p, pgsz, PROT_NONE);
  fn1 (p + pgsz);
  return 0;
}

generates out of bound memory access on linux vector targets 

Program received signal SIGSEGV, Segmentation fault.
0x000000000001067c in fn1 (b=b@entry=0x2aaaab4be000) at
../gcc/gcc/testsuite/gcc.dg/torture/pr112736.c:14
14            c[a][e] = b[a];
(gdb) disass fn1
Dump of assembler code for function fn1:
   0x000000000001066c <+0>:     addi    a1,a0,-4
   0x0000000000010670 <+4>:     vsetivli        zero,4,e32,m1,ta,ma
   0x0000000000010674 <+8>:     addi    a5,gp,-1968
   0x0000000000010678 <+12>:    addi    a2,a0,-12
=> 0x000000000001067c <+16>:    vle32.v v1,(a1)
   0x0000000000010680 <+20>:    vrgather.vi     v2,v1,3
   0x0000000000010684 <+24>:    li      a7,-1
   0x0000000000010686 <+26>:    addi    a3,a5,40
   0x000000000001068a <+30>:    addi    a0,a0,-8
   0x000000000001068c <+32>:    addi    a4,a5,20
   0x0000000000010690 <+36>:    vle32.v v3,(a2)
   0x0000000000010694 <+40>:    vrgather.vi     v1,v3,3
   0x0000000000010698 <+44>:    vse32.v v2,(a3)
   0x000000000001069c <+48>:    vse32.v v1,(a5)
   0x00000000000106a0 <+52>:    vle32.v v2,(a0)
   0x00000000000106a4 <+56>:    sw      a7,-1984(gp)
   0x00000000000106a8 <+60>:    vrgather.vi     v1,v2,3
   0x00000000000106ac <+64>:    vse32.v v1,(a4)
   0x00000000000106b0 <+68>:    ret
End of assembler dump.
(gdb) p /x $a1
$8 = 0x2aaaab4bdffc
(gdb) p /x *$a1
Cannot access memory at address 0x2aaaab4bdffc

first appeared: https://github.com/patrick-rivos/gcc-postcommit-ci/issues/282

compile command: ./build-gcc-linux-stage2/gcc/xgcc
-B./build-gcc-linux-stage2/gcc/ ../gcc/gcc/testsuite/gcc.dg/torture/pr112736.c
-march=rv64gcv -mabi=lp64d -mcmodel=medlow -fdiagnostics-plain-output -O3 -g
-lm -o ./pr112736.exe

run command:
QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true
./bin/qemu-riscv64 ./pr112736.exe

[Bug target/113073] [14] RISC-V: segfault from out of bounds memory access in gcc.dg/torture/pr112736.c

[rguenth at gcc dot gnu.org]

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

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|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-12-19

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, OK.  This is because of

                        else if (alignment_support_scheme == dr_aligned)
                          /* Aligned access to excess elements is OK if
                             at least one element is accessed in the
                             scalar loop.  */
                          ;

it seems we're using dr_aligned when the target is happy with element
alignment, not only when the full vector is aligned according to its size.

I have a patch that instead produces

fn1:
.LFB0:
        lui     a5,%hi(.LANCHOR0)
        addi    a5,a5,%lo(.LANCHOR0)
        vsetivli        zero,4,e32,m1,ta,ma
        lw      a3,8(a0)
        vlse32.v        v1,0(a0),zero
        lw      a4,4(a0)
        lui     a6,%hi(a)
        li      a7,-1
        addi    a1,a5,40
        addi    a2,a5,20
        vmv.v.x v2,a3
        vse32.v v1,0(a5)
        sw      a7,%lo(a)(a6)
        vmv.v.x v1,a4
        vse32.v v2,0(a1)
        vse32.v v1,0(a2)
        ret

[Bug target/113073] [14] RISC-V: segfault from out of bounds memory access in gcc.dg/torture/pr112736.c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 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:aa2a48984c3d8c7a6a6da10d924e030b141b44cd

commit r14-6683-gaa2a48984c3d8c7a6a6da10d924e030b141b44cd
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Dec 19 09:58:03 2023 +0100

    tree-optimization/113073 - amend PR112736 fix

    The PR112736 testcase fails on RISC-V because the aligned exception
    uses the wrong check.  The alignment support scheme can be
    dr_aligned even when the access isn't aligned to the vector size
    but some targets are happy with element alignment.  The following
    fixes that.

            PR tree-optimization/113073
            * tree-vect-stmts.cc (vectorizable_load): Properly ensure
            to exempt only vector-size aligned overreads.

[Bug target/113073] [14] RISC-V: segfault from out of bounds memory access in gcc.dg/torture/pr112736.c

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Should be fixed.