Summary
The carry/borrow-producing instructions vmadc.vv/vmadc.vx/vmadc.vi/vmsbc.vv/vmsbc.vx write a single mask-result register (EEW=1) while reading SEW-width register groups from vs2 and vs1. The RISC-V V extension (Section 5.2) requires the mask result to be written to element 0 of a single register, and a destination that falls inside a source register group is a reserved encoding unless it names the lowest-numbered register of that group. The affected RAX Vmadc/Vmsbc execution path performs no overlap check, so encodings such as
vsetvli t0, x0, e32, m2
vmadc.vv v1, v0, v2 # vd=v1 lies inside the vs2 group {v0,v1}: reservedexecute and write the mask result into a register that is simultaneously read as part of a source group, instead of raising an illegal-instruction trap.
Steps to reproduce
Build a minimal RV64 program with the V extension enabled and execute the witness above.
Expected result
The encoding raises an illegal-instruction exception (SIGILL / status 132 on QEMU).
Observed result
QEMU (qemu-riscv64 -cpu max,v=true) raises SIGILL via vext_check_sss / the mask-result overlap rule. Affected RAX executes the instruction and writes the mask result into the source group.
Environment
RAX current master as of 2026-08-13; QEMU 8.2.2 (-cpu max).
Suggested fix
Add the vmadc/vmsbc mask-result overlap rule to the vector legality checks: the destination may overlap a source group only when it names the lowest-numbered register of that group. The normative rule is norm:emul_offgroup_rsv in the RISC-V V extension specification.
The check applies to vs2 in every form. rs1 is checked only in the vv form, because the vx form reads a scalar from rs1 and the vi form reads a 5-bit immediate — neither may be treated as a vector register number for the overlap or alignment checks.
I searched the issue tracker and found no existing report for the vmadc/vmsbc mask-result overlap rule.
Relation to the general alignment rule
A separate report covers the general LMUL register-group alignment rule on the integer vadd.vv path (vd/vs must be aligned to EMUL). This report is the mask-result special case: vmadc/vmsbc write a single mask register (EEW=1, not subject to group alignment), but the destination must not fall inside a source group unless it names that group's lowest-numbered register. The two cases use different spec clauses (§3.4.2 vs §5.2) and different check points; neither patch can fix the other defect.
Summary
The carry/borrow-producing instructions
vmadc.vv/vmadc.vx/vmadc.vi/vmsbc.vv/vmsbc.vxwrite a single mask-result register (EEW=1) while reading SEW-width register groups fromvs2andvs1. The RISC-V V extension (Section 5.2) requires the mask result to be written to element 0 of a single register, and a destination that falls inside a source register group is a reserved encoding unless it names the lowest-numbered register of that group. The affected RAXVmadc/Vmsbcexecution path performs no overlap check, so encodings such asexecute and write the mask result into a register that is simultaneously read as part of a source group, instead of raising an illegal-instruction trap.
Steps to reproduce
Build a minimal RV64 program with the V extension enabled and execute the witness above.
Expected result
The encoding raises an illegal-instruction exception (SIGILL / status 132 on QEMU).
Observed result
QEMU (
qemu-riscv64 -cpu max,v=true) raises SIGILL viavext_check_sss/ the mask-result overlap rule. Affected RAX executes the instruction and writes the mask result into the source group.Environment
RAX current master as of 2026-08-13; QEMU 8.2.2 (
-cpu max).Suggested fix
Add the
vmadc/vmsbcmask-result overlap rule to the vector legality checks: the destination may overlap a source group only when it names the lowest-numbered register of that group. The normative rule isnorm:emul_offgroup_rsvin the RISC-V V extension specification.The check applies to
vs2in every form.rs1is checked only in thevvform, because thevxform reads a scalar fromrs1and theviform reads a 5-bit immediate — neither may be treated as a vector register number for the overlap or alignment checks.I searched the issue tracker and found no existing report for the
vmadc/vmsbcmask-result overlap rule.Relation to the general alignment rule
A separate report covers the general LMUL register-group alignment rule on the integer
vadd.vvpath (vd/vs must be aligned to EMUL). This report is the mask-result special case:vmadc/vmsbcwrite a single mask register (EEW=1, not subject to group alignment), but the destination must not fall inside a source group unless it names that group's lowest-numbered register. The two cases use different spec clauses (§3.4.2 vs §5.2) and different check points; neither patch can fix the other defect.