JIT: Fix double handling of call operands when importing intrinsic by jakobbotsch · Pull Request #96557 · dotnet/runtime

jakobbotsch · 2024-01-05T15:20:51Z

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix#96461

Some intrinsics can be a noop when they are imported. For example, `Unsafe.BitCast<T, T>(X)` just returns its operand when importing. If that operand is a call then we will run the tail logic of call importation for that call node twice, since that logic tries to filter out intrinsic importation with an `IsCall()` check. Switch the check to be based on `!bIntrinsicImported` instead. Fixdotnet#96461

ghost · 2024-01-05T15:21:03Z

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

Issue Details

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix #96461

Author:	jakobbotsch
Assignees:	-
Labels:	`area-CodeGen-coreclr`
Milestone:	-

jakobbotsch · 2024-01-05T18:01:45Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs

tannergooding · 2024-01-05T18:16:15Z

-
- if (call->IsCall())
+ // Sometimes "call" is not a GT_CALL (if we imported an intrinsic that didn't turn into a call)
+ if (!bIntrinsicImported)


Is this something that needs backported?
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.

Seems likely this double-processing ended up with the same result, so didn't actually cause a bug.

I don't think it needs to be backported, I think it's very hard for the code that runs twice here to cause problems in release builds. Also we need a customer report for backporting.
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
Presumably people do not write code that involves noop intrinsics like op_UnaryPlus very often, and even more rarely that also satisfies the other conditions to hit the bug.
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.
Let me address that as part of a future PR to rerunning CI.

jakobbotsch · 2024-01-05T15:20:51Z

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix#96461

Some intrinsics can be a noop when they are imported. For example, `Unsafe.BitCast<T, T>(X)` just returns its operand when importing. If that operand is a call then we will run the tail logic of call importation for that call node twice, since that logic tries to filter out intrinsic importation with an `IsCall()` check. Switch the check to be based on `!bIntrinsicImported` instead. Fixdotnet#96461

ghost · 2024-01-05T15:21:03Z

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

Issue Details

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix #96461

Author:	jakobbotsch
Assignees:	-
Labels:	`area-CodeGen-coreclr`
Milestone:	-

jakobbotsch · 2024-01-05T18:01:45Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs

tannergooding · 2024-01-05T18:16:15Z

-
- if (call->IsCall())
+ // Sometimes "call" is not a GT_CALL (if we imported an intrinsic that didn't turn into a call)
+ if (!bIntrinsicImported)


Is this something that needs backported?
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.

Seems likely this double-processing ended up with the same result, so didn't actually cause a bug.

I don't think it needs to be backported, I think it's very hard for the code that runs twice here to cause problems in release builds. Also we need a customer report for backporting.
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
Presumably people do not write code that involves noop intrinsics like op_UnaryPlus very often, and even more rarely that also satisfies the other conditions to hit the bug.
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.
Let me address that as part of a future PR to rerunning CI.

jakobbotsch · 2024-01-05T15:20:51Z

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix#96461

Some intrinsics can be a noop when they are imported. For example, `Unsafe.BitCast<T, T>(X)` just returns its operand when importing. If that operand is a call then we will run the tail logic of call importation for that call node twice, since that logic tries to filter out intrinsic importation with an `IsCall()` check. Switch the check to be based on `!bIntrinsicImported` instead. Fixdotnet#96461

ghost · 2024-01-05T15:21:03Z

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

Issue Details

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix #96461

Author:	jakobbotsch
Assignees:	-
Labels:	`area-CodeGen-coreclr`
Milestone:	-

jakobbotsch · 2024-01-05T18:01:45Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs

tannergooding · 2024-01-05T18:16:15Z

-
- if (call->IsCall())
+ // Sometimes "call" is not a GT_CALL (if we imported an intrinsic that didn't turn into a call)
+ if (!bIntrinsicImported)


Is this something that needs backported?
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.

Seems likely this double-processing ended up with the same result, so didn't actually cause a bug.

I don't think it needs to be backported, I think it's very hard for the code that runs twice here to cause problems in release builds. Also we need a customer report for backporting.
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
Presumably people do not write code that involves noop intrinsics like op_UnaryPlus very often, and even more rarely that also satisfies the other conditions to hit the bug.
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.
Let me address that as part of a future PR to rerunning CI.

jakobbotsch · 2024-01-05T15:20:51Z

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix#96461

