blob: 8b19407dccc6189c8ad7f1c2cf330ad1741e4e3a (
plain) (
blame)
1
2
3
4
5
6
7
8
9
|
<think>
Okay, let's see. The user provided a bug report related to QEMU's RISC-V RVV implementation. The specific issue is an assertion failure when using the vmv.v.x instruction with e64 and vl set to vl_max on an RV32 guest. The error occurs because the code is trying to use a 32-bit function for a 64-bit operation, leading to an assertion that vece (vector element size) is within MO_32, but it's actually MO_64 here.
The problem is in the trans_vmv_v_x function in trans_rvv.c.inc. When the SEW (vector element width) is e64 (which is 64 bits), but the target is RV32, the code calls tcg_gen_gvec_dup_i32, which expects a maximum of 32 bits. The solution proposed involves checking if the target is 32-bit and the SEW is 64, then using a 64-bit temporary variable and generating the correct 64-bit instruction.
Since the issue is directly related to the handling of a specific instruction (vmv.v.x) and the incorrect code generation for that instruction under certain conditions (RV32 with e64), this is an instruction-related bug. The problem isn't with a syscall or general runtime error but specifically with the implementation of the vector instruction in QEMU's translation code. So the category should be "instruction".
</think>
instruction
|