JIT: make sure to set compLongUsed during struct promotion #32702
Conversation
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
If we're promoting a long field, make sure `compLongUsed` gets set. Otherwise we may fail to properly decompose a long later on. Fixes dotnet#32059.
AndyAyersMS
added
the
area-CodeGen-coreclr
Member
Author
|
cc @dotnet/jit-contrib Not sure this is reachable in C#. I may need to create an IL test case. |
BruceForstall
approved these changes
Feb 24, 2020
Contributor
|
@AndyAyersMS Looks like this should get fixed in 3.1? |
Member
Author
|
Yes, we should make a case for fixing this in 3.1. I think it can be the exact same fix, but haven't looked yet. |
Member
Author
|
live build failure is unrelated; will ignore. |
AndyAyersMS
added a commit
to AndyAyersMS/coreclr
that referenced
this pull request
Feb 24, 2020
If we're promoting a long field, make sure `compLongUsed` gets set. Otherwise we may fail to properly decompose a long later on, leading to access violations in the jit. See dotnet/runtime#32059 for the original bug report, and dotnet/runtime#32702 for the fix in 5.0. ## Customer Impact Unexpected and hard to diagnose crash in the jit. No easy workaround. ## Regression? Yes, introduced during the development 3.0 cycle. 2.x behaves correctly. ## Testing Verified the user's test case now passes; no diffs seen in any existing framework or test code. ## Risk **Low**: fix is surgical and enables existing long operand handling in the jit in one case that can be overlooked. Only impacts x86 and arm codegen. Problematic IL patterns may not be reachable from C#.
Anipik
pushed a commit
to dotnet/coreclr
that referenced
this pull request
Mar 25, 2020
If we're promoting a long field, make sure `compLongUsed` gets set. Otherwise we may fail to properly decompose a long later on, leading to access violations in the jit. See dotnet/runtime#32059 for the original bug report, and dotnet/runtime#32702 for the fix in 5.0. ## Customer Impact Unexpected and hard to diagnose crash in the jit. No easy workaround. ## Regression? Yes, introduced during the development 3.0 cycle. 2.x behaves correctly. ## Testing Verified the user's test case now passes; no diffs seen in any existing framework or test code. ## Risk **Low**: fix is surgical and enables existing long operand handling in the jit in one case that can be overlooked. Only impacts x86 and arm codegen. Problematic IL patterns may not be reachable from C#.
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
If we're promoting a long field, make sure
compLongUsedgets set.Otherwise we may fail to properly decompose a long later on.
Fixes #32059.