akldc opened issue #10976:
.clifTest Casetest optimize set opt_level=none set preserve_frame_pointers=true set enable_multi_ret_implicit_sret=true function %main() -> f64x2 fast { const0 = 0x66dcb93ce18195cd25ba9b1858b0b8d5 block0: v14 = vconst.f64x2 const0 v16 = bor_not v14, v14 ; v14 = const0, v14 = const0 v80 = fmul.f64x2 v14, v16 ; v14 = const0 return v80 } ; print: %main()Result
Run this test case on four architectures.
[x86 ] %main() -> 0xffffffffffffffffffffffffffffffff [aarch64] %main() -> 0xffffffffffffffffffffffffffffffff [riscv64] %main() -> 0x7ff80000000000007ff8000000000000 [s390x ] %main() -> 0xffffffffffffffffffffffffffffffffThe result on riscv64 differs from the other architectures.
akldc added the bug label to Issue #10976.
akldc added the fuzz-bug label to Issue #10976.
alexcrichton added the cranelift:area:riscv64 label to Issue #10976.
akldc commented on issue #10976:
@alexcrichton Any follow‑up on this issue? I’ve found a few other related cases.
alexcrichton commented on issue #10976:
Alas we don't have any one actively working on the riscv64 backend at this time. I took a glance and I don't immediately know the solution myself, but I'm also pretty unfamilar with riscv64's vector extension. I do think that these issues are valuable nevertheless, but if you've got some related issues it might make sense to drop more tests on the current issues instead of opening new issues?
If you're curious to continue to do this testing it may make sense to exclude riscv64 for now until these preexisting issues have been fixed too.
akldc commented on issue #10976:
@alexcrichton
Ok, we won't be opening new issues for similar problems for now. We're very interested in Cranelift, and we might report new issues in the future if we run into something more meaningful or with different behavior — like issues related to other architectures such as aarch64 or s390x.
alexcrichton closed issue #10976:
.clifTest Casetest optimize set opt_level=none set preserve_frame_pointers=true set enable_multi_ret_implicit_sret=true function %main() -> f64x2 fast { const0 = 0x66dcb93ce18195cd25ba9b1858b0b8d5 block0: v14 = vconst.f64x2 const0 v16 = bor_not v14, v14 ; v14 = const0, v14 = const0 v80 = fmul.f64x2 v14, v16 ; v14 = const0 return v80 } ; print: %main()Result
Run this test case on four architectures.
[x86 ] %main() -> 0xffffffffffffffffffffffffffffffff [aarch64] %main() -> 0xffffffffffffffffffffffffffffffff [riscv64] %main() -> 0x7ff80000000000007ff8000000000000 [s390x ] %main() -> 0xffffffffffffffffffffffffffffffffThe result on riscv64 differs from the other architectures.
alexcrichton commented on issue #10976:
That seems reasonable yeah, I'm going to try again to poke at a few of these and see if I recognize them. FWIW if you're curious I'd be quite interested to hear more about what you're doing in in the Cranelift project meeting and I'm sure others would as well, so you're welcome to join if you'd like!
For this specific issue after digging in a bit I believe this is expected behavior. The results here are f64x2(NaN, NaN) and Cranelift doesn't guarantee deterministic NaN patterns across platforms. If I add
set enable_nan_canonicalization=trueI get the same result on riscv64 and x86 so this issue is otherwise working as intended. Now the others definitely look like legitimate issues though...
cfallin commented on issue #10976:
FWIW if you're curious I'd be quite interested to hear more about what you're doing in in the Cranelift project meeting and I'm sure others would as well, so you're welcome to join if you'd like!
I'll second this -- thanks for doing this round of fuzzing; and we're always interested in finding new ways of adding to our testing.
Last updated: Dec 06 2025 at 06:05 UTC