https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
Edwin Lu <ewlu at rivosinc dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ewlu at rivosinc dot com
--- Comment #25 from Edwin Lu <ewlu at rivosinc dot com> ---
(In reply to Richard Sandiford from comment #24)
> Fixed on trunk so far, but it's latent on branches. I'll see what
> the trunk fallout is like before asking about backports.
It looks like we have a regression for riscv
I was going through the scan dump failures on trunk and ended up revisiting
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/463 where
gcc.dg/vect/costmodel/riscv/rvv/pr113281-[125].c are failing the scan-dump
checks. I didn't realize at the time that the scan dumps were checking code
correctness and ended up ignoring it.
It's still persisting on trunk (at least for pr113281-1.c
https://godbolt.org/z/M9EK44hKe)
A bisection on https://github.com/patrick-rivos/gcc-postcommit-ci/issues/463
commit range suggests
https://gcc.gnu.org/g:1a8261e047f7a2c2b0afb95716f7615cba718cd1 introduced it.
# first bad commit: [1a8261e047f7a2c2b0afb95716f7615cba718cd1] vect: Tighten
vect_determine_precisions_from_range [PR113281]
Configuration
../configure --prefix=$(pwd) --with-multilib-generator="rv64gcv-lp64d--"
make stamps/build-gcc-linux-stage1 -j 32
Testing
./build-gcc-linux-stage1/gcc/cc1
../gcc/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/pr113281-1.c
-march=rv64gcv -mabi=lp64d -mtune=rocket -mcmodel=medlow
-fdiagnostics-plain-output -march=rv64gcv_zvl256b -mabi=lp64d -O3
-ftree-vectorize -ffat-lto-objects -fno-ident -o pr113281-1.s
