Bug report: dependent arithmetic/muldiv single-precision operations cause wrong output

[flaviens]

Hi there!

I've detected a bug in VexRiscv.

Brief bug description

A pair of dependent single-precision floating arithmetic/muldiv operations (not necessarily immediately following each other), provides wrong results in some cases, differing by one from the expectation.

Example instance 1

fadd.s -> fsub.s

Snippet

Here is an example RISC-V (rv32imfd) snippet:

  .section ".text.init","ax",@progbits
  .globl _start
  .align 2
_start:
  # Enable the FPU
  li t0, 0x2000
  csrs mstatus, t0
  csrw	fcsr,x0

  la t0, .fdata0
  la t1, .fdata1

  fld ft0, (t0)
  fld ft3, (t1)

  fmul.s	ft1, ft3, ft3, rtz
  fsub.s ft2, ft0, ft1, rmm

  li t2, 0x18
  fsd ft2, 0(t2)

  sw x0, (x0)

infinite_loop:
  jal	x0,infinite_loop

.section ".fdata0","ax",@progbits
  .8byte 0xffffffff100e4696
.section ".fdata1","ax",@progbits
  .8byte 0xfffffffff6ad0aa4

Expected and actual results

We expect ft2= 0xffffffffff7fffff. I verified this with Spike.
However, VexRiscv returns ft0 = 0xffffffffff800000.

Example instance 2

fmul.s -> fsub.s

Snippet

Here is an example RISC-V (rv32imfd) snippet:

  .section ".text.init","ax",@progbits
  .globl _start
  .align 2
_start:
  # Enable the FPU
  li t0, 0x2000
  csrs mstatus, t0
  csrw	fcsr,x0

  la t0, .fdata0
  la t1, .fdata1
  la t2, .fdata2
  fld ft1, (t0)
  fld ft2, (t1)
  fld ft0, (t2)

  fadd.s ft3,ft0,ft1,rup
  fsub.s ft4,ft2,ft3,rdn

  li t2, 0x18
  fsd ft4, 0(t2)

  sw x0, (x0)

infinite_loop:
  jal	x0,infinite_loop

.section ".fdata0","ax",@progbits
  .8byte 0xffffffffab7d8deb
.section ".fdata1","ax",@progbits
  .8byte 0xffffffff2074e8c5
.section ".fdata2","ax",@progbits
  .8byte 0xffffffff0687a703

Expected and actual results

We expect ft4= 0xffffffff2b7d8ded. I verified this with Spike.
However, VexRiscv returns ft0 = 0xffffffff2b7d8dee.

Notes

There may be commonality in the root cause with #310, #311, #312, # 313 and #314, however this time we do not require conversions to trigger the bug.

Thanks!
Flavien

[Dolu1990]

5f67075 seems to fix it too