SPMI diff failure for SqlSingleTest

[tannergooding]

Error Blob

{
  "ErrorMessage": "Assertion failed 'type != TYP_VOID' in 'System.Data.Tests.SqlTypes.SqlSingleTest:Lessers():this' during 'Expand static init'",
  "BuildRetry": false,
  "ErrorPattern": "",
  "ExcludeConsoleLog": false
}

Reproduction Steps

No response

Report

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	0	0

[ghost]

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

Issue Details

---

Error Blob

{
  "ErrorMessage": "Assertion failed 'type != TYP_VOID' in 'System.Data.Tests.SqlTypes.SqlSingleTest:Lessers():this' during 'Expand static init'",
  "BuildRetry": false,
  "ErrorPattern": "",
  "ExcludeConsoleLog": false
}

Reproduction Steps

No response

Author:	tannergooding
Assignees:	-
Labels:	area-CodeGen-coreclr, blocking-clean-ci, Known Build Error
Milestone:	-

[EgorBo]

the assert is fired in gtSplitTree

[EgorBo]

@jakobbotsch does it ring a bell to you why gtSplitTree fail here on void COMMA while splitting this tree on the helper call point?

[jakobbotsch]

@EgorBo The IR looks invalid, the type of a COMMA should always be the same as its op2. Where do we create that comma?

[EgorBo]

Where do we create that comma?

@SingleAccretion said it's dead store removal?

[BruceForstall]

How did this regress, given that JIT PRs run replay/asmdiffs pipelines before checkin?

[jakobbotsch]

@BruceForstall The PR that introduced the "Expand static init" phase (#83911) also changed JIT-EE GUID. The failure is in libraries tests so maybe the PR runs of libraries tests did not manage to expose it (another reason why it's good to trigger libraries-jitstress on large changes).

[BruceForstall]

But spmi collection process would filter out any failures, so if #83911 introduced the failure but also changed the GUID, I would expect the new collection to hit the assertion during collection, but the collection "clean" process to remove the failing MCs from the resultant MCH.

[jakobbotsch]

Good point. On a closer look the issue actually was introduced with my change in the splitter in #83388 (itself a fix for a different issue I hit as part of that PR)... The last test runs in that PR were from Friday, so before the new phase.

[tannergooding]

So this was the result of a couple different passing PRs conflicting post merge?

[jakobbotsch]

Yes, essentially. Well, the bug was in my PR, but apparently stress did not manage to expose it until the extra cases seen with #83911.