Non-Canonical NaN Representation in Double-Precision Results from fmadd.d Instruction

[youzi27]

Describe the bug
When executing the fmadd.d fa5, ft0, fa3, fa1, rtz instruction in the XS, the resulting value in fa5 for a NaN outcome does not conform to the expected canonical NaN representation for double-precision floating-point numbers as specified in the RISC-V ISA. Instead of getting the canonical NaN value (0x7ff8000000000000), a different NaN value is observed.

To Reproduce

• Initialize the ft0 and fa3 registers with e.g.. 0x00092afc56e7eaeb, and fa1 with e.g.. 0xffffffff00000000.
• Execute the fmadd.d fa5, ft0, fa3, fa1, rtz instruction.
• Observe the value in the fa5 register.

Expected behavior
The expected result for a NaN outcome in double-precision floating-point operation, according to the IEEE 754
standard and RISC-V ISA, should be the canonical NaN value. For double-precision, this is 0x7ff8000000000000, which represents a NaN with a positive sign, all exponent bits set to 1, and the most significant bit of the significand set to 1 (quiet bit), with all other significand bits clear.

Screenshots

Environment (optional, if necessary):

• OS: Ubuntu 22.04.3 LTS
• Compiler: gcc 11.4.0

Additional context
None

[poemonsense]

Internally known issue as in https://github.com/OpenXiangShan/XiangShan-internal/issues/5

[youzi27]

Internally known issue as in https://github.com/OpenXiangShan/XiangShan-internal/issues/5

Hi @poemonsense, thank you for the response. I would like to confirm if this is indeed an issue with XiangShan, but I am unable to open the link you shared.
Thank you.

[flaviens]

Hi! Nice catch @youzi27, despite apparently already known. Out of curiosity, how did you proceed for finding this issue? (Cascade maybe?)
Thanks!
Flavien

[youzi27]

Hi! Nice catch @youzi27, despite apparently already known. Out of curiosity, how did you proceed for finding this issue? (Cascade maybe?) Thanks! Flavien

Hi @flaviens ! It was through my own testing framework, not through Cascade approach.

[flaviens]

Interesting. This is typically the kind of bugs that Cascade would find immediately. Did you have any difficulties with it?

[youzi27]

Interesting. This is typically the kind of bugs that Cascade would find immediately. Did you have any difficulties with it?

Excellent, but as far as I know, Cascade itself does not support testing for XiangShan.

[flaviens]

It does :) . The only, small, effort that you would have to supply is to connect Cascade to it. More info in the bottom of the Readme. If you have any issues, please open an issue there.

I am not at all saying that Cascade is the solution to all problems but I would like to save you time, given that there is already a tool good at finding these bugs and designed to be particularly easy to use.

[youzi27]

It does :) . The only, small, effort that you would have to supply is to connect Cascade to it. More info in the bottom of the Readme. If you have any issues, please open an issue there.

I am not at all saying that Cascade is the solution to all problems but I would like to save you time, given that there is already a tool good at finding these bugs and designed to be particularly easy to use.

Thank you for your kind reminder. I will keep an eye on the Cascade project if needed in the future.