Skip to content

chore: upgrade default LLVM toolchain to 22 - #2470

Merged
xushiwei merged 11 commits into
xgo-dev:mainfrom
zhouguangyuan0718:codex/llvm22-main-20260901
Sep 5, 2026
Merged

xushiwei merged 11 commits into
xgo-dev:mainfrom
zhouguangyuan0718:codex/llvm22-main-20260901

Conversation

@zhouguangyuan0718

@zhouguangyuan0718 zhouguangyuan0718 commented Sep 1, 2026 •

Copy link
Copy Markdown
Collaborator

This is the main-based LLVM 22 upgrade. It supersedes #2334 rather than stacking LLVM 22 changes onto the LLVM 21 PR.

Exact base: 714e8c6eff9fa5c51e037a89f05af9a6a6c80986

Exact head: 052e23226d90e235dcd8bef5f9933cdf5723643f

Scope

  • make LLVM 22 the default and update the released Go LLVM binding to github.com/xgo-dev/llvm v0.9.9
  • update LLVM/Clang/LLD/LLDB installation and qualification for Linux, Apple Silicon/Intel macOS, and the existing Windows amd64/arm64/386 x MSVC/MinGW profiles
  • keep the official Windows host LLVM and the downloaded embedded-target compiler separate
  • use the released full-target ESP LLVM payload 22.1.4_20260905 for named embedded targets on every supported host, including Windows, with pinned checksums and toolchain-aware cross-library caches
  • consume compiler-rt tag xtensa_release_22.1.4_20260903
  • apply LLVM 22 compatibility changes required by the binding, identified-struct handling, target triples/features, LTO plugin header/build/load contract, LLDB, and actual LLVM 22 IR test spelling
  • update Homebrew, apt.llvm.org, MSYS2 host packages, Fedora, Alpine, the development container, GoReleaser payload selection, README, and third-party notices

The wasm64 closure CodeGen issue is fixed independently by #2496, which is now part of this PR's base. This branch retains that nonnull allocation contract and its optimized CodeGen/runtime tests; it does not carry the earlier volatile code-pointer barrier or require dynamic closure calls to remain indirect.

Plan9ASM remains covered by the repository tests; no Plan9ASM source change is required.

Deliberately excluded

The branch keeps the LLVM 22 upgrade, direct LLVM 22 IR expectations, the released full-target ESP payload switch, and a focused CI cleanup. It does not contain:

  • the generic internal/llvmpayload package/CLI and runtime version parser
  • explicit LLVM 21 compatibility files or CI
  • generic HTTP/GOPROXY retry, build-cache logging, or public cache-directory refactors
  • release sysroot cache-to-artifact handoff changes
  • dedicated distribution/container/LTO qualification jobs and expanded release-artifact checksum steps
  • unrelated compiler.used, inline-asm keepalive, llvm.reloc.none, or LTO modernization
  • test-layer rewriting of LLVM 22 IR back to LLVM 19 spelling
  • the temporary secondary MSYS2 embedded-LLVM install or LLGO_WINDOWS_EMBEDDED_CLANG_ROOT

Released dependencies

  • github.com/xgo-dev/llvm v0.9.9
  • github.com/goplus/lib v0.5.1
  • github.com/goplus/compiler-rt@xtensa_release_22.1.4_20260903
  • github.com/goplus/espressif-llvm-project-prebuilt@22.1.4_20260905

No personal-fork module replacement, temporary dependency branch, or unstable payload URL remains.

Windows ESP selection test repair

Commit 2d37a571b69868ce0abc24c3f304e90fd2d91814 fixes the test fixture responsible for both Windows coverage-job failures on the previous head. The old fixture created an empty toolchain cache directory, but UseTarget must execute clang++ --version for its library cache key.

  • use the real installed/downloaded ESP LLVM toolchain and retain the compiler-root, compiler-path, and linker-path assertions
  • run the selection test on Linux/macOS as well as Windows, instead of skipping the local host
  • no production compiler code, cache policy, dependency pins, or CI configuration changes

Local validation with host LLVM 22.1.8 and released ESP LLVM 22.1.4_20260905: all five focused tests pass (TestUseTargetESPClang, TestESPClangHostDownload, TestUseTargetESPClangDownloadError, TestCompilerVersionCacheKey, TestCompilerCacheKeyErrors). The selection test actually builds RP2040 picolibc and compiler-rt. A local-only Go test overlay redirects the cache root to an isolated directory; it does not replace the compiler or test assertions. Formatting and git diff --check pass. Windows execution remains pending at the new exact head.

CI setup cleanup

Commit 61c15cd5d removes four redundant setup changes without changing compiler/runtime code or dependency pins:

  • restore the original late MSVC MSYS2 host-shell initialization and inherited PATH; remove the four auxiliary path variables and manual PATH reconstruction. No secondary embedded MSYS2 LLVM is installed.
  • restore x64 host Python and normal esptool dependency installation on Windows ARM64, retaining main's independent archive-extractor fix and LLVM 22's required LLDB Python ABI setup.
  • remove the duplicate Emscripten EM_LLVM_ROOT overrides from both workflows; the SDK's own configuration selects its target LLVM.
  • remove the duplicate LLVM pkg-config metadata check; the existing complete dependency check remains.

Validation for this CI-only cleanup:

  • all 30 YAML files parse; actionlint passes for both changed workflows
  • all 48 Bash/MSYS2 blocks in the affected actions/workflows and the host-shell script pass syntax checks
  • setup-go and the Windows host-shell test script match main byte-for-byte; the MSVC shell setup and ESP startup test steps match main structurally
  • removed environment-variable references and conflict-marker scans are clean; git diff --check passes
  • with host LLVM 22 first on PATH and EM_LLVM_ROOT unset, Emscripten selects its SDK compiler/linker and passes a C-to-WebAssembly compile/link/Node execution smoke test using an isolated build directory and fresh cache
  • native Windows execution and the complete Go/LLGo suite are left to this exact head's CI; older CI results are not substituted

