Possible bugs in fcvt.d.s

[misterjdrg]

So, I looking onto generated assembly for fcvt.d.s and seeing this:

00000000800004ac <inst_0>:
    800004ac:   00083c87                fld     fs9,0(a6)
    800004b0:   00205073                fsrmi   zero,0
    800004b4:   420c86d3                fcvt.d.s        fa3,fs9
    800004b8:   001018f3                fsflags a7,zero
    800004bc:   00d7b027                fsd     fa3,0(a5)
    800004c0:   0117b423                sd      a7,8(a5)

fcvt.d.s is converting from f32 to f64.
So fs9 @800004b4 should contain 32bit float.
fld loading f64 into fs9
Maybe flw should be used?

[allenjbaum]

IS this on an RV64 or an RV32? For an RV64, I think we need to see that this works properly with a NaN-boxed value, so it loads all 64 bits. For a single precision float, this will look like a NaN, but the cvt.d.s will notice that the upper 32bits are all 1 and will treat it as a single instead of an actual NaN.

…

On Sat, Apr 30, 2022 at 1:21 PM misterjdrg ***@***.***> wrote: So, I looking onto generated assembly for fcvt.d.s and seeing this: 00000000800004ac <inst_0>: 800004ac: 00083c87 fld fs9,0(a6) 800004b0: 00205073 fsrmi zero,0 800004b4: 420c86d3 fcvt.d.s fa3,fs9 800004b8: 001018f3 fsflags a7,zero 800004bc: 00d7b027 fsd fa3,0(a5) 800004c0: 0117b423 sd a7,8(a5) fcvt.d.s is converting from f32 to f64. So fs9 @800004b4 should contain 32bit float. fld loading f64 into fs9 Maybe flw should be used? — Reply to this email directly, view it on GitHub <#253>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJWI4Z4LKQVFJVLCQULVHWI5RANCNFSM5UYZV34A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[misterjdrg]

This is RV64.
Values in tests doesn't look like 64bit floats and most results of convertion is NaN.

riscv-arch-test/riscv-test-suite/rv64i_m/D/src/d_fcvt.d.s_b22-01.S

Line 221 in 6f7f47b

.dword 0x3fc08577924770d3

I trying to generate unit tests suite for my emulator, so
I patched spike to generate detailed traces of execution.
d_fcvt.d.s_b22-01.spike.reglog.txt

[allenjbaum]

If you do a fld of a properly Nan-boxed single precision value (so, 32bits of all1, 32 bits 0f fp single) or an. flw of a single precision value, and then convert single->double and then fsd, you should not be getting a Nan result unless the 32 bit of FP single was a Nan If you did a fld of a single precision value where the upper 32bits were not all1), you'll get a Nan upon conversion. That's a valid test to show that nan-boing is working properly. So, - are you using fld or flw, and - what is the value in hex that you're loading, and -what is the value being stored?

…

On Sun, May 1, 2022 at 1:19 PM misterjdrg ***@***.***> wrote: This is RV64. Values in tests doesn't look like 64bit floats and most results of convertion is NaN. I trying to generate unit tests suite for my emulator, so I patched spike to generate detailed trac d_fcvt.d.s_b22-01.spike.reglog.txt <https://github.com/riscv-non-isa/riscv-arch-test/files/8599666/d_fcvt.d.s_b22-01.spike.reglog.txt> es of execution. — Reply to this email directly, view it on GitHub <#253 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJT6NBWCANKAFB46JBTVH3RMTANCNFSM5UYZV34A> . You are receiving this because you commented.Message ID: ***@***.***>

[misterjdrg]

Form riscv spec:

When multiple floating-point precisions are supported, then valid values of narrower n-bit types,
n < FLEN, are represented in the lower n bits of an FLEN-bit NaN value, in a process termed
NaN-boxing. The upper bits of a valid NaN-boxed value must be all 1s.

So if 32 bit is properly boxed, all bits above 32-th should be 1
This is not the case

[allenjbaum]

If I am understanding you correctly (not a certainty), you are saying that some tests are doing a 64bit fld instruction of a value that doesn't not have the upper bits all1, and that the result of converting it to a double is a Nan. As I explained, that is the correct result, and a perfectly valid test to demonstrate that an implementation is checking that the upper bits are all1. What assumption am I making here that is not correct?

…

On Mon, May 2, 2022 at 7:31 AM misterjdrg ***@***.***> wrote: Form riscv spec: When multiple floating-point precisions are supported, then valid values of narrower n-bit types, n < FLEN, are represented in the lower n bits of an FLEN-bit NaN value, in a process termed NaN-boxing. The upper bits of a valid NaN-boxed value must be all 1s. So if 32 bit is properly boxed, all bits above 32-th should be 1 This is not the case — Reply to this email directly, view it on GitHub <#253 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJR5LA3PTXA3SOAJ3TTVH7RNNANCNFSM5UYZV34A> . You are receiving this because you commented.Message ID: ***@***.***>

[misterjdrg]

It true.
I mean fcvt.d.s doesn't have a single 'happy path' test, where 127-32 are ones.

[neelgala]

The issues mentioned here are already captured in this and this issue on isac and are being worked on.

[misterjdrg]

Ok, thanks