Mono: Min/MinNumber lowering does not preserve the sign of zero

[tannergooding]

Description

Mono (observed on the LLVM AOT configuration) does not preserve the sign of zero when lowering Min / MinNumber for floating-point types. Per the BCL contract, double.Min(+0.0, -0.0) (and the float/MinNumber variants) must return -0.0, treating -0.0 as less than +0.0. Mono instead returns +0.0.

Reproduction

using System;
using System.Runtime.CompilerServices;

[MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.AggressiveOptimization)]
static double MinNegZeroConst(double value) => double.Min(value, -0.0);

// Expected: -9223372036854775808 (bits of -0.0)
// Mono LLVM AOT actual: 0 (bits of +0.0)
Console.WriteLine(BitConverter.DoubleToInt64Bits(MinNegZeroConst(+0.0)));

The same divergence affects float.Min, double.MinNumber, and float.MinNumber.

Analysis

This surfaced in the CI for #130832: the regression test Runtime_130831 (added to validate a CoreCLR JIT constant-folding fix) fails on the AllSubsets_Mono_LLVMAot_RuntimeTests leg with:

Expected: -9223372036854775808
Actual:   0

The test has been marked [SkipOnMono] referencing this issue so it continues to validate the CoreCLR fix while the Mono divergence is tracked here.

Configuration

• Mono, LLVM AOT (AllSubsets_Mono_LLVMAot_RuntimeTests), linux-x64 Release.

Note

This issue was authored with the assistance of GitHub Copilot.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @vitek-karas
See info in area-owners.md if you want to be subscribed.

[vitek-karas]

This reproes on .NET 10 as well. Since it's a long standing issue I would vote for closing it. @steveisok what do you think?

[steveisok]

Fine by me

[tannergooding]

@vitek-karas, just noting this is a correctness and IEEE 754 compliance bug. I'm fine with not fixing it, but did want to call that out.

[vitek-karas]

@tannergooding I do understand... and I don't have a problem if we get a PR to accept it...

[tannergooding]

@vitek-karas, I have such a PR here: #131172