Skip to content

[release/11.0] [mono][llvm] Fix malformed uaddlp/saddlp intrinsic declarations - #133972

Open
github-actions[bot] wants to merge 1 commit into
release/11.0from
backport/pr-132744-to-release/11.0
Open

github-actions[bot] wants to merge 1 commit into
release/11.0from
backport/pr-132744-to-release/11.0

Conversation

@github-actions

@github-actions github-actions Bot commented Sep 15, 2026

Copy link
Copy Markdown
Contributor

Backport of #132744 to release/11.0

/cc @rolfbjarne

Customer Impact

  • Customer reported
  • Found internally

The bug can manifest on iOS/tvOS projects if LLVM is enabled (which it is by default for Release builds), and the result is that the build fails (LLVM raises an error).

A mitigating factor is that the bug typically only manifests when certain APIs in System.Private.CoreLib.dll are LLVM-compiled, and won't manifest if those APIs have been trimmed away by the trimmer earlier in the build. OTOH we have no visibility into how often those APIs are trimmed away or not (some apps might not even trim System.Private.CoreLib.dll, in which case they'll certainly encounter this problem).

Regression

  • Yes
  • No

Testing

  • Existing tests in dotnet/macios caught this.
  • I built dotnet/runtime locally with the fix and the tests passed when using that runtime.

Risk

Low risk:

  • Mono is not supported in the first place in .NET 11, the backport is only to keep Mono viable as a backup option.
  • It's a very small and targeted fix, only affects Mono/LLVM code paths.

IMPORTANT: If this backport is for a servicing release, please verify that:

  • For .NET 8 and .NET 9: The PR target branch is release/X.0-staging, not release/X.0.
  • For .NET 10+: The PR target branch is release/X.0 (no -staging suffix).

)

`add_intrinsic ()` computes the source type of a `Widen`-kind intrinsic
as `intrin_types [vw][ew - 1]`, but SADDLP/UADDLP were declared with
`I1` in their overload spec, so `ew == 0` was reached and `intrin_types
[vw][-1]` was read out of bounds. That reads the last element of the
previous row, which is a floating point type, so two of the eight
registered declarations were malformed:

| overload spec | declaration |

|----------------|----------------------------------------------------------------|
| `V64 \| I1` | `declare <8 x i8>
@llvm.aarch64.neon.uaddlp.v8i8.f64(double)` ❌ |
| `V64 \| I2` | `declare <4 x i16>
@llvm.aarch64.neon.uaddlp.v4i16.v8i8(<8 x i8>)` |
| `V64 \| I4` | `declare <2 x i32>
@llvm.aarch64.neon.uaddlp.v2i32.v4i16(<4 x i16>)` |
| `V64 \| I8` | `declare <1 x i64>
@llvm.aarch64.neon.uaddlp.v1i64.v2i32(<2 x i32>)` |
| `V128 \| I1` | `declare <16 x i8>
@llvm.aarch64.neon.uaddlp.v16i8.v1f64(<1 x double>)` ❌ |
| `V128 \| I2` | `declare <8 x i16>
@llvm.aarch64.neon.uaddlp.v8i16.v16i8(<16 x i8>)` |
| `V128 \| I4` | `declare <4 x i32>
@llvm.aarch64.neon.uaddlp.v4i32.v8i16(<8 x i16>)` |
| `V128 \| I8` | `declare <2 x i64>
@llvm.aarch64.neon.uaddlp.v2i64.v4i32(<4 x i32>)` |

The element width in these specs is that of the widened *result*, and
there is no `uaddlp`/`saddlp` form with an 8-bit result element, so `I1`
doesn't belong there in the first place. SADDLP and UADDLP are the only
two `Widen`-kind entries in `llvm-intrinsics.h`, so no other intrinsic
is affected. Call sites are unaffected too —
`ovr_tag_from_mono_vector_class (ins->klass)` uses the result vector
class, which is never an 8-bit element vector for these.

The malformed declarations were never called, but starting with **LLVM
23** the IR verifier rejects them, so AOT compiling any assembly that
references `AdvSimd.AddPairwiseWidening` fails:

```
intrinsic argument 0 type (overload type 1) expected any vector type, but got double
declare <8 x i8> @llvm.aarch64.neon.uaddlp.v8i8.f64(double)
intrinsic argument 0 type (overload type 1) expected any vector type, but got double
declare <8 x i8> @llvm.aarch64.neon.saddlp.v8i8.f64(double)
LLVM ERROR: Broken module found, compilation aborted!
```

The out-of-bounds read has been there since #51993 (2021); it only
started failing now because of the LLVM 23 bump. It was found in
dotnet/macios, where the untrimmed `dont link` iOS test started failing
to AOT compile `System.Private.CoreLib.dll`.

Fixes #132743

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 1b1fe653-aecb-469b-b96d-85e0691818de
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

@rolfbjarne rolfbjarne added the Servicing-consider Issue for next servicing release review label Sep 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-VM-meta-mono Servicing-consider Issue for next servicing release review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants