Embedded Wasm SDK leg: compiler crash (signal 11) — red at job level on four consecutive runs, hidden by advisory leg

[coenttb]

Observed behavior

The "ci / Ubuntu (Swift 6.3, Embedded Wasm SDK build)" job fails on at least four consecutive runs (most recently run 30580226709, job 90998335088, head 1d5abe5) with a compiler crash: error: compile command failed due to signal 11 (use -v to see invocation). The run-level conclusion stays success because the leg is advisory (continue-on-error), so the regression is invisible at run level. The "Swift main nightly, Embedded build" job on the same runs passes, so the failure is specific to the 6.3 Embedded Wasm SDK leg, not to Embedded mode generally.

Expected behavior

The package compiles under the Embedded Wasm SDK leg, or the blocker is classified and tracked: a signal-11 compiler crash is a toolchain-defect candidate per the workspace skill's toolchain-defects flow (reduce, verify against the production shape, file the isolated reproducer in swift-institute/Issues), not a silent permanent red.

Minimal reproduction

Dispatch ci.yml (full tier) on this repository and read the Embedded Wasm SDK job, or build the package with the 6.3 Embedded Wasm SDK through the Workspace coordinator. Job log for the crash: https://github.com/swift-primitives/swift-array-primitives/actions/runs/30580226709/job/90998335088

Swift version

Swift 6.3 Embedded Wasm SDK CI leg (nightly Embedded leg passes at the same heads).

Platform

wasm32 (Embedded Wasm SDK); Ubuntu runner.

Additional context

Surfaced under Goal swift-institute/.github#145: swift-primitives/swift-navigation-primitives assessed Array.Shared for reuse (assertion record: swift-institute/.github#156) and deferred adoption solely because of this red leg — Wasm deployability is load-bearing for that Goal, and adopting the owner would inherit the regression. A consumer-side adoption task is filed blocked on this issue. Classification (source-fixable workaround vs toolchain reproducer) is the first step; the crash signature (signal 11, no diagnostic) points at the toolchain flow.

[coenttb]

Localization: the crash is in a dependency's module, not this package's sources

Read the failing job's full log as the first step of the toolchain-defects flow. The crash does
not localize into swift-array-primitives. It localizes into swift-bit-index-primitives,
which this package pulls transitively (no bit-index edge exists in this package's
Package.swift; the path runs through the memory family).

The crashing frame

Job: https://github.com/swift-primitives/swift-array-primitives/actions/runs/30580226709/job/90998335088

The swift-frontend invocation that takes signal 11 has as its only primary inputs the four
files of the dependency's module, from the resolved checkout of swift-bit-index-primitives:

Sources/Bit Index Primitives/Bit+Affine.Discrete.Ratio.swift
Sources/Bit Index Primitives/Bit.Index+Byte.swift
Sources/Bit Index Primitives/Bit.Index.swift
Sources/Bit Index Primitives/exports.swift
-module-name Bit_Index_Primitives
-target wasm32-unknown-wasip1  -Onone  -enable-experimental-feature Embedded

Compiler and pass, verbatim from the stack dump:

Swift version 6.3.3 (swift-6.3.3-RELEASE)
3. While evaluating request ExecuteSILPipelineRequest(Run pipelines
   { Mandatory Diagnostic Passes + Enabling Optimization Passes } on SIL for Bit_Index_Primitives)
4. While running pass #897 SILModuleTransform "MandatoryPerformanceOptimizations".
 #4 isLegalSILType(swift::CanType)
 #5 (anonymous namespace)::AvailableValueDataflowContext::computeAvailableValues(...) PredictableMemOpt.cpp
 #6 swift::eliminateDeadAllocations(swift::SILFunction*, swift::DominanceInfo*)
*** Program crashed: Bad pointer dereference at 0x0000003100000023 ***

MandatoryPerformanceOptimizations is the Embedded-mode mandatory pipeline, which is why the
crash occurs at -Onone.

Deterministic, not a soak flake

Same module, same pass, same pass number on all three runs checked:

run	Embedded Wasm job	SIL module	pass
30580226709	90998335088	Bit_Index_Primitives	#897 MandatoryPerformanceOptimizations
30578016363	90991078070	Bit_Index_Primitives	#897 MandatoryPerformanceOptimizations
30573226271	90974974783	Bit_Index_Primitives	#897 MandatoryPerformanceOptimizations

This package's own sources are unmeasured on this leg

The job emits 174 Compiling lines and not one is an Array_* module — the build dies in the
dependency before reaching any target this repository owns. Control: the same scan over the same
log returns 6 hits for Bit_Index_Primitives and 0 for a known-absent token.

So the red leg is currently no evidence either way about whether this package compiles under
the Embedded Wasm SDK. That question cannot be answered until the dependency compiles.

Correction to this issue's premise: the nightly Embedded leg's green is not a build

