Repository navigation
[release/11.0] Correct decimal conversions to Half and BFloat16 - #135730
Merged
tannergooding merged 1 commit intoOct 15, 2026
Merged
tannergooding merged 1 commit into
tannergooding merged 1 commit into
Conversation
Use target-format fast paths and exact fallback rounding to avoid double-rounding. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> (cherry picked from commit 8e8152d)
|
Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
|
Tagging subscribers to this area: @dotnet/area-system-numerics |
This was referenced Oct 14, 2026
jeffhandley
approved these changes
Oct 14, 2026
jeffhandley
left a comment
jeffhandley
left a comment
Member
There was a problem hiding this comment.
I support backporting this for .NET 11 GA for sake of correctness involving APIs that are new in .NET 11.
Member
|
Hi, the code complete date for GA is Monday 19th October. Make sure to merge this PR on that date at the latest, or it won't make it into that release. As a reminder, if this is a product change, you also need Tactics approval before merging this PR (test-only or infra-only changes don't require Tactics approval). Happy to help with the merge if needed! |
tannergooding
added
the
Servicing-consider
rbhanda
added
Servicing-approved
Member
Author
|
/ba-g unrelated known test failures |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes Issue #135659
main PR #135668
Description
This backports the fix for double-rounding in decimal-to-Half and decimal-to-BFloat16 conversions. The exact fallback now rounds directly to the destination format, and Half parsing uses the corrected tie-to-even exponent boundary.
Customer Impact
Applications converting decimal values close to Half or BFloat16 midpoints can receive the adjacent representable value on the wrong side of the midpoint. The error also affects some Half subnormal values.
Regression
No. The issue reproduces in .NET 11 RC builds; Half had the same double-rounding issue in .NET 10, and BFloat16 is new in .NET 11.
Testing
.\build.cmd clr+libs -rc checked— passed (checked baseline)..\build.cmd clr.corelib+clr.nativecorelib+libs.pretest -rc checked— passed, 0 warnings and 0 errors.dotnet build /t:test src\libraries\System.Runtime\tests\System.Runtime.Tests\System.Runtime.Tests.csproj— passed: 77,859 total, 0 failed, 87 skipped.Risk
Low. The change is limited to decimal floating-point rounding and Half's parser tie boundary, with regression cases for midpoint-adjacent values, ties, and subnormals. The mainline PR's focused comparison reported 6.368 ns for a BFloat16 decimal cast versus 4.096 ns for casting through double; the run had notable variance and was not a separate baseline-runtime build, so this is an observed cost rather than conclusive regression evidence. No separate release-branch benchmark was run.
Package authoring no longer needed in .NET 9
IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.
Resolves #135659
Note
This PR description was prepared with GitHub Copilot.