Set `HAVE_CXX_ATOMICS_WITHOUT_LIB` or `HAVE_LIBATOMIC` when build LLVM with xlclang. With these macros set, libraries like libLLVMSupport are able to know whether it's necessary to add `-latomic` to dependent system libs. If `HAVE_LIBATOMIC` is set, `llvm-config --system-libs` appends `-latomic` to its output.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D111782
This finds the curl libraries if LLVM_ENABLE_CURL is set. This is needed
to implement the debuginfod client library in LLVM.
Patch By: noajshu
Differential Revision: https://reviews.llvm.org/D111238
mold says it is compatible with GNU ld and gold linkers:
```
$ mold -v
mold 0.9.5 (compatible with GNU ld and GNU gold)
```
And thus it currently gets detected as Gold.
With the following diff, CMake now correctly reports the linker name, and mold keeps being identified as Gold internally for now.
Reviewed By: ldionne, MaskRay
Differential Revision: https://reviews.llvm.org/D110035
This reverts commit 6d7b3d6b3a.
Breaks running cmake with `-DCLANG_ENABLE_STATIC_ANALYZER=OFF`
without turning off CLANG_TIDY_ENABLE_STATIC_ANALYZER.
See comments on https://reviews.llvm.org/D109611 for details.
Since https://reviews.llvm.org/D87118, the StaticAnalyzer directory is
added unconditionally. In theory this should not cause the static analyzer
sources to be built unless they are referenced by another target. However,
the clang-cpp target (defined in clang/tools/clang-shlib) uses the
CLANG_STATIC_LIBS global property to determine which libraries need to
be included. To solve this issue, this patch avoids adding libraries to
that property if EXCLUDE_FROM_ALL is set.
In case something like this comes up again: `cmake --graphviz=targets.dot`
is quite useful to see why a target is included as part of `ninja all`.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D109611
Visibility options currently have limited support on AIX and may cause warnings or errors
depending on the build compiler used.
Reviewed By: ZarkoCA
Differential Revision: https://reviews.llvm.org/D108467
This updates llvm/utils/sysroot.py to include the "DIA SDK" folder in the
sysroot.
It also updates the build to look for the DIA SDK there if a sysroot is set.
This requires moving LLVM_WINSYSROOT to config-ix.cmake.
For the GN build, I chose to pass a qualified path to diaguids in libs instead
of pushing a config with a `/libpath:` flag. The former requires a GN with
https://gn-review.googlesource.com/c/gn/+/12200, the latter requires D109624.
The former is more like the cmake build, arguably a bit simpler, and it's
easier to check for the wrong GN revision and easier to update GN.
Differential Revision: https://reviews.llvm.org/D109708
The original change to add the workaround is from 10 years ago and a lot has happened with msvc and cmake and llvm's usage of cmake since and we no longer need the workaround for any scenarios that I am aware of. Build more is now correctly configured for multi-configuration generators such as Visual Studio.
The workaround is, however, causing issues with some of the recent mlir tests as because of the workaround we cannot correctly determine whether assertions are enabled (see https://reviews.llvm.org/D105961).
The original change is:
```
commit b46fdac460
Author: Andrew Trick <atrick@apple.com>
Date: Tue Jun 28 16:32:01 2011
cmake: Our MSVC build does not support config-time build mode.
llvm-svn: 134008
```
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D109521
so that it gets installed in LLVM_INSTALL_TOOLCHAIN_ONLY builds,
such as used by the Windows installer.
Differential revision: https://reviews.llvm.org/D109358
This is a pretty small bit of CMake goop to generate code coverage
reports. I always forget the right script invocation and end up
fumbling around too much.
Wouldn't it be great to have targets that "Just Work"?
Well, I thought so.
At present this only really works correctly for LLVM, but I'll extend
it in subsequent patches to work for subprojects.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D109019
At least as of CMake 3.20.3, the CMake platform file for Linux doesn't
define the file type prefix and suffix variables, relying on them being
implicitly empty when they're unset. If we're cross-compiling targeting
Windows on a Linux machine, the values of these prefixes and suffixes
populated by the Windows platform file will still be set after including
the Linux platform file, so we'll incorrectly assume the ".exe" suffix
for the host machine. Explicitly unset the variables before including
the platform file, to prevent any previous values from leaking. Thanks
@beanz for suggesting the fix.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D108473
After some moment VS solution generated with LLVM_OPTIMIZED_TABLEGEN started to
generate all .inc files for each build. The reason was it had
"<path to native tablegen>/llvm-tblgen" without .exe as a dependency.
Differential Revision: https://reviews.llvm.org/D107898
It's sometimes useful to use these directives when dealing with
external projects:
target_link_directories
target_link_libraries
target_include_directories
However, under certain circumstances,
llvm_add_library can generate multiple targets. We need to transfer
these properties to the new targets. Note that using a generator
expression is necessary because these properties will only be set
after llvm_add_library is called.
Differential Revision: https://reviews.llvm.org/D108098
libgcc and libunwind have different flavours of __register_frame. Both
flavours are already correctly handled, except that the code to handle
the libunwind flavour is guarded by __APPLE__. This change uses the
presence of __unw_add_dynamic_fde in libunwind instead to detect whether
libunwind is used, rather than hardcoding it as Apple vs. non-Apple.
Fixes PR44074.
Thanks to Albert Jin <albert.jin@gmail.com> and Chris Schafmeister
<chris.schaf@verizon.net> for identifying the problem.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D106129
Consistently use 'w64' as vendor string; it was 'pc' for the original
i686 triple added in 91bd6c922d, but the later x86_64 triple
used 'w64' as vendor, added in d6c1f37f86.
When the arm triples were added in c84ad73a27, the differing
vendors were copied over accidentally to the arm targets too.
When using per-target runtime directories, having inconsistent vendor
parts of the target triples is fatal.
Differential Revision: https://reviews.llvm.org/D107894
In MSVC mode, CMake provides CMAKE_C_COMPILER_ARCHITECTURE_ID,
which should be accurate for what the compiler produces. Keep
the old CMAKE_C_SIZEOF_VOID_P based fallback in case this
doesn't provide matches.
In GCC/MinGW mode, CMake doesn't provide that. As we're trying to
guess the default host architecture, use CMAKE_HOST_SYSTEM_PROCESSOR
in combination with the existing CMAKE_C_SIZEOF_VOID_P check to
estimate whether it's x86/x86_64/arm/aarch64.
Differential Revision: https://reviews.llvm.org/D107626
Include the vaue of LLVM_ENABLE_NEW_PASS_MANAGER in generated
LLVMConfig.cmake since it is needed by clang's build system. This fixes
test failures when the new pass manager is enabled (i.e. by default)
by having clang's CMake files correctly detect that and skip relevant
tests.
Differential Revision: https://reviews.llvm.org/D107628
Use absolute path to link z3 to allow builds both on windows and linux
since the library name is platform dependent for Z3 (libz3 on Windows
and z3 on Linux) and MSVC does not recognized -L and -l options.
Fix CMAKE_CROSSCOMPILING that does not work correctly since it uses
Z3_BUILD_VERSION instead of Z3_BUILD_NUMBER
Fix building with the static version of z3 library (supersedes D80227).
- Build the Z3 version detection code as C++, since the static
library brings in libstdc++ symbols
- Detect threading support and link against threading, in the
(likely) case Z3 was built with threads
Exposed compilation error from building a program that is used to detect
z3 version in the warning message, to simplify troubleshooting.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D106131
Currently when linking LLVM against Libxml2, a simple check is performed to check whether it can be linked successfully. This check currently adds the include directories and the libraries for libxml2, but not definitions found by the config.
This causes issues on Windows when trying to link against a static libxml2. Libxml2 requires LIBXML_STATIC to be defined in the preprocessor to be able to link statically. This definition is put into LIBXML2_DEFINITIONS in the cmake config, but not properly forwarded to check_symbol_exists leading to it failing as it could not find xmlReadMemory in a DLL.
This patch simply appends the content of LIBXML2_DEFINITIONS to the symbol check definitions, fixing the issue.
Differential Revision: https://reviews.llvm.org/D106740
This is just a workaround. Pass the `-mllvm,-O0` link flags only if its
not ThinLTO. Doing that with ThinLTO currently results in an error:
```
Remaining virtual register operands
UNREACHABLE executed at .../llvm/lib/CodeGen/MachineRegisterInfo.cpp:209!
```
This is referenced in several of the cmake files that are part of an llvm install and it is also useful by downstream components such as onnx-mlir.
Differential Revision: https://reviews.llvm.org/D106686
This patch adds llvm-readobj and the binutils symlink for readelf to
LLVM_TOOLCHAIN_TOOLS.
Tvoid *thread, void *attr,hey are required by some (most?)
autoconf-built libraries, adding these allows me to build newlib with
the toolchain generated this way.
Also opened an issue for that some days ago, see
https://bugs.llvm.org/show_bug.cgi?id=50698
Reviewed By: sbc100
Differential Revision: https://reviews.llvm.org/D104957
`-fno-semantic-interposition` was added for GCC in D102453, but some MLIR tests
on SystemZ failed with GCC<10.3 due to a bug.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D105453
`llvm-strip` does not support `-l`. Apple's `strip` supports `-l`, but
it is not documented, and the latest code doesn't seem to do anything
meaningful. From the old source code drops it seems that `-l` was added
around version 795 of cctools and removed before 898. The code around
the flag usage in 795 talks about problems with kext and forcing the
execution of `ld -r`, which seems a behaviour that is not enforceable in
latest versions of cctools.
The `-l` flag was added in https://reviews.llvm.org/D15133 without a lot
of explanation.
Since the flag is not active, removing it should not modify the
behaviour for most people (except if someone is trying to compile LLVM
with a really old version of `strip`).
Additionally, break the invocation into two different flags, since
`llvm-strip` doesn't at the moment support grouped flags, and other
`strip` implementations should work the same no matter if grouped or
not.
Test Plan:
Using `strip` from Xcode 12.5 in Big Sur to strip the same binary (a
simple Hello World), using both `-Sxl` and `-Sx` produces exactly the
same binary.
Repeating the same process with `clang` results also in the same binary.
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D105243
Synchronizing multiple custom targets requires not only target but also
file dependencies. Building Linalg involves running yaml-gen followed by
tablegen. Currently, these custom targets are only synchronized using a
target dependency resulting in issues in specific incremental build
setups (https://llvm.discourse.group/t/missing-build-cmake-tblgen-dependency/3727/10).
This patch introduces a novel LLVM_TARGET_DEPENDS variable to the
TableGen.cmake file to provide a way to specify file dependencies.
Additionally, it adapts the Linalg CMakeLists.txt to introduce the
necessary file dependency between yaml-gen and tablegen.
Differential Revision: https://reviews.llvm.org/D105272
They are not conducive to being stored in git. Instead, we autogenerate
mock model artifacts for use in tests. Production models can be
specified with the cmake flag LLVM_INLINER_MODEL_PATH.
LLVM_INLINER_MODEL_PATH has two sentinel values:
- download, which will download the most recent compatible model.
- autogenerate, which will autogenerate a "fake" model for testing the
model uptake infrastructure.
Differential Revision: https://reviews.llvm.org/D104251
If the flag is not set, the script saved_model_aot_compile.py in tensorflow will
default it to the correct value. However, in TF 2.5, the way the value is set in
TensorFlowCompile.cmake file triggers a build error.
Reviewed By: mtrofin
Differential Revision: https://reviews.llvm.org/D103972
This is an attempt to fix clang test failures due to 'nonportable-include-path'
warnings on Windows when a path to llvm-project's base directory contains some
uppercase letters (excluding a drive letter).
The issue originates from 2 problems:
* discovery.py loads site config in lower case causing all the paths
based on __file__ and requested within the config file to be in lowercase as well,
* neither os.path.abspath() nor os.path.realpath() (both used to obtain paths of
config files, sources, object directories, etc) do not return paths in the correct
case for Windows (at least consistently for all python versions).
As os.path library doesn't seem to provide any relaible way to restore
the case for paths on Windows, this patch proposes to use pathlib.resolve().
pathlib is a part of Python 3.4 while llvm lit requires Python 3.6.
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D103014
In a `-DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_LINK_LLVM_DYLIB=on -DCLANG_LINK_CLANG_DYLIB=on`
build, libLLVM-13git.so is 2% smaller and libclang-cpp.so is 1% smaller (on top of -Wl,-Bsymbolic-functions).
There may be some small performance improvement as well because GCC
-fPIC suppresses interprocedural optimizations for non-inline
definitions by default.
Note: we cannot add -fno-semantic-interposition for Clang<13. Clang<13's
implementation additionally optimizes global variables, which is incompatible
with unfortunate ELF -fno-pic default: direct access relocations for external
data. If the executable has a -fno-pic object file referencing a global variable
declared in a public header, the direct access relocation will cause a copy
relocation. The executable and libLLVM.so/libclang-cpp.so will disagree on the
address.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D102453
This precomputes some hashes that LLD uses for type merging to speed up
linking when PDBs are enabled. Only do this if any kind of /DEBUG flag
is passed to the linker. -gcodeview-ghash is orthogonal to /Z7, -g, -g1,
or -gmlt, so it is safe to set it independently from those flags. It
will not increase debug info emission.
Differential Revision: https://reviews.llvm.org/D103287
lld/MachO/Driver.cpp and lld/MachO/SyntheticSections.cpp include
llvm/Config/config.h which doesn't exist when building standalone lld.
This patch replaces llvm/Config/config.h include with llvm/Config/llvm-config.h
just like it is in lld/ELF/Driver.cpp and HAVE_LIBXAR with LLVM_HAVE_LIXAR and
moves LLVM_HAVE_LIBXAR from config.h to llvm-config.h
Also it adds LLVM_HAVE_LIBXAR to LLVMConfig.cmake and links liblldMachO2.so
with XAR_LIB if LLVM_HAVE_LIBXAR is set.
Differential Revision: https://reviews.llvm.org/D102084
Kai Luo