[ci-scan] Test failure: Avx512F.FusedMultiplyAddNegated assertion in jitstress2-jitstressregs

[github-actions]

Build Information

Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1433539
Build error leg or test failing: coreclr Pri1 Runtime Tests Run windows x64 checked - HardwareIntrinsics_X86_Avx512_r

Error Details

JIT assertion failure in emitxarch.cpp when compiling Avx512F:FusedMultiplyAddNegated under jitstress2-jitstressregs mode. The assertion validates register allocation constraints for FMA instructions with AVX-512 encoding.

Assert failure(PID 7260 [0x00001c5c], Thread: 5484 [0x156c]): Assertion failed '(op3Reg != targetReg) || (op1Reg == targetReg)' in 'System.Runtime.Intrinsics.X86.Avx512F:FusedMultiplyAddNegated(System.Runtime.Intrinsics.Vector512`1[float],System.Runtime.Intrinsics.Vector512`1[float],System.Runtime.Intrinsics.Vector512`1[float],byte):System.Runtime.Intrinsics.Vector512`1[float]' during 'Generate code' (IL size 10; hash 0x93fdea0a; FullOpts)

    File: D:\a\_work\1\s\src\coreclr\jit\emitxarch.cpp:10315

Related closed issues: #114322, #106866 (same assertion pattern on ARM64/SVE, now regressed on x64 AVX-512 under stress).

Confirmed failing in builds 1433539 (2026-05-24) and 1432990 (2026-05-23). Build 1423851 succeeded between them, suggesting intermittent or recently re-introduced.

Error Message

{
  "ErrorMessage": "Assertion failed '(op3Reg != targetReg) || (op1Reg == targetReg)' in 'System.Runtime.Intrinsics.X86.Avx512F:FusedMultiplyAddNegated",
  "ErrorPattern": "",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Note

🔒 Integrity filter blocked 6 items

The following items were blocked because they don't meet the GitHub integrity level.

• #125825 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• [ci-scan] Known Build Error: SocketBlockingModeTransitionTests.ConnectAsync_WithBuffer_Succeeds on Android #128141 issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #115508 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #114358 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #104841 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #62267 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by CI Outer-Loop Failure Scanner · ● 44.6M · ◷

Report

Summary

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

[mangod9]

Dump Analysis

Dump: corerun.exe.7260.dmp (201MB, Windows x64) from Helix job 5283d7c1-a6ee-4d56-8b3e-966e1857384f, work item HardwareIntrinsics_X86_Avx512_r, build 1433539.

Crash Details

Assert: emitxarch.cpp:10315 in emitIns_SIMD_R_R_R_R

(op3Reg != targetReg) || (op1Reg == targetReg)

Method being compiled: Avx512F.FusedMultiplyAddNegated(Vector512<float>, Vector512<float>, Vector512<float>, byte) — FullOpts, IL size 10, hash 0x93fdea0a.

Environment: jitstress2-jitstressregs, Windows x64, AVX-512 capable hardware.

Root Cause

The assert enforces a register constraint for 3-operand RMW (read-modify-write) FMA instructions. The codegen sequence is:

// emitxarch.cpp:10317-10318
emitIns_Mov(INS_movaps, attr, targetReg, op1Reg, /* canSkip */ true);  // step 1: copy op1 → target
emitIns_R_R_R(ins, attr, targetReg, op2Reg, op3Reg, instOptions);      // step 2: target = target * op2 + op3

If op3Reg == targetReg but op1Reg != targetReg, step 1 overwrites the target register (which holds op3) with op1 before step 2 can read op3 — producing wrong results.

Call Path

The 4-operand embedded-rounding FMA path triggers this:

hwintrinsiccodegenxarch.cpp:1843  case NI_AVX512_FusedMultiplyAddNegated (4-operand variant with rounding control byte)
hwintrinsiccodegenxarch.cpp:1865    genHWIntrinsic_R_R_R_RM(ins, attr, targetReg, op1Reg, op2Reg, op3, newInstOptions)
hwintrinsiccodegenxarch.cpp:1478      emit->emitIns_SIMD_R_R_R_R(ins, attr, targetReg, op1Reg, op2Reg, op3Reg, instOptions)
emitxarch.cpp:10315                     assert FAILS: op3Reg == targetReg && op1Reg != targetReg

The embedded-rounding FMA variant (line 1843-1869) uses genHWIntrinsicJumpTableFallback which builds a jump table over the rounding control byte. This path calls genHWIntrinsic_R_R_R_RM directly with the register assignments from LSRA, without the FMA-specific register swapping that the normal 3-operand codegen path does.

Why jitstress-only

Normal LSRA gives op1 a strong preference for the target register (since FMA is RMW on op1), so op1Reg == targetReg naturally holds and the movaps is a no-op. Under jitstress2-jitstressregs, the allocator assigns random registers, breaking this implicit assumption.

Fix

The LSRA build phase for the 4-operand embedded-rounding FMA needs to mark op2 and op3 as delayFree (cannot share the target register), or the codegen at line 1865 needs to handle the case where op3Reg == targetReg by either:

1. Emitting an extra movaps to save op3 before the op1→target copy
2. Selecting a different FMA instruction form (e.g., 213 vs 231 vs 132) that puts the memory/last operand in a position that doesn't conflict

Related Issues

• JIT: Assertion failed '(targetReg == op1Reg) || (targetReg != op3Reg)' during 'Generate code' #114322 and JIT SVE: Assertion failed '(targetReg == op1Reg) || (targetReg != op3Reg)' during 'Generate code' #106866: Same assertion pattern on ARM64/SVE FMA instructions, suggesting a systemic gap in RMW register constraint handling for multi-operand FMA across architectures.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

[jeffschwMSFT]

closing as this issue has not been hit since opening