Use this function to create the install targets rather than doing so
manually, which gains us the `-stripped` install targets to perform
stripped installations.
Differential Revision: https://reviews.llvm.org/D40675
llvm-svn: 319489
When LLVM_BUILD_EXTERNAL_COMPILER_RT option is set to true,
all of projects in compiler-rt are built with a freshly-built compiler using
a recursive CMake invocation.
(e.g. that's how compiler-rt is used in Swift)
Just now I have noticed that libFuzzer binaries were missing in such a case,
and ninja fuzzer returned "no such target", while ninja asan worked just fine.
To my surprise, the list of allowed targets was actually hardcoded in Clang!
While the current setup is clearly suboptimal, for the lack of a better fix
I'm just adding `fuzzer` to a list of `compiler-rt` targets.
Differential Revision: https://reviews.llvm.org/D38904
llvm-svn: 315771
This is a resubmission of r313270. It broke standalone builds of
compiler-rt because we were not correctly generating the llvm-lit
script in the standalone build directory.
The fixes incorporated here attempt to find llvm/utils/llvm-lit
from the source tree returned by llvm-config. If present, it
will generate llvm-lit into the output directory. Regardless,
the user can specify -DLLVM_EXTERNAL_LIT to point to a specific
lit.py on their file system. This supports the use case of
someone installing lit via a package manager. If it cannot find
a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or
invalid, then we print a warning that tests will not be able
to run.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313407
This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix is, but I want to get the bots green
for now and then try re-applying in the morning.
llvm-svn: 313335
The recent lit refactor changed the location of the lit script
run by check targets from <source>/utils/lit/lit.py to
<bin>/llvm-lit.py. In some 2-stage build scenarios, the location
of <bin> was not properly passed through to the second stage,
and it was looking for /llvm-lit.py instead, causing failures.
Fix suggested by Mike Edwards and Chris Bieneman @apple
llvm-svn: 313300
This breaks some Swift builds, because Swift's build scripts explicitly set CMAKE_OSX_DEPLOYMENT_TARGET. This however isn't propagated to the compiler-rt build, causing build errors.
Differential Revision: https://reviews.llvm.org/D26558
llvm-svn: 286898
This correctly connects compiler-rt-test-depends to test-depends and
check-compiler-rt to check-all.
Based on LLVM r280392, and Compiler-RT r280393.
llvm-svn: 280394
When using the LLVM_BUILD_EXTERNAL_COMPILER_RT option with
LLVM_ENABLE_TESTS we should also bind check-compiler-rt to check-all so
that the compiler-rt tests run too.
llvm-svn: 274045
Now that we're on CMake 3.4.3 all the ExternalProject features we use are supported everywhere, so we don't need the version checks anymore.
llvm-svn: 272324
It makes compiler-rt tests fail if the gold plugin is enabled.
Revert "Rework interface for bitset-using features to use a notion of LTO visibility."
Revert "Driver: only produce CFI -fvisibility= error when compiling."
Revert "clang/test/CodeGenCXX/cfi-blacklist.cpp: Exclude ms targets. They would be non-cfi."
llvm-svn: 267871
Bitsets, and the compiler features they rely on (vtable opt, CFI),
only have visibility within the LTO'd part of the linkage unit. Therefore,
only enable these features for classes with hidden LTO visibility. This
notion is based on object file visibility or (on Windows)
dllimport/dllexport attributes.
We provide the [[clang::lto_visibility_public]] attribute to override the
compiler's LTO visibility inference in cases where the class is defined
in the non-LTO'd part of the linkage unit, or where the ABI supports
calling classes derived from abstract base classes with hidden visibility
in other linkage units (e.g. COM on Windows).
If the cross-DSO CFI mode is enabled, bitset checks are emitted even for
classes with public LTO visibility, as that mode uses a separate mechanism
to cause bitsets to be exported.
This mechanism replaces the whole-program-vtables blacklist, so remove the
-fwhole-program-vtables-blacklist flag.
Because __declspec(uuid()) now implies [[clang::lto_visibility_public]], the
support for the special attr:uuid blacklist entry is removed.
Differential Revision: http://reviews.llvm.org/D18635
llvm-svn: 267784
This patch introduces the -fwhole-program-vtables flag, which enables the
whole-program vtable optimization feature (D16795) in Clang.
Differential Revision: http://reviews.llvm.org/D16821
llvm-svn: 261767
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"This is the way [autoconf] ends
Not with a bang but a whimper."
-T.S. Eliot
Reviewers: chandlerc, grosbach, bob.wilson, echristo
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D16472
llvm-svn: 258862
The add_dependencies call on compiler-rt-configure adds llvm-config and clang to the phony target, but not to the actual configure custom command. We need the dependency bound to the custom command so that it can't be re-ordered by Ninja.
llvm-svn: 255798
When passing around CMake arguments as lists of arguments any arguments containing lists need to have their semi-colons escaped otherwise CMake will split the arguments in the middle.
llvm-svn: 253720
This allows COMPILER_RT_* variables to be passed from the top-level CMake into the external project when LLVM_BUILD_EXTERNAL_COMPILER_RT=On.
llvm-svn: 252809
The required compiler-rt changes aren't present yet so attempting to
build with compiler-rt breaks. And since we're trying to deprecate
autotools we actually want to fix this in CMake primarily anyway.
This reverts r251712.
llvm-svn: 251953
This change makes LLVM_BUILD_EXTERNAL_COMPILER_RT work correctly when overriding CMAKE_INSTALL_PREFIX on the install action (which is how LLVM_CREATE_XCODE_TOOLCHAIN works).
This fix is two parts:
(1) Pass CMAKE_INSTALL_PREFIX in as a variable from the parent install to the child install
(2) When passing COMPILER_RT_INSTALL_PATH into the external project make sure it is passed as a string not a path.
Not specifying the full path for COMPILER_RT_INSTALL_PATH isn't enough to fix the issue because relative paths specified on the CMake command line are expanded relative to the working directory before the cache is populated. Forcing this to a string allows it to remain a relative path through to the install() calls. Relative paths specified in install() calls are expanded relative to CMAKE_INSTALL_PREFIX at install time.
llvm-svn: 250834
Summary:
Many small improvements to LLVM_BUILD_EXTERNAL_COMPILER_RT.
* Works correctly with Ninja by working around CMake Bug 14771 (https://cmake.org/Bug/view.php?id=14771)
* Has install-compiler-rt target, and installs as part of the default install target
* Sets the install paths properly so that it matches the non-standalone build
* Only generate the test targets if(LLVM_INCLUDE_TESTS)
Reviewers: samsonov, Bigcheese
Differential Revision: http://reviews.llvm.org/D13399
llvm-svn: 250064
Summary: When LLVM/Clang is built without ARM support, the ios_kext runtime
library is not built, but without this patch, the Makefile still tries to
copy it. This is a recent regression, because the ios_kext library used
to also be built on x86_64.
Reviewers: beanz
Subscribers: aemerson, cfe-commits, rengolin
Differential Revision: http://reviews.llvm.org/D13421
llvm-svn: 249281
Summary:
This corresponds to a patch to compiler-rt (D13112).
Xcode 7 doesn't support targeting iOS5 and earlier. Instead of just dropping cc_kext_ios5, I've repurposed it to cc_kext_ios, and I'm pulling the iOS architectures out of cc_kext. Putting OS X and iOS slices inside the same archive was just odd.
Reviewers: bogner, bob.wilson
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13113
llvm-svn: 248442
Summary:
UBSan is now used in the same way as ASan, and is supported on
OSX and on iOS simulator. At the moment ASan and UBSan can't be used
together due to PR21112, but I hope to resolve it soon by
embedding UBSan into ASan.
Test Plan: regression test suite.
Reviewers: zaks.anna, kubabrecka
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8471
llvm-svn: 233035
They autotools build has a number of missing features, supports less
OS, architectures, build configurations, doesn't have any tests and
is hard to support in sync with CMake build.
llvm-svn: 229554
This reverts the runtime library portion of r194168. As of r221621,
the libclang_rt libraries for Darwin build with explicit SDK options
so there is no need to set SDKROOT here.
llvm-svn: 221625
This was already set up for the iOS simulator ASan dylib simulator,
and this change extends that to the other iOS runtime libraries.
This is in preparation for building all those iOS libraries against
the real SDKs instead of the fake SDKs in compiler-rt.
llvm-svn: 221614
Shoaib Meenai