Bug/packld nanbox

[RunjiaChen]

Packed loads (vx_packlb_f / vx_packlh_f) do not NaN-box their result

This PR adds a reproducer test only — it does not fix the RTL. It makes an
existing defect observable and reproducible; the fix is left to whoever owns
the LSU, since (see Root cause below) it is not a one-line change.

Summary

vx_packlb_f / vx_packlh_f write a 32-bit float into a 64-bit FP register.
With EXT_D enabled (FLEN=64, the default config) RISC-V requires the upper
32 bits to be NaN-boxed (all ones). SimX does this; the RTL does not.

The upper half is not merely left un-set to ones — for packlb it is never
written, so it retains whatever the destination register previously held. The
architectural result of a packed load therefore depends on prior register
state.

Reproduction

cd build && ../configure --xlen=64 --tooldir=$HOME/tools
make -C tests/regression/packld_box
./ci/blackbox.sh --driver=simx   --app=packld_box
./ci/blackbox.sh --driver=rtlsim --app=packld_box

Measured, default config (1 cluster / 1 core / 4 warps / 4 threads,
VX_CFG_EXT_D_ENABLED=1, NUM_THREADS=4 SIMD_WIDTH=4 NUM_ALU_LANES=4):

driver	verdict	exit	counters
simx	PASSED!	0	value errors = 0, nanbox errors = 0
rtlsim	FAILED!	2	value errors = 0, nanbox errors = 512

512 = 16 tasks × 16 points × 2 instructions, i.e. every packed load.

value errors = 0 on both drivers is the important half: the packing itself —
byte order, strided addressing, both widths — is correct everywhere. The
NaN-box is the sole divergence.

Sample failures:

PACKLB NANBOX error t=0 p=0: upper32 expected=0xffffffff got=0x01e5a123 (full=0x01e5a12329316446)
PACKLH NANBOX error t=0 p=0: upper32 expected=0xffffffff got=0x00000000 (full=0x0000000029316446)
PACKLB NANBOX error t=0 p=1: upper32 expected=0xffffffff got=0x00000000 (full=0x000000009ced8664)

Reproduced on two independent machines (RHEL9 native, and Ubuntu 24.04 under
Docker/Rosetta). Counts are identical; the stale upper word differs between
machines (0x8d2428b1 vs 0x01e5a123), which is itself the evidence that
those bytes are never written rather than zeroed.

Why the existing packld test does not catch this

tests/regression/packld is blind by construction, not by a weak assertion:

dst_lb[tid * NUM_POINTS + p] = vx_packlb_f(base_lb, stride);  // float* => 32-bit fsw
memcpy(&got_lb, &h_dst_lb[t * NUM_POINTS + p], 4);            // host compares 4 bytes

The result is stored through a float* (a 32-bit fsw), so the NaN-box is
discarded before it ever reaches memory, and the host then compares four bytes.
The observation window is 32 bits wide and the defect is in the other 32 bits.
Both drivers report no failures.

What this PR contains

A single new directory, tests/regression/packld_box/, derived from
tests/regression/packld with the observation window widened:

• kernel.cpp : stores uint64_t instead of float, and reads the packed
  result with fmv.x.d fused into the same asm block as the packed load.
  As separate statements the compiler may spill the float through an
  fsw/flw pair, which would fabricate the very bits under test. Verified:
  the compiled kernel contains 0 fsw/flw and 32 fmv.x.d, one per
  packed load.
• main.cpp : buffers sized for uint64_t; the verify step counts the packed
  value and the NaN-box as separate error classes, so a box-only
  failure cannot be mistaken for a mis-packed value.
• Makefile, common.h : unchanged

No existing file is modified. packld_box is deliberately not added to
the tests/regression/Makefile app list, so the suite and CI are unaffected by
a test that is expected to fail. Happy to wire it in as a regression guard once
a fix lands — that is arguably where it belongs.

Environment

Upstream master @ d76b7f24. Also confirmed present at e6fcb7d2, so this is
neither new nor master-specific — and the diff between them does not touch
VX_uop_packld.sv (byte-identical) nor the boxing logic in VX_lsu_slice.sv.