[Bug target/121985] [RISCV] [Miscompile] GCC - riscv64 target, miscompiles at -O3 as well as -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985 --- Comment #13 from Sujay Kothadiya --- This issue was Found via fuzzer.
[Bug target/121985] [RISCV] [Miscompile] GCC - riscv64 target, miscompiles at -O3 as well as -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985 Robin Dapp changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Robin Dapp --- Fixed.
[Bug target/121985] [RISCV] [Miscompile] GCC - riscv64 target, miscompiles at -O3 as well as -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985 --- Comment #11 from GCC Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:a98b6cf01ba9fb69450a5e883c5d8e8600e2cc95 commit r16-5118-ga98b6cf01ba9fb69450a5e883c5d8e8600e2cc95 Author: Robin Dapp Date: Fri Nov 7 15:54:52 2025 +0100 vect: Do not set range for step != 1 [PR121985]. In PR120922 we first disabled setting a range on niters_vector for partial vectorization and later introduced a ceiling division instead. In PR121985 we ran into this again where a bogus range caused wrong code later. On top I saw several instances of this issue on a local branch that enables more VLS length-controlled loops. I believe we must not set niter_vector's range to TYPE_MAX / VF, no matter the rounding due to the way niters_vector is used. It's not really identical to the number of vector iterations but the actual number the loop will iterate is niters_vector / step where step = VF for partial vectors. Thus, only set the range to TYPE_MAX / VF if step == 1. gcc/ChangeLog: PR middle-end/121985 * tree-vect-loop-manip.cc (vect_gen_vector_loop_niters): Only set niter_vector's range if step == 1. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/pr121985.c: New test.
[Bug target/121985] [RISCV] [Miscompile] GCC - riscv64 target, miscompiles at -O3 as well as -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985 Robin Dapp changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=120922 --- Comment #10 from Robin Dapp --- This is due to changes from PR120922. I think we must not set niters_vector's range at all for riscv. Testing a patch.
[Bug target/121985] [RISCV] [Miscompile] GCC - riscv64 target, miscompiles at -O3 as well as -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985 --- Comment #9 from Robin Dapp --- I just ran into this issue while working on some gather/scatter simplification. Going to look into it once the VLS work has calmed down.
[Bug target/121985] [RISCV] [Miscompile] GCC - riscv64 target, miscompiles at -O3 as well as -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985 --- Comment #8 from Jeffrey A. Law --- Ah! I was struggling to believe how Ranger could be mucking up something this simple. Thanks for the nugget. Looks like it's back to Robin and I for the next step in debugging.
[Bug target/121985] [RISCV] [Miscompile] GCC - riscv64 target, miscompiles at -O3 as well as -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985 --- Comment #7 from Andrew Macleod --- Ranger is picking up a global value of [1,1] that was set in red.c.t186.vect a.c:7:22: note: === vect_make_slp_decision === a.c:7:22: missed: no stmts to vectorize. a.c:7:22: note: * Analysis failed with vector mode V1QI a.c:7:22: note: * Choosing vector mode RVVM8HI a.c:7:22: optimized: loop vectorized using masked 512 byte vectors and unroll factor 256 a.c:7:22: note: === vec_transform_loop === Global Exported: bnd.9_10 = [irange] char [1, 1] It is properly calculating bnd.9_10 as [6, 6] - [0, 5] resulting in [1, 6], but then applies the global range of [1, 1]. That is why dom3 is getting [1,1]
[Bug target/121985] [RISCV] [Miscompile] GCC - riscv64 target, miscompiles at -O3 as well as -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985 Jeffrey A. Law changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #6 from Jeffrey A. Law --- Forgot to add Andrew to this a while back. Andrew, note c#5. The comment is a couple months old, but I'm still seeing it on the trunk as of this morning. Compile the attached testcase with a riscv64-elf cross compiler using: -march=rv64gcv_zvl512b -mrvv-vector-bits=zvl -mrvv-max-lmul=dynamic -O3 -mabi=lp64d
[Bug target/121985] [RISCV] [Miscompile] GCC - riscv64 target, miscompiles at -O3 as well as -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985 --- Comment #5 from Jeffrey A. Law --- Somehow ranger is mucking things up. === BB 2 Imports: var_8 Exports: var_8 [local count: 153437704]: var_8 = f; pretmp_23 = a; if (var_8 <= 5) goto ; [85.71%] else goto ; [14.29%] 2->3 (T) var_8 : [irange] char [0, 5] 2->4 (F) var_8 : [irange] char [6, +INF] That looks fine to me. === BB 3 var_8 [irange] char [0, 5] Partial equiv (_28 pe8 bnd.9_10) Relational : (_26 != _31) [local count: 131511457]: bnd.9_10 = 6 - var_8; [ ... ] bnd.9_10 : [irange] char [1, 1] _28 : [irange] unsigned long [1, 1] That range on bnd.9_10 looks totally bogus.
[Bug target/121985] [RISCV] [Miscompile] GCC - riscv64 target, miscompiles at -O3 as well as -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org --- Comment #4 from Jeffrey A. Law --- If it's DOM, then it's mine, so I can take the next step here. But conceptually cprop_operand is just const/copy propagation, nothing particularly weird in there.
[Bug target/121985] [RISCV] [Miscompile] GCC - riscv64 target, miscompiles at -O3 as well as -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985 Robin Dapp changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||rdapp at gcc dot gnu.org Last reconfirmed||2025-09-17 Ever confirmed|0 |1 --- Comment #3 from Robin Dapp --- Heh, we're extracting element 1 when we should extract (6 - f). This seems to only happens with LMUL8 and zvl512b because we hold the multiplication result in a short (not in char for overflow reasons) and 512 bit * 8 can hold all 256 possible values of the loop. The loop counter is a char. dom3 does: Optimizing statement _28 = (unsigned long) bnd.9_10; Replaced 'bnd.9_10' with constant '1' gimple_simplified to _28 = 1; Folded to: _28 = 1; LKUP STMT _28 = 1 ASGN _28 = 1 Optimizing statement _31 = .SELECT_VL (_28, 256); Replaced '_28' with constant '1' At first sight this seems bogus but I haven't looked at cprop_operand what's actually going on.
[Bug target/121985] [RISCV] [Miscompile] GCC - riscv64 target, miscompiles at -O3 as well as -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985 --- Comment #2 from Sujay Kothadiya --- Created attachment 62409 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62409&action=edit Verbose log
[Bug target/121985] [RISCV] [Miscompile] GCC - riscv64 target, miscompiles at -O3 as well as -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985 Sujay Kothadiya changed: What|Removed |Added Build||x86 CC||skothadiya at whileone dot in Target||riscv --- Comment #1 from Sujay Kothadiya --- Verbose logs / Try -O2 or -O3 ```skothadiya@AMD-ubuntu:~...out-tmp-45-13831/testpad$ /home/skothadiya/CIFUZZRR/riscv-gnu-toolchain-build/bin/riscv64-unknown-linux-gnu-gcc -march=rv64gcv_zvl512b -mrvv-vector-bits=zvl -mrvv-max-lmul=dynamic -O3 red.c -o user-config.out -fsigned-char -fno-strict-aliasing -fwrapv -Wno-unknown-warning-option -Werror -Wfatal-errors -Wall -Wformat -Wno-int-in-bool-context -Wno-dangling-pointer -Wno-compare-distinct-pointer-types -Wno-overflow -Wuninitialized -Warray-bounds -Wreturn-type -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -Wno-unused-value -Wno-address -Wno-bool-compare -Wno-pointer-sign -Wno-bool-operation -Wno-tautological-compare -Wno-self-assign -Wno-implicit-const-int-float-conversion -Wno-constant-conversion -Wno-unused-value -Wno-tautological-constant-out-of-range-compare -Wno-constant-logical-operand -Wno-parentheses-equality -Wno-pointer-sign skothadiya@AMD-ubuntu:~...out-tmp-45-13831/testpad$ gcc -O1 red.c -o native.out -fno-strict-aliasing -fwrapv -w skothadiya@AMD-ubuntu:~...out-tmp-45-13831/testpad$ QEMU_CPU=rv64,vlen=512,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 /home/skothadiya/CIFUZZR/riscv-gnu-toolchain-build/bin/qemu-riscv64 user-config.out 1 15 skothadiya@AMD-ubuntu:~...out-tmp-45-13831/testpad$ timeout --verbose -k 0.1 1 ./native.out 1 9375```
