riscv-software-src
No coverage of NaN-boxing of 32-bit SP values in 64-bit F registers (fmv_w,...)
It's easy to introduce a bug in the handling of SP instructions that are stored in 64-bit wide F registers, but the tests currently doesn't appear to check for DP NaNs.
In particular,
rv64uf/move.S
Actually that's all that I checked.
To save Andrew time I figured I'd go ahead and post his (likely) response too.
"Thanks, this is certainly a hole, and if anyone wants to take [part of] this on, I'll happily review pull requests." - Andrew, probably
I'll take [part of] this on, because I'm interested in better testing of this feature as it pertains to recoded floating-point implementations, and I know where those bodies are buried.
The following tests are already testing certain aspects of NaN boxing:
rv64ud/ldst, test 6 rv64ud/move, tests 40-63
Obviously they're not comprehensive, and I'll try to do better.
I'm assuming your question didn't come out of the ether, and you encountered a bug that the tests didn't hit. Distilling that into a test is probably more useful than all the work I'll do.
Skimming through, I believe the coverage hole is fmv.w.x. rv64ud/ldst:test 6 is checking (flw; fsd), and it looks like rv64ud/move: tests 40-63 are testing fmv.x.w.
OK, I guess we should be testing all cross-products of mismatched-size moves:
fmv.w.x; fsd
fmv.d.x; fsw
fmv.w.x; fmv.x.d
fmv.d.x; fmv.x.w
flw; fsd
fld; fsw
flw; fmv.x.d
fld; fmv.x.w