Prior upgrade validation (before this CI-only cleanup)

  • git diff --check, conflict-marker and obsolete closure/toolchain-workaround scans: pass
  • workflow YAML parsing: pass; actionlint only reports repository-existing custom runner-label and shellcheck diagnostics
  • LLVM 22.1.8 go test ./ssa -count=1: pass, using the actual generated IR without normalization
  • LLVM 22.1.8 tests for build, crosscompile, compiler-rt, DCE, lit, LTO, and LLVM tool setup: pass
  • rebuilt LLGo wasm target profiles: Emscripten, memory64, legacy wasm, WASI, legacy wasip1, and raw wasm pass
  • LLVM 22 wasm64 encoding/json/v2 reproducer: pass
  • ThinLTO and FullLTO memory64 builds and Node execution: pass
  • ESP LLVM release workflow run 33908361034: all five platform builds, native Windows validation, and release job pass
  • all five release archives: aggregate SHA-256, extraction, version, source revision, and target manifest pass
  • formal macOS arm64 payload: LLVM verifier plus ARM/AArch64/AVR/Mips/RISCV/WebAssembly/Xtensa CodeGen/link validation pass
  • LLGo final-link smoke with the released payload: ESP32 (Xtensa), ESP32-C3 (RISC-V), Pico (ARM), and Arduino (AVR) pass

Rebase onto current main (2026-09-05)

Rebased onto 714e8c6eff9fa5c51e037a89f05af9a6a6c80986, including main's runner fixes from #2476. The five failed Linux runner jobs on old head 720c60b9f634e88f799f37386d3901c67566632c failed during Go setup with EACCES: permission denied, mkdir '/opt/go', before compilation/tests. Main now configures writable Go paths under RUNNER_TEMP and updates runner placement; this PR preserves those changes instead of adding an upgrade-specific workaround.

Resolved only the three workflow conflicts by combining main's runner selections with LLVM 22. All job runner selections match main, and setup-go is byte-for-byte identical to main. Range-diff confirms the five later commits retain their original patches.

Validation after rebase: all 29 action/workflow YAML files parse; actionlint passes for build-cache, llgo, targets, benchmark, and go workflows with the existing qiniu custom runner label declared in a local-only config (shellcheck/pyflakes disabled). Diff/conflict-marker checks pass. Focused go test runs pass for crosscompile ESP selection/cache keys, SSA struct comparison/TargetMachine, and compiler large-struct comparison under LLVM 22.1.8 with isolated task caches. Full host/target CI must run again at the new exact head.

Review follow-up (2026-09-05)

Commit 104aec559defc032c9f97b180878ef8b2974c4c5 implements three requested scope corrections:

  • Only MSVC targets copy supplemental builtins in setup-deps. The 386 MinGW lane uses its existing standalone toolchain install, avoiding the duplicate llvm-mingw download. Windows support cache keys include the ABI so a MinGW cache without supplemental builtins cannot satisfy an MSVC job.
  • Restore one apt install retry in Dockerfile.dev using the identical version-qualified LLVM 22 package list; no fallback to unversioned distro LLVM.
  • Remove the c++ to msvcprt mapping and its added test/import. Both internal/build files now match main. The released lib already has a Windows-specific C++ link configuration.

Validation: focused internal/build package/link-argument tests pass; 29 YAML files parse; workflow actionlint passes with the main custom runner label declared locally; all Docker RUN shell syntax checks pass; a stubbed apt harness passes first-success, retry-success and retry-failure paths and confirms both attempts request identical LLVM 22 packages. Diff checks pass. A native Windows run and a full Docker image build were not performed locally (Docker daemon did not respond); new-head CI is pending.

Win32 LLDB investigation, not a toolchain change in this commit: the immutable mstorsjo/llvm-mingw release 20260616 contains llvm-mingw-20260616-ucrt-i686.zip (SHA-256 c68b26561883d5c7f33307aeb2b9b6c188eb705808b3f780dfce0be49f4e835d). Download/checksum and extracted PE headers confirm native i386 LLDB plus Python 3.14 and the LLDB Python extension. liblldb contains version 22.1.8. Its tagged workflow builds i686 with Python and includes native LLDB breakpoint/backtrace tests. This is a concrete candidate to restore full 386 debugging; LLGo's MSVC/MinGW suites have not yet been run with it. At that commit, load-only was still unchanged; it is removed by the native Win32 LLDB follow-up below.

Native Win32 LLDB and restored full tests

Commit 460e9925bfce6480131d08e03c3c5df1454ea9d4 switches both Windows 386 ABI profiles to the pinned llvm-mingw 20260616 i686 LLDB 22.1.8 payload described above. The cache preserves the debugger's bundled DLLs and Python 3.14 layout, with a new cache key. The debugger directory is not placed on the compiler/target runtime's global PATH. Only the debugger setup check uses it in its step-local PATH.

  • The 386 MSVC builtins come from the same i686 archive; no additional x64 LLVM installer or x64 builtins-only archive is downloaded for 386 support. The existing x64 MinGW target-toolchain installation remains separate.
  • The official x64/ARM64 debugger setup and matching Python 3.11 remain unchanged in scope. The 386 lane uses bundled Python instead of installing x64 Python 3.11 for LLDB.
  • A native LLDB embedded-Python check requires a 32-bit interpreter and LLDB 22.1.8 before the integration suite.
  • Remove --load-only and both workflow bypasses. cmd/llgo/lldbtest/runtest.sh matches main byte-for-byte; both Go variable-formatting and mixed Go/C fault/backtrace suites execute for 386 MSVC and MinGW.

Local verification: immutable archive SHA-256 passes; PE headers confirm i386 debugger/Python, and direct DLL imports match bundled libraries or Windows system libraries. All 29 YAML files parse; 16 PowerShell blocks parse with PowerShell's parser; 38 Bash/MSYS2 blocks plus runtest.sh parse; actionlint passes with the existing custom runner label configured locally; diff and removed-option scans pass. This CI/test-harness change does not alter compiler source or Go dependencies; no full Go suite was rerun locally. Native Windows LLDB launch, Python initialization, source breakpoints, variables and mixed-stack execution must pass at the new exact CI head; they have not been claimed as locally validated.

Hello World standalone dependency correction

Commit 92946954a111316e32131077482f1a17752ce344 updates only the standalone module created by dev/test_helloworld.sh, from goplus/lib v0.3.1 to the same released v0.5.1 used by this PR. The Windows ARM64 MSVC job on head 460e9925b failed before LLDB with lld-link: error: could not open 'c++.lib'. The script's independently pinned old lib still declares link: c++ and lacks the current Windows string layout; the root go.mod update does not affect this temporary module. The compiler-side runtime-name mapping remains removed. All Hello World output assertions, the Go module-version matrix, and embedded test logic are unchanged.

