[RISC-V] Floating NaN overflow test fix

[denis-paranichev]

There are differences between results of floating NaN conversions overflow on X64 or ARM64 and RISC-V. As I suppose it is caused by runtime using some sort of flush-to-zero option for X64 and ARM64 which replace such overflowing values with zero.
But RISC-V specification does not provide such option.
Thus I suggest to change expected result of NaN overflow tests on RISC-V.

Part of #84834
cc @gbalykov @t-mustafin @clamp03 @tomeksowi

[ghost]

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.

Issue Details

---

There are differences between results of floating NaN conversions overflow on X64 or ARM64 and RISC-V. As I suppose it is caused by runtime using some sort of flush-to-zero option for X64 and ARM64 which replace such overflowing values with zero.
But RISC-V specification does not provide such option.
Thus I suggest to change expected result of NaN overflow tests on RISC-V.

Part of #84834
cc @gbalykov @t-mustafin @clamp03 @tomeksowi

Author:	DenisParal
Assignees:	-
Labels:	area-System.Numerics
Milestone:	-

[denis-paranichev]

@dotnet-policy-service agree company="Samsung"

[MichalPetryka]

As I suppose it is caused by runtime using some sort of flush-to-zero option for X64 and ARM64

The runtime does not use the FTZ flags cc @tannergooding

[tannergooding]

We're working on moving towards deterministic behavior across platforms: #61885

This is going to necessitate, longer term, that saturation occurs as it is what most newer platforms do and what many specs (like WASM) require. This is also going to necessitate standardizing the behavior for NaN.

For x64, it currently returns a sentinel value 0x8000_0000 (int) or 0x8000_0000_0000_0000 (long) when the output type would overflow or when NaN is given. byte and short therefore currently expect 0 because its truncating the 32 or 64-bit result to 8 or 16-bits.

For Arm64, it saturates and converts NaN to zero. For WASM, it requires saturation and leaves NaN conversion undefined.

We plan on matching Arm64 for the cross platform deterministic behavior here as it is simple and straightforward. It matches the general IEEE 754 guidance that you compute the result as if to infinite precision and unbounded range, and then round to the nearest representable. NaN then logically has no equivalent, so it becoming zero "makes sense" and avoids confusion in other regards.

[tannergooding]

As such, it would be better if we could ensure the RISC-V implementation adjusts and matches this behavior. The underlying platform specific behavior would then be available in the future for the APIs proposed in the linked issue.

[denis-paranichev]

Thank you for your comment, I will try to find the proper solution.

[denis-paranichev]

#94762 fixes this problem, thus this PR can be closed.