This issue states that "the 'Swift main nightly, Embedded build' job on the same runs passes, so
the failure is specific to the 6.3 Embedded Wasm SDK leg, not to Embedded mode generally." That
inference does not hold, because that job did not compile anything.

Job 90998335278 on run 30580226709:

• actions/cache@v5, path: .build, key linux-embedded-swift63-spm-v2-<hash> → Cache hit,
  ~84 MB .build restored.
• Then swift build -Xswiftc -enable-experimental-feature -Xswiftc Embedded.
• Build complete! (10.35 secs) with zero Compiling lines.

Measured across the same three runs — Compiling lines on the nightly Embedded leg: 0, 0, 0
(build times 10.35s, 10.59s, 60.02s; cache hit recorded on the first two).

Two further properties of that leg are worth recording:

• Its target is x86_64-unknown-linux-gnu, the host triple, not an embedded or wasm triple.
  It is the Embedded feature flag on the host, not an embedded-target build.
• Its cache key carries swift63 while the job's toolchain reports
  Swift version 6.5-dev (LLVM 6f2057ffeafd4c6, Swift 83c32e02f71e4bb). The key does not encode
  toolchain identity, so a .build produced under one compiler is restorable into a job running
  another.

This is the shape the CI doctrine already prohibits: ordinary SwiftPM .build must not be cached,
because with branch-pinned dependencies no key can prove it represents the resolved graph. The
practical effect is that "Embedded (main nightly) = success" is a green that attests to a cache
restore, not to a compile — including in the comparison table on
swift-institute/.github#156 (comment), which used that
column as evidence.

Disposition

Per the coordinator's routing (2026-07-31), the fix belongs to the owner,
swift-primitives/swift-bit-index-primitives, and is being handled as a batch item covering the
fleet-wide occurrence of this signature rather than per-consumer — see
swift-institute/.github#94 (comment).

No source-level change in this repository can avoid the crash: the trigger is another module's
source, compiled from its own resolved checkout with its own flags, and this package declares no
direct edge to it. The only lever here would be severing the memory-family dependency chain the
array tower is built on, which would weaken the package's semantics and is not a lawful
workaround.

This issue therefore stays open, blocked on the owner. The consumer-side adoption task
swift-primitives/swift-navigation-primitives#1 stays blocked as
recorded. No reduction or reproducer is filed from here, to avoid duplicating the owner's batch
item.

[coenttb]

Disposition: unavoidable toolchain defect — blocked on the embedded-wasm-sdk toolchain floor

The classification asked for in this issue's premise is complete. Recording the terminal state here so this thread carries the full disposition.

Reduction is recorded and pins the crash

The owner investigation, swift-primitives/swift-bit-index-primitives#2, reproduced the identical signature off CI (same module, same pass, MandatoryPerformanceOptimizations pass #897) and bisected it to the Carrier.\Protocol` where Underlying == Cardinalaccessor onTagged<_, Cardinal>— three packages belowswift-bit-index-primitives, nothing bit-, index-, or affine-specific. A 21-line dependency-free reproducer is filed at https://github.com/swift-institute/Issues/issues/65#issuecomment-5142917647 (internal record per the standing toolchain-defect ruling; no upstream filing). Measured predicate: crashes under Embedded + wasm32-unknown-wasip1at both-Ononeand-O` on 6.3.3; clean without Embedded on any target; clean on 6.5-dev with an assertions-enabled build, so the defect is already fixed ahead of the current floor.

No viable source-level avoidance

• In this repository: ruled out above — the crash occurs while compiling a transitive dependency's module from its own resolved checkout; no edge to it exists in this Package.swift.
• In the owner: an avoidance was measured and rejected on the merits (it bypasses the affine composition surface, hardcodes constants, and resurfaces at the next consumer of a tagged cardinal) — see the owner disposition.

Decision path (a) is therefore closed; this is path (b): dispositioned as an unavoidable toolchain defect with the reduction on record.

Visibility of the red

The hidden-red property cannot be fixed from this repository. continue-on-error: true on the embedded-wasm-sdk job is set in the central reusable workflow swift-primitives/.github .github/workflows/swift-ci.yml (annotated "advisory; classified soak. Drop after flip"), and ci-ok excludes the advisory legs by design; this repository's ci.yml only calls the reusable workflow. The fleet audit found 96/209 repos red on these advisory legs (swift-institute/.github#94 (comment)), so the advisory→mandatory flip is a central-workflow fleet decision, routed through that batch record — not a per-consumer change. Until then, this issue plus the fleet audit are the discovery surface for the job-level red.

Exit condition

This issue stays open, blocked on the toolchain floor: it clears when the central embedded-wasm-sdk job's Swift toolchain moves past 6.3.3. At that point, dispatch a fresh full-tier ci.yml run on this repository; a green Embedded Wasm SDK job here is the first measurement of this package's own sources on that leg, and unblocks swift-primitives/swift-navigation-primitives#1.