-
Notifications
You must be signed in to change notification settings - Fork 2.7k
JIT: Fix bug in finally cloning caused by unsound callfinally reordering #18348
Conversation
We need to make sure that if we reorder a callfinally during finally cloning that the callfinally is actually the one being targeted by the last block in the try range. Closes #18332. Linked issue has some more detailed notes.
@BruceForstall PTAL Don't expect any FX diffs from this. Will verify. |
Well, there are FX diffs.... possibly requires exceptions to see the impact of this bug, so maybe not caught in any testing.
Am also trying out PMI based diffs on this across all tests, but amhitting some issues with (I think) marker file collision. So need to tweak that some... |
Here's an all-up PMI diff for this change using the still somewhat-in-flight PMI diffs I've been working on over in jitutils. Not surprisingly the new test case shows up.
|
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.
LGTM
OSX failure is some kind of infrastructure/networking hiccup. Will retry @dotnet-bot retest OSX10.12 x64 Checked Innerloop Build and Test |
@RussKeldorph this is a candidate for 2.1 servicing. |
…ing (dotnet#18348) We need to make sure that if we reorder a callfinally during finally cloning that the callfinally is actually the one being targeted by the last block in the try range. Closes #18332. Linked issue has some more detailed notes.
Port of #18348 to release/2.1 We need to make sure that if we reorder a callfinally during finally cloning that the callfinally is actually the one being targeted by the last block in the try range. Closes #18332. Linked issue has some more detailed notes.
…ing (dotnet/coreclr#18348) We need to make sure that if we reorder a callfinally during finally cloning that the callfinally is actually the one being targeted by the last block in the try range. Closes dotnet/coreclr#18332. Linked issue has some more detailed notes. Commit migrated from dotnet/coreclr@311322b
We need to make sure that if we reorder a callfinally during finally cloning
that the callfinally is actually the one being targeted by the last block in
the try range.
Closes #18332. Linked issue has some more detailed notes.