Uh oh!
There was an error while loading. Please reload this page.
Fix build break in PackedSimdTests in outerloop - #130962
Conversation
jakobbotsch
commented
Jul 17, 2026
/azp run runtime-coreclr outerloop |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
Azure Pipelines: Successfully started running 4 pipeline(s). 11 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
jakobbotsch
commented
Jul 17, 2026
/azp run runtime-coreclr outerloop |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
The build is fixed, it now uncovers 2 new test failures. These tests were not updated for #128604 changes yet. |
jakobbotsch
commented
Jul 17, 2026
Looks like it. I am going to merge this, but @tannergooding can you please handle that fallout from #128604 ASAP? |
tannergooding
commented
Jul 17, 2026
Ah, sorry. I think this means we're missing the CI filter that triggers this job when the hwintrinsic* files are changed. Probably got missed when the new wasm files were added.
Yep. Looking now and I'll look at fixing the filter too |
jakobbotsch
commented
Jul 17, 2026
/ba-g Failures will be handle separately, this is fixing a build break |
Uh oh!
There was an error while loading. Please reload this page.
radekdoulik
commented
Jul 17, 2026
These tests are only in priority1, so they run only in outerloop and thus PRs CI run didn't catch them. |
The wasm `HardwareIntrinsics` tests (`src/tests/JIT/HardwareIntrinsics/Wasm`) are gated by `HWITestsWasmOnly` -> `CLRTestTargetUnsupported` unless `TargetArchitecture == wasm` (plus an `EnableWasmHWIntrinsicsTests` opt-in). As a result, none of the existing PR-triggered intrinsics pipelines ever compile them: - `runtime-coreclr hardware-intrinsics` (`src/coreclr/jit/**`, x86/x64/arm/osx) passes without building the wasm tree. - `hardware-intrinsics-arm64` (`src/coreclr/jit/*arm64*`) is skipped for wasm-only changes. So a break in the wasm intrinsic tests only surfaces in a rolling/outerloop browser-wasm build, which is what required the #130962 follow-up to #130850. ---------- This adds a wasm counterpart mirroring `hardware-intrinsics-arm64.yml`: - `eng/pipelines/coreclr/hardware-intrinsics-wasm.yml` -- PR-triggered, filtered on `src/coreclr/jit/*wasm*` (covers `hwintrinsic*wasm*`, `lowerwasm.cpp`, `regallocwasm.cpp`) plus `src/tests/JIT/HardwareIntrinsics/Wasm/**`. Runs a `browser_wasm` leg with `/p:EnableWasmHWIntrinsicsTests=true -tree:JIT/HardwareIntrinsics/Wasm`. - `eng/pipelines/coreclr/templates/jit-hardware-intrinsics-wasm.yml` -- modeled on the existing `wasi-wasm-coreclr-runtime-tests.yml` (`global-build-job`, `runtimeFlavor: coreclr`, `-s clr+libs+packs`). It is build-only (`sendToHelix: false`) since browser/V8 can''t execute these tests yet -- enough to catch compile breaks like #130962. Like `hardware-intrinsics-arm64.yml`, the new pipeline still needs an Azure DevOps definition registered against the YAML to appear as a PR check. > [!NOTE] > This PR description was drafted by Copilot. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
…0974) The saturating `float`/`double` -> small integral cast changes from #128604 were not reflected in two outerloop tests, breaking CI (see #130962 (comment)). ---------- `JIT/Regression/CLR-x86-JIT/V1-M10/b05617`: under saturation `conv.u1` of `2.564783e7` now yields `255` (was `214`) and `conv.i1` of `5246667200` yields `127` (was `-1`). Propagating through the stack, the final `conv.u4` constant is updated `4294967086` -> `4294967043` so the test still returns `100`. Mono still truncates, so the test is marked unsupported on Mono, referencing the same tracking issue (#100368) used by the JIT regression test in #128604. ---------- `JIT/IL_Conformance/Convert/TestConvertFromIntegral`: the two checked `ushort.MaxValue -> short` via `Conv_I2` cases now saturate to `short.MaxValue` on CoreCLR instead of truncating to `-1`. Since the result is now runtime-divergent (Mono truncates), they are marked `UnspecifiedBehaviour`, consistent with how every other cross-runtime-divergent float->integral out-of-range case in this file is already handled. This keeps the rest of the file running on Mono. Verified locally against a checked runtime: `b05617` returns `100` and `TestConvertFromIntegral` reports "All tests passed". > [!NOTE] > This PR description was drafted by Copilot. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Fix break from #130850