Summary:
As it was, always exporting LLVM_LINK_LLVM_DYLIB caused out-of-tree
clients to lose the ability to link against the dylib, even if in-tree tools did
not. By only exporting the setting if it is enabled, out-of-tree clients get the
correct default, but may still choose if they can.
Reviewers: mgorny, beanz, labath, bogner, chandlerc
Reviewed By: bogner, chandlerc
Subscribers: bollu, llvm-commits
Differential Revision: https://reviews.llvm.org/D49843
llvm-svn: 338119
It looks like currently the UBSan blacklist is only applied when "Undefined" is selected.
This patch updates the cmake file to apply it whenever Undefined is selected
(e.g. 'Address; Undefined' ). This allows us to use the workaround added in
rL335525 when using AddressSan and UBSan together.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D49558
llvm-svn: 337539
It fires on things like SmallVector<std::pair<int, int>>, where we
intentionally use memcpy instead of calling the assignment operator.
This warning fires in practically every LLVM TU, so we have to do
something about it, even if we aren't interested in being 100% warning
clean with GCC.
Reported as PR37337
llvm-svn: 337492
Summary:
When building out-of-tree tools, there are several macros available to
automate linking against llvm. An examples is `add_llvm_executable`, or
the clang variant of this.
These macros use the LLVM_LINK_LLVM_DYLIB option to decide whether to
link against libraries defined by setting LLVM_LINK_COMPONENTS or to
link against libLLVM instead. Currently this is problematic in
out-of-tree targets, because they cannot identify whether this option is
required or even available. If the option was enabled in LLVM's own
build, the clang libraries are built against libLLVM, so a client
linking against those must link against it too. On the other hand the
client can't just always link against it, because it might not be
available.
This is related to D44391, but that change assumed the client knew
whether they wanted the dylib or not.
Reviewers: mgorny, beanz, labath
Reviewed By: mgorny
Subscribers: bollu, llvm-commits
Differential Revision: https://reviews.llvm.org/D49193
llvm-svn: 337366
This is necessary to make install-<target>-stripped work for
external projects such as runtimes.
Differential Revision: https://reviews.llvm.org/D49335
llvm-svn: 337115
Automatically codesign all executables and dynamic libraries if a
codesigning identity is given (via LLVM_CODESIGNING_IDENTITY). This
option is darwin only for now.
Also update platforms/iOS.cmake to pick up the right versions of
codesign and codesign_allocate.
llvm-svn: 336708
The test is about what can be run on the host, not the cmake target.
When cross-compiling (compiler-rt at least) on Windows, we end up with
lit being unable to run llvm-lit because it can't find the llvm-lit
module.
llvm-svn: 335961
This allows overriding the strip and dsymutil tools, and updates
iOS.cmake to do so. I've also added libtool to iOS.cmake, but it was
already respecting CMAKE_LIBTOOL if set.
llvm-svn: 335900
LLVM currently assumes that Apple platforms will always use ld64. In the
future, LLD Mach-O might also be supported, so add the beginnings of
linker detection support. ld64 is currently the only detected linker,
since `ld64.lld -v` doesn't yield any useful version output, but we can
add that detection later, and in the meantime it's still useful to have
the ld64 identification.
Switch clang's order file check to use this new detection rather than
just checking for the presence of an ld64 executable.
Differential Revision: https://reviews.llvm.org/D48201
llvm-svn: 334780
This is needed when the external projects try to use other tools
besides just the compiler and the linker.
Differential Revision: https://reviews.llvm.org/D47833
llvm-svn: 334136
Summary:
The macro parses out the USE_SHARED option out of the argument list, but
then ignores it and accesses the variable with the same name instead. It
seems the intention here was to check the argument value.
Technically, this is NFC, because the only in-tree usage
(add_llvm_executable) of USE_SHARED sets both the variable and the
argument when calling llvm_config, but it makes the usage of this macro
for out-of-tree users more sensible.
Reviewers: mgorny, beanz
Reviewed By: mgorny
Subscribers: foutrelis, llvm-commits
Differential Revision: https://reviews.llvm.org/D44420
llvm-svn: 334082
The return value of sys::getDefaultTargetTriple, which is derived from
-DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default target,
and in the future also to control the search path directly; as such it
should be used textually, without interpretation by LLVM.
Normalization of this value may lead to unexpected results, for example
if we configure LLVM with -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu,
normalization will transform that value to x86_64--linux-gnu. Driver will
use that value to search for tools prefixed with x86_64--linux-gnu- which
may be confusing. This is also inconsistent with the behavior of the
--target flag which is taken as-is without any normalization and overrides
the value of LLVM_DEFAULT_TARGET_TRIPLE.
Users of sys::getDefaultTargetTriple already perform their own
normalization as needed, so this change shouldn't impact existing logic.
Differential Revision: https://reviews.llvm.org/D46910
llvm-svn: 332750
This behavior has been the default for a long time, so the default value is On, however this can make it difficult to debug sanitizer failures, so we should have an option to turn it off.
llvm-svn: 332628
Don't hardcode objcopy and strip names, rather use CMAKE_OBJCOPY and
CMAKE_STRIP variables which allows users to override the tools used
such as using llvm-objcopy and llvm-strip instead of binutils versions.
Differential Revision: https://reviews.llvm.org/D46611
llvm-svn: 331827
This change causes us to re-run tablegen for every single target on
every single build. This is much, much worse than the problem being
fixed AFAICT.
On my system, it makes a clean rebuild of `llc` with nothing changed go
from .5s to over 8s. On systems with less parallelism, slower file
systems, or high process startup overhead this will be even more
extreme.
The only way I see this could be a win is in clean builds where we churn
the filesystem. But I think incremental rebuild is more important, and
so if we want to re-instate this, it needs to be done in a way that
doesn't trigger constant re-runs of tablegen.
llvm-svn: 331702
These are necessary changes to support building LLVM for Fuchsia.
While these are not sufficient to run on Fuchsia, they are still
useful when cross-compiling LLVM libraries and runtimes for Fuchsia.
Differential Revision: https://reviews.llvm.org/D46345
llvm-svn: 331423
See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
I replaced all uses of LLVM_ON_WIN32 with _WIN32 in r331127 (llvm),
r331069 (clang), r329697 (lldb), r329696 (lld), r329696 (clang-tools-extra).
If your out-of-tree program used LLVM_ON_WIN32, just use _WIN32 instead, which
is set at exactly the same time to exactly the same value.
https://reviews.llvm.org/D46264
llvm-svn: 331224
LLVM might be compiled using a toolchain file which controls the linker
to use via flags (e.g. `-B` or `-fuse-ld=`). Take these flags into
account for linker detection. We can also correct the detection by
manually passing LLVM_USE_LINKER, of course, but it seems more
convenient to have the detection take flags into account.
Differential Revision: https://reviews.llvm.org/D45464
llvm-svn: 330924
Virtually all other tablegen outputs are called .inc, not .gen, so rename these two too for consistency.
No behavior change.
https://reviews.llvm.org/D46058
llvm-svn: 330843
-stdlib=libc++ is added to both the compilation and the link flags, but
the logic for adding it was only checking if it was supported during
compilation and not linking. This could lead to false positives, for
example when using clang with libstdc++ (where the compiler would
support -stdlib=libc++ but then linking would fail because of libc++
actually being unavailable).
llvm-svn: 330761
Removes one subprocess and one temp file from the build for each tablegen
invocation.
No intended behavior change.
https://reviews.llvm.org/D45899
llvm-svn: 330742
This reverts SVN r330158.
Seems that there was a change to linker flags handling in SVN r316972.
That would alter the behaviour to correct the linker flag handling in
CMake (requiring CMake 3.4.3+). Since that is already the minimum
version required for LLVM, hard coding the knowledge of the linker is
not required, which is a strictly better solution.
llvm-svn: 330161
When building out-of-tree compilers (e.g. swift), the linker check here
may yield incorrect values. Ensure that we are using lld before we
attempt to use `--color-diagnostics` for the linker. Other linkers (i.e
bfd, gold) do not support this flag and the test can pass in some cases
and then fail subsequently when building.
llvm-svn: 330158
Summary:
As we are only doing X.0.Z releases (not using the minor version), there is no need to keep -X.Y in the version.
Like patch https://reviews.llvm.org/D41808, I propose that we rename libLLVM-7.0svn.so to libLLVM-7svn.so
This patch will also rename downstream libraries like liblldb-7.0 to liblldb-7
Reviewers: axw, beanz, dim, hans
Reviewed By: dim, hans
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D41869
llvm-svn: 328768
Cmake function llvm_check_source_file_list currently only accepts paths
relative to current CMAKE_SOURCE_DIR or relative to argument SOURCE_DIR.
Extend it to accept any path, including absolute ones.
Differential revision: https://reviews.llvm.org/D44625
llvm-svn: 327912
Summary:
This is needed so that external projects (e.g. a standalone build of
lldb) can link to the LLVM shared library via the USE_SHARED argument of
llvm_config. Without this, llvm_config would add LLVM to the link list,
but then also add the constituent static libraries, resulting in
multiply defined symbols.
Reviewers: beanz, mgorny
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44391
llvm-svn: 327484
Append -Wl,-rpath-link conditionally to whether GNU ld.bfd is used
rather than the Linux+!gold conditionals. Also move it out of 'else'
branch of *BSD handling. This fixes build failures with ld.bfd
on Gentoo/FreeBSD, and should cause no harm on other systems using
ld.bfd.
This patch improves the original logic by reusing results of linker
detection introduced in r307852.
Differential Revision: https://reviews.llvm.org/D43751
llvm-svn: 327007
Summary:
It can be useful for tools to be able to retrieve the values of variables
declared via STATISTIC() directly without having to emit them and parse
them back. Use cases include:
* Needing to report specific statistics to a test harness
* Wanting to post-process statistics. For example, to produce a percentage of
functions that were fully selected by GlobalISel
Make this possible by adding llvm::GetStatistics() which returns an
iterator_range that can be used to inspect the statistics that have been
touched during execution. When statistics are disabled (NDEBUG and not
LLVM_ENABLE_STATISTICS) this method will return an empty range.
This patch doesn't address the effect of multiple compilations within the same
process. In such situations, the statistics will be cumulative for all
compilations up to the GetStatistics() call.
Reviewers: qcolombet, rtereshin, aditya_nandakumar, bogner
Reviewed By: rtereshin, bogner
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D43901
This re-commit fixes a missing include of <vector> which it seems clang didn't
mind but G++ and MSVC objected to. It seems that, clang was ok with std::vector
only being forward declared at the point of use since it was fully defined
eventually but G++/MSVC both rejected it at the point of use.
llvm-svn: 326738
Despite building cleanly on my machine in three separate configs, it's failing on pretty much all bots due to missing includes among other things. Investigating.
llvm-svn: 326726
Summary:
It can be useful for tools to be able to retrieve the values of variables
declared via STATISTIC() directly without having to emit them and parse
them back. Use cases include:
* Needing to report specific statistics to a test harness
* Wanting to post-process statistics. For example, to produce a percentage of
functions that were fully selected by GlobalISel
Make this possible by adding llvm::GetStatistics() which returns an
iterator_range that can be used to inspect the statistics that have been
touched during execution. When statistics are disabled (NDEBUG and not
LLVM_ENABLE_STATISTICS) this method will return an empty range.
This patch doesn't address the effect of multiple compilations within the same
process. In such situations, the statistics will be cumulative for all
compilations up to the GetStatistics() call.
Reviewers: qcolombet, rtereshin, aditya_nandakumar, bogner
Reviewed By: rtereshin, bogner
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D43901
llvm-svn: 326723
Introduce the LLVM_ENABLE_PDB option so that users can request them
explicitly instead.
Add /OPT:REF and /OPT:ICF back, which /DEBUG disables by default.
Differential Revision: https://reviews.llvm.org/D43156
llvm-svn: 325296
This patch enables PDB generation for Release build, which has
slightly different optimize option with RelWithDebInfo on windows.
This helps to know slow part of Release build when profiling.
Patch by Takuto Ikuta
Differential Revision: https://reviews.llvm.org/D42632
llvm-svn: 324504
Summary:
Rename LLVM_CONFIG_EXE to LLVM_CONFIG_PATH, and avoid building it if
passed in by user. This is the same way CLANG_TABLEGEN and
LLVM_TABLEGEN are handled, e.g., when -DLLVM_OPTIMIZED_TABLEGEN=ON is
passed.
Differential Revision: https://reviews.llvm.org/D41806
llvm-svn: 323053
Include the LLVM_LIBXML2_ENABLED cache variable in LLVMConfig.cmake
in order to make it available for other LLVM packages to query. This
is necessary to fix stand-alone testing of LLD.
Differential Revision: https://reviews.llvm.org/D42252
llvm-svn: 322973
Summary:
Currently LLVM has no way to support configuring for IDE's like CLion. Like XCode and MSVC's IDE, CLion needs to see all of the headers and tablegen files in order to properly parse the sources.
This patch adds an `LLVM_ENABLE_IDE` option which can be used to configure for IDE's in general. It is used by `LLVMProcessSources.cmake` to determine if the extra source files should be added to the target.
Unfortunately because of the low level of `LLVMProcessSources.cmake`, I'm not sure where the `LLVM_ENABLE_IDE` option should live. I choose `HandleLLVMOptions.cmake` so that out-of-tree Clang builds would correctly configure the option by default.
Reviewers: beanz, mgorny, lebedev.ri
Reviewed By: beanz
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40219
llvm-svn: 322349
When cross-compiling for Windows on Unix, the built toolchain will need
to be transferred to Windows to actually run. My opinion is that the
Unix build should use symlinks, and the transfer to Windows should take
care of making those symlinks usable. E.g., I envision tarballs to be a
common form of transfer from Unix to Windows, in which case the tarball
can be created using --dereference to follow the symlinks.
The motivation here is that, when cross-compiling for Windows on Unix,
the installation will *already* create symlinks. The reason is that the
installation script will be invoked without knowing the host system, so
the `if(UNIX)` check in the installation symlink creation script will
reflect the build system rather than the host system. We could either
make the build and install trees both contain copies or both contain
symlinks, and using symlinks is a significant space saving without (in
my opinion) having any detrimental effect on the usage of the cross-
compiled toolchain on Windows.
A secondary motivation is that Windows 10 version 1703 and later finally
lift the administrator rights requirement for creating symbolic links
(if the system is in Developer Mode), which makes symlinks a lot more
practical even on Windows. Of course Unix and Windows symlinks aren't
interoperable, but symlinks for Windows toolchains is a reasonable
future direction to be going in anyway.
Differential Revision: https://reviews.llvm.org/D41314
llvm-svn: 322061
When cross-compiling, we cannot use the just built toolchain, instead
we need to use the host toolchain which we assume has a support for
targeting the selected target platform. We also need to pass the path
to the native version of llvm-config to external projects.
Differential Revision: https://reviews.llvm.org/D41678
llvm-svn: 322046
If the make program isn't in the path, the native configure will fail.
Pass CMAKE_MAKE_PROGRAM to the native configure explicitly to remedy
this, similar to what's already done for external project configuration.
Explicitly set CMAKE_MAKE_PROGRAM before the user flags so that they can
override it for the native build if they desire (though I can't fathom
why that would be useful).
llvm-svn: 322032
Summary:
Always respect existing CMAKE_REQUIRED_FLAGS when adding
additional ones. This is important when cross compiling where
--sysroot and -target were already added.
In particular, this is needed when cross compiling from Darwin to
Linux, since --sysroot is required to find headers and libraries.
Cmake has a similar bug in check_include_file[_cxx] where
CMAKE_REQUIRED_LIBRARIES isn't passed, which causes
try_compile to fail.
(please see https://gitlab.kitware.com/cmake/cmake/merge_requests/1620)
Reviewers: compnerd, silvas, beanz, brad.king
Reviewed By: compnerd
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D41568
llvm-svn: 321434
Hans Wennborg