Revert "Delete llvm::is_trivially_copyable and CMake variable HAVE_STD_IS_TRIVIALLY_COPYABLE"
This reverts commit 4d4bd40b578d77b8c5bc349ded405fb58c333c78.
This reverts commit 557b00e0afb2dc1776f50948094ca8cc62d97be4.
GCC<5 did not support std::is_trivially_copyable. Now LLVM builds
require 5.1 we can delete llvm::is_trivially_copyable after the users
have been migrated to std::is_trivially_copyable.
We need a real target now, and it was only being created if grpc was
built from source or imported from homebrew.
Differential Revision: https://reviews.llvm.org/D92107
Use exact component name in add_ocaml_library.
Make expand_topologically compatible with new architecture.
Fix quoting in is_llvm_target_library.
Fix LLVMipo component name.
Write release note.
No longer rely on an external tool to build the llvm component layout.
Instead, leverage the existing `add_llvm_componentlibrary` cmake function and
introduce `add_llvm_component_group` to accurately describe component behavior.
These function store extra properties in the created targets. These properties
are processed once all components are defined to resolve library dependencies
and produce the header expected by llvm-config.
Differential Revision: https://reviews.llvm.org/D90848
The macro HAVE_EHTABLE_SUPPORT is used by parts of ExecutionEngine to tell __register_frame/__deregister_frame is available to register the
FDE for a generated (JIT) code. It's currently set by a slowly growing set of macro tests in the respective headers, which is updated now and then when it fails to link on some platform or another due to the symbols being missing (see for example https://bugs.llvm.org/show_bug.cgi?id=5715).
This change converts the macro in two HAVE_(DE)REGISTER_FRAME config.h macros (like most of the other HAVE_* macros) and set's them based on whether CMake can actually find a definition for these symbols to link to at configuration time.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D87114
Previously, if make_paths_relative() failed due to some reason, it would
happily keep going and set the ${out_pathlist} to the standard output
of the command, which would be the empty string if the command failed.
This can lead to issues that are difficult to diagnose, since the calling
code will usually try to keep going with a variable that was set to the
empty string.
Differential Revision: https://reviews.llvm.org/D89985
Allow overriding the default set of flags used to enable UBSan when
building llvm.
This can be used to test new checks or opt out of certain checks.
Differential Revision: https://reviews.llvm.org/D89439
The change in 0ba98433971f changed the behaviour of the build when
using an XL build compiler because `-G` is not a pure linker option:
it also implies `-shared`. This was accounted for in the base CMake
configuration, so an analysis of the change from 0ba98433971f in
relation to a build using Clang (where `-shared` is introduced by CMake)
would not identify the issue. This patch resolves this particular issue
by adding `-shared` alongside `-Wl,-G`.
At the same time, the investigation reveals that several aspects of the
various build configurations are not operating in the manner originally
intended.
The other issue related to the `-G` linker option in the build is that
the removal of it (to avoid unnecessary use of run-time linking) is not
effective for the build using the Clang compiler. This patch addresses
this by adjusting the regular expressions used to remove the broadly-
applied `-G`.
Finally, the issue of specifying the export list with `-Wl,` instead of
a compiler option is flagged with a FIXME comment.
Reviewed By: daltenty, amyk
Differential Revision: https://reviews.llvm.org/D90041
When using a custom `LLVM_EXTERNAL_LIT`, it's possible the file may not exist at the CMake is generating the build. One example is LLDB standalone builds. When the external lit doesn't exist, a warning message is emitted, but the warning is printed once for every single lit target. This produces many redundant warnings.
This changes the warning to only be emitted once, controlled by a CACHE variable.
Other options are:
1. remove the warning
2. have callers pass an option to silence the warning if desired
See https://reviews.llvm.org/D76945 for some context.
Differential Revision: https://reviews.llvm.org/D89356
The Darwin linker now defaults to ad hoc signing binaries when targeting
Apple Silicon. This creates a problem when configuring targets that must
be built with entitlements: we either need to add -Wl,-no_adhoc_codesign
when building the target, or sign with the force flag set to allow
replacing a pre-existing signature.
Unconditionally force-signing is the more convenient solution. This
doesn't require a ld64 version check, and it's a much less invasive
cmake change.
Patch by Fred Riss!
rdar://70237254
Differential Revision: https://reviews.llvm.org/D89343
Export LLVM_USE_SPLIT_DWARF in LLVMConfig.cmake so that it can be used
from standalone builds of clang and lldb. Currently, there is no way for
standalone builds to know whether this option was set which means that
it only applies to LLVM.
Differential revision: https://reviews.llvm.org/D89282
The following code doesn't compile
uint64_t i = x.load(std::memory_order_relaxed);
return 0;
when CMAKE_C_FLAGS set to -Werror -Wall, thus incorrectly
breaking the CMake configuration step:
-- Looking for __atomic_load_8 in atomic
-- Looking for __atomic_load_8 in atomic - not found
CMake Error at cmake/modules/CheckAtomic.cmake:79 (message):
Host compiler appears to require libatomic for 64-bit operations, but
cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:360 (include)
CMakeLists.txt:671 (include)
This reverts commit e9b87f43bde8b5f0d8a79c5884fdce639b12e0ca.
There are issues with macros generating macros without an obvious simple fix
so I'm going to revert this and try something different.
New projects (particularly out of tree) have a tendency to hijack the existing
llvm configuration options and build targets (add_llvm_library,
add_llvm_tool). This can lead to some confusion.
1) When querying a configuration variable, do we care about how LLVM was
configured, or how these options were configured for the out of tree project?
2) LLVM has lots of defaults, which are easy to miss
(e.g. LLVM_BUILD_TOOLS=ON). These options all need to be duplicated in the
CMakeLists.txt for the project.
In addition, with LLVM Incubators coming online, we need better ways for these
incubators to do things the "LLVM way" without alot of futzing. Ideally, this
would happen in a way that eases importing into the LLVM monorepo when
projects mature.
This patch creates some generic infrastructure in llvm/cmake/modules and
refactors MLIR to use this infrastructure. This should expand to include
add_xxx_library, which is by far the most complicated bit of building a
project correctly, since it has to deal with lots of shared library
configuration bits. (MLIR currently hijacks the LLVM infrastructure for
building libMLIR.so, so this needs to get refactored anyway.)
Differential Revision: https://reviews.llvm.org/D85140
This is a follow on to D85329 which disabled some llvm tools in the
runtimes build due to XCOFF64 limitations. This change disables them
in other external project builds as well, when no list of tools is
specified in the arguments.
Reviewed By: hubert.reinterpretcast, stevewan
Differential Revision: https://reviews.llvm.org/D88310
We currently try to pick it up from the CMake arguments passed to llvm_ExternalProject_Add but
if there isn't an explicit option passed, we should reflect CMake's own default behaviour
of targeting the host, since we'll make decisions about what tools to use for the build based on
the setting. Otherwise, we'll get different behaviour between configuring an external project with
the default target and configuring with an explicit one targeting the same platform.
Reviewed By: stevewan, hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D88157
As of cmake 3.18, cmake changes how it searches for compilers for
Windows (see
55196a1440)
and now finds llvm-ar instead of llvm-lib as CMAKE_AR. This explicitly
specifies CMAKE_AR as llvm-lib so the correct program is found.
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D88176
This ensures that required includes and libraries such as -lm that
were added earlier aren't overwritten.
Differential Revision: https://reviews.llvm.org/D88068
This prefered over find_package as find_dependency forwards the correct
parameters for QUIET and REQUIRED to find_package.
Differential Revision: https://reviews.llvm.org/D88069
Configure default value of `LLVM_ENABLE_WARNINGS` in `HandleLLVMOptions.cmake`.
`LLVM_ENABLE_WARNINGS` is documented as ON by default, but `HandleLLVMOptions` assumes the default has been set somewhere else. If it has not been explicitly set, then `HandleLLVMOptions` implicitly uses OFF as a default.
This removes the various `option()` declarations in favor of a single declaration in `HandleLLVMOptions`. This will prevent the unwanted use of `-w` that is mentioned in a couple of the comments.
Reviewed By: DavidTruby, #libunwind, JDevlieghere, compnerd
Differential Revision: https://reviews.llvm.org/D87243
In MinGW world, UNIX like lib prefix is preferred for the libraries.
This patch adjusts CMake files to do that.
Differential Revision: https://reviews.llvm.org/D87517
This matches the changes made to handling of zlib done in 10b1b4a
where we rely on find_package and the imported target rather than
manually appending the library and include paths. The use of
LLVM_LIBXML2_ENABLED has been replaced by LLVM_ENABLE_LIBXML2
thus reducing the number of variables.
Differential Revision: https://reviews.llvm.org/D84563
Currently it is hard to avoid having LLVM link to the system install of
ncurses, since it uses check_library_exists to find e.g. libtinfo and
not find_library or find_package.
With this change the ncurses lib is found with find_library, which also
considers CMAKE_PREFIX_PATH. This solves an issue for the spack package
manager, where we want to use the zlib installed by spack, and spack
provides the CMAKE_PREFIX_PATH for it.
This is a similar change as https://reviews.llvm.org/D79219, which just
landed in master.
Patch By: haampie
Differential Revision: https://reviews.llvm.org/D85820
Tests on Solaris/sparcv9 currently show about 250 failures when building
with gcc, most of them like the following:
FAIL: LLVM-Unit :: Support/./SupportTests/TaskQueueTest.UnOrderedFutures (4269 of 67884)
******************** TEST 'LLVM-Unit :: Support/./SupportTests/TaskQueueTest.UnOrderedFutures' FAILED ********************
Note: Google Test filter = TaskQueueTest.UnOrderedFutures
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from TaskQueueTest
[ RUN ] TaskQueueTest.UnOrderedFutures
0 SupportTests 0x0000000100753b20 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 32
1 SupportTests 0x0000000100752974 llvm::sys::RunSignalHandlers() + 68
2 SupportTests 0x0000000100752b18 SignalHandler(int) + 372
3 libc.so.1 0xffffffff7eedc800 __sighndlr + 12
4 libc.so.1 0xffffffff7eecf23c call_user_handler + 852
5 libc.so.1 0xffffffff7eecf594 sigacthandler + 84
6 SupportTests 0x00000001006f8cb8 std:🧵:_State_impl<std:🧵:_Invoker<std::tuple<llvm::ThreadPool::ThreadPool(llvm::ThreadPoolStrategy)::'lambda'()> > >::_M_run() + 512
7 libstdc++.so.6.0.28 0xfffffffc628117cc execute_native_thread_routine + 16
8 libc.so.1 0xffffffff7eedc6a0 _lwp_start + 0
Since it's effectively impossible to debug such a `SEGV` in a `Release`
build, I tried a `Debug` build instead, only to find that the failures had
gone away.
Further investigation revealed that most of the issue centers around
`llvm/lib/Support/ThreadPool.cpp`. That file is built with `-O3 -fPIC` in
a `Release` build. The failure vanishes if
- compiling without `-fPIC`
- compiling with `-O -fPIC`
- linking with GNU `ld` instead of Solaris `ld`
It has meanwhile been determined that `gcc` doesn't correctly heed some TLS
code sequences. To make things worse, Solaris `ld` doesn't properly
validate its assumptions against the input, generating wrong code.
`gld` like `gcc` is more liberal here and correctly deals with the code it
gets fed from `gcc`.
There's PR target/96607: GCC feeds SPARC/Solaris linker with unrecognized
TLS sequences <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607> now.
An attempt to build with `-DLLVM_ENABLE_PIC=Off` initially failed since
neither `libRemarks.so` (D85626 <https://reviews.llvm.org/D85626>) nor
`LLVMPolly.so` (D85627 <https://reviews.llvm.org/D85627>) heed that option.
Even with that fixed, a few codegen failures remain.
Next I tried to build just `ThreadPool.cpp` with `-O -fPIC`. While that
fixed the vast majority of the failures, 16 `LLVM :: CodeGen/X86` failures
remained.
Given that that solution was both incomplete and fragile, I went for
building the whole tree with `-O -fPIC` for `Release` and `RelWithDebInfo`
builds.
As detailed in Bug 47304, 2-stage builds also show large numbers of
failures when building with `-O3` or `-O2`, which are likewise worked
around by building with `-O` until they are sufficiently analyzed and
fixed.
This way, all failures relative to a `Debug` build go away.
Tested on `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D85630
The introduction of find_library for ncurses caused more issues than it solved problems. The current open issue is it makes the static build of LLVM fail. It is better to revert for now, and get back to it later.
Revert "[CMake] Fix an issue where get_system_libname creates an empty regex capture on windows"
This reverts commit 1ed1e16ab83f55d85c90ae43a05cbe08a00c20e0.
Revert "Fix msan build"
This reverts commit 34fe9613dda3c7d8665b609136a8c12deb122382.
Revert "[CMake] Always mark terminfo as unavailable on Windows"
This reverts commit 76bf26236f6fd453343666c3cd91de8f74ffd89d.
Revert "[CMake] Fix OCaml build failure because of absolute path in system libs"
This reverts commit 8e4acb82f71ad4effec8895b8fc957189ce95933.
Revert "[CMake] Don't look for terminfo libs when LLVM_ENABLE_TERMINFO=OFF"
This reverts commit 495f91fd33d492941c39424a32cf24bcfe192f35.
Revert "Use find_library for ncurses"
This reverts commit a52173a3e56553d7b795bcf3cdadcf6433117107.
Differential revision: https://reviews.llvm.org/D86521
This applies the same fix that D84748 did for macro definitions.
Appropriate include path is now automatically set for all libraries
which link against gtest targets, which avoids the need to set
include_directories in various parts of the project.
Differential Revision: https://reviews.llvm.org/D86616
The non-standard header file `<sysexits.h>` provides some return values.
`EX_IOERR` is used to as a special value to signal a broken pipe to the clang driver.
On z/OS Unix System Services, this header file does not exists. This patch
- adds a check for `<sysexits.h>`, removing the dependency on `LLVM_ON_UNIX`
- adds a new header file `llvm/Support/ExitCodes`, which either includes
`<sysexits.h>` or defines `EX_IOERR`
- updates the users of `EX_IOERR` to include the new header file
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D83472
This change extend the CMake files with the necessary additions
to build LLVM for z/OS.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D83866
It's full featured now and we can use it for the runtimes build instead
of relying on an external libtool, which means the CMAKE_HOST_APPLE
restriction serves no purpose either now. Restrict llvm-lipo to Darwin
targets while I'm here, since it's only needed there.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D86367
ld.lld is an ELF linker. We can switch to the new LLD for Mach-O port
when it's more complete, but for now, assume the user will have set
CMAKE_LINKER correctly themselves when targeting Darwin.
D85820 introduced a bug where LLVM_ENABLE_TERMINFO was set to true when
the library was found, even when the user had set
-DLLVM_ENABLE_TERMINFO=OFF.
Patch By: haampie
Differential Revision: https://reviews.llvm.org/D86173
