fix(failure_code): use fflags CSR instead of fcsr in fflags mismatch reporter

[dev-aditya-hub]

Summary

While going through the failure reporting path for floating-point tests, I noticed that failedtest_saveresults_fflags was reading fcsr to capture the bad value — but the reference signature is built using csrr fflags, which gives only the lower 5 bits (NV, DZ, OF, UF, NX). fcsr includes frm[2:0] in bits 7:5 on top of that.

So whenever a test runs with a non-default rounding mode (RTZ, RDN, RUP, RMM), the reported bad value has frm bits set that the expected value doesn't, making the diff look like a frm discrepancy even when the actual problem is just an fflags mismatch. In the worst case this causes someone to write it off as a test infra issue rather than a real hardware defect.

The fix is a one-liner — swap fcsr for fflags in the re-read so the reporting path matches how the signature was written.

Root Cause

# Before (wrong)
csrr x6, fcsr      # reads {frm[2:0], fflags[4:0]} — up to 8 bits

# After (correct)
csrr x6, fflags    # reads fflags[4:0] only — matches signature format

The comparison in RVTEST_SIGUPD_FFLAGS was already doing the right thing (csrr _LINK_REG, fflags), so PASS/FAIL determination is unaffected. Only the post-failure debug output was wrong.

Impact

Affects all F/D/Q/Zfh tests that:

1. Set a non-default rounding mode (frm != 0) via fsrm or per-instruction rm field, and
2. Hit an fflags mismatch during the test run

Tests with default rounding (frm = 0) were silently fine since fcsr == fflags in that case, which is why this went unnoticed.

Test Plan

• Run an fflags-checking test with frm set to RTZ and verify bad value now shows only the 5-bit fflags field
• Confirm none() / pass cases are unaffected
• CI green on rv32/rv64 across F, D, Q configurations