Embedded `_Concurrency` is never built for `aarch64-none-none-elf` on a macOS host — arch filter omits the `aarch64` spelling

Beginne in stdlib/public/Concurrency/CMakeLists.txt beim macOS-Host-Architekturfilter und dem CPU-Define-Zweig und vergleiche anschließend die Einträge für eingebettete Targets in stdlib/public/CMakeLists.txt. Überprüfe, dass die Konfiguration libswift_Concurrency.a für aarch64-none-none-elf erstellt und dass der bestehende Pfad arm64-apple-none-macho unverändert bleibt.

Description

What I have to do today. I'm running Embedded Swift with async/await on a bare-metal Raspberry Pi 4 (BCM2711, Cortex-A72). The natural target for a bare-metal AArch64 kernel is aarch64-none-none-elf — but that triple ships no libswift_Concurrency.a, so any use of Task / an async entry point fails to link. The only way I found to get the concurrency runtime onto the board is a workaround: target arm64-apple-none-macho instead (same AArch64 ISA, Mach-O container), -force_load its libswift_Concurrency.a, and post-process the Mach-O into a flat kernel8.img. It works — async/await and a custom SerialExecutor run fine on the hardware — but it means building a non-Apple-platform kernel through an Apple-platform triple purely to obtain _Concurrency.

The embedded concurrency build matrix is actively growing — this one entry looks left behind. In the 6.4 cycle, commit f161a60e1213 (2026-04-25) extended the macOS-host arch filter in stdlib/public/Concurrency/CMakeLists.txt to add the ARMv8-M targets (armv8m.main|armv8.1m.main), and 01ac09a1792e fixed SDK macro handling for non-Darwin embedded targets. So _Concurrency is being brought up across the embedded matrix — but aarch64 (the ELF spelling of ARM64) still isn't in the filter, so aarch64-none-none-elf is silently skipped.

Where it's missing — exact location (verified at release/6.4.x @ 9140a9cd4ec5):

1. The triple is a first-class embedded stdlib target — stdlib/public/CMakeLists.txt:241-244:

   if("AArch64" IN_LIST LLVM_TARGETS_TO_BUILD)
     list(APPEND EMBEDDED_STDLIB_TARGET_TRIPLES
       "aarch64  aarch64-none-none-elf     aarch64-none-none-elf"
     )
   

2. But stdlib/public/Concurrency/CMakeLists.txt, inside the foreach(entry ${EMBEDDED_STDLIB_TARGET_TRIPLES}) loop (line 304), drops it on the macOS host path (lines 322-325):

   elseif (SWIFT_HOST_VARIANT STREQUAL "macosx")
     if(NOT "${mod}" MATCHES "x86_64|arm64|arm64e|armv7|armv7m|armv7em|armv8m.main|armv8.1m.main")
       continue()        # line 324 — mod="aarch64-none-none-elf" matches nothing here
     endif()
   

   arm64-apple-none-macho matches arm64 and proceeds; aarch64-none-none-elf matches nothing (arm64 is not a substring of aarch64) and continue()s, never reaching its add_swift_target_library_single(embedded-concurrency-...). The Linux-host path (lines 318-321) only passes -linux-gnu$ modules, so the triple is skipped there too.
3. A second miss with the same cause — the CPU-define branch (lines 337-338):

   elseif("${arch}" MATCHES "arm64")
     list(APPEND extra_c_compile_flags -DTARGET_CPU_ARM64=1)
   

   arch here is aarch64, which doesn't match arm64 either.

I'm not sure whether this is intentional. I couldn't find any comment, test, or doc in the tree marking the ELF AArch64 triple as excluded from concurrency — a repo-wide search for aarch64-none-none-elf matches only its declaration in stdlib/public/CMakeLists.txt. And f161a60e1213 shows the filter line being actively extended for other embedded targets without aarch64 coming along, which reads like an oversight rather than a decision — but you'd know better than I would.

If it's not intentional, the fix appears to be two lines in stdlib/public/Concurrency/CMakeLists.txt:

1. Add aarch64 to the host arch filter: "x86_64|aarch64|arm64|arm64e|armv7|...".
2. Make the CPU-define branch also match it: elseif("${arch}" MATCHES "arm64|aarch64").

The architecturally identical Mach-O triple already builds and runs this runtime on real AArch64 hardware (that's my kernel), so there's no architectural blocker — only the triple-name filter. Closing it would let bare-metal AArch64 projects use concurrency on the native ELF target instead of routing through an Apple-platform triple.

Reproduction

On a stock Swift 6.4 development snapshot, on a macOS host, compare the embedded runtime dir for the two AArch64 triples:

# Mach-O AArch64 — the runtime archive exists:
ls <toolchain>/usr/lib/swift/embedded/arm64-apple-none-macho/libswift_Concurrency.a   # present

# ELF AArch64 — never built:
ls <toolchain>/usr/lib/swift/embedded/aarch64-none-none-elf/libswift_Concurrency.a    # absent

Any attempt to use async/await (Task, an async entry point) when targeting aarch64-none-none-elf then fails to link, because there is no libswift_Concurrency.a for that triple.

Expected behavior

aarch64-none-none-elf should get the Embedded _Concurrency runtime built for it on a macOS host, the same as the architecturally-identical arm64-apple-none-macho already does. Both are AArch64; there is no architectural reason only the Mach-O spelling ships async/await.

Environment

• Swift source verified: release/6.4.x @ commit 9140a9cd4ec5 (2026-06-09), files stdlib/public/CMakeLists.txt and stdlib/public/Concurrency/CMakeLists.txt.
• Host: macOS.
• Hardware evidence toolchain: swift-6.3.2-RELEASE, target arm64-apple-none-macho.

Additional information

I have Embedded Swift async/await with a custom bare-metal SerialExecutor running on a real Raspberry Pi 4 (BCM2711, Cortex-A72), booting from kernel8.img on swift-6.3.2-RELEASE — project here: https://github.com/infektyd/AetherKernel (the workaround lives in Toolsets/rpi4-macho.json and build.sh). The only way I could get the _Concurrency runtime onto AArch64 was to target arm64-apple-none-macho and -force_load its libswift_Concurrency.a; the aarch64-none-none-elf path has no such archive to link — consistent with the continue() above. So the runtime demonstrably works on the architecture; the ELF triple just never gets it built.

Related: #87327 (Xcode 26.4 / TargetConditionals.h embedded build) touches the same macOS-host machinery — not a duplicate, just adjacent.

I'm happy to send the two-line PR if that's preferred — I'd appreciate guidance on how you'd want a build-configuration change like this tested, since there's no obvious unit-test hook.