https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120651
Alexey Merzlyakov <alexey.merzlyakov at samsung dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |alexey.merzlyakov at samsung
dot c
| |om
--- Comment #1 from Alexey Merzlyakov <alexey.merzlyakov at samsung dot com> ---
This most probably to be related to both pr117682 and pr120356 tickets.
Initially, the https://gcc.gnu.org/cgit/gcc/commit/?id=771256bcb9d is seem to
just uncover the problem by forcing to use const stepped vector (assembler code
after this patch became contain vid.v for this test). -O3 result changed from
correct "18446744073709540355" -> to "259" due to the problem described and
solved in pr117682.
The commit https://gcc.gnu.org/cgit/gcc/commit/?id=7b815107f40 fixes it, for
this test-case vector is having negative step1 = -512. However the result was
updated from "259" -> to another value "15875", as code still has incorrect
"vsll.vi" generated for constant stepped interleaved vector.
This secondary issue was described solved in pr120356. After applying the patch
proposed in https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688139.html,
the problem was disappeared:
> $ riscv64-rise-linux-gnu-gcc -march=rv64gcv -flto -O3 -mrvv-vector-bits=zvl
> pr120651.c -static -o pr120651.x -fsigned-char -fno-strict-aliasing -fwrapv
> $
> QEMU_CPU=rv64,vlen=128,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve64f=true
> timeout --verbose -k 0.1 4 qemu-riscv64 pr120651.x 1
> 18446744073709540355
