Inconsistent Double to UInt64 conversion on ARM vs x64 Architectures

[OceanOak]

Description

When converting the double value 1.8446744073709552E+19 to a uint64, the result of the conversion changes based on the architecture

Reproduction Steps

In dotnet fsi run
uint64(1.8446744073709552E+19);;

Expected behavior

The conversion of 1.8446744073709552E+19 to uint64 should be consistent across different architectures

Actual behavior

• On ARM architecture: uint64(1.8446744073709552E+19) = 18446744073709551615.
• On x64 architecture: uint64(1.8446744073709552E+19) = 0

[ghost]

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

Issue Details

---

Description

When converting the double value 1.8446744073709552E+19 to a uint64, the result of the conversion changes based on the architecture

Reproduction Steps

In dotnet fsi run
uint64(1.8446744073709552E+19);;

Expected behavior

The conversion of 1.8446744073709552E+19 to uint64 should be consistent across different architectures

Actual behavior

• On ARM architecture: uint64(1.8446744073709552E+19) = 18446744073709551615.
• On x64 architecture: uint64(1.8446744073709552E+19) = 0

Author:	OceanOak
Assignees:	-
Labels:	area-System.Numerics, untriaged
Milestone:	-

[tannergooding]

This is a known difference as the exact semantics for floating-point values which cannot be represented in the destination format is considered undefined behavior (by IEEE 754, by the runtime, and by most languages).

Many platforms have standardized on saturation as the "correct" behavior as it best matches the IEEE 754 semantics required for other operations, which is to say results are computed as if to infinite precision and unbounded range; then rounded (using the current/targeted rounding mode) to the nearest representable result. -- The behavior of NaN handling is often still left undefined, but many platforms have defaulted to converting it to integer 0.

Adjusting .NET to have deterministic behavior here is tracked by #61885 and is being actively worked on. We plan on matching the saturating behavior that many platforms expect and converting NaN to integer 0. -- AVX10 (for x86/x64) will be adding new instructions that support this semantic behavior directly which can help mitigate the long term performance impact. AVX512 can use vfixupimmps to help handle some cases and there will be a slightly more complex required for downlevel hardware.