-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[release/8.0-staging] JIT: Fixed incorrect reversed condition for GT #100372
[release/8.0-staging] JIT: Fixed incorrect reversed condition for GT #100372
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
@dotnet/jit-contrib |
@kunalspathak I would have classified this as low risk, we have had the fix in 9.0 for a while and it has not led to further issues. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
approved. we will take for consideration in 8.0.x
@jeffschwMSFT @AndyAyersMS @TIHan - please assess failures and merge today. |
Build/test logs are gone, so will need to rerun. |
going to bounce this as all the assets are gone too. |
Looking good, @AndyAyersMS |
Yep. |
Backport of #92316 to release/8.0-staging
/cc @kunalspathak @TIHan
Customer Impact
This was reported by a customer in #99954, where they were having a wrong functional behavior from a simple condition evaluation
a <= b
should have been evaluated totrue
but was evaluating tofalse
, leading to having their code take different code path. In the example that customer provided, they were seeing an exception was thrown because of the issue and the correct behavior was that no exception should have been thrown. The circumstances for it to occur is rare though and would trigger under very specific conditions. Thefalse
block (the code follows theelse
should have been optimized in prior phases and should be empty when we were trying to optimize the code in question) and there are some other requirements like what type of blocks they jump to in order the problematic code path to get triggered.Regression
The code has been there since
dotnet/coreclr
days and was introduced back in dotnet/coreclr#17733, but we recently saw it getting exposed.Testing
The fix was verified on the customer provided example in #99954. The code has been there for a while and was not discovered until September 2023 when we found out and fixed it in .NET 9. However, we didn't back-ported to .NET 8 back then. The backport also adds a test case for this scenario.
Risk
Low: This is a rare scenario and we had it .NET 9 for a while without causing any problem.