Some intrinsics can be a noop when they are imported. For example, `Unsafe.BitCast<T, T>(X)` just returns its operand when importing. If that operand is a call then we will run the tail logic of call importation for that call node twice, since that logic tries to filter out intrinsic importation with an `IsCall()` check. Switch the check to be based on `!bIntrinsicImported` instead. Fixdotnet#96461

ghost · 2024-01-05T15:21:03Z

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

Issue Details

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix #96461

Author:	jakobbotsch
Assignees:	-
Labels:	`area-CodeGen-coreclr`
Milestone:	-

jakobbotsch · 2024-01-05T18:01:45Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs

tannergooding · 2024-01-05T18:16:15Z

-
- if (call->IsCall())
+ // Sometimes "call" is not a GT_CALL (if we imported an intrinsic that didn't turn into a call)
+ if (!bIntrinsicImported)


Is this something that needs backported?
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.

Seems likely this double-processing ended up with the same result, so didn't actually cause a bug.

I don't think it needs to be backported, I think it's very hard for the code that runs twice here to cause problems in release builds. Also we need a customer report for backporting.
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
Presumably people do not write code that involves noop intrinsics like op_UnaryPlus very often, and even more rarely that also satisfies the other conditions to hit the bug.
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.
Let me address that as part of a future PR to rerunning CI.

jakobbotsch · 2024-01-05T15:20:51Z

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix#96461

Some intrinsics can be a noop when they are imported. For example, `Unsafe.BitCast<T, T>(X)` just returns its operand when importing. If that operand is a call then we will run the tail logic of call importation for that call node twice, since that logic tries to filter out intrinsic importation with an `IsCall()` check. Switch the check to be based on `!bIntrinsicImported` instead. Fixdotnet#96461

ghost · 2024-01-05T15:21:03Z

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

Issue Details

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix #96461

Author:	jakobbotsch
Assignees:	-
Labels:	`area-CodeGen-coreclr`
Milestone:	-

jakobbotsch · 2024-01-05T18:01:45Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs

tannergooding · 2024-01-05T18:16:15Z

-
- if (call->IsCall())
+ // Sometimes "call" is not a GT_CALL (if we imported an intrinsic that didn't turn into a call)
+ if (!bIntrinsicImported)


Is this something that needs backported?
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.

Seems likely this double-processing ended up with the same result, so didn't actually cause a bug.

I don't think it needs to be backported, I think it's very hard for the code that runs twice here to cause problems in release builds. Also we need a customer report for backporting.
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
Presumably people do not write code that involves noop intrinsics like op_UnaryPlus very often, and even more rarely that also satisfies the other conditions to hit the bug.
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.
Let me address that as part of a future PR to rerunning CI.

jakobbotsch · 2024-01-05T15:20:51Z

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix#96461

Some intrinsics can be a noop when they are imported. For example, `Unsafe.BitCast<T, T>(X)` just returns its operand when importing. If that operand is a call then we will run the tail logic of call importation for that call node twice, since that logic tries to filter out intrinsic importation with an `IsCall()` check. Switch the check to be based on `!bIntrinsicImported` instead. Fixdotnet#96461

ghost · 2024-01-05T15:21:03Z

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

Issue Details

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix #96461

Author:	jakobbotsch
Assignees:	-
Labels:	`area-CodeGen-coreclr`
Milestone:	-

jakobbotsch · 2024-01-05T18:01:45Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs

tannergooding · 2024-01-05T18:16:15Z

-
- if (call->IsCall())
+ // Sometimes "call" is not a GT_CALL (if we imported an intrinsic that didn't turn into a call)
+ if (!bIntrinsicImported)


Is this something that needs backported?
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.

Seems likely this double-processing ended up with the same result, so didn't actually cause a bug.

I don't think it needs to be backported, I think it's very hard for the code that runs twice here to cause problems in release builds. Also we need a customer report for backporting.
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
Presumably people do not write code that involves noop intrinsics like op_UnaryPlus very often, and even more rarely that also satisfies the other conditions to hit the bug.
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.
Let me address that as part of a future PR to rerunning CI.

jakobbotsch · 2024-01-05T15:20:51Z

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix#96461

Some intrinsics can be a noop when they are imported. For example, `Unsafe.BitCast<T, T>(X)` just returns its operand when importing. If that operand is a call then we will run the tail logic of call importation for that call node twice, since that logic tries to filter out intrinsic importation with an `IsCall()` check. Switch the check to be based on `!bIntrinsicImported` instead. Fixdotnet#96461

