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.
Summary: Currently, llvm-lipo is not specified as a dependency, but it is needed when building Darwin-x86_64 runtimes, so I'm adding it to the dependencies lists.
Reviewers: alexshap, beanz, phosek, compnerd, smeenai, mtrent, plotfi, xiaobai
Reviewed By: phosek, smeenai
Subscribers: smeenai, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71429
Summary:
export_symbols.py discards duplicate symbols, assuming they have public definitions, so if we end
up calling it with duplicate libraries we will end up with an inaccurate export list.
Reviewers: jasonliu, stevewan, john.brawn
Reviewed By: john.brawn
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70918
Summary:
This new warning (enabled by -Wextra) fires when a std::move is
redundant, as the default compiler behavior would be to select a move
operation anyway (e.g., when returning a local variable). Unlike
-Wpessimizing-move, it has no performance impact -- it just adds noise.
Currently llvm has about 1500 of these warnings. Unfortunately, the
suggested fix -- removing std::move -- does not work because of some
older compilers we still support. Specifically clang<=3.8 will not use a
move operation if an implicit conversion is needed (Core issue 1579). In
code like "A f(ConvertibleToA a) { return a; }" it will prefer a copy,
or fail to compile if a copy is not possible.
This patch disables that warning to get a meaningful signal out of a GCC
9 build.
Reviewers: rnk, aaron.ballman, xbolva00
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70963
This reverts commit 2e75681b55ab55301022533b203269f5f3d6f909. Restore
the clean up change. The underlying CMake issue was resolved in
372ad32734ecb455f9fb4d0601229ca2dfc78b66.
as it breaks uses of llvm-config --system-libs and the follow-on commit
"build: avoid cached literals being linked against"
This reverts commits 340e7c0b77a7037afefe7255503afe362967b577 and
340e7c0b77a7037afefe7255503afe362967b577.
FindLibXml2 will set the LIBXML2_LIBRARIES variable to the libraries that
we must link against. This will be an empty string if libxml2 is not
found. Avoid hardcoding the library name as xml2 in the configuration.
Simplify the usage in the WindowsManifest library.
On RHEL, the OS tooling (ar, ranlib) is not deterministic by default.
Therefore, we cannot get bit-for-bit identical builds.
The goal of this patch is that it adds the flags required to force determinism.
Differential Revision: https://reviews.llvm.org/D64817
Summary:
Most libraries are defined in the lib/ directory but there are also a
few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining
"Component Libraries" as libraries defined in lib/ that may be included in
libLLVM.so. Explicitly marking the libraries in lib/ as component
libraries allows us to remove some fragile checks that attempt to
differentiate between lib/ libraries and tools/ libraires:
1. In tools/llvm-shlib, because
llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of
all libraries defined in the whole project, there was custom code
needed to filter out libraries defined in tools/, none of which should
be included in libLLVM.so. This code assumed that any library
defined as static was from lib/ and everything else should be
excluded.
With this change, llvm_map_components_to_libnames(LIB_NAMES, "all")
only returns libraries that have been added to the LLVM_COMPONENT_LIBS
global cmake property, so this custom filtering logic can be removed.
Doing this also fixes the build with BUILD_SHARED_LIBS=ON
and LLVM_BUILD_LLVM_DYLIB=ON.
2. There was some code in llvm_add_library that assumed that
libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or
ARG_LINK_COMPONENTS set. This is only true because libraries
defined lib lib/ use LLVMBuild.txt and don't set these values.
This code has been fixed now to check if the library has been
explicitly marked as a component library, which should now make it
easier to remove LLVMBuild at some point in the future.
I have tested this patch on Windows, MacOS and Linux with release builds
and the following combinations of CMake options:
- "" (No options)
- -DLLVM_BUILD_LLVM_DYLIB=ON
- -DLLVM_LINK_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON
Reviewers: beanz, smeenai, compnerd, phosek
Reviewed By: beanz
Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70179
The mlir-tblgen tool was not getting installed. This change allows
the MLIR project to be installed along with llvm-tblgen.
Differential Revision: https://reviews.llvm.org/D69824
Projects that set LLVM_TARGETS_TO_BUILD to an empty list
can't use add_llvm_tool (and probably other macros).
Here's the error that this change fixes:
list sub-command REMOVE_ITEM requires two or more arguments.
https://reviews.llvm.org/D70167
Signed-off-by: Kevin Petit <kevin.petit@arm.com>
Summary:
This makes it look like an elseif and also the variable referenced
in the condition was removed from this function in r366622.
Reviewers: dsanders, beanz, smeenai, compnerd, phosek
Reviewed By: beanz
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70159
Summary:
when building plugins, as AIX has symbols in it's standard library that
must be garbage collected or we will see link errors. Export lists will
handle this instead on AIX.
Reviewers: stevewan, sfertile, jasonliu, xingxue, DiggerLin
Reviewed By: DiggerLin
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70130
Summary:
this allows us to move logic about when it is appropriate set
LLVM_NO_DEAD_STRIP out of each tool and into add_llvm_executable,
which will enable future platform specific handling.
This is a follow on to the reverted D69356
Reviewers: hubert.reinterpretcast, beanz, lhames
Reviewed By: beanz
Subscribers: mgorny, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69638
Also add the aliases for these tools so that
LLVM_INSTALL_BINUTILS_SYMLINKS and LLVM_INSTALL_TOOLCHAIN_ONLY can work
together.
Differential Revision: https://reviews.llvm.org/D69635
This extension point is not needed. Provide the equivalent option
through `CMAKE_CXX_STANDARD` which mirrors the previous extension point. Rely on
CMake to provide the check for the compiler instead.
Summary:
The variable LLVM_NO_DEAD_STRIP is set in LLVM cmake files when building executables that might make use of plugins .The name of the variable does not convey the actual intended usage (i.e. for use with tools that have plugins), just what the eventual effect of setting in on some (i.e. not garbage collecting unused symbols).
This patch renames it to LLVM_SUPPORT_PLUGINS to convey the intended usage, which will allow subsequent patches to add behavior to support that in different ways without confusion about whether it will do on, for example, non-gnu platforms.
Reviewers: hubert.reinterpretcast, stevewan
Reviewed By: stevewan
Subscribers: cfe-commits, mgorny, llvm-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D69356
We're passing LLVM_EXTERNAL_PROJECTS to cross-compilation configures, so
we also need to pass the source directories of those projects, otherwise
configuration can fail from not finding them.
Differential Revision: https://reviews.llvm.org/D69076
llvm-svn: 375157
Support linking OCaml modules against LLVM dylib when requested,
rather than against static libs that might not be installed at all.
Differential Revision: https://reviews.llvm.org/D68452
llvm-svn: 374556
Move the write-if-changed logic behind a flag and don't pass it
with the MSVC generator. msbuild doesn't have a restat optimization,
so not doing write-if-change there doesn't have a cost, and it
should fix whatever causes PR43385.
llvm-svn: 373664
Add install targets as necessary to include all files normally installed
in LLVM_DISTRIBUTION_COMPONENTS. This includes targets for Sphinx docs,
opt-viewer Python modules and TableGens.
Differential Revision: https://reviews.llvm.org/D68339
llvm-svn: 373482
Differential Revision: https://reviews.llvm.org/D55842
-----------------
As discussed on PR43385 this is causing Visual Studio msbuilds to perpetually rebuild all tablegen generated files
llvm-svn: 373338
Serialize the value of the configuration option into the configuration so that
builds which integrate LLVM can identify the value of the flag that was used to
build the libraries. This is intended to be used by Swift to control tests
which rely on the unwind information.
llvm-svn: 373253
Mimics the changes in r372209 to handle the change of quotes in
r372226. Probably isn't sufficient for windows, but unbreaks the cmake
flag at least.
llvm-svn: 372791
Modify LLVMConfig to produce LLVM_USE_CRT variables in build-directory. It helps to set the same compiler debug options like in builded library.
Committed on behalf of @igorban (Igor)
Differential Revision: https://reviews.llvm.org/D67175
llvm-svn: 372610
Fixes quoting of profile arguments to work on Windows
Suppresses adding profile arguments to linker flags when using lld-link
Avoids -fprofile-instr-use being added to rc.exe flags
Removes duplicated adding of -fprofile-instr-use to linker flags (since
r355541)
Move handling LLVM_PROFDATA_FILE to HandleLLVMOptions.cmake
Differential Revision: https://reviews.llvm.org/D62063
llvm-svn: 372209
Tested on VS2017 and VS2019 llvm/clang builds with WX enabled - its no longer necessary to disable this warning.
Differential Revision: https://reviews.llvm.org/D67103
llvm-svn: 370871
Tested on VS2017 and VS2019 llvm/clang builds with WX enabled - its no longer necessary to disable this warning.
Differential Revision: https://reviews.llvm.org/D67047
llvm-svn: 370866
In r370135 I committed a temporary workaround for the sanitized bot to
not set (DY)LD_LIBRARY_PATH when (DY)LD_INSERT_LIBRARIES was set.
Setting (DY)LD_LIBRARY_PATH is only necessary for (standalone)
shared-library builds, so a better solution is to only set the
environment variable when necessary.
Differential revision: https://reviews.llvm.org/D67012
llvm-svn: 370549
As promised, I've updated the comment for the C4324 MSVC warning that was re-disabled at rL367409 / rG8f823e63e3edf87ab029ba32b68f3eb5d2f392b5 to put it in terms of currently supported VS versions
llvm-svn: 369368
Address post-commit comment on D66256 regarding the `else( MSVC )` block
containing only blocks guarded with `LLVM_COMPILER_IS_GCC_COMPATIBLE`,
which would imply `NOT MSVC`.
llvm-svn: 369221
Summary:
LLVM now requires C++14. For IBM XL compilers with C++14 support, this
can be done with the GCC-style options. The relevant block in the CMake
file is split up into smaller parts as part of this patch to allow the
common cases to be shared.
Reviewers: jfb, jasonliu, daltenty, xingxue
Reviewed By: jfb, xingxue
Subscribers: mstorsjo, mgorny, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66256
llvm-svn: 369058
It is sometimes useful to have the C++ standard library linked into the
assembly when compiling clang, particularly when distributing a compiler
onto systems that don't have a copy of stdlibc++ or libc++ installed.
This functionality should work with either GCC or Clang as the host
compiler, though statically linking libc++ (as may be required for
licensing purposes) is only possible if the host compiler is Clang with
a copy of libc++ available.
Differential Revision: https://reviews.llvm.org/D65603
llvm-svn: 368907
Summary:
Back in January I changed the minimum toolchain version required to build clang
and LLVM: D57264. Since then we've release LLVM 8, following
[our process](http://llvm.org/docs/DeveloperPolicy.html#toolchain)
it's therefore now a good time to remove the soft-error and officially deprecate
older toolchains. I tried this out last Tursday night to see if any bots
complained, and I saw no complaints. I also manually audited bots and didn't see
any bot that should break, but their toolchain information is unreliable and
some bots are offline.
Once this patch stick we'll move to C++14 as we've
[already agreed](http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html).
Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, EricWF, thakis, chandlerc
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66188
llvm-svn: 368799
It's been in for more than 30 min and no bots have complained. Let's see if some
slow ones catch up. I'll do another manual pass on bots later (in case some that
were down are back up), and then turn this on permanently through a regular
review.
llvm-svn: 368253
