[BUG] Incorrect fflags Set When Using fdiv Instruction to Divide by Infinity

[fly-1011]

Is there an existing CVA6 bug for this?

• I have searched the existing bug issues

Bug Description

In the CVA6 implementation, when the fdiv.s instruction is used to divide by a single-precision floating-point number representing positive infinity (0x7F800000), the Overflow (OF) flag in fflags is erroneously set. The value of fflags becomes 0x4, indicating an overflow error. However, in the Spike simulator, the fflags value is 0x0. According to the IEEE 754 standard, an Overflow (OF) condition should not occur in this case.

Steps to Reproduce:
Initialize ft4 to 0x00000000 and ft6 to 0x7F800000 (infinity).
Execute the instruction: fdiv.s ft1, ft4, ft6.
Observe the value of fflags.

The log from CVA6 is as follows:

core   0: 0x0000000080002018 (0x186270d3) fdiv.s  ft1, ft4, ft6
3 0x0000000080002018 (0x186270d3) f 1 0xffffffff00000000
core   0: 0x000000008000201c (0x001023f3) csrrs   t2, fflags, zero
3 0x000000008000201c (0x001023f3) x 7 0x0000000000000004

The log from Spike is as follows:

core   0: 0x0000000080002018 (0x186270d3) fdiv.s  ft1, ft4, ft6
core   0: 3 0x0000000080002018 (0x186270d3) f1  0xffffffff00000000
core   0: 0x000000008000201c (0x001023f3) csrrs   t2, fflags, zero
core   0: 3 0x000000008000201c (0x001023f3) x7  0x0000000000000000

I will also report this issue to CVFPU.

[Codemaker-1]

The root cause of this issue seems to be the same as #2058, where the OF bit is set incorrectly for infinite operations.

Please complete the tasks for thorough checking before submitting an issue.

[fly-1011]

The root cause of this issue seems to be the same as #2058, where the OF bit is set incorrectly for infinite operations.

Please complete the tasks for thorough checking before submitting an issue.

Hi @Codemaker-1
Thank you for your comment. May I ask if you are a developer of CVA6? I did not see your information in the list of contributors.

The instruction that triggers the OF exception in #2058 you mentioned is the fsqrt instruction, which has only one operand. The issue I raised is a div instruction, and the instruction types that trigger OF exceptions are different.

At the same time, the problem you mentioned has been fixed by the author of this problem. For details, see: #2063. The code involved in triggering the OF exception is only about the sqrt instruction. However, the code that triggers the OF exception when dividing the div instruction by infinity is: https://github.com/pulp-platform/fpu_div_sqrt_mvp/blob/917dd79cb2dc1a8f43df1a84e0e4231508a980e9/hdl/norm_div_sqrt_mvp.sv#L174C1-L184C12. Therefore, the code that triggers the OF exception is different.

Therefore, these are two separate bugs. I hope you can carefully research this issue before commenting.

[Codemaker-1]

If you differentiate whether a bug is new based on different manifestations of the same bug, it is clearly unreasonable. Additionally, I have no intention of arguing with you; I am merely stating my opinion. I have seen you submit incorrect bugs or erroneous comments more than once, which is why I am commenting. This has nothing to do with whether I am the repository maintainer. Furthermore, I suggest you look at the actual code to check if this PR has been merged.

[fly-1011]

If you differentiate whether a bug is new based on different manifestations of the same bug, it is clearly unreasonable. Additionally, I have no intention of arguing with you; I am merely stating my opinion. I have seen you submit incorrect bugs or erroneous comments more than once, which is why I am commenting. This has nothing to do with whether I am the repository maintainer. Furthermore, I suggest you look at the actual code to check if this PR has been merged.

Thank you very much for your reply,

I'm not arguing with you, I'm just stating the facts. You said that I submitted wrong comments more than once, so please list them for me and I will correct them.

Also I know this PR is not merged, I'm just showing you the code that triggers the OF exception. The code that triggers the bug is different from the question I asked.

So this is a new bug