ghost · 2024-01-05T15:21:03Z

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

Issue Details

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix #96461

Author:	jakobbotsch
Assignees:	-
Labels:	`area-CodeGen-coreclr`
Milestone:	-

jakobbotsch · 2024-01-05T18:01:45Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs

tannergooding · 2024-01-05T18:16:15Z

-
- if (call->IsCall())
+ // Sometimes "call" is not a GT_CALL (if we imported an intrinsic that didn't turn into a call)
+ if (!bIntrinsicImported)


Is this something that needs backported?
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.

Seems likely this double-processing ended up with the same result, so didn't actually cause a bug.

I don't think it needs to be backported, I think it's very hard for the code that runs twice here to cause problems in release builds. Also we need a customer report for backporting.
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
Presumably people do not write code that involves noop intrinsics like op_UnaryPlus very often, and even more rarely that also satisfies the other conditions to hit the bug.
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.
Let me address that as part of a future PR to rerunning CI.

jakobbotsch · 2024-01-05T15:20:51Z

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix#96461

Some intrinsics can be a noop when they are imported. For example, `Unsafe.BitCast<T, T>(X)` just returns its operand when importing. If that operand is a call then we will run the tail logic of call importation for that call node twice, since that logic tries to filter out intrinsic importation with an `IsCall()` check. Switch the check to be based on `!bIntrinsicImported` instead. Fixdotnet#96461

ghost · 2024-01-05T15:21:03Z

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

Issue Details

Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X) just returns its operand when importing. If
that operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an IsCall() check. Switch the check to
be based on !bIntrinsicImported instead.

Fix #96461

Author:	jakobbotsch
Assignees:	-
Labels:	`area-CodeGen-coreclr`
Milestone:	-

jakobbotsch · 2024-01-05T18:01:45Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs

tannergooding · 2024-01-05T18:16:15Z

-
- if (call->IsCall())
+ // Sometimes "call" is not a GT_CALL (if we imported an intrinsic that didn't turn into a call)
+ if (!bIntrinsicImported)


Is this something that needs backported?
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.

Seems likely this double-processing ended up with the same result, so didn't actually cause a bug.

I don't think it needs to be backported, I think it's very hard for the code that runs twice here to cause problems in release builds. Also we need a customer report for backporting.
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
Presumably people do not write code that involves noop intrinsics like op_UnaryPlus very often, and even more rarely that also satisfies the other conditions to hit the bug.
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.
Let me address that as part of a future PR to rerunning CI.

jakobbotsch added 2 commits January 5, 2024 16:12

Add test
8e0dc28

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jan 5, 2024

ghost assigned jakobbotsch Jan 5, 2024

jakobbotsch marked this pull request as ready for review January 5, 2024 18:00

jakobbotsch requested a review from AndyAyersMS January 5, 2024 18:02

tannergooding reviewed Jan 5, 2024
View reviewed changes

AndyAyersMS approved these changes Jan 5, 2024
View reviewed changes

jakobbotsch merged commit 4ce2ee9 into dotnet:mainJan 5, 2024

jakobbotsch deleted the fix-96461 branch January 5, 2024 18:36

github-actionsBot locked and limited conversation to collaborators Feb 5, 2024

jakobbotsch added 2 commits January 5, 2024 16:12

Add test
8e0dc28

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jan 5, 2024

ghost assigned jakobbotsch Jan 5, 2024

jakobbotsch marked this pull request as ready for review January 5, 2024 18:00

jakobbotsch requested a review from AndyAyersMS January 5, 2024 18:02

tannergooding reviewed Jan 5, 2024
View reviewed changes

AndyAyersMS approved these changes Jan 5, 2024
View reviewed changes

jakobbotsch merged commit 4ce2ee9 into dotnet:mainJan 5, 2024

jakobbotsch deleted the fix-96461 branch January 5, 2024 18:36

github-actionsBot locked and limited conversation to collaborators Feb 5, 2024

jakobbotsch added 2 commits January 5, 2024 16:12

Add test
8e0dc28

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jan 5, 2024

ghost assigned jakobbotsch Jan 5, 2024

jakobbotsch marked this pull request as ready for review January 5, 2024 18:00

jakobbotsch requested a review from AndyAyersMS January 5, 2024 18:02

tannergooding reviewed Jan 5, 2024
View reviewed changes

AndyAyersMS approved these changes Jan 5, 2024
View reviewed changes

jakobbotsch merged commit 4ce2ee9 into dotnet:mainJan 5, 2024