Local verification: built the current LLGo with LLVM 22.1.8 and ran the native Hello World smoke for go.mod 1.21 through 1.27 under Go 1.27.0 on macOS arm64; all seven pass including C++ string output. A local-only build overlay redirects LLGo's runtime cache into the task directory. Local smoke runs use the existing LLGO_HELLO_EMBED=false option; embedded checks remain enabled in the CI Go 1.27 step and were not revalidated locally here. Windows ARM64 package selection resolves v0.5.1's config_windows.go and string_type_windows.go. Bash syntax and diff checks pass; native Windows execution awaits new-head CI.

On the superseded head, three Linux jobs failed from runner disk exhaustion; populate-linux-sysroot failed downloading Debian security packages (HTTP 404), leaving rsync unavailable and dependent artifact/release jobs skipped. Those are not source-test passes. Job rerun remains unavailable to the current account (GitHub 403, no repository push/admin permission); no runner settings or release tags were changed.

Checksum error-path tests

Commit 92bca1838bc755aa12f43309db1066dba8a36d3f adds only two unit tests (27 lines). After all four coverage uploads for head 92946954a completed, Codecov reported 93.54% patch coverage against 94.24%, with six uncovered added lines. The tests exercise rejection of a missing host payload checksum and hashing a missing file/directory. Five focused crosscompile tests pass locally with LLVM 22.1.8; the coverage profile confirms the missing-checksum return and both file-hash error returns execute. No production code, CI configuration, coverage threshold, or existing assertions changed. New exact-head coverage and full CI remain pending.

Rebase onto Debian 12 release baseline (2026-09-05)

Rebased onto 714e8c6eff9fa5c51e037a89f05af9a6a6c80986, which includes merged #2504. The upstream sysroot script is retained byte-for-byte: it uses pinned Debian 12 amd64/arm64 images, GCC 12 headers/libraries, package download retries, and explicit layout checks. Conflict resolution in .goreleaser.yaml keeps those Debian 12/GCC 12 paths and changes only the four platform link entries from LLVM 19 to LLVM 22 relative to main.

Range-diff shows the other nine LLVM 22 commits are patch-identical. YAML parsing, sysroot shell syntax, conflict-marker and obsolete Debian 11/GCC 10 scans pass. Actionlint passes with shellcheck/pyflakes disabled and the repository's custom runner label declared locally. PR #2504's exact-head CI passed sysroot population, GoReleaser build, and all four release-artifact smoke tests; the combined LLVM 22 branch must pass those checks again at the new exact head.

Review follow-up after rebase

Commit 052e23226d90e235dcd8bef5f9933cdf5723643f addresses both new review threads without changing behavior: README now documents the actual LLDB candidate search and explicit overrides, and compiled-library cache parameters use the name compiledLibraryKey consistently. Four focused crosscompile cache/config tests pass locally with LLVM 22.1.8; formatting and diff checks pass. Both review threads are resolved.

CI

CI must be evaluated at exact head 052e23226d90e235dcd8bef5f9933cdf5723643f. Pending checks are not counted as passing. The earlier empty-commit retry and all older-head results are historical only.

Windows 386 now runs the full LLDB suites with native i686 LLDB; pending checks are not debugger validation. A failed Windows benchmark base build still yields unavailable base comparisons, not a passing performance comparison.

@codecov

codecov Bot commented Sep 1, 2026 •

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 97.84946% with 2 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
internal/crosscompile/crosscompile.go 96.00% 1 Missing ⚠️
internal/crosscompile/fetch.go 93.75% 1 Missing ⚠️

📢 Thoughts on this report? Let us know!

@github-actions

github-actions Bot commented Sep 1, 2026 •

Copy link
Copy Markdown

LLGo baseline benchmarks

052e23226d90 | workflow run | long-term charts

Program measurements

