https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
Bug ID: 116686
Summary: [15 Regression] RISC-V:
gcc.target/riscv/rvv/autovec/pr114734.c failing with
zvl1024b lmul2
Product: gcc
Version: 15.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 following test is failing for linux rv64gcv_zvl1024b with -mrvv-max-lmul=m2
/data-disk-1/github/rise-postcommit-14/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/../scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run:
line 17: 93488 Aborted (core dumped) QEMU_CPU="${qemu_cpu}"
qemu-riscv${xlen} -r 5.10 "${qemu_args[@]}" -L ${RISC_V_SYSROOT} "$@"
FAIL: gcc.target/riscv/rvv/autovec/pr114734.c -O3 -ftree-vectorize execution
test
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/1708
Bisected to r15-3501-gead5f587dad as the first bad commit but I'm not actually
sure if this commit just revealed a latent bug or is the cause of the bug.
We're now just getting a segfault before main
gdb output
0x00002aaaab2bcc84 in _start ()
from
/scratch/ewlu/ci/triage/baseline/hash-ead5f587dad3206e45db7ac31f5c34c1530ae529/sysroot/lib/ld-linux-riscv64-lp64d.so.1
(gdb) b main
Breakpoint 1 at 0x104e0: file
../gcc/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr114734.c, line 15.
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x00000000ab2b3b66 in ?? ()
(gdb) bt
#0 0x00000000ab2b3b66 in ?? ()
(gdb) q
compile command:
./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/
../gcc/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr114734.c
-march=rv64gcv_zvl1024b -mabi=lp64d -mcmodel=medlow -mrvv-max-lmul=m2
-fdiagnostics-plain-output -O3 -ftree-vectorize -march=rv64gcv_zvl256b
-mabi=lp64d -fwhole-program -O3 -mrvv-vector-bits=zvl -g -lm -o ./pr114734.exe
execute command:
QEMU_CPU=rv64,vlen=256,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve64f=true
./bin/qemu-riscv64 ./pr114734.exe
quick note: the QEMU_CPU has vlen=256 because the testcase itself overwrote the
previous march during the compilation
-march=rv64gcv_zvl1024b ... -ftree-vectorize -march=rv64gcv_zvl256b