jakobbotsch deleted the fix-96461 branch January 5, 2024 18:36

github-actionsBot locked and limited conversation to collaborators Feb 5, 2024

jakobbotsch added 2 commits January 5, 2024 16:12

Add test
8e0dc28

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jan 5, 2024

ghost assigned jakobbotsch Jan 5, 2024

jakobbotsch marked this pull request as ready for review January 5, 2024 18:00

jakobbotsch requested a review from AndyAyersMS January 5, 2024 18:02

tannergooding reviewed Jan 5, 2024
View reviewed changes

AndyAyersMS approved these changes Jan 5, 2024
View reviewed changes

jakobbotsch merged commit 4ce2ee9 into dotnet:mainJan 5, 2024

jakobbotsch deleted the fix-96461 branch January 5, 2024 18:36

github-actionsBot locked and limited conversation to collaborators Feb 5, 2024

jakobbotsch added 2 commits January 5, 2024 16:12

Add test
8e0dc28

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jan 5, 2024

ghost assigned jakobbotsch Jan 5, 2024

jakobbotsch marked this pull request as ready for review January 5, 2024 18:00

jakobbotsch requested a review from AndyAyersMS January 5, 2024 18:02

tannergooding reviewed Jan 5, 2024
View reviewed changes

AndyAyersMS approved these changes Jan 5, 2024
View reviewed changes

jakobbotsch merged commit 4ce2ee9 into dotnet:mainJan 5, 2024

jakobbotsch deleted the fix-96461 branch January 5, 2024 18:36

github-actionsBot locked and limited conversation to collaborators Feb 5, 2024

jakobbotsch added 2 commits January 5, 2024 16:12

Add test
8e0dc28

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jan 5, 2024

ghost assigned jakobbotsch Jan 5, 2024

jakobbotsch marked this pull request as ready for review January 5, 2024 18:00

jakobbotsch requested a review from AndyAyersMS January 5, 2024 18:02

tannergooding reviewed Jan 5, 2024
View reviewed changes

AndyAyersMS approved these changes Jan 5, 2024
View reviewed changes

jakobbotsch merged commit 4ce2ee9 into dotnet:mainJan 5, 2024

jakobbotsch deleted the fix-96461 branch January 5, 2024 18:36

github-actionsBot locked and limited conversation to collaborators Feb 5, 2024

jakobbotsch added 2 commits January 5, 2024 16:12

Add test
8e0dc28

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jan 5, 2024

ghost assigned jakobbotsch Jan 5, 2024

jakobbotsch marked this pull request as ready for review January 5, 2024 18:00

jakobbotsch requested a review from AndyAyersMS January 5, 2024 18:02

tannergooding reviewed Jan 5, 2024
View reviewed changes

AndyAyersMS approved these changes Jan 5, 2024
View reviewed changes

jakobbotsch merged commit 4ce2ee9 into dotnet:mainJan 5, 2024

jakobbotsch deleted the fix-96461 branch January 5, 2024 18:36

github-actionsBot locked and limited conversation to collaborators Feb 5, 2024

jakobbotsch added 2 commits January 5, 2024 16:12

Add test
8e0dc28

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jan 5, 2024

ghost assigned jakobbotsch Jan 5, 2024

jakobbotsch marked this pull request as ready for review January 5, 2024 18:00

jakobbotsch requested a review from AndyAyersMS January 5, 2024 18:02

tannergooding reviewed Jan 5, 2024
View reviewed changes

AndyAyersMS approved these changes Jan 5, 2024
View reviewed changes

jakobbotsch merged commit 4ce2ee9 into dotnet:mainJan 5, 2024

jakobbotsch deleted the fix-96461 branch January 5, 2024 18:36

github-actionsBot locked and limited conversation to collaborators Feb 5, 2024

Uh oh!

Conversation

jakobbotsch commented Jan 5, 2024

Uh oh!

ghost commented Jan 5, 2024

Uh oh!

jakobbotsch commented Jan 5, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

jakobbotsch commented Jan 5, 2024

Uh oh!

ghost commented Jan 5, 2024

Uh oh!

jakobbotsch commented Jan 5, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

jakobbotsch commented Jan 5, 2024

Uh oh!

ghost commented Jan 5, 2024

Uh oh!

jakobbotsch commented Jan 5, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

jakobbotsch commented Jan 5, 2024

Uh oh!

ghost commented Jan 5, 2024

Uh oh!

jakobbotsch commented Jan 5, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!