Platform Workload File size vs base Text size vs base Build vs base Run vs base
Linux cprintf 19848 B 0 B / +0.0% 387 B 0 B / +0.0% 453.974 ms -1.919 ms / -0.4% (better) 1.229 ms -11.3 us / -0.9% (better)
Linux cprintf-lto 19600 B 0 B / +0.0% 368 B 0 B / +0.0% 453.672 ms -7.554 ms / -1.6% (better) 1.292 ms +54.03 us / +4.4% (worse)
Linux fmtprintf 1612920 B -8 B / -0.000496% (better) 489274 B 0 B / +0.0% 3.637 s +146.6 ms / +4.2% (worse) 2.998 ms +28.93 us / +1.0% (worse)
Linux fmtprintf-lto 1477880 B -8 B / -0.0005413% (better) 442330 B 0 B / +0.0% 10.542 s -116.7 ms / -1.1% (better) 2.878 ms -160.4 us / -5.3% (better)
Linux println 62600 B 0 B / +0.0% 14972 B 0 B / +0.0% 452.859 ms +2.283 ms / +0.5% (worse) 1.582 ms +70.14 us / +4.6% (worse)
Linux println-lto 54656 B 0 B / +0.0% 12537 B 0 B / +0.0% 656.896 ms -1.328 ms / -0.2% (better) 1.602 ms +101.8 us / +6.8% (worse)
macOS cprintf 84480 B 0 B / +0.0% 17117 B 0 B / +0.0% 538.053 ms +7.411 ms / +1.4% (worse) 2.245 ms -176.6 us / -7.3% (better)
macOS cprintf-lto 84288 B 0 B / +0.0% 12881 B 0 B / +0.0% 654.246 ms -24.48 ms / -3.6% (better) 3.016 ms +581.2 us / +23.9% (worse)
macOS fmtprintf 1473408 B 0 B / +0.0% 867292 B 0 B / +0.0% 2.971 s +73.46 ms / +2.5% (worse) 4.742 ms -1.664 ms / -26.0% (better)
macOS fmtprintf-lto 1159568 B 0 B / +0.0% 848572 B 0 B / +0.0% 7.615 s -633 ms / -7.7% (better) 5.521 ms +63.75 us / +1.2% (worse)
macOS println 114864 B 0 B / +0.0% 35081 B 0 B / +0.0% 569.818 ms -155 ms / -21.4% (better) 3.005 ms +65.46 us / +2.2% (worse)
macOS println-lto 118736 B 0 B / +0.0% 32917 B 0 B / +0.0% 753.275 ms +120.9 ms / +19.1% (worse) 8.084 ms +5.16 ms / +176.5% (worse)
Windows MinGW cprintf 19456 B 0 B / +0.0% 4550 B 0 B / +0.0% 1.196 s +55.17 ms / +4.8% (worse) 4.320 ms +934.8 us / +27.6% (worse)
Windows MinGW cprintf-lto 17920 B 0 B / +0.0% 4486 B 0 B / +0.0% 1.252 s +83.41 ms / +7.1% (worse) 4.173 ms +686.7 us / +19.7% (worse)
Windows MinGW fmtprintf 1885184 B 0 B / +0.0% 592822 B 0 B / +0.0% 4.909 s +782.2 ms / +19.0% (worse) 9.214 ms +1.185 ms / +14.8% (worse)
Windows MinGW fmtprintf-lto 1948672 B 0 B / +0.0% 566070 B 0 B / +0.0% 10.282 s +275.8 ms / +2.8% (worse) 8.896 ms +636.1 us / +7.7% (worse)
Windows MinGW println 72192 B 0 B / +0.0% 24198 B 0 B / +0.0% 1.184 s +13.8 ms / +1.2% (worse) 7.161 ms +324.8 us / +4.8% (worse)
Windows MinGW println-lto 66048 B 0 B / +0.0% 21158 B 0 B / +0.0% 1.435 s +84.42 ms / +6.3% (worse) 7.048 ms +315.1 us / +4.7% (worse)
Windows MinGW 386 cprintf 37888 B 0 B / +0.0% 5326 B 0 B / +0.0% 1.119 s -1.882 ms / -0.2% (better) 5.623 ms +455.3 us / +8.8% (worse)
Windows MinGW 386 cprintf-lto 20992 B 0 B / +0.0% 5094 B 0 B / +0.0% 1.247 s +52.21 ms / +4.4% (worse) 6.424 ms +1.057 ms / +19.7% (worse)
Windows MinGW 386 fmtprintf 1842688 B 0 B / +0.0% 468250 B 0 B / +0.0% 4.730 s +781.8 ms / +19.8% (worse) 12.206 ms +1.326 ms / +12.2% (worse)
Windows MinGW 386 fmtprintf-lto 2165760 B 0 B / +0.0% 463410 B 0 B / +0.0% 9.335 s -203.7 ms / -2.1% (better) 10.931 ms -1.342 ms / -10.9% (better)
Windows MinGW 386 println 86528 B 0 B / +0.0% 20454 B 0 B / +0.0% 1.209 s +120.1 ms / +11.0% (worse) 10.074 ms +1.446 ms / +16.8% (worse)
Windows MinGW 386 println-lto 71168 B 0 B / +0.0% 18394 B 0 B / +0.0% 1.468 s +176.8 ms / +13.7% (worse) 10.600 ms +1.833 ms / +20.9% (worse)
Windows MinGW ARM64 cprintf 18944 B 0 B / +0.0% 4436 B 0 B / +0.0% 1.352 s -43.69 ms / -3.1% (better) 6.165 ms -33.6 us / -0.5% (better)
Windows MinGW ARM64 cprintf-lto 17920 B 0 B / +0.0% 4368 B 0 B / +0.0% 1.417 s +1.469 ms / +0.1% (worse) 6.326 ms -58.5 us / -0.9% (better)
Windows MinGW ARM64 fmtprintf 1774080 B 0 B / +0.0% 506428 B 0 B / +0.0% 4.140 s -141.1 ms / -3.3% (better) 12.177 ms -926.1 us / -7.1% (better)
Windows MinGW ARM64 fmtprintf-lto 1866240 B 0 B / +0.0% 486456 B 0 B / +0.0% 9.578 s -44.85 ms / -0.5% (better) 12.275 ms -589.2 us / -4.6% (better)
Windows MinGW ARM64 println 69120 B 0 B / +0.0% 22840 B 0 B / +0.0% 1.367 s +22.69 ms / +1.7% (worse) 10.502 ms -241.6 us / -2.2% (better)
Windows MinGW ARM64 println-lto 65024 B 0 B / +0.0% 20304 B 0 B / +0.0% 1.566 s -38.46 ms / -2.4% (better) 11.126 ms +64.9 us / +0.6% (worse)
Windows MSVC cprintf 120320 B 0 B / +0.0% 65782 B 0 B / +0.0% 1.277 s +349.7 ms / +37.7% (worse) 3.497 ms -206.8 us / -5.6% (better)
Windows MSVC cprintf-lto 119808 B 0 B / +0.0% 65718 B 0 B / +0.0% 1.171 s +220.6 ms / +23.2% (worse) 4.255 ms +501.7 us / +13.4% (worse)
Windows MSVC fmtprintf 1615872 B 0 B / +0.0% 688326 B 0 B / +0.0% 3.779 s +15.17 ms / +0.4% (worse) 9.148 ms -142.4 us / -1.5% (better)
Windows MSVC fmtprintf-lto 1636352 B 0 B / +0.0% 668598 B 0 B / +0.0% 8.894 s -19.99 ms / -0.2% (better) 10.518 ms +1.699 ms / +19.3% (worse)
Windows MSVC println 193024 B 0 B / +0.0% 119606 B 0 B / +0.0% 1.027 s +106.3 ms / +11.6% (worse) 7.578 ms -194.1 us / -2.5% (better)
Windows MSVC println-lto 190464 B 0 B / +0.0% 116998 B 0 B / +0.0% 1.132 s +9.263 ms / +0.8% (worse) 7.655 ms -262 us / -3.3% (better)
Windows MSVC 386 cprintf 9728 B 0 B / +0.0% 3931 B 0 B / +0.0% 949.760 ms -15.09 ms / -1.6% (better) 6.269 ms -220.9 us / -3.4% (better)
Windows MSVC 386 cprintf-lto 9216 B 0 B / +0.0% 3853 B 0 B / +0.0% 972.876 ms -143.1 ms / -12.8% (better) 6.335 ms +321.6 us / +5.3% (worse)
Windows MSVC 386 fmtprintf 1186304 B 0 B / +0.0% 451601 B 0 B / +0.0% 3.820 s +63.86 ms / +1.7% (worse) 46.060 ms +2.162 ms / +4.9% (worse)
Windows MSVC 386 fmtprintf-lto 1241600 B 0 B / +0.0% 443541 B 0 B / +0.0% 8.932 s -755.8 ms / -7.8% (better) 13.123 ms -1.984 ms / -13.1% (better)
Windows MSVC 386 println 34816 B 0 B / +0.0% 19313 B 0 B / +0.0% 938.628 ms -25.21 ms / -2.6% (better) 10.302 ms -306.8 us / -2.9% (better)
Windows MSVC 386 println-lto 33792 B 0 B / +0.0% 17463 B 0 B / +0.0% 1.116 s -38.7 ms / -3.4% (better) 10.301 ms +33.5 us / +0.3% (worse)
Windows MSVC ARM64 cprintf 11264 B 0 B / +0.0% 3976 B 0 B / +0.0% 2.008 s +14.09 ms / +0.7% (worse) 6.474 ms +355.8 us / +5.8% (worse)
Windows MSVC ARM64 cprintf-lto 10752 B 0 B / +0.0% 3868 B 0 B / +0.0% 2.015 s +6.152 ms / +0.3% (worse) 6.884 ms +561.2 us / +8.9% (worse)
Windows MSVC ARM64 fmtprintf 1362944 B 0 B / +0.0% 506204 B 0 B / +0.0% 6.265 s -37.48 ms / -0.6% (better) 13.896 ms -189.3 us / -1.3% (better)
Windows MSVC ARM64 fmtprintf-lto 1397760 B 0 B / +0.0% 487292 B 0 B / +0.0% 15.172 s -148.3 ms / -1.0% (better) 14.417 ms -150 us / -1.0% (better)
Windows MSVC ARM64 println 42496 B 0 B / +0.0% 22424 B 0 B / +0.0% 1.981 s -1.31 ms / -0.1% (better) 11.700 ms +856.6 us / +7.9% (worse)
Windows MSVC ARM64 println-lto 40448 B 0 B / +0.0% 20204 B 0 B / +0.0% 2.319 s +60.45 ms / +2.7% (worse) 11.854 ms +406.3 us / +3.5% (worse)
Core language and compiler benchmarks
Platform Benchmark ns/op vs base
Linux BenchmarkLookupPCRandom 14.700 ns/op +0.02 ns/op / +0.1% (worse)
Linux BenchmarkMergeCompilerFlags 210.500 ns/op +16.5 ns/op / +8.5% (worse)
Linux BenchmarkMergeLinkerFlags 146.700 ns/op +21.3 ns/op / +17.0% (worse)
Linux BenchmarkChannelBuffered 69.910 ns/op +0.04 ns/op / +0.1% (worse)
Linux BenchmarkChannelHandoff 13327 ns/op -760 ns/op / -5.4% (better)
Linux BenchmarkDefer 48.130 ns/op +2.88 ns/op / +6.4% (worse)
Linux BenchmarkDirectCall 1.164 ns/op -0.001 ns/op / -0.1% (better)
Linux BenchmarkGlobalRead 1.165 ns/op +0.001 ns/op / +0.1% (worse)
Linux BenchmarkGlobalWrite 7.758 ns/op -0.005 ns/op / -0.1% (better)
Linux BenchmarkGoroutine 21204 ns/op +479 ns/op / +2.3% (worse)
Linux BenchmarkInterfaceCall 6.991 ns/op +0.525 ns/op / +8.1% (worse)
Linux BenchmarkRuntimeGetG 2.265 ns/op -0.181 ns/op / -7.4% (better)
macOS BenchmarkLookupPCRandom 12.480 ns/op -5.81 ns/op / -31.8% (better)
macOS BenchmarkMergeCompilerFlags 129.400 ns/op -40 ns/op / -23.6% (better)
macOS BenchmarkMergeLinkerFlags 82.360 ns/op -18.14 ns/op / -18.0% (better)
macOS BenchmarkChannelBuffered 38.350 ns/op +8.22 ns/op / +27.3% (worse)
macOS BenchmarkChannelHandoff 10676 ns/op +5138 ns/op / +92.8% (worse)
macOS BenchmarkDefer 48.220 ns/op +11.29 ns/op / +30.6% (worse)
macOS BenchmarkDirectCall 1.127 ns/op +0.031 ns/op / +2.8% (worse)
macOS BenchmarkGlobalRead 1.166 ns/op -0.015 ns/op / -1.3% (better)
macOS BenchmarkGlobalWrite 1.253 ns/op +0.083 ns/op / +7.1% (worse)
macOS BenchmarkGoroutine 26322 ns/op -5535 ns/op / -17.4% (better)
macOS BenchmarkInterfaceCall 5.560 ns/op +0.564 ns/op / +11.3% (worse)
macOS BenchmarkRuntimeGetG 2.795 ns/op +0.548 ns/op / +24.4% (worse)
Windows MinGW BenchmarkLookupPCRandom 13.300 ns/op -0.02 ns/op / -0.2% (better)
Windows MinGW BenchmarkMergeCompilerFlags 640.700 ns/op +33.9 ns/op / +5.6% (worse)
Windows MinGW BenchmarkMergeLinkerFlags 540.500 ns/op -21.4 ns/op / -3.8% (better)
Windows MinGW BenchmarkChannelBuffered 39.280 ns/op -0.37 ns/op / -0.9% (better)
Windows MinGW BenchmarkChannelHandoff 1011 ns/op +70.1 ns/op / +7.5% (worse)
Windows MinGW BenchmarkDefer 63.390 ns/op -0.07 ns/op / -0.1% (better)
Windows MinGW BenchmarkDirectCall 2.173 ns/op +0.006 ns/op / +0.3% (worse)
Windows MinGW BenchmarkGlobalRead 1.870 ns/op +0.002 ns/op / +0.1% (worse)
Windows MinGW BenchmarkGlobalWrite 2.456 ns/op -0.001 ns/op / -0.0407% (better)
Windows MinGW BenchmarkGoroutine 82032 ns/op -3359 ns/op / -3.9% (better)
Windows MinGW BenchmarkInterfaceCall 9.380 ns/op +0.043 ns/op / +0.5% (worse)
Windows MinGW BenchmarkRuntimeGetG 2.177 ns/op -0.009 ns/op / -0.4% (better)
Windows MinGW 386 BenchmarkLookupPCRandom 26.500 ns/op -0.02 ns/op / -0.1% (better)
Windows MinGW 386 BenchmarkMergeCompilerFlags 755.700 ns/op -4.6 ns/op / -0.6% (better)
Windows MinGW 386 BenchmarkMergeLinkerFlags 697.100 ns/op +2.2 ns/op / +0.3% (worse)
Windows MinGW 386 BenchmarkChannelBuffered 43.030 ns/op +0.14 ns/op / +0.3% (worse)
Windows MinGW 386 BenchmarkChannelHandoff 1029 ns/op +14 ns/op / +1.4% (worse)
Windows MinGW 386 BenchmarkDefer 42.140 ns/op -1.83 ns/op / -4.2% (better)
Windows MinGW 386 BenchmarkDirectCall 1.547 ns/op -0.001 ns/op / -0.1% (better)
Windows MinGW 386 BenchmarkGlobalRead 1.550 ns/op +0.001 ns/op / +0.1% (worse)
Windows MinGW 386 BenchmarkGlobalWrite 7.784 ns/op +0.001 ns/op / +0.01285% (worse)
Windows MinGW 386 BenchmarkGoroutine 85437 ns/op -1358 ns/op / -1.6% (better)
Windows MinGW 386 BenchmarkInterfaceCall 9.611 ns/op +0.016 ns/op / +0.2% (worse)
Windows MinGW 386 BenchmarkRuntimeGetG 2.166 ns/op -0.002 ns/op / -0.1% (better)
Windows MinGW ARM64 BenchmarkLookupPCRandom 12.140 ns/op +0.08 ns/op / +0.7% (worse)
Windows MinGW ARM64 BenchmarkMergeCompilerFlags 566.700 ns/op -7.6 ns/op / -1.3% (better)
Windows MinGW ARM64 BenchmarkMergeLinkerFlags 531.600 ns/op -7.4 ns/op / -1.4% (better)
Windows MinGW ARM64 BenchmarkChannelBuffered 47.030 ns/op +3.34 ns/op / +7.6% (worse)
Windows MinGW ARM64 BenchmarkChannelHandoff 2575 ns/op -44 ns/op / -1.7% (better)
Windows MinGW ARM64 BenchmarkDefer 52.210 ns/op -0.3 ns/op / -0.6% (better)
Windows MinGW ARM64 BenchmarkDirectCall 0.593 ns/op +0.003 ns/op / +0.5% (worse)
Windows MinGW ARM64 BenchmarkGlobalRead 0.666 ns/op -0.0007 ns/op / -0.1% (better)
Windows MinGW ARM64 BenchmarkGlobalWrite 0.589 ns/op 0 ns/op / +0.0%
Windows MinGW ARM64 BenchmarkGoroutine 53687 ns/op -1206 ns/op / -2.2% (better)
Windows MinGW ARM64 BenchmarkInterfaceCall 4.736 ns/op +0.01 ns/op / +0.2% (worse)
Windows MinGW ARM64 BenchmarkRuntimeGetG 1.805 ns/op +0.002 ns/op / +0.1% (worse)
Windows MSVC BenchmarkLookupPCRandom 12.930 ns/op -0.19 ns/op / -1.4% (better)
Windows MSVC BenchmarkMergeCompilerFlags 659.900 ns/op +11.9 ns/op / +1.8% (worse)
Windows MSVC BenchmarkMergeLinkerFlags 567.900 ns/op -7.5 ns/op / -1.3% (better)
Windows MSVC BenchmarkChannelBuffered 36.070 ns/op -0.26 ns/op / -0.7% (better)
Windows MSVC BenchmarkChannelHandoff 1171 ns/op +20 ns/op / +1.7% (worse)
Windows MSVC BenchmarkDefer 54.500 ns/op -0.49 ns/op / -0.9% (better)
Windows MSVC BenchmarkDirectCall 1.549 ns/op +0.001 ns/op / +0.1% (worse)
Windows MSVC BenchmarkGlobalRead 1.547 ns/op 0 ns/op / +0.0%
Windows MSVC BenchmarkGlobalWrite 2.475 ns/op +0.004 ns/op / +0.2% (worse)
Windows MSVC BenchmarkGoroutine 83151 ns/op +6952 ns/op / +9.1% (worse)
Windows MSVC BenchmarkInterfaceCall 9.305 ns/op -0.029 ns/op / -0.3% (better)
Windows MSVC BenchmarkRuntimeGetG 2.169 ns/op -0.004 ns/op / -0.2% (better)
Windows MSVC 386 BenchmarkLookupPCRandom 71.830 ns/op -0.02 ns/op / -0.02784% (better)
Windows MSVC 386 BenchmarkMergeCompilerFlags 762.100 ns/op -4.6 ns/op / -0.6% (better)
Windows MSVC 386 BenchmarkMergeLinkerFlags 752.900 ns/op +3.2 ns/op / +0.4% (worse)
Windows MSVC 386 BenchmarkChannelBuffered 66.420 ns/op +0.99 ns/op / +1.5% (worse)
Windows MSVC 386 BenchmarkChannelHandoff 1701 ns/op -815 ns/op / -32.4% (better)
Windows MSVC 386 BenchmarkDefer 53.290 ns/op +3.44 ns/op / +6.9% (worse)
Windows MSVC 386 BenchmarkDirectCall 1.062 ns/op -0.051 ns/op / -4.6% (better)
Windows MSVC 386 BenchmarkGlobalRead 1.053 ns/op +0.032 ns/op / +3.1% (worse)
Windows MSVC 386 BenchmarkGlobalWrite 17.720 ns/op +0.19 ns/op / +1.1% (worse)
Windows MSVC 386 BenchmarkGoroutine 86601 ns/op -1511 ns/op / -1.7% (better)
Windows MSVC 386 BenchmarkInterfaceCall 6.367 ns/op +0.166 ns/op / +2.7% (worse)
Windows MSVC 386 BenchmarkRuntimeGetG 1.369 ns/op +0.004 ns/op / +0.3% (worse)
Windows MSVC ARM64 BenchmarkLookupPCRandom 12.020 ns/op -0.03 ns/op / -0.2% (better)
Windows MSVC ARM64 BenchmarkMergeCompilerFlags 578.800 ns/op +1.8 ns/op / +0.3% (worse)
Windows MSVC ARM64 BenchmarkMergeLinkerFlags 548.300 ns/op +6 ns/op / +1.1% (worse)
Windows MSVC ARM64 BenchmarkChannelBuffered 45.590 ns/op +1.78 ns/op / +4.1% (worse)
Windows MSVC ARM64 BenchmarkChannelHandoff 2643 ns/op +234 ns/op / +9.7% (worse)
Windows MSVC ARM64 BenchmarkDefer 61.270 ns/op -3.94 ns/op / -6.0% (better)
Windows MSVC ARM64 BenchmarkDirectCall 0.589 ns/op -0.0009 ns/op / -0.2% (better)
Windows MSVC ARM64 BenchmarkGlobalRead 0.666 ns/op -0.0019 ns/op / -0.3% (better)
Windows MSVC ARM64 BenchmarkGlobalWrite 3.760 ns/op 0 ns/op / +0.0%
Windows MSVC ARM64 BenchmarkGoroutine 54746 ns/op +1156 ns/op / +2.2% (worse)
Windows MSVC ARM64 BenchmarkInterfaceCall 4.726 ns/op -0.004 ns/op / -0.1% (better)
Windows MSVC ARM64 BenchmarkRuntimeGetG 1.804 ns/op +0.002 ns/op / +0.1% (worse)

