.NET Core 3.1 compiles integral conversions to doubles differently than real literals. This is not true for .NET Framework.

[zacknewman]

Description

• Implicit (and explicit) casts from integrals to doubles don't undergo the same process as real literals during compilation.
• Example:

using System;
namespace App
{
    internal static class Program
    {
        internal static void Main()
        {
            /// Displays 'True'.
           Console.WriteLine(10648738977740919977d != 10648738977740919977);
        }
    }
}

• C# 6.0 draft specification states “the value of a real literal of type float or double is determined by using the IEEE ‘round to nearest’ mode” under Lexical structure -> Grammars -> Lexical grammar -> Lexical analysis -> Tokens -> Literals -> Real literals. IEEE 754 explicitly allows for extended precision format, so the compiler can compile both the real literal and the implicit cast using (or not) any extended precision capabilities that may exist on the CPU during compilation and still be compliant with the specification.

Configuration

• Compiled with Microsoft Visual C# Compiler version 3.7.0-6.20459 for .NET Core 3.1.
• Windows 10 Pro 18363.1139.
• x64-based CPU with an 80-bit FPU (which has a 64-bit significand).
• .NET Framework compiles both the implicit cast and real literal the same (both not using the extended precision format available on my CPU).

Other information

• As mentioned by Eric Lippert, “... C# allows a higher precision type to be used for all floating-point operations”; however I was under the impression this is only true at runtime.

[YairHalberstadt]

It seems this is actually a difference between x64 and x86, even on .Net Framework. The compiler converts this comparison straight to a constant, but the constant is false for x86, and true for x64.

@tannergooding any ideas here?

[zacknewman]

Ah, I apologize. I carelessly assumed it was a .NET Core vs. .NET Framework issue. I didn't bother trying x86.

[YairHalberstadt]

No problem - playing around with sharplab is a great way to see what's going on here.

[zacknewman]

Can one compile under "x64" mode on an x86 CPU (only the 32-bit version)? If so, what happens? I don't own any devices that have an x86 CPU, and sharplab doesn't have an option for "x64 on x86 CPU". Even better, what happens when one compiles under "x64" mode on a CPU that doesn't have extended precision format capabilities?

[tannergooding]

CC. @jaredpar this is a determinism bug and looks to be caused by Roslyn depending on the runtime for the ulong -> double conversion. x64 vs x86 doesn't matter.

The root cause is a runtime bug in the conversion. I'll be opening a separate issue here shortly.

[zacknewman]

@tannergooding, do you want to post that as its own comment so that I can mark it as an answer?

[tannergooding]

This is a determinism bug and looks to be caused by Roslyn depending on the runtime for the ulong -> double conversion. x64 vs x86 doesn't matter.

The root cause is a runtime bug in the conversion code: dotnet/runtime#43895

Roslyn could implement its own conversion algorithm for correctness such as by using the Berkeley SoftFloat 3 implementation which is known to be good/correct: https://github.com/ucb-bar/berkeley-softfloat-3/blob/master/source/ui64_to_f64.c

[tannergooding]

That is to say, both the runtime and the compiler need to take similar fixes.

The runtime needs it to ensure correctness on future releases and the compiler needs it to ensure correctness regardless of the underlying runtime since only one of the runtimes it runs on will get fixed.

[zacknewman]

But isn’t the x87 FPU stack which only has 80-bits of precision non-compliant with IEEE 754 and (per the proof) will not always perform binary64 arithmetic correctly since 64 ≠ 80 and 80 < 64n for natural numbers n > 1?

[tannergooding]

The x87 FPU stack isn't really used by anything other than the 32-bit legacy JIT on full framework. .NET Core (and RyuJIT in general) uses SSE/SSE2 and only has to use the x87 FPU stack for where it required by the calling convention on 32-bit machines (namely for returning floating-point values). This has been the case for both 32-bit and 64-bit since .NET Core 2.1 and for 64-bit for quite a while prior to that even extending back to full framework.

Also, while the underlying registers are indeed 80-bits, the x87 FPU stack supports explicitly setting the rounding mode to 32-bits, 64-bits, or 80-bits. When using the x87 FPU stack, .NET has traditionally set this rounding mode to 64-bits which (as per the paper I linked above) avoids the double rounding issues for most code. You are then only left with potential differences if you are doing 32-bit float operations and not explicitly rounding down to 32-bits after each operation or in cases where the underlying algorithm is wrong/buggy.

[zacknewman]

Ah! As is often the case with natural language, it took some time and extended dialogue for the interpretations of both parties to converge to the same thing; although I am sure mine is still “off” since I am a bit out of my element here.

[tannergooding]

Happy to answer any further questions you might have. Communicating everything correctly can be difficult 😄