Use the supplied Fuchsia SDK's version_history.json to deduce the
oldest API level still supported, and target that for toolchain
runtimes so they'll be runtime-compatible when linked into user
programs that target any SDK-supported API level.
Reverts llvm/llvm-project#192515
We have addressed the CFI related workflow by introducing a new
MD_callgraph and by disambiguating it from MD_type used for CFI.
This reverts commit 42eb7db188. This
reland 3fbb037d03 (#209922).
Under CMake 4+, calling add_library(... SHARED IMPORTED) on a target
platform that lacks dynamic linking support triggers a fatal error. This
becomes an issue when building LLVM and runtimes for baremetal targets
like armv6m-none-eabi. This patch adds the option
"LLVM_OMIT_EXPORTS_FROM_CONFIG" in LLVM. When used in sub builds like
LLVM runtimes, it makes CMake to skip including the LLVM and Clang
exports. This mitigates the CMake 4 errors on baremetal runtimes.
42eb7db188 originally
apply this flag on all runtimes build and causing issues on runtimes
like intel-sycl-gpu, amdgpu-offload-ubuntu-22-cmake-build-only.
This PR only set this flag when the target platform lacks shared library
support.
COMPILER_RT_INSTALL_LIBRARY_DIR must be CACHE STRING, not CACHE PATH: a
relative PATH-typed cache entry resolves against the runtimes sub-build
directory instead of CMAKE_INSTALL_PREFIX, misplacing sanitizer libs.
Replace the explicit COMPILER_RT_BUILD_* ON list with
COMPILER_RT_SANITIZERS_TO_BUILD=all, since those options already default
ON upstream and infeasible sanitizers self-exclude via their own
ALL_<X>_SUPPORTED_ARCH lists.
Add FORCE to the dylib overrides so they take effect after
hexagon-unknown-linux-musl-clang-dist.cmake has already cached them OFF.
Under CMake 4+, calling add_library(... SHARED IMPORTED) on a
target platform that lacks dynamic linking support triggers a fatal
error. This becomes an issue when building LLVM and runtimes for
baremetal targets like armv6m-none-eabi. This patch
adds the option "LLVM_OMIT_EXPORTS_FROM_CONFIG" in LLVM.
When used in sub builds like LLVM runtimes, it makes CMake to skip
including the LLVM and Clang exports. This mitigates the CMake 4
errors on baremetal runtimes.
The change broke the runtimes build for Android; see discussion on the
PR. There are fixes in progress, but let's revert to unbreak the tree
until all those are ready to land.
This reverts commit 00b2f81418 and the
follow-up commit 1008b485e4.
This adds a instrumentor-tools folder into compiler RT to showcase use
cases of the instrumentor. The initial example is a program that, via
instrumentation, counts the number of flops performed. Call and
intrinsic support will follow after #198042.
This is the second try with more CMake magic after
https://github.com/llvm/llvm-project/pull/205221 failed on some
platforms.
Partially developped by Claude (AI), tested and verified by me.
Compute the cmake system name from the target triple, rather
than passing through the host's. This is primarily to stop
forwarding OSX specific cmake variables.
This fixes build failures when trying to build gpu libc on mac
hosts. Previously it would fail on several issues, starting with
an unused argument -mmacos-version-min error, followed by other
errors caused by passing -isysroot.
Secondarily, restrict the cmake imported targets when cross compiling.
Without this, the amdgpu build prints many cmake warnings about the
target not supporting shared libraries.
Claude did most of the actual work, though it required quite a few
rounds of prodding to get it into the right place. In particular it
took care of handling all of the cmake platform recognized names from
the triple.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Fuchsia's default runtime environment prefers no-exceptions. Compiling
the C++ slice of ASan (asan_new_delete.cpp) with exceptions introduces
dependencies on EH symbols
(__cxa_begin_catch, etc.) in libclang_rt.asan.so. This causes link
failures when linking ASan-enabled binaries with noexcept libc++abi.
Explicitly disable COMPILER_RT_ASAN_ENABLE_EXCEPTIONS for Fuchsia
targets in the stage2 cache.
Adds and extends the
clang/cmake/caches/hexagon-unknown-linux-musl-clang* files to drive a
full install-distribution build: host tools, per-target builtins (Linux
and baremetal), and runtimes for hexagon-unknown-linux-musl.
Building with --fat-lto-objects was added in #140381 (cff9ae7a15). On
macOS the tests are failing when building release binaries with many
"The file was not recognized as a valid object file" errors, e.g.:
2026-01-16T12:54:26.0928880Z
/Users/runner/work/llvm-project/llvm-project/build/tools/clang/stage2-instrumented-bins/tools/clang/stage2-bins/_CPack_Packages/Darwin/TXZ/LLVM-22.1.0-rc1-macOS-ARM64/bin/llvm-strip:
error:
'/Users/runner/work/llvm-project/llvm-project/build/tools/clang/stage2-instrumented-bins/tools/clang/stage2-bins/_CPack_Packages/Darwin/TXZ/LLVM-22.1.0-rc1-macOS-ARM64/lib/libLLVMAArch64AsmParser.a(AArch64AsmParser.cpp.o)':
The file was not recognized as a valid object file
It's assuming bitcode is embedded in section .llvm.lto
(llvm/lib/Object/ObjectFile.cpp:80) but on MachO it's in
__LLVM,__bitcode (llvm/lib/Object/MachOObjectFile.cpp:2184)
llvm-bitcode-strip is a driver for the MachO bitcode_strip utility which
handles this. Use this instead.
Fixes#176398.
Assisted-by: codex
Reverts llvm/llvm-project#175677
We noticed using -fexperimental-call-graph-section with Control Flow
Integrity causes link failures in certain situations. Reverting this
change that sets the call graph section flag until we investigate the
root cause of the problem and handle it in the compiler well.
Dynamically depending on libxml2 results in various annoyances across
different linux distros for release artifacts. Specifically on fedora
and nixos the library has a different name than on debian, and on
arch-linux they tried to remove the old name entirely.
With this, enabled by default for releases, we don't sacrifice any
behavior changes, but no longer have these issues. For lld the binary
size impact is <1mb
This continues to use the shared libxml for lldb since otherwise
it requires linking ICU, which is off by default
macOS ignores this setting since libxml2 is part of the OS and stable
enough.
This mirrors what we do for zstd
Fixes https://github.com/llvm/llvm-project/issues/113696
Fixes https://github.com/llvm/llvm-project/issues/138225
Fixes
https://discourse.llvm.org/t/official-builds-without-libxml2-and-libtinfo/58169
Fuchsia toolchain includes runtime builds for several targets. This
patch adds `-fstack-sizes` and `-fexperimental-call-graph-section` flags
for all Fuchsia, baremetal runtimes built by Fuchsia stage2 cache file.
Add a config to document building compiler-rt for a baremetal RISCV
target. It works on a Linux host, but not a macOS host, due to CMake
issues.
Documenting building libcxx and libcxxabi for these targets is left to a
follow-up.
gRPC adds -pthread, which is incompatible with PCH without it. At some
point, we probably should generally switch from -lpthread to -pthread,
but until then, disable PCH for affected targets.
Fixes https://github.com/llvm/llvm-project/issues/184759.
Previously, transitively inherited calls to
`target_include_directories(foo SYSTEM ...)` were being squashed into a
flat list of includes, effectively stripping off `-isystem` and
unintentionally forwarding warnings from such dependencies.
To correctly propagate `SYSTEM` dependencies, use
`target_link_libraries` to forward the parent target's link dependencies
to the OBJECT library (similar to the `_static` flow below). Unlike a
flat `target_include_directories`, this lets CMake resolve transitive
SYSTEM include directories through the proper dependency chain.
Note that `target_link_libraries` on an OBJECT library propagates all
usage requirements, not just includes. This also brings in transitive
`INTERFACE_COMPILE_DEFINITIONS`, `INTERFACE_COMPILE_OPTIONS`, and
`INTERFACE_COMPILE_FEATURES`. This is arguably more correct, as the
OBJECT library compiles the same sources and should see the same flags.
The existing `target_include_directories` call is retained for include
directories set directly on the target (not through link dependencies).
CMake deduplicates include directories that appear through both paths.
Compile definitions and options may technically appear twice (once via
the OBJECT library, once via the consuming target), but duplicate `-D`
and flag entries are harmless in practice.
Also fix `clang_target_link_libraries` and `mlir_target_link_libraries`
to forward the link type (PUBLIC/PRIVATE/INTERFACE) to `obj.*` targets.
Previously the type keyword was silently dropped, resulting in plain-
signature `target_link_libraries` calls. This is now required because
the new keyword-signature call in `llvm_add_library` would otherwise
conflict (CMake requires all calls on a target to use the same
signature).
…83889)"
This reverts commit 2342db00ab.
Revert "[CMake] Propagate dependencies to OBJECT libraries in
`add_llvm_library` (#183541)"
This reverts commit e3c045415a.
Previously, transitively inherited calls to
`target_include_directories(foo SYSTEM ...)` were being squashed into a
flat list of includes, effectively stripping off `-isystem` and
unintentionally forwarding warnings from such dependencies.
To correctly propagate `SYSTEM` dependencies, use
`target_link_libraries` to forward the parent target's link dependencies
to the OBJECT library (similar to the `_static` flow below). Unlike a
flat `target_include_directories`, this lets CMake resolve transitive
SYSTEM include directories through the proper dependency chain.
Note that `target_link_libraries` on an OBJECT library propagates all
usage requirements, not just includes. This also brings in transitive
`INTERFACE_COMPILE_DEFINITIONS`, `INTERFACE_COMPILE_OPTIONS`, and
`INTERFACE_COMPILE_FEATURES`. This is arguably more correct, as the
OBJECT library compiles the same sources and should see the same flags.
The existing `target_include_directories` call is retained for include
directories set directly on the target (not through link dependencies).
CMake deduplicates include directories that appear through both paths.
Compile definitions and options may technically appear twice (once via
the OBJECT library, once via the consuming target), but duplicate `-D`
and flag entries should be harmless in practice.
Also fix `clang_target_link_libraries` and `mlir_target_link_libraries`
to forward the link type (PUBLIC/PRIVATE/INTERFACE) to `obj.*` targets.
Previously the type keyword was silently dropped, resulting in
plain-signature `target_link_libraries` calls. This is now required
because the new keyword-signature call in `llvm_add_library` would
otherwise conflict (CMake requires all calls on a target to use the same
signature).
The build incorrectly used `MSVC` to determine that we were building for
Windows (MS ABI). This prevents the use of the GNU driver for building
LLVM for Windows. Adjust the condition to `WIN32 AND NOT MINGW` to
correctly identify that we are building for Windows MS ABI.
This reapplies #149878
Remove all the CMake code for openmp standalone builds. Standalone
builds have been superseded by the runtimes default build (also
sometimes called the standalone runtimes build). The runtimes default
build can be thought of a standalone build with the standalone
boilerplate contained in <llvm-project>/runtimes/CMakeLists.txt. There
is no need for each runtime to contain the same boilerplate code again.
Builds still using the standalone build via
```sh
cmake -S <llvm-project>/openmp ...
```
can switch over to the runtimes default build using
```sh
cmake -S <llvm-project>/runtimes -DLLVM_ENABLE_RUNTIMES=openmp ...
```
Options that were valid for the standalone build are also valid for
default runtimes build, unless handled only in `if
(OPENMP_STANDALONE_BUILD)` regions.
The existence of both, standalone builds and runtime default builds,
easily leads to confusion such as fixed in #149871. A non-standalone
build does not mean that it is built as part of a bootstrapping-build of
LLVM inside the `runtimes/runtimes-bins` directory, nor does it mean
that the compiler is necessarily Clang. Some of the remaining code may
have been written with that assumption. However, the purpose of this
patch is to only remove the standalone build functionality.
Remove all the CMake code for openmp standalone builds. Standalone
builds have been superseded by the runtimes default build (also
sometimes called the standalone runtimes build). The runtimes default
build can be thought of a standalone build with the standalone
boilerplate contained in <llvm-project>/runtimes/CMakeLists.txt. There
is no need for each runtime to contain the same boilerplate code again.
Builds still using the standalone build via
```sh
cmake -S <llvm-project>/openmp ...
```
can switch over to the runtimes default build using
```sh
cmake -S <llvm-project>/runtimes -DLLVM_ENABLE_RUNTIMES=openmp ...
```
Options that were valid for the standalone build are also valid for
default runtimes build, unless handled only in
`if (OPENMP_STANDALONE_BUILD)` regions.
The existence of both, standalone builds and runtime default builds,
easily leads to confusion such as fixed in #149871. A non-standalone
build does not mean that it is built as part of a bootstrapping-build of
LLVM inside the `runtimes/runtimes-bins` directory, nor does it mean
that the compiler is necessarily Clang. Some of the remaining code may
have been written with that assumption. However, the purpose of this
patch is to only remove the standalone build functionality.
This cache file can be used to build a multi-target cross Windows/Linux
to ARM/Aarch64/etc. Linux toolchain.
[Replacement for CrossWinToARMLinux.cmake on the buildbot]
The toolchains take up much less space when we enable dylib, so let's
create an option to build them that way.
Also: TOOLCHAIN_ONLY was ineffective in
hexagon-unknown-linux-musl-clang-cross.cmake because cmake takes the
first setting from hexagon-unknown-linux-musl-clang.cmake with
precedence. FORCE it to fix that issue.
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
This change expands the stdio support on baremetal to support opaque
FILE*. This builds on top of the existing baremetal embedding API; we
treat the standard FILE* streams as pointers that point to the cookie
symbols which are a part of the embedding API. This also allows users to
define their own FILE* streams, but we don't (yet) support the API that
return FILE* such as fopen or fopencookie.
No other runtimes can yet be built for the arm-fuchsia target,
but this one can be. There is no OS-specific code in the arm
builtins needed for Fuchsia.
This was causing a build failure on Darwin and a test failure on Linux.
This config is not widely used or well tested, so I don't think the
potential and likely small performance gains and the portability from
this are worth the maintenance costs.
When building llvm from a subdirectory (like clspv does)
`CMAKE_BINARY_DIR` is at the top of the build directory.
When building runtimes (libclc for example), the build fails looking for
clang (through `find_package` looking at `LLVM_BINARY_DIR` with
`NO_DEFAULT_PATH` & `NO_CMAKE_FIND_ROOT_PATH`) because clang is not in
`LLVM_BINARY_DIR`.
Fix that issue by setting `clang_cmake_builddir` the same way we set
`llvm_cmake_builddir` from `LLVM_BINARY_DIR`.
For default llvm build (using llvm as the main cmake project), it should
not change anything.
For standalone clang build, keep the actual value as libclc cannot be
built that way.