Timer runtime benchmarks

Platform Operation and runtime ns/op vs base
Linux AfterFuncZeroDelivery/Go 896.600 ns/op -3.3 ns/op / -0.4% (better)
Linux AfterFuncZeroDelivery/LLGo 39396 ns/op +7172 ns/op / +22.3% (worse)
Linux CreateStop/Go 289.500 ns/op -0.1 ns/op / -0.03453% (better)
Linux CreateStop/LLGo 1922 ns/op +538 ns/op / +38.9% (worse)
Linux RearmStopped/Go 114.600 ns/op -1.3 ns/op / -1.1% (better)
Linux RearmStopped/LLGo 1307 ns/op +129 ns/op / +11.0% (worse)
Linux ResetActive/Go 67.630 ns/op -1.07 ns/op / -1.6% (better)
Linux ResetActive/LLGo 736.800 ns/op +50.2 ns/op / +7.3% (worse)
Linux ResetHeap1024/Go 67.020 ns/op -0.08 ns/op / -0.1% (better)
Linux ResetHeap1024/LLGo 199.400 ns/op +1 ns/op / +0.5% (worse)
macOS AfterFuncZeroDelivery/Go 571.600 ns/op +70.3 ns/op / +14.0% (worse)
macOS AfterFuncZeroDelivery/LLGo 93341 ns/op +8057 ns/op / +9.4% (worse)
macOS CreateStop/Go 145.200 ns/op -49.5 ns/op / -25.4% (better)
macOS CreateStop/LLGo 627.300 ns/op -419.7 ns/op / -40.1% (better)
macOS RearmStopped/Go 70.210 ns/op -10.94 ns/op / -13.5% (better)
macOS RearmStopped/LLGo 375.700 ns/op +28.4 ns/op / +8.2% (worse)
macOS ResetActive/Go 46.340 ns/op -17.26 ns/op / -27.1% (better)
macOS ResetActive/LLGo 154.800 ns/op +3.2 ns/op / +2.1% (worse)
macOS ResetHeap1024/Go 52.750 ns/op +4.63 ns/op / +9.6% (worse)
macOS ResetHeap1024/LLGo 114.600 ns/op +20.75 ns/op / +22.1% (worse)
Windows MinGW AfterFuncZeroDelivery/Go 549.300 ns/op -10.1 ns/op / -1.8% (better)
Windows MinGW AfterFuncZeroDelivery/LLGo 166308 ns/op +3983 ns/op / +2.5% (worse)
Windows MinGW CreateStop/Go 116 ns/op -8.2 ns/op / -6.6% (better)
Windows MinGW CreateStop/LLGo 493.100 ns/op -27 ns/op / -5.2% (better)
Windows MinGW RearmStopped/Go 31.860 ns/op +0.1 ns/op / +0.3% (worse)
Windows MinGW RearmStopped/LLGo 301.200 ns/op -5.9 ns/op / -1.9% (better)
Windows MinGW ResetActive/Go 20.510 ns/op -0.08 ns/op / -0.4% (better)
Windows MinGW ResetActive/LLGo 167.400 ns/op -4.4 ns/op / -2.6% (better)
Windows MinGW ResetHeap1024/Go 20.850 ns/op +0.2 ns/op / +1.0% (worse)
Windows MinGW ResetHeap1024/LLGo 138.700 ns/op -1.4 ns/op / -1.0% (better)
Windows MinGW 386 AfterFuncZeroDelivery/Go 950.300 ns/op -11.7 ns/op / -1.2% (better)
Windows MinGW 386 AfterFuncZeroDelivery/LLGo 191757 ns/op +2150 ns/op / +1.1% (worse)
Windows MinGW 386 CreateStop/Go 190.700 ns/op +0.4 ns/op / +0.2% (worse)
Windows MinGW 386 CreateStop/LLGo 2083 ns/op +28 ns/op / +1.4% (worse)
Windows MinGW 386 RearmStopped/Go 63.240 ns/op +0.1 ns/op / +0.2% (worse)
Windows MinGW 386 RearmStopped/LLGo 354.800 ns/op -0.7 ns/op / -0.2% (better)
Windows MinGW 386 ResetActive/Go 38.890 ns/op -0.22 ns/op / -0.6% (better)
Windows MinGW 386 ResetActive/LLGo 1053 ns/op +38 ns/op / +3.7% (worse)
Windows MinGW 386 ResetHeap1024/Go 39.390 ns/op +0.04 ns/op / +0.1% (worse)
Windows MinGW 386 ResetHeap1024/LLGo 193.600 ns/op -0.4 ns/op / -0.2% (better)
Windows MinGW ARM64 AfterFuncZeroDelivery/Go 678.100 ns/op +0.2 ns/op / +0.0295% (worse)
Windows MinGW ARM64 AfterFuncZeroDelivery/LLGo 125082 ns/op +2397 ns/op / +2.0% (worse)
Windows MinGW ARM64 CreateStop/Go 199.400 ns/op +2.6 ns/op / +1.3% (worse)
Windows MinGW ARM64 CreateStop/LLGo 397.900 ns/op +4.1 ns/op / +1.0% (worse)
Windows MinGW ARM64 RearmStopped/Go 70.600 ns/op -0.22 ns/op / -0.3% (better)
Windows MinGW ARM64 RearmStopped/LLGo 283.100 ns/op +4.5 ns/op / +1.6% (worse)
Windows MinGW ARM64 ResetActive/Go 30.850 ns/op -0.18 ns/op / -0.6% (better)
Windows MinGW ARM64 ResetActive/LLGo 121.300 ns/op -3.7 ns/op / -3.0% (better)
Windows MinGW ARM64 ResetHeap1024/Go 31.020 ns/op -0.17 ns/op / -0.5% (better)
Windows MinGW ARM64 ResetHeap1024/LLGo 137.400 ns/op -0.3 ns/op / -0.2% (better)
Windows MSVC AfterFuncZeroDelivery/Go 554.100 ns/op -6 ns/op / -1.1% (better)
Windows MSVC AfterFuncZeroDelivery/LLGo 151949 ns/op -3504 ns/op / -2.3% (better)
Windows MSVC CreateStop/Go 115.700 ns/op +0.3 ns/op / +0.3% (worse)
Windows MSVC CreateStop/LLGo 435.900 ns/op -40.5 ns/op / -8.5% (better)
Windows MSVC RearmStopped/Go 31.680 ns/op +0.08 ns/op / +0.3% (worse)
Windows MSVC RearmStopped/LLGo 293 ns/op -0.6 ns/op / -0.2% (better)
Windows MSVC ResetActive/Go 20.150 ns/op -1 ns/op / -4.7% (better)
Windows MSVC ResetActive/LLGo 153.600 ns/op +6.9 ns/op / +4.7% (worse)
Windows MSVC ResetHeap1024/Go 20.530 ns/op -1.09 ns/op / -5.0% (better)
Windows MSVC ResetHeap1024/LLGo 135.900 ns/op -1.1 ns/op / -0.8% (better)
Windows MSVC 386 AfterFuncZeroDelivery/Go 1042 ns/op +3 ns/op / +0.3% (worse)
Windows MSVC 386 AfterFuncZeroDelivery/LLGo 388397 ns/op +3003 ns/op / +0.8% (worse)
Windows MSVC 386 CreateStop/Go 264.400 ns/op +1.9 ns/op / +0.7% (worse)
Windows MSVC 386 CreateStop/LLGo 66525 ns/op -3790 ns/op / -5.4% (better)
Windows MSVC 386 RearmStopped/Go 96.180 ns/op +0.43 ns/op / +0.4% (worse)
Windows MSVC 386 RearmStopped/LLGo 395.200 ns/op -8.4 ns/op / -2.1% (better)
Windows MSVC 386 ResetActive/Go 46.540 ns/op +0.27 ns/op / +0.6% (worse)
Windows MSVC 386 ResetActive/LLGo 342.600 ns/op +29.2 ns/op / +9.3% (worse)
Windows MSVC 386 ResetHeap1024/Go 46.770 ns/op +0.25 ns/op / +0.5% (worse)
Windows MSVC 386 ResetHeap1024/LLGo 174.400 ns/op -1.8 ns/op / -1.0% (better)
Windows MSVC ARM64 AfterFuncZeroDelivery/Go 685.800 ns/op +14 ns/op / +2.1% (worse)
Windows MSVC ARM64 AfterFuncZeroDelivery/LLGo 138038 ns/op +10429 ns/op / +8.2% (worse)
Windows MSVC ARM64 CreateStop/Go 215 ns/op +19.3 ns/op / +9.9% (worse)
Windows MSVC ARM64 CreateStop/LLGo 409.900 ns/op -20.6 ns/op / -4.8% (better)
Windows MSVC ARM64 RearmStopped/Go 70.610 ns/op +0.2 ns/op / +0.3% (worse)
Windows MSVC ARM64 RearmStopped/LLGo 296.300 ns/op -5.8 ns/op / -1.9% (better)
Windows MSVC ARM64 ResetActive/Go 31.010 ns/op 0 ns/op / +0.0%
Windows MSVC ARM64 ResetActive/LLGo 130.800 ns/op -4.3 ns/op / -3.2% (better)
Windows MSVC ARM64 ResetHeap1024/Go 31.080 ns/op +0.14 ns/op / +0.5% (worse)
Windows MSVC ARM64 ResetHeap1024/LLGo 142.600 ns/op -1.2 ns/op / -0.8% (better)

Compared with 714e8c6eff9f measured in the same runner job.

@github-actions

github-actions Bot commented Sep 3, 2026 •

Copy link
Copy Markdown

LLGo WebAssembly build benchmarks

052e23226d90 | workflow run | long-term charts

WebAssembly output sizes

Profile and compiler Wasm module vs base Generated JS glue vs base
ec32/LLGo 70828 B 0 B / +0.0% 70588 B 0 B / +0.0%
ec64/LLGo 75144 B 0 B / +0.0% 73884 B 0 B / +0.0%
js/Go 1895533 B 0 B / +0.0% 0 B 0 B / 0.0%
js/LLGo 65334 B 0 B / +0.0% 68499 B 0 B / +0.0%
wasip1/Go 1909947 B 0 B / +0.0% 0 B 0 B / 0.0%
wasip1/LLGo 71656 B 0 B / +0.0% 0 B 0 B / 0.0%
wc32/LLGo 74839 B 0 B / +0.0% 0 B 0 B / 0.0%

LLGo WebAssembly build measurements

Profile Build vs base
ec32 4.147 s -515.8 us / -0.01244% (better)
ec64 3.814 s +19.77 ms / +0.5% (worse)
js 4.148 s -12.7 ms / -0.3% (better)
wasip1 2.851 s -61.49 ms / -2.1% (better)
wc32 2.755 s -4.087 ms / -0.1% (better)

Compared with 714e8c6eff9f measured in the same runner job.

@zhouguangyuan0718
zhouguangyuan0718 force-pushed the codex/llvm22-main-20260901 branch 3 times, most recently from 720c60b to 2d37a57 Compare September 5, 2026 03:38
@zhouguangyuan0718
zhouguangyuan0718 force-pushed the codex/llvm22-main-20260901 branch from 92bca18 to 7f9f06b Compare September 5, 2026 11:07
@zhouguangyuan0718
zhouguangyuan0718 marked this pull request as ready for review September 5, 2026 11:10

@fennoai fennoai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review: LLVM 19 → LLVM 22 upgrade

Overall this is a well-structured toolchain upgrade. The compiled-library cache-key refactor (keying on compiler version + codegen flags), the streaming SHA256 verification of downloaded ESP Clang archives (fail-closed on a missing checksum), and the dcepass switch to IsStructOpaque() are all solid, and each is backed by targeted tests. No correctness or performance blockers found.

A few points below, plus one pre-existing security note surfaced for follow-up (not introduced by this PR):

  • Pre-existing zip-slip gap in extractZip (internal/crosscompile/fetch.go). Unlike extractTarGz, extractZip joins the archive-controlled entry name into the destination with no containment check, and it's reachable via the unauthenticated picolibc .zip download (no checksum on that path). Out of this PR's diff, so not blocking — but worth mirroring the tar guard (reject ../absolute names, require filepath.Clean(dest)+sep prefix) in a follow-up now that the codebase relies on archive integrity elsewhere.

Verified as correct: the new -gnu linux triple leaves ARM on -gnueabihf; ESP Clang checksum enforcement cannot reach extraction with an empty hash (map-miss errors out, all five entries populated); the per-build clang --version probe runs once per UseTarget, not in any hot path.

Comment thread README.md Outdated
Comment thread internal/crosscompile/libc.go Outdated
@xushiwei
xushiwei merged commit bf3071f into xgo-dev:main Sep 5, 2026
68 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants