This report was found with an automated fuzzing/emulation-differential tool and manually triaged against QEMU master c513597761d6fc06690b5b7cf10dfb7ab05815d0. The reproducer and expected outcomes were independently validated before submission. ## Host environment - Operating system: Linux x86_64 Docker execution plane. - OS/kernel version: Linux container; no guest kernel is involved because this uses linux-user QEMU. - Architecture: x86_64 host running RISC-V linux-user QEMU. - QEMU flavor: qemu-riscv32. - QEMU version: qemu-riscv32 rebuilt from master d49f87606a1c6e15701b26c1b16c5d7e948ffcb for the runtime matrix; current upstream source c513597761d6fc06690b5b7cf10dfb7ab05815d0 was checked separately. - QEMU command line: ```bash qemu-riscv32 -cpu rv32,f=false,d=false,zfa=false,zfh=false,zfhmin=false,zfinx=true,zhinx=true ./target_fsgnjn_h.elf qemu-riscv32 -cpu rv32,f=false,d=false,zfa=false,zfh=false,zfhmin=false,zfinx=true,zhinx=true ./target_fsgnjx_h.elf ``` ## Emulated/Virtualized environment - Operating system: statically linked Linux ELF under QEMU linux-user. - OS/kernel version: no guest kernel; the witnesses execute directly in linux-user mode. - Architecture: RISC-V RV32 with integer-register floating-point extensions Zfinx and Zhinx. ## Description of problem With `zfinx=true` and `zhinx=true`, the legal half-precision sign-injection instructions `fsgnjn.h` and `fsgnjx.h` compute a result but never write it back to `rd`. A witness that initializes the destination to a sentinel and reads it after the instruction observes the sentinel instead of the expected sign-injected value. The sibling `fsgnj.h` writes back correctly. The baseline target witnesses exit 1 three out of three times because the sentinel remains unchanged. The patched target witnesses and the `fsgnj.h` control exit 0 three out of three times. With `zhinx=false`, all three instructions raise the expected illegal-instruction result (exit 132), confirming that the issue is specific to the writeback path after extension gating. The ratified Zfh specification defines `FSGNJ.H`, `FSGNJN.H`, and `FSGNJX.H` as half-precision sign-injection instructions. The ratified Zfinx/Zhinx specification maps their floating-point register operands to the same-numbered integer registers and requires narrower results to be sign-extended in the integer register. The root cause is in `target/riscv/tcg/insn_trans/trans_rvzfh.c.inc`: `trans_fsgnjn_h()` and `trans_fsgnjx_h()` compute into a `dest_fpr()` temporary but return after `mark_fs_dirty(ctx)` without calling `gen_set_fpr_hs(ctx, a->rd, dest)`. Under Zfinx, the result therefore remains in a scratch value and is lost. The minimal fix is to insert `gen_set_fpr_hs(ctx, a->rd, dest);` before `mark_fs_dirty(ctx)` in both translators, mirroring `trans_fsgnj_h()`. ## Steps to reproduce 1. Build static RV32 Linux witnesses containing `fsgnj.h x8,x6,x7` as a control, `fsgnjn.h x10,x6,x7` as a target, and `fsgnjx.h x12,x6,x7` as a target. 2. Run each witness with `qemu-riscv32 -cpu rv32,f=false,d=false,zfa=false,zfh=false,zfhmin=false,zfinx=true,zhinx=true`. 3. The baseline control exits 0, while the `fsgnjn.h` and `fsgnjx.h` targets exit 1; the expected result for all three is exit 0. 4. Repeat with `zhinx=false`; all three instructions must be rejected with exit 132. ## Additional information The runtime witnesses and patched matrix were rebuilt and rerun on master d49f87606a1c6e15701b26c1b16c5d7e948ffcb. Source review against current upstream c513597761d6fc06690b5b7cf10dfb7ab05815d0 still finds both missing writeback calls, and the proposed patch applies cleanly there. I am not claiming a fresh runtime matrix for c513597761d6fc06690b5b7cf10dfb7ab05815d0. The specification references are https://docs.riscv.org/reference/isa/v20260120/unpriv/zfh.html and https://docs.riscv.org/reference/isa/v20260120/unpriv/zfinx.html. A read-only search of the QEMU GitLab issue tracker on 2026-09-03 found no matching issue for `zhinx fsgnj`, `fsgnjn.h`, or `fsgnjx.h`. This report has no security implications and does not require confidential handling. The related patch will be sent to qemu-devel according to QEMU's patch submission workflow; it is intentionally not attached to this issue.