23.1.2.10

LLVM 23.1.2 with eight more patches, 0010 to 0017, and 0004 refreshed (patches/), built by xclang 23.1.2.6 (build run). The assets are as in 23.1.2.9: the toolchain archives are 86 to 93 MB, 3 to 5 MB more, with the musl targets and the MSVC targets' libc++ added; the libclang archives are the same size.

Breaking: libc++ is the C++ library of the MSVC targets

• x86_64-pc-windows-msvc and aarch64-pc-windows-msvc build with xclang's libc++, as every other target does, import std included; until 23.1.2.9 their C++ library was Microsoft's STL. Code that passes C++ types to or from libraries built with MSVC (or with the STL) needs the STL's ABI: -stdlib=platform selects the STL again (clang-cl: /clang:-stdlib=platform, CMake: -DXCLANG_MSVC_STL=ON, Bazel: --features=msvc_stl). C interfaces are not affected (MSVC targets, libc++ and the STL).
• libc++ is static, on Microsoft's vcruntime (exceptions, RTTI, operator new) and UCRT, with the hybrid CRT as before: a program still loads only Windows' DLLs. One build serves every C runtime (/MT, /MD, /MTd, /MDd), and lld-link finds it by itself in lib/clang/23/lib/windows (libc++-<arch>.lib, named by libc++'s headers), also when it links without clang. For x64 there is its ASan build too.
• clang's default standard for MSVC targets stays C++14, where libc++ has none of the C++17 library the STL offers early (std::is_integral_v): build with -std=c++17 or later.
• The config files define _STATIC_INLINE_UCRT_FUNCTIONS=0, MSVC 19.50's default, so a module can export UCRT's inline functions (ctime, ...).
• Patches: 0015, clang's MSVC toolchain takes -stdlib=libc++ and -stdlib=platform; 0016, libc++ on vcruntime no longer defines std::nothrow a second time beside the C runtime's, and has std::set_new_handler and std::get_new_handler; 0011, clang-cl does not report a config file's /clang: options unused.

musl targets

• x86_64-unknown-linux-musl and aarch64-unknown-linux-musl, in every toolchain archive: static programs with no program interpreter and no shared library, which take nothing from the system they run on (musl targets). musl 1.2.6 with the patches of its security advisories and Linux 6.18's UAPI headers, built by xclang; libc++, libc++abi, libunwind, compiler-rt and import std as for the other Linux targets; of the sanitizers UBSan. -static by default, -static-pie on request. CMake (XCLANG_TARGET), Bazel (@xclang//platforms:<arch>-unknown-linux-musl) and cargo (Rust's musl targets) build them. They add 0.6 to 2.1 MB to an archive, 42 MB unpacked.

Bazel: the MSVC targets, and macOS from Linux and Windows

• The root module accepts the vendor's license with xclang.windows_sdk(accept_license = True) and xclang.macos_sdk(accept_license = True), and the module fetches the SDK when a build first needs it, into Bazel's repository cache and output base. The platforms @xclang//platforms:x86_64-pc-windows-msvc and aarch64-pc-windows-msvc (C library @xclang//platforms/libc:msvc) have the features generate_pdb_file, dynamic_link_msvcrt, debug_msvcrt, msvc_stl, ubsan and, for x64, asan with the ASan libc++. The macOS targets make their dSYM on every host (Bazel).
• An optimized macOS program exports nothing (the no_exported_symbols feature, on by default), and a C++20 module interface embeds its sources (modules_embed_all_files, on by default: -c opt -g builds of module partitions found no source in the sandbox).
• xclang sdk packages macos|windows [--json]: what xclang sdk fetch downloads, for a build system that downloads it itself.

Crash traces

• 0010: crash stack traces on arm64 Windows go past the frames of system DLLs, which sign their return addresses, in clang, lld and tools on libclang (llvm/llvm-project#229371).
• macOS: a crash trace of the toolchain's clang or lld no longer names its frames after unrelated functions: llvm exports nothing and keeps no symbols, and its frames are addresses, as on Linux and Windows.

Fixes

• 0012: on a Windows host without a fetched SDK, clang links MSVC targets with xclang's compiler-rt ahead of Visual Studio's own clang_rt.*.lib: __int128 division, UBSan and libFuzzer link.
• 0013: the pc spellings of the Linux and MinGW targets (--target=x86_64-pc-linux-gnu, x86_64-pc-windows-gnu) find compiler-rt and link.
• 0014: COFF objects for MinGW targets have no compile time in their header again (llvm/llvm-project#222099, upstream's fix).
• 0017: lld-link lays out a program the same way on every link; with a call graph profile, static functions of one name in several objects moved between links.
• clang --version names LLVM's release commit, and a rebuild of a revision with its profile gives the same archives again, but for the Windows hosts' llvm.exe, which is the same bytes only once the bootstrap compiler carries 0017 (reproducible builds).
• The repository's layout: the build pipeline is under toolchain/, the Bazel module and conda scripts in packages/; what a project takes from the repository has not moved (packages/bazel, packages/cmake).

23.1.2.9

LLVM 23.1.2 with the same patches as 23.1.2.8 (patches/): a repack of 23.1.2.8. The compiler and runtimes are 23.1.2.8's, the same bytes, which are 23.1.2.7's, from its build run: every program, library and header in the archives, and the profile. Only the packaging differs: the config files of the MSVC targets (and the new bin/<target>-sdk.cfg they read), bin/xclang, the CMake package in lib/cmake/xclang, and share/licenses/README.md and sbom.spdx.json. Every archive was compared with 23.1.2.8's, file by file (run). The assets are as in 23.1.2.8.

Changes

• MSVC targets without a fetched SDK: the config files load. Every compile for *-pc-windows-msvc stopped at loading them, also one that needs no SDK (-ffreestanding, a tool's queries of the compiler, such as clice's). On Windows, clang and clang-cl then find Visual Studio as upstream clang does, and so does the CMake package, with the std module of its STL; on Linux and macOS a compile stops at the first header of Microsoft's it includes ('stdio.h' file not found). A fetched SDK still comes first everywhere: the config files read the SDK in use through bin/<target>-sdk.cfg (and -clang-cl-sdk.cfg), which xclang sdk fetch, use and remove write, for the architectures it has.
• Bazel on Linux and macOS: a library's objects are linked as they are, between --start-lib and --end-lib, not from its archive. On macOS, objects of one name in a library (a C++20 module's partition foo.cppm and implementation unit foo.cpp, or a/foo.cpp and b/foo.cpp) had the DWARF of only one of them in the dSYM: dsymutil tells archive members apart by name and modification time, and Bazel's are all 0.
• The newest release without naming it: xclang = "*" in a pixi workspace, the toolchain and libclang from releases/latest, and GIT_TAG latest for CMake's FetchContent (installing, versions).

23.1.2.8

LLVM 23.1.2 with the same patches as 23.1.2.7 (patches/): a repack of 23.1.2.7. The compiler and runtimes are 23.1.2.7's, the same bytes, from its build run: every program, library and header in the archives, and the profile. Only what names the release differs: bin/xclang and lib/cmake/xclang/xclang-config-version.cmake in each toolchain archive, and share/licenses/README.md and sbom.spdx.json in every archive. Every archive was compared with 23.1.2.7's, file by file (run). The assets are as in 23.1.2.7.

Changes

• Bazel on macOS: a C++20 module unit and its dependency scan get the defines of the libraries it depends on, as on Linux and Windows. They got none: rules_cc leaves macOS the legacy defines feature, which does not cover the module actions.

23.1.2.7

LLVM 23.1.2 with the same patches as 23.1.2.6 (patches/), built by xclang 23.1.2.6. The assets are as in 23.1.2.6, smaller: the toolchain archives are 86 to 94 MB, 8 to 9 MB less for the Linux and Windows hosts and 31 to 35 MB less for the macOS ones (730 MB unpacked for Linux x64, was 845; 710 for macOS arm64, was 946), with bin/xclang and the MSVC targets' compiler-rt added; each libclang archive is about 2 MB less.

The xclang command, MSVC targets, macOS from any host

• The xclang command in every toolchain archive, bin/xclang (xclang.exe): xclang sdk fetch windows --accept-license and xclang sdk fetch macos --accept-license fetch Microsoft's and Apple's SDKs from the vendors into the toolchain's sdk/; xclang sdk list, use and remove manage them (the xclang command). It loads nothing but its OS's libraries (glibc 2.17 at most on Linux).
• MSVC targets, x86_64-pc-windows-msvc and aarch64-pc-windows-msvc, from every host, against the fetched CRT, STL and Windows SDK, with config files for clang and clang-cl (MSVC targets). By default the hybrid CRT: the VC runtime and the STL linked statically, UCRT Windows' own DLL, so a program loads no vcruntime140.dll; the DLLs (/MD), all-static and the static debug CRT on request. compiler-rt for both in lib/clang/23/lib/windows: the builtins (named in every object, so __int128 division links), the profile runtime, UBSan, and for x64 AddressSanitizer (a DLL) and libFuzzer. A plain clang-cl and clang --target=<arch>-pc-windows-msvc now build with the fetched SDK, and without it stop and name sdk/windows, where they took an installed Visual Studio; --no-default-config looks for one as before. The SDK in use is sdk/windows, a link to the one fetched last (the SDK in use).
• CMake: XCLANG_TARGET=x86_64-pc-windows-msvc (or aarch64) builds with clang and clang++ and the hybrid CRT (CMAKE_MSVC_RUNTIME_LIBRARY MultiThreaded unless set); xclang::std is the STL's std and std.compat for them (CMake).
• macOS targets from Linux and Windows hosts: clang++ --target=arm64-apple-macos (or x86_64) builds against the macOS SDK that xclang sdk fetch macos --accept-license fetches into sdk/macos (macOS). On those hosts the macOS targets' config files begin with -isysroot <CFGDIR>/../sdk/macos: an -isysroot on the command line replaces it, and clang no longer reads SDKROOT there. On macOS hosts nothing changes. The programs are those of a Mac: xclang's libc++, ld64.lld's ad-hoc signature for arm64, dSYMs, universal programs by llvm-lipo, and the sanitizers' dylibs. xclang sdk fetch macos takes the macOS 27 SDK too.
• CMake: XCLANG_TARGET=aarch64-apple-darwin (or x86_64) on Linux and Windows hosts: CMAKE_SYSTEM_NAME Darwin, CMAKE_OSX_SYSROOT the one given, else SDKROOT, else the toolchain's sdk/macos (CMake).

The Bazel module builds neither yet (roadmap).

The archives

• License notices in every archive (the toolchain, libclang, the ASan libclang, the option tables): share/licenses/<component>/ holds each component's license and notice files, share/licenses/README.md says what each component is, its version, its license and where its source is, and share/licenses/sbom.spdx.json the same as an SPDX 2.3 document: LLVM and its runtimes, glibc 2.17, the kernel's UAPI headers and NSS's libfreebl3 of the Linux sysroots (with the conda-forge packages, CentOS 7 source RPMs and upstream releases they come from), mingw-w64 and winpthreads, zlib, zstd, and Rust's standard library and the crates of bin/xclang (layout).
• Reproducible archives: the same files make the same .tar.xz, whatever the machine, the time or the number of xz threads (sorted entries, the commit's time, no owner, xz in fixed blocks). Each host's archives were made twice, on two machines, and compared.
• Shared headers: libc++'s headers are in the archive once, in libc++/include/c++/v1, with each target's __config_site in libc++/include/<target>/c++/v1 (LLVM's per-target runtime layout, under a prefix of its own), and mingw-w64's headers, the same for x64 and arm64, once in mingw-w64/include; 155 MB less unpacked. The config files name them, so clang --target=... builds as before. A build that passes --no-default-config and its own --sysroot=$XCLANG/<target> adds them itself (layout).
• macOS archives carry no lib/libLTO.dylib (120 MB unpacked), as the Linux and Windows ones carry no LTO plugin for their system linkers: macOS targets link with ld64.lld, and -fuse-ld=ld still selects Apple's ld, for links without LTO.

Debug symbols

• xclang_debug_symbols (Bazel and CMake) runs llvm-gsymutil with one thread, so the same program makes the same GSYM file, about 1.4 times as slow; --num-threads=0 in gsymutil_args / GSYM_ARGS undoes it (debugging).
• Bazel: bazel run @xclang//bazel:llvm-gsymutil -- <absolute .gsym> --address=0x... reads a GSYM with the toolchain's llvm-gsymutil. debug_symbols.bzl asks for -g: -gline-tables-only gives a GSYM without functions.

Documentation

• docs.clice.io/xclang, from docs/en: a guide (what xclang is and when not to use it, why it is built the way it is, a quick start, installing, cross-compiling, comparisons, FAQ), the integrations, the features, a reference and the design, with how each claim is tested.
• examples/: the projects the docs show, built as written on a machine of every host from the published release's channels by examples.yml.

23.1.2.6

LLVM 23.1.2 with one more patch, built by xclang 23.1.2.5. The assets are as in 23.1.2.5; the libclang archives are larger (about 25 MB each, the ASan ones 14 MB), with every target's MC layer.

Patches

• 0009 (new): ld64.lld reads the .tbd stubs of the macOS 27 SDK (Xcode 27), which list arm64e.x1, so macOS programs link against it (release/23.x's backport of llvm/llvm-project#222721, in 23.1.3). The other patches are as in 23.1.2.5 (patches/).

Other changes

• CMake package (docs/cmake.md), in every toolchain archive as lib/cmake/xclang, and so in the conda package: find_package(xclang) gives xclang::std, libc++'s std and std.compat modules built for the build, so import std works without CMake's experimental switches (CMake 3.28, Ninja 1.11); xclang_add_std() makes one for other language options; toolchain.cmake makes the tree a build's toolchain, for any of its targets with XCLANG_TARGET. A build without xclang installed fetches this repository's tag with FetchContent, and packages/cmake/xclang.cmake downloads the host's toolchain, checked against the release's SHA256SUMS, into the user's cache.
• ThinLTO link cache: XCLANG_THINLTO_CACHE, an absolute directory, makes the links of libclang's bitcode after the first take seconds instead of minutes, with the same program. In Bazel, --repo_env=XCLANG_THINLTO_CACHE=<dir> (docs/bazel.md, with the .bazelrc and CI setup); in CMake, -DXCLANG_THINLTO_CACHE=<dir> (or the environment variable) before find_package(xclang) (docs/cmake.md).
• Bazel cross-compiling (docs/bazel.md): the module registers the host's toolchain for every target of its archive, and @xclang//platforms:<triple> (x86_64-w64-mingw32, aarch64-unknown-linux-gnu, ...) are platforms for them, with a C library constraint (@xclang//platforms/libc): bazel build --platforms=@xclang//platforms:x86_64-w64-mingw32 //... builds for Windows from Linux with nothing downloaded but the host's toolchain. The macOS targets build on macOS hosts only. @libclang, @libclang_asan and @xclang//bazel:std are the target platform's; a target's libclang is downloaded only by a build for it.
• Debug symbols for a program's release, by the toolchain's own dsymutil and llvm-gsymutil (names of llvm in every archive): GSYM for every target, the dSYM for macOS ones. Bazel: xclang_debug_symbols (@xclang//bazel:debug_symbols.bzl), and rules_cc's generate_dsym_file feature makes a macOS program's dSYM in its link, ThinLTO's code included (docs/bazel.md); CMake: xclang_debug_symbols(<target>) (docs/cmake.md).
• Bazel: debug information that holds wherever the build ran. Its paths are relative to the execution root (-ffile-compilation-dir=.; Mach-O debug maps with -oso_prefix), and PE programs have no link time, so a program is the same bytes from any sandbox or checkout; debuggers map . to the workspace's bazel-<workspace> (docs/bazel.md).
• Bazel: a program's .stripped is a release's, by the target's object format: ELF and COFF --strip-unneeded, Mach-O --strip-all, without the globals that misname local functions in macOS crash logs.
• Bazel: @libclang is the ASan build with --features=asan, libraries, headers and resource directory together; xclang_resource_dir lays the resource directory out in lib/clang next to a program's bin/ (docs/libclang.md).
• Bazel: the module loads archives without libc++'s ASan build (releases before 23.1.2.5) too.
• Bazel: the module is now under packages/bazel, next to the CMake package (packages/cmake) and the conda package's activation scripts (packages/conda). Its labels and the registry's archive are the same; a git_override of a commit needs strip_prefix = "packages/bazel".
• libclang: every target's MC layer (TargetInfo, MC descriptions, assembly parser, disassembler), not X86's only: a tool registers them all (InitializeAllTargetInfos(), InitializeAllTargetMCs(), InitializeAllAsmParsers(), InitializeAllDisassemblers(), CMake's components of those names) and looks any target up by triple. Bazel: @libclang//:AllTargetsInfos, :AllTargetsDescs, :AllTargetsAsmParsers, :AllTargetsDisassemblers.
• libclang's ASan build is of every target, as the release, with the same headers and libraries.
• libclang: clang-tidy/clang-tidy-config.h, as clang-tidy's build generates it for xclang's configuration.
• libclang no longer has Sema's private headers (TreeTransform.h, TypeLocBuilder.h, CoroutineStmtBuilder.h).
• The README keeps to what xclang is and where it is going; the rest is in docs/, and the roadmap has the targets, their tiers and where each stands.

23.1.2.5

LLVM 23.1.2 with two more patches, built by xclang 23.1.2.3. The assets are as in 23.1.2.3.

Patches

The changes in patches/, each with a README on what it fixes and where it stands upstream:

• 0007 (new): ld64.lld keeps a function's unwind entry when an empty section's symbol shares its address, so ThinLTO programs compiled and linked by one clang command catch their exceptions on arm64 macOS (llvm/llvm-project#225055).
• 0008 (new): clang -E writes a raw string literal's CRLF line breaks as \n and counts its lines, so compiling its output gives the same strings and line numbers (llvm/llvm-project#122070).
• 0005 dropped: libc++'s ASan build replaces it.

Other changes

• Bazel module (Bazel 9, rules_cc 0.2.25), published to the clice registry, bazel.clice.io: the host's toolchain by its sha256 as a hermetic C++ toolchain, @xclang//bazel:std for import std, sanitizer features, libclang (@libclang, @libclang_asan) with the link interfaces of its CMake packages, and the option tables (@llvm_option_inc) (README).
• macOS targets link with ld64.lld on macOS too; before, only Linux and Windows hosts did, and macOS used the system's ld. -fuse-ld=ld still selects it, with xclang's libLTO.dylib.
• libc++'s ASan build for the Linux and macOS targets, in lib/asan of the target directory (usr/lib/asan on Linux): an ASan build compiles and links with it (-isystem <asan>/include, -nostdlib++ <asan>/libc++.a), and gets std::string's container checks without false container-overflow reports. The ASan libclang is built with it.

23.1.2.4

LLVM 23.1.2 again, built by xclang 23.1.2.3. The assets and the patches are as in 23.1.2.3.

Changes

• Windows: clang++.exe and the other names of llvm.exe now start it inside their kill-on-close job from the moment it is created. Before, a launcher killed while starting it (a build tool's timeout, or its parent's job closing) could leave llvm.exe suspended forever, holding its working directory and handles.

23.1.2.3

LLVM 23.1.2 with xclang's first patches, built by xclang 23.1.2.2. The assets are as in 23.1.2.1.

Patches

The changes in patches/, each with a README on what it fixes and where it stands upstream:

• 0001: signature help in a class template whose parameter pack follows another parameter no longer crashes clang (clice-io/clice#701, llvm/llvm-project#226788).
• 0002, 0003: member-access completion hands the consumer an unresolved base too, and the base expression as written, for tools that resolve dependent types themselves.
• 0004: a MinGW-built clang, and every tool built on its libraries, finds Visual Studio 2017 and later through the Setup API, as an MSVC-built clang does (clice-io/clice#714, llvm/llvm-project#226794).
• 0005: an ASan program no longer shares libc++'s internal functions with the uninstrumented libc++.a, which gave false container-overflow reports (llvm/llvm-project#226789).
• 0006: std::format_to into a string, vector or deque no longer writes past its stack buffer after output whose length is a multiple of 256 (llvm/llvm-project#154670, llvm/llvm-project#226791).

Other changes

• A macOS target on a Linux or Windows host links with ld64.lld again; 23.1.2.2 took the system linker there.
• clang-cl no longer reads the host target's config file, and no longer warns about every option in it.
• Config files for <arch>-pc-linux-gnu and <arch>-apple-macosx too.
• The libclang archives carry compiler-rt's headers as well, like the toolchain.

23.1.2.2

LLVM 23.1.2 again, this time built by xclang 23.1.2.1 rather than by LLVM's release. The assets and everything else are as in 23.1.2.1.

Changes

• compiler-rt's headers are back in clang's resource directory: <sanitizer/asan_interface.h>, <fuzzer/FuzzedDataProvider.h> and the rest. 23.1.2.1 did not have them.
• clang no longer has built-in defaults for the C++ library, runtimes and linker. The config files still choose libc++, compiler-rt, libunwind and lld, as before. Without them (--no-default-config, or libclang's driver inside a tool), clang behaves like upstream clang. For example, clice's in-process driver standing in for g++ now uses libstdc++ instead of libc++.

23.1.2.1

The first xclang release: LLVM 23.1.2, built with PGO and ThinLTO, for six hosts, each carrying every target. See the README (中文).

Assets

xclang-23.1.2.1-<host>.tar.xz	the toolchain, 80–116 MB: clang, lld and the LLVM binary tools as one llvm program, FileCheck, and the sysroots and runtimes of all six targets
libclang-23.1.2.1-<host>.tar.xz	the clang and LLVM static libraries (PGO + ThinLTO bitcode) and headers from the same build, for tools on clang; find_package(Clang) finds them
libclang-23.1.2.1-<host>-asan.tar.xz	the same, Debug with assertions and ASan (Linux x64, macOS arm64)
llvm-option-inc-23.1.2.1.tar.xz	the option tables of clang, lld, llvm-lib and llvm-dlltool
xclang-23.1.2.1.profdata	the PGO profile
SHA256SUMS

Hosts: x86_64-unknown-linux-gnu, aarch64-unknown-linux-gnu, x86_64-w64-mingw32, aarch64-w64-mingw32, aarch64-apple-darwin, x86_64-apple-darwin. The same six are the targets; clang++ --target=<triple> needs nothing else (macOS targets use Xcode's SDK).

In short

• Every host's clang and lld are linked statically against xclang's own libc++; the Linux toolchain needs glibc 2.17, the macOS one macOS 13.
• Programs link libc++, libc++abi, libunwind and compiler-rt statically. Linux targets: glibc 2.17 (-static works); Windows targets: mingw-w64 with UCRT; macOS targets: 13.0.
• compiler-rt: builtins with wide atomics, profile, and for Linux and macOS ASan, TSan, LSan, UBSan and libFuzzer.
• Build scripts written for GCC keep working: -latomic, -lgcc*, -lssp, -lstdc++, windres.
• Windows archives hold no symlinks: every name of llvm.exe is a small launcher.
• clang -### prints its cc1 job as ".../llvm" "clang" "-cc1" ...: a tool reading that output has to skip the tool name.

Limits: no -static-pie and -pg needs -no-pie (glibc 2.17), no OpenMP, no sanitizers for Windows targets, no clang-format/clang-tidy/clangd binaries; a standard exception crossing a shared-library boundary on Linux and macOS is caught only by catch (...).

Speed

Compile time against LLVM's own 23.1.2 build (median of three CI machines per host, lower is faster): macOS arm64 0.80–1.05×, Linux arm64 0.96–1.05×, Linux x64 1.01–1.11×. LLVM's Linux x64 clang is also BOLT-optimized; xclang's is not yet.

Checked

Each host's archives were tested on that host: C and C++ for every target (run where possible), import std, PCH, ThinLTO, the sanitizers and libFuzzer, -static, wide atomics, hardening flags, a version resource, and a libclang tool through find_package(Clang). clice (with this libclang, on all six hosts) and catter (Linux x64, Windows x64) were built with it; their tests pass but for what the test machines lacked (CUDA, GCC 14's <print>, clang-format).

Build: https://github.com/clice-io/xclang/actions/runs/36244824217 (toolchain from https://github.com/clice-io/xclang/actions/runs/36238500847).