Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
This quietly disabled use of zlib on Windows even when building with
-DLLVM_ENABLE_ZLIB=FORCE_ON.
> Rather than handling zlib handling manually, use find_package from CMake
> to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
> HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
> set to YES, which requires the distributor to explicitly select whether
> zlib is enabled or not. This simplifies the CMake handling and usage in
> the rest of the tooling.
>
> This is a reland of abb0075 with all followup changes and fixes that
> should address issues that were reported in PR44780.
>
> Differential Revision: https://reviews.llvm.org/D79219
This reverts commit 10b1b4a231 and follow-ups
64d99cc6ab and
f9fec0447e.
The /Zc:__cplusplus option fixes GTEST_LANG_CXX11 value but not GTEST_HAS_TR1_TUPLE,
so we still need to force the latter off.
Still pass the option since it is required by https://reviews.llvm.org/D78186 too.
Differential Revision: https://reviews.llvm.org/D84023
This drops a GNU gold workaround and reverts the revert commit rL366708.
Before binutils 2.34, gold -O2 and above did not correctly handle R_386_GOTOFF to
SHF_MERGE|SHF_STRINGS sections: https://sourceware.org/bugzilla/show_bug.cgi?id=16794
From the original review:
... it reduced the size of a big ARM-32 debug image by 33%. It contained ~68M
of relocations symbols out of total ~71M symbols (96% of symbols table was
generated for relocations with symbol).
-Wl,-O2 (and -Wl,-O3) is so rare that we should just lower the
optimization level for LLVM_LINKER_IS_GOLD rather than pessimizing all users.
BUG_REPORT_URL is currently used both in LLVM and in Clang but declared
only in the latter. This means that it's missing in standalone clang
builds and the driver ends up outputting:
PLEASE submit a bug report to and include [...]
(note the missing URL)
To fix this, include LLVM_PACKAGE_BUGREPORT in LLVMConfig.cmake
(similarly to how we pass PACKAGE_VERSION) and use it to fill
BUG_REPORT_URL when building clang standalone.
Differential Revision: https://reviews.llvm.org/D84987
The issue with LLVM_ENABLE_LLD is that it just passes -fuse-ld=lld
to compiler/linker options which makes sense only for those platforms
where cmake invokes a compiler driver for linking. On Windows (MSVC) cmake
invokes the linker directly and requires CMAKE_LINKER to be specified
otherwise it defaults CMAKE_LINKER to be link.exe.
This patch allows BOOTSTRAP_LLVM_ENABLE_LLD to set CMAKE_LINKER in two cases:
* if building for host Windows,
* if crosscompiling for target Windows.
It also skips adding '-fuse-ld=lld' to make lld-link not warning
about 'unknown argument'.
This fixes build with `clang/cmake/caches/DistributionExample.cmake`
on Windows.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D80873
This way, downstream projects don't have to invoke find_package(ZLIB)
reducing the amount of boilerplate.
Differential Revision: https://reviews.llvm.org/D84691
add_compile_options is more sensitive to its location in the file than add_definitions--it only takes effect for sources that are added after it. This updated patch ensures that the add_compile_options is done before adding any source files that depend on it.
Using add_definitions caused the flag to be passed to rc.exe on Windows and thus broke Windows builds.
After lots of follow-up fixes, there are still problems, such as
-Wno-suggest-override getting passed to the Windows Resource Compiler
because it was added with add_definitions in the CMake file.
Rather than piling on another fix, let's revert so this can be re-landed
when there's a proper fix.
This reverts commit 21c0b4c1e8.
This reverts commit 81d68ad27b.
This reverts commit a361aa5249.
This reverts commit fa42b7cf29.
This reverts commit 955f87f947.
This reverts commit 8b16e45f66.
This reverts commit 308a127a38.
This reverts commit 274b6b0c7a.
This reverts commit 1c7037a2a5.
A previous patch added -Wsuggest-override using a simple add_flag_if_supported(). This causes lots of warnings in LLVM when building with older GCC versions (< 9.2) which suggest adding override to functions that are only marked final. The current flags in both GCC >=9.2 and Clang accept plain final as equivalent to override final.
This patch adds logic to detect versions of -Wsuggest-override that warn on void foo() final and disables them to avoid warning spam in builds using older GCC's. This has the added minor benefit of getting rid of the useless C_SUPPORTS_SUGGEST_OVERRIDE_FLAG CMake cache variable which was set by add_flag_if_supported().
Differential Revision: https://reviews.llvm.org/D84292
This patch adds Clang's new (and GCC's old) -Wsuggest-override to the warning flags for the LLVM build. The warning is a stronger form of -Winconsistent-missing-override which warns _everywhere_ that override is missing, not just in places where it's inconsistent within a class.
Some directories in the monorepo need the warning disabled for compatibility's, or sanity's, sake; in particular, libcxx/libcxxabi, and any code implementing or interoperating with googletest, googlemock, or google benchmark (which do not themselves use override). This patch adds -Wno-suggest-override to the relevant CMakeLists.txt's to accomplish this.
Differential Revision: https://reviews.llvm.org/D84126
This pacth fix out-of-tree build of Flang after the introduction of acc_gen.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D83835
We should also pass down the LLVM_LIT_ARGS in runtime build mode,
so that the runtime tests can be well controlled as well.
We actually passed this down in clang/runtime/CMakeLists.txt
But not for calls from llvm/runtime/CMakeLists.txt.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D83565
The name of the make program does not necessarily match "ninja",
especially if an alternative implementation like samurai is used.
Using CMAKE_GENERATOR is a more robust detection method, and is
already used elsewhere in this file.
Differential revision: https://reviews.llvm.org/D77091
Do not enforce recommonmark dependency if sphinx is called to build
manpages. In order to do this, try to import recommonmark first
and do not configure it if it's not available. Additionally, declare
a custom tags for the selected builder via CMake, and ignore
recommonmark import failure when 'man' target is used.
This will permit us to avoid the problematic recommonmark dependency
for the majority of Gentoo users that do not need to locally build
the complete documentation but want to have tool manpages.
Differential Revision: https://reviews.llvm.org/D83161
Followup to b8000c0ce8, the library path needs to go in
CMAKE_MODULE_LINKER_FLAGS too, for the sake of a few files
like LLVMHello.dll.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D82888
Summary:
add_unittest was checking that the result of get_target_property was not
"NOTFOUND", but despite what the documentation says, get_target_property
returns <the var>-NOTFOUND on failure.
Reviewers: efriedma, thakis, serge-sans-paille, chandlerc
Reviewed By: serge-sans-paille
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81762
This reverts commit 62841415e6.
The commit is a misnomer, and it "made its way in" unintentionally,
through a patch that had it as a depdendency. The change itself ended up
to be just a comment update, but the description is completely wrong.
Summary:
Currently, add_llvm_library would create an OBJECT library alongside
of a STATIC / SHARED library, but losing the link interface (its
elements would become dependencies instead). To support scenarios
where linking an object library also brings in its usage
requirements, this patch adds support for 'stand-alone' OBJECT
libraries - i.e. without an accompanying SHARED/STATIC library, and
maintaining the link interface defined by the user.
This is useful for cases where, for example, we want to build a part
of a component separately. Using a STATIC target would incur the risk
that symbols not referenced in the consumer would be dropped (which may
be undesirable).
The current application is the ML part of Analysis. It should be part
of the Analysis component, so it may reference other analyses; and (in
upcoming changes) it has dependencies on optional libraries.
Reviewers: karies, davidxl, beanz, phosek, smeenai
Subscribers: mgorny, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81447
Summary: CMake's `find_package` outputs to the console on success, which confuses the smart console mode of the `ninja` build system. Let's quiet the success message and manually warn instead.
Reviewers: tstellar, phosek, mehdi_amini
Reviewed By: mehdi_amini
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D82276
Summary:
Currently, add_llvm_library would create an OBJECT library alongside
of a STATIC / SHARED library, but losing the link interface (its
elements would become dependencies instead). To support scenarios
where linking an object library also brings in its usage
requirements, this patch adds support for 'stand-alone' OBJECT
libraries - i.e. without an accompanying SHARED/STATIC library, and
maintaining the link interface defined by the user.
The support is via a new option, OBJECT_ONLY, to avoid breaking changes
- since just specifying "OBJECT" would currently imply also STATIC or
SHARED, depending on BUILD_SHARED_LIBS.
This is useful for cases where, for example, we want to build a part
of a component separately. Using a STATIC target would incur the risk
that symbols not referenced in the consumer would be dropped (which may
be undesirable).
The current application is the ML part of Analysis. It should be part
of the Analysis component, so it may reference other analyses; and (in
upcoming changes) it has dependencies on optional libraries.
Reviewers: karies, davidxl
Subscribers: mgorny, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81447
I'm currently working to port `libc++` to Solaris. There exists a slightly
bitrotten port already, which was done on Illumos, an OpenSolaris
derivative. In order not to break that port with my work, I need to test
the result on both Solaris and Illumos. While doing so, it turned out that
Illumos `ld` doesn't support the `-z discard-sections=unused` option
currently used on SunOS unconditionally.
While there exists a patch
<https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/developer/clang-90/patches/02-cmake_modules_AddLLVM.cmake.patch>
for LLVM 9.0 in the OpenIndiana repository, it apparently hasn't been
submitted upstream and is completely wrong: it replaces
`-z discard-sections=unused` with `-z ignore`. In terms of the equivalent
`gld` options, this means replacing `--gc-sections` with `--as-needed`.
This patch instead tests if the linker actually supports the option before
using it.
Tested on `amd64-pc-solaris2.11` (all of Solaris 11.4, 11.3 and OpenIndiana
2020.04).
Differential Revision: https://reviews.llvm.org/D81545
As LLVM has moved from SVN to git, there is no need to
keep SVN related code. Also, this code piece was never used.
Differential Revision: https://reviews.llvm.org/D79400
cmake configure fails when it tries to setup target for llvm_vcsrevision_h
This happens only when source is checked out using repo in a read
only filesystem, because cmake tries to create `.git/logs/HEAD` file.
This patch:
1. Recovers from failure gracefully.
2. Ensures that VCSRevision.h is successfully created and updated
in above scenarios.
Differential Revision: https://reviews.llvm.org/D79400
After D80096, bots that build clang for distribution and that can't use
system gcc / libstdc++ need to pass a working rpath so that unit test
binaries can run. The method suggested in GettingStarted.rst works fine
for local development, but it results in an absolute local rpath ending
up even in distributed binaries like clang, which is both ugly and
unnecessary.
Add an explicit toggle that can be used to add an rpath only for the
non-distributed binaries that need it.
Differential Revision: https://reviews.llvm.org/D80534
We want to make sure that LINKER_IS_LLD_LINK is properly set - in
this case it shouldn't be set when building for MinGW.
Then we want to make the test for it correct and finally include
the option to build with thinlto cache since the MinGW driver now
supports that.
Differential Revision: https://reviews.llvm.org/D80493
Summary:
The `-bcdtors:mbr` option causes processing for constructors and
destructors to omit otherwise-unreferenced members of static libraries,
matching the processing done on Linux, where `--whole-archive` is not
the default. Applying this option is desirable for reducing the
footprint of an installation.
Reviewed By: daltenty
Differential Revision: https://reviews.llvm.org/D79749
Omitting comments can make the output much smaller. Size/time impact on
my machine:
* lib/Target/AArch64/AArch64GenDAGISel.inc, 10MiB (8.89s) -> 5MiB (3.20s)
* lib/Target/X86/X86GenDAGISel.inc, 20MiB (6.48s) -> 8.5MiB (4.18s)
In total, this change decreases lib/Target/*/*GenDAGISel.inc from
71.4MiB to 30.1MiB.
As rnk suggested, we can consider an option next to LLVM_OPTIMIZED_TABLEGEN
once we have more needs like this.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D78884
REGEX matching doesn't work here because the problematic library can
sometimes be "-lpthread" and sometimes "pthread". Let's do the
simplest thing possible and just string compare.
Differential Revision: https://reviews.llvm.org/D79908
We need to avoid declaring dependencies on strings which are valid
LINK_LIBS and not valid targets. Previously, we used if(TARGET) to
check this condition. However, if(TARGET) checks whether a target has
been created (in the cmake subdirectory traversal order) and not
whether it *will* be created. This results in annoying directory
ordering problems.
This patch changes the check to more explicitly eliminate problematic
libraries (namely -lpthread) using a REGEX.
Differential Revision: https://reviews.llvm.org/D79837
Summary:
Besides just generating and consuming the lists, this includes:
* Calling nm with the right options in extract_symbols.py. Such as not
demangling C++ names, which AIX nm does by default, and accepting both
32/64-bit names.
* Not having nm sort the list of symbols or we may run in to memory
issues on debug builds, as nm calls a 32-bit sort.
* Defaulting to having LLVM_EXPORT_SYMBOLS_FOR_PLUGINS on for AIX
* CMake versions prior to 3.16 set the -brtl linker flag globally on
AIX. Clear it out early on so we don't run into failures. We will set
it as needed.
Reviewers: jasonliu, DiggerLin, stevewan, hubert.reinterpretcast
Reviewed By: hubert.reinterpretcast
Subscribers: hubert.reinterpretcast, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70972
See PR45812 for motivation.
No explicit test since I couldn't figure out how to get the
current disk drive in lower case into a form in lit where I could
mkdir it and cd to it. But the change does have test coverage in
that I can remove the case normalization in lit, and tests failed
on several bots (and for me locally if in a pwd with a lower-case
drive) without that normalization prior to this change.
Differential Revision: https://reviews.llvm.org/D79531
Previous patch broken flang, which has some yet-to-be resolved cyclic
dependencies. This patch fixes the breakage by restricting the dependencies
which are generated to public libraries, which is probably more sensible anyway.
Differential Revision: https://reviews.llvm.org/D79366
In MLIR, it is common for automatically generated headers to be included
in many places. To avoid tracking these dependencies explicitly in
cmake, they are treated as part of a library which 'owns' the generated
header. Users of the generated header link against the owning library.
However, object libraries don't actually 'link', so this dependence gets
lost. This patch adds an explicit dependence for these generated headers
when creating object library targets to ensure that generated headers
are appropriately generated
Differential Revision: https://reviews.llvm.org/D79241
llvm-lit gets '.py' extension on Windows host during its configuration.
We need to provide a correct name for llvm-lit including file extension
within LLVM_CONFIG_DEFAULT_EXTERNAL_LIT variable.
Update for commit 45526d29a5.
Differential Revision: https://reviews.llvm.org/D79144
Petr Hosek