A CMake change included in CMake 4.0 makes `AIX` into a variable
(similar to `APPLE`, etc.)
ff03db6657
However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to
`AIX` and `if` auto-expands variable names in CMake. That means you get
a double expansion if you write:
`if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")`
which becomes:
`if (AIX MATCHES "AIX")`
which is as if you wrote:
`if (ON MATCHES "AIX")`
You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}",
due to policy
[CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054)
which is on by default in 4.0+. Most of the LLVM CMake already does
this, but this PR fixes the remaining cases where we do not.
Updated version of #134990 which was reverted because of the buildbot
[openmp-offload-amdgpu-runtime-2](https://lab.llvm.org/buildbot/#/builders/10)
failing. Its configuration has `LLVM_ENABLE_LIBCXX=ON` set although it
does not even have libc++ installed. In addition to #134990, this PR
adds a check whether C++ libraries are actually available. `#include
<chrono>` was chosen because this is the library that
[openmp-offload-amdgpu-runtime-2 failed
with](https://github.com/llvm/llvm-project/pull/134990#issuecomment-2792138162).
Original summary:
The buidbot
[flang-aarch64-libcxx](https://lab.llvm.org/buildbot/#/builders/89) is
currently failing with an ABI issue. The suspected reason is that
LLVMSupport.a is built using libc++, but the unittests are using the
default C++ standard library, libstdc++ in this case. This predefined
`llvm_gtest` target uses the LLVMSupport from `find_package(LLVM)`,
which finds the libc++-built LLVMSupport.
To fix, store the `LLVM_ENABLE_LIBCXX` setting in the LLVMConfig.cmake
such that everything that links to LLVM libraries use the same standard
library. In this case discussed in
https://github.com/llvm/llvm-zorg/pull/387 it was the flang-rt
unittests, but other runtimes with GTest unittests should have the same
issue (e.g. offload), and any external project that uses
`find_package(LLVM)`. This patch fixed the problem for me locally.
The CMake flag has been on by default for a month without any issues.
This makes the feature support in LLVM unconditional (but does not
enable the feature by default).
This per-file macro definition on the command line breaks caching of
modules. See discussion in #150677
Instead we use a constexpr function that processes the __FILE__ macro,
but prefer also the __FILE_NAME__ macro when available (clang/gcc) to spare
compile-time in the frontend.
If the constexpr function isn't const-evaluated, it'll be only evaluated when
printing the debug message.
Although the false positives that caused it to be disabled originally
may have been fixed in GCC 12, GCC also suffers from a problem where
-Wuninitialized may cause the build to hang on some platforms (GCC
#120729). This has been fixed in GCC 15, so turn on -Wuninitialized for
GCC 15+ instead of GCC 12+.
Depending on the order of CMake includes the
`tablegen_compile_commands.yml` was previously missing entries due to
being deleted after a `tablegen` commands.
This PR fixes this by 1) making sure `AddMLIR` includes `TableGen` such
that new compile commands are added to a fresh YML file and 2) using an
include guard to ensure the file is cleared exactly once
This tries to be a bit smarter for the OLD behaviour of CMP0116, to glob
more relevant directories looking for possible dependencies.
The changes are:
- Remove some duplication of lines in the `tablegen` function.
- Put CURRENT_SOURCE_DIR into `tblgen_includes` (at the front)
- Glob all directories in `tblgen_includes`
- Give up on `local_tds` which was wrong when using tablegen to compile
a file in a different directory (as TargetParser does)
- Use `EXTRA_INCLUDES` in TargetParser `tablegen` calls.
This is still an under-approximation of what might be included, at least
comparing the RISCVTargetParserDef.inc.d (after building
`target_parser_gen`), and the list of deps in the ninja file when
explicitly setting CMP0116 to OLD.
Fixes#144639
We're doing some slightly odd things with LIT in the offload-test-suite.
Specifically we generate multiple binary directories to configure and
run tests with different configurations from the same source root.
In this configuration the subdirectory targets need to instead point to
the correct generated binary directory and use test filtering to get a
subset of tests.
On unix systems, we were trying to determine the terminal width using
the `COULMNS` environment variable. Unfortunately, `COLUMNS` is not
exported by all shells and thus not available on some systems.
We were previously using `ioctl()` for this; fall back to doing so if `COLUMNS`
does not exist or does not store a positive integer.
This essentially reverts a3eb3d3d92d037fe3c9deaad87f6fc42fe9ea766 and
parts of https://reviews.llvm.org/D61326.
For more information, see #139499.
Fixes#139499.
Change in #107278 modified the CMake CACHE variable with values
that are not supported for it as documented. This patch renames the
derived vars so that they do not conflict with the CACHE variable.
Extend `FindFFI.cmake` to include the paths obtained from pkg-config
when searching for libffi. This is going to help systems where libffi is
installed in nonstandard directory such as Gentoo, saving us from having
to copy the paths from pkg-config to `FFI_*` variables explicitly. The
logic is inspired by `FindLibEdit.cmake`.
It has been introduced in #107278 but it was passing
"DISABLED" of LLVM_ENABLE_DEBUGLOC_COVERAGE_TRACKING to cmakedefine01.
cmakadefine01 treats non-false-like strings as 1.
"DISABLED" is replaced with 1.
This patch is part of a series that adds origin-tracking to the debugify
source location coverage checks, allowing us to report symbolized stack
traces of the point where missing source locations appear.
This patch adds the configuration options needed to enable this feature,
in the form of a new CMake option that enables a flag in
`llvm-config.h`; this is not an entirely new CMake flag, but a new
option, `COVERAGE_AND_ORIGIN`, for the existing flag
`LLVM_ENABLE_DEBUGLOC_COVERAGE_TRACKING`. This patch contains
documentation, but no actual implementation for the flag itself.
This fixes#139614 on non-clang compilers by moving `__has_warning`
completely inside the `#if defined(__clang__)` block. This prevents a
parse failure from compilers which don't recognize `__has_warning`.
Original description:
Followup to #138741.
This adds the requested macro to silence
`-Wunnecessary-virtual-specifier` when declaring virtual anchor
functions in `final` classes, per [LLVM
policy](https://llvm.org/docs/CodingStandards.html#provide-a-virtual-method-anchor-for-classes-in-headers).
It also cleans up any remaining instances of the warning, allowing us to
stop disabling it when we build LLVM.
The zstd_shared autodetection was broken for non-MSVC (mingw) compiled
LLVM, since it assumed that `*.a` uniquely identifies a file as being a
static library, but typically this is actually an import lib formed as
the longer name `*.dll.a` from the binary. This leads to confusing
output elsewhere, in cmake and llvm-config, when they report this is a
static library at an absolute path instead of a shared library named
`-lzstd`.
Add a linker test for -Bsymbolic-functions to AddLLVM and remove
the illumos hardcoded bits for its handling. OpenBSD also has a
local patch for linking with the old BFD linker on mips64 and
sparc64.
Ideally we should perhaps even error out here; if the user requested
building with profiling info, but that profile wasn't found, it seems
like the build configuration is subtly broken, and I would expect the
user to want to know about it. But that may be a too disruptive change,
as users may very well rely on being able to build things in such a
setup anyway thanks to Hyrum's Law.
To make things clearer, at least print a warning in this case.
Effectively a reland of #133265, though due to discussion there we add
the warning to -Wextra instead of turning it on by default. We still
need to disable it for LLVM due to our unusual policy of using virtual
`anchor` functions even in final classes. We now check if the warning
exists before disabling it in LLVM builds, so hopefully this will fix
the issues libcxx ran into last time.
From the previous PR:
I've been working on cleaning up this warning in two codebases: LLVM and
chromium (plus its dependencies). The chromium + dependency cleanup has
been straightforward. Git archaeology shows that there are two reasons
for the warnings: classes to which `final` was added after they were
initially committed, and classes with virtual destructors that nobody
remarks on. Presumably the latter case is because people are just very
used to destructors being virtual.
The LLVM cleanup was more surprising: I discovered that we have an [old
policy](https://llvm.org/docs/CodingStandards.html#provide-a-virtual-method-anchor-for-classes-in-headers)
about including out-of-line virtual functions in every class with a
vtable, even `final` ones. This means our codebase has many virtual
"anchor" functions which do nothing except control where the vtable is
emitted, and which trigger the warning. I looked into alternatives to
satisfy the policy, such as using destructors instead of introducing a
new function, but it wasn't clear if they had larger implications.
Overall, it seems like the warning is genuinely useful in most codebases
(evidenced by chromium and its dependencies), and LLVM is an unusual
case. Therefore we should enable the warning by default, and turn it off
only for LLVM builds.
If ValueTypes.td contains conditional directives enabled by defs in
LLVM_TABLEGEN_FLAGS then native build tblgen and min-tblgen must be
built with matching flags.
This ensures the embedded types in TableGen are consistent with those
used for building tables.
This patch follows the reversion of #107279, which caused errors by
including `llvm/Config/config.h` in a public header. In order to reapply
that patch, this PR moves the definition of the config option to the
`llvm-config.h` header instead, so that it can be used publicly. This
patch also adds `LLVM_` as a prefix to the define, since it is now in a
public header.
The `llvm-headers` target wasn't depending on the generated TargetParser
headers, so they'd be flakily installed or not installed depending on
which order the build steps ran in. Add an explicit dependency to fix
this, and switch to a single `target_parser_gen` target to mirror the
pattern used by `intrinsics_gen` (which also fixes a few other missing
dependencies). Switch `llvm-headers` to use `add_dependencies` instead
of `DEPENDS` for the tablegen dependencies as well, since `DEPENDS` is
only intended for creating a file-level dependency on the output of an
`add_custom_command` in the same CMakeLists.txt (see `DEPENDS` under
https://cmake.org/cmake/help/latest/command/add_custom_target.html).
This reverts commit fa65a228f4b46346e69e9b95805a8bcfa8483a60.
This relands commit ab405fb6e9ff9202ca722f632b945d4b84c653f5.
There was an issue where CMake versions <3.23.0 would not properly parse
dep files, causing the build to file. This patch fixes that by just
making CMake versions <3.23.0 use the fallback behavior.
CMP0116 was originally set to old to get rid of warnings. However, this
behavior is now set to new by default with the minimum CMake version
that LLVM requires so does not produce any warnings, and setting it
explicitly to old does produce a warning in newer CMake versions. Due to
these reasons, remove this check for now.
Splitting off from removing the CMP0114 check just in case something
breaks.
Partially fixes#83727.
Treat Cygwin like WIN32 in llvm-shlib for naming the library.
Don't create shlib symlinks on Cygwin, they don't help anything there,
but teach llvm_install_library_symlink that Cygwin's shared libraries
live in BINDIR like WIN32.
Add a new variable to llvm-config's BuildVariables to have CMake's
shared library prefix, to avoid having to patch between "cyg" and
"msys-" on MSYS2.
This mainly transitions the LLVM intrinsic string table from character
emission to string literal emission, which I confirmed happens for me
locally.
I moved the guts of StringToOffsetTable to a cpp file so I could move
the `EmitLongStrLiterals` cl::opt global to a non-vague linkage home in
the `TableGen` library. I had to add missing FormatVariadic.h includes
to account for moving other includes to a cpp file.
This reverts commit 785e7f06ddb1ba36aa679d23436726dcf61f8afb.
It did not solve the problem with flang-aarch64-libcxx and caused
another failure with openmp-offload-amdgpu-runtime-2.
The buidbot
[flang-aarch64-libcxx](https://lab.llvm.org/buildbot/#/builders/89) is
currently failing with an ABI issue. The suspected reason is that
LLVMSupport.a is built using libc++, but the unittests are using the
default C++ standard library, libstdc++ in this case. This predefined
`llvm_gtest` target uses the LLVMSupport from `find_package(LLVM)`,
which finds the libc++-built LLVMSupport.
To fix, store the `LLVM_ENABLE_LIBCXX` setting in the LLVMConfig.cmake
such that everything that links to LLVM libraries use the same standard
library. In this case discussed in
https://github.com/llvm/llvm-zorg/pull/387 it was the flang-rt
unittests, but other runtimes with GTest unittests should have the same
issue (e.g. offload), and any external project that uses
`find_package(LLVM)`.
Reverts llvm/llvm-project#133265
This causes the whole libc++ CI to fail, since we're not building
against a compiler built from current trunk. Specifically, the CMake
changes causes some feature detection to fail, resulting in CMake
being unable to configure libc++.
This turns on the unnecessary-virtual-specifier warning in general, but
disables it when building LLVM. It also tweaks the warning description
to be slightly more accurate.
Background: I've been working on cleaning up this warning in two
codebases: LLVM and chromium (plus its dependencies). The chromium
cleanup has been straightforward. Git archaeology shows that there are
two reasons for the warnings: classes to which `final` was added after
they were initially committed, and classes with virtual destructors that
nobody remarks on. Presumably the latter case is because people are just
very used to destructors being virtual.
The LLVM cleanup was more surprising: I discovered that we have an [old
policy](https://llvm.org/docs/CodingStandards.html#provide-a-virtual-method-anchor-for-classes-in-headers)
about including out-of-line virtual functions in every class with a
vtable, even `final` ones. This means our codebase has many virtual
"anchor" functions which do nothing except control where the vtable is
emitted, and which trigger the warning. I looked into alternatives to
satisfy the policy, such as using destructors instead of introducing a
new function, but it wasn't clear if they had larger implications.
Overall, it seems like the warning is genuinely useful in most codebases
(evidenced by chromium and its dependencies), and LLVM is an unusual
case. Therefore we should enable the warning by default, and turn it off
only for LLVM builds.
We're seeing following configuration error when building the `runtimes`
target on our buildbots:
```
CMake Error at /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/llvm/cmake/modules/CheckProblematicConfigurations.cmake:14 (if):
if given arguments:
"STREQUAL" "MSVC"
Unknown arguments specified
Call Stack (most recent call first):
/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/llvm/cmake/modules/HandleLLVMOptions.cmake:10 (include)
CMakeLists.txt:175 (include)
```
If I understand correctly this happens because ${CMAKE_CXX_COMPILER_ID}
is empty. Quoting it should make the comparison work for those cases.
Move `FindLibcCommonUtils` from LLVM's CMake module directory to the
shared top-level CMake directory, as the module is intended to be used
from within the source tree rather than the installed LLVM version. This
fixes standalone offload builds after #131205.
Key Instructions will start development behind a compile time flag to avoid
passing on the increased memory usage to all debug builds. We're working on
improving DILocation memory characteristics simultaneously; once that work lands
we can remove `EXPERIMENTAL_KEY_INSTRUCTIONS`.
This patch doesn't add any code, it's just so we can get the SIE buildbot
building with the new option right away.
Summary:
Always passing this option is problematic since it is not supported by
`clang.` this leads to conflicts when using extra CMake tools like
`compile-commands` or `include-what-you-use`. This mainly works around a
bug that showed up during the LTO build. Theoretically this can show up
without LTO, but it's likely to work.
This can be removed once
https://github.com/llvm/llvm-project/issues/24952 is resolved.
Summary:
This patch moves the RPC server handling to be a header only utility
stored in the `shared/` directory. This is intended to be shared within
LLVM for the loaders and `offload/` handling.
Generally, this makes it easier to share code without weird
cross-project binaries being plucked out of the build system. It also
allows us to soon move the loader interface out of the `libc` project so
that we don't need to bootstrap those and can build them in LLVM.
