Commit Graph

1086 Commits

Author SHA1 Message Date
Bob Haarman
955228a2c6 enable building with LTO on Windows using clang-cl and lld
Summary: With clang-cl gaining support for link-time optimization, we can now enable builds using LTO when using clang-cl and lld on Windows. To do this, we must not pass the -flto flag to the linker; lld-link does not understand it, but will perform LTO automatically when it encounters bitcode files. We also don't pass /Brepro when using LTO - the compiler doesn't generate object files for LTO, so passing the flag would only result in a warning about it being unused.

Reviewers: rnk, ruiu, hans

Reviewed By: hans

Subscribers: mgorny, mehdi_amini, llvm-commits

Differential Revision: https://reviews.llvm.org/D30240


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296658 91177308-0d34-0410-b5e6-96231b3b80d8
2017-03-01 19:22:18 +00:00
Michal Gorny
39b10e911b [Support] Provide linux/magic.h fallback for older kernels
The function for distinguishing local and remote files added in r295768
unconditionally uses linux/magic.h header to provide necessary
filesystem magic numbers. However, in kernel headers predating 2.6.18
the magic numbers are spread throughout multiple include files.
Furthermore, LLVM did not require kernel headers being installed so far.

To increase the portability across different versions of Linux kernel
and different Linux systems, add CMake header checks for linux/magic.h
and -- if it is missing -- the linux/nfs_fs.h and linux/smb.h headers
which contained the numbers previously.

Furthermore, since the numbers are static and the feature does not seem
critical enough to make LLVM require kernel headers at all, add fallback
constants for the case when none of the necessary headers is available.

Differential Revision: https://reviews.llvm.org/D30261

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295854 91177308-0d34-0410-b5e6-96231b3b80d8
2017-02-22 18:09:15 +00:00
Petr Hosek
8cea2afdc7 [CMake] Support externalizing debug info on non-Darwin platforms
On other platorms, we use objcopy to export the debug info.

Differential Revision: https://reviews.llvm.org/D28575

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295481 91177308-0d34-0410-b5e6-96231b3b80d8
2017-02-17 19:29:12 +00:00
Chris Bieneman
36d946dcba [CMake] Add variable IOS to iOS toolchain
This is useful for some edge cases where detecting things gets tricky. Specifically LLDB needs this to support iOS because CMake doesn't support running tests using obj-c code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295392 91177308-0d34-0410-b5e6-96231b3b80d8
2017-02-17 01:11:41 +00:00
Aditya Nandakumar
3ca564103a [Tablegen] Instrumenting table gen DAGGenISelDAG
To help assist in debugging ISEL or to prioritize GlobalISel backend
work, this patch adds two more tables to <Target>GenISelDAGISel.inc -
one which contains the patterns that are used during selection and the
other containing include source location of the patterns
Enabled through CMake varialbe LLVM_ENABLE_DAGISEL_COV

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295081 91177308-0d34-0410-b5e6-96231b3b80d8
2017-02-14 18:32:41 +00:00
Matthias Braun
4f013f8a83 config-ix.cmake: Search for CMAKE_XCRUN before using it.
This was previously searched in CMakeLists.txt unconditionally but as of
r294371 it is only searched in some circumstances. Repeating the search
in config-ix.cmake to make this robust and hopefully fix the macOS
Asan+Ubsan jenkins build.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294811 91177308-0d34-0410-b5e6-96231b3b80d8
2017-02-11 00:14:01 +00:00
Eric Fiselier
a61fc423f3 [CMake] Fix pthread handling for out-of-tree builds
LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects
to correctly link the threading library when needed. Unfortunately
`PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed
and therefore can't be used when configuring out-of-tree builds. This causes
such builds to fail since `pthread` isn't being correctly linked.

This patch attempts to fix that problem by renaming and exporting
`LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB`
because It seemed likely to cause collisions with downstream users of
`LLVMConfig.cmake`.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294690 91177308-0d34-0410-b5e6-96231b3b80d8
2017-02-10 01:59:20 +00:00
Chris Bieneman
606c50d357 [CMake] Fix standalone project builds broken in r294514
This patch sets the global property indicating that target registration is complete for standalone sub-project builds.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294602 91177308-0d34-0410-b5e6-96231b3b80d8
2017-02-09 18:14:12 +00:00
Chris Bieneman
405386b95e [CMake] Fix is_llvm_target_library and support out-of-order components
Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies.

Reviewers: mgorny, chapuni, bryant

Subscribers: llvm-commits, jgosnell

Differential Revision: https://reviews.llvm.org/D28869

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294514 91177308-0d34-0410-b5e6-96231b3b80d8
2017-02-08 20:58:37 +00:00
Eric Fiselier
9652e72de3 [CMake] Fix USE_LLVM_SANITIZER configuration for out-of-tree builds.
Summary:
r291918 changed `HandleLLVMOptions.cmake` to add `-fsanitize-blacklist=<llvm-file>` when `LLVM_USE_SANITIZER=Undefined` is specified. This breaks out-of-tree users of `LLVM_USE_SANITIZER` since that file is not present.

This patch fixes the issue by checking if the file exists first.

Reviewers: mgorny, bogner, vitalybuka, krasin

Reviewed By: krasin

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D29686

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294367 91177308-0d34-0410-b5e6-96231b3b80d8
2017-02-07 22:48:20 +00:00
Chris Bieneman
d2206e4788 [CMake] Move ninja job pool options to HandleLLVMOptions
Moving the Ninja job pool configuration settings into the HandleLLVMOptions module will allow standalone builds of LLVM sub-projects to use the LLVM options without needing to re-implement them.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294334 91177308-0d34-0410-b5e6-96231b3b80d8
2017-02-07 19:06:22 +00:00
Omair Javaid
367ed08f22 Fix LLDB Android AArch64 GCC debug info build
Committing after fixing suggested changes and tested release/debug builds on 
x86_64-linux and arm/aarch64 builds.

Differential revision: https://reviews.llvm.org/D29042



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293850 91177308-0d34-0410-b5e6-96231b3b80d8
2017-02-02 01:17:49 +00:00
Reid Kleckner
fa35d5c251 Remove LLVM_CONFIG from config headers
It appears to be dead, and it needlessly caused me to rebuild all of
LLVM when I changed CMAKE_INSTALL_PREFIX.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293574 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-31 00:34:23 +00:00
Yichao Yu
eca8aa608d CMake is funky on detecting Intel 17 as GCC compatible.
Summary: This adds a fallback in case that the Intel compiler is failed to be detected correctly.

Reviewers: chapuni

Reviewed By: chapuni

Subscribers: llvm-commits, mgorny

Differential Revision: https://reviews.llvm.org/D27610

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293230 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-26 23:50:18 +00:00
Justin Bogner
92e82c5733 cmake: Only sanitize use-after-scope if the host compiler supports it
In r292256, we started adding -fsanitize-use-after-scope when using
the address sanitizer, but that flag wasn't always available. This
fixes the config to only add the flag if the host compiler supports
it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292423 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-18 19:01:58 +00:00
Vitaly Buka
73275fd4d0 Enabled -fsanitize-address-use-after-scope for -DLLVM_USE_SANITIZER=Address
Subscribers: mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D28823

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292256 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-17 21:04:23 +00:00
Michal Gorny
e3aa75949b [cmake] Update SOVERSION for the new versioning scheme
Update SOVERSION to use just the major version number rather than
major+minor, to match the new versioning scheme where only major is used
to indicate API/ABI version.

Since two-digit SOVERSIONs were introduced post 3.9 branching, this
change does not risk any SOVERSION collisions. In the past,
two-component X.Y SOVERSIONs were shortly used but those will not
interfere with the new ones since the new versions start at 4.

Differential Revision: https://reviews.llvm.org/D28730

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292255 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-17 21:04:19 +00:00
Mehdi Amini
a9134d2526 Add a LLVM_USE_LINKER that defines the linker to use when building LLVM
Summary:
This string parameter is passed to -fuse-ld when linking. It can be
an absolute path to your custom linker, otherwise clang will look for
`ld.{name}`.

Reviewers: davide, tejohnson, pcc

Subscribers: llvm-commits, mgorny

Differential Revision: https://reviews.llvm.org/D28738

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292047 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-15 03:21:30 +00:00
Ivan Krasin
eccbfd44dd Fix UBSan bots by blacklisting bits/stl_tree.h.
Summary:
libstdc++ has some undefined behavior in bits/stl_tree.h that
has recently became excercised by some of the LLVM code.
Given that fixing libstdc++ will take years, adding the file
into a blacklist to fix bots seems like a necessity.

Reviewers: vitalybuka

Subscribers: llvm-commits, mgorny

Differential Revision: https://reviews.llvm.org/D28686

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291918 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-13 17:30:10 +00:00
Rui Ueyama
bdb13d2c7c Add -Wl,-color-diagnostics if a linker supports the option.
Differential Revision: https://reviews.llvm.org/D28046

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291719 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-11 22:55:35 +00:00
Chandler Carruth
054b6040e5 Add the 'googlemock' component of Google Test to LLVM's unittest libraries.
I have two immediate motivations for adding this:
1) It makes writing expectations in tests *dramatically* easier. A
   quick example that is a taste of what is possible:

     std::vector<int> v = ...;
     EXPECT_THAT(v, UnorderedElementsAre(1, 2, 3));

   This checks that v contains '1', '2', and '3' in some order. There
   are a wealth of other helpful matchers like this. They tend to be
   highly generic and STL-friendly so they will in almost all cases work
   out of the box even on custom LLVM data structures.

   I actually find the matcher syntax substantially easier to read even
   for simple assertions:

     EXPECT_THAT(a, Eq(b));
     EXPECT_THAT(b, Ne(c));

   Both of these make it clear what is being *tested* and what is being
   *expected*. With `EXPECT_EQ` this is implicit (the LHS is expected,
   the RHS is tested) and often confusing. With `EXPECT_NE` it is just
   not clear. Even the failure error messages are superior with the
   matcher based expectations.

2) When testing any kind of generic code, you are continually defining
   dummy types with interfaces and then trying to check that the
   interfaces are manipulated in a particular way. This is actually what
   mocks are *good* for -- testing *interface interactions*. With
   generic code, there is often no "fake" or other object that can be
   used.

   For a concrete example of where this is currently causing significant
   pain, look at the pass manager unittests which are riddled with
   counters incremented when methods are called. All of these could be
   replaced with mocks. The result would be more effective at testing
   the code by having tighter constraints. It would be substantially
   more readable and maintainable when updating the code. And the error
   messages on failure would have substantially more information as
   mocks automatically record stack traces and other information *when
   the API is misused* instead of trying to diagnose it after the fact.

I expect that #1 will be the overwhelming majority of the uses of gmock,
but I think that is sufficient to justify having it. I would actually
like to update the coding standards to encourage the use of matchers
rather than any other form of `EXPECT_...` macros as they are IMO
a strict superset in terms of functionality and readability.

I think that #2 is relatively rarely useful, but there *are* cases where
it is useful. Historically, I think misuse of actual mocking as
described in #2 has led to resistance towards this framework. I am
actually sympathetic to this -- mocking can easily be overused. However
I think this is not a significant concern in LLVM. First and foremost,
LLVM has very careful and rare exposure of abstract interfaces or
dependency injection, which are the most prone to abuse with mocks. So
there are few opportunities to abuse them. Second, a large fraction of
LLVM's unittests are testing *generic code* where mocks actually make
tremendous sense. And gmock is well suited to building interfaces that
exercise generic libraries. Finally, I still think we should be willing
to have testing utilities in tree even if they should be used rarely. We
can use code review to help guide the usage here.

For a longer and more complete discussion of this, see the llvm-dev
thread here:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/108672.html

The general consensus seems that this is a reasonable direction to start
down, but that doesn't mean we should race ahead and use this
everywhere. I have one test that is blocked on this to land and that was
specifically used as an example. Before widespread adoption, I'm going
to work up some (brief) guidelines as some of these facilities should be
used sparingly and carefully.

Differential Revision: https://reviews.llvm.org/D28156

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291606 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-10 22:32:26 +00:00
Chandler Carruth
2ff6bc0d1d [gtest] Detect warning flags using the positive spelling.
Some GCC versions will accept any warning flag name after a '-Wno-',
which would cause us to try to disable warnings with names GCC didn't
understand. This will silently succeed unless there is some other output
from GCC in which case we get weird cc1plus warnings about the warning
name being bogus.

There is still the issue that gtest sets warning flags for building
gtest-all.cc using weird 'add_definitions' and the fact that there is
a GCC version which warns on the variadic macro usage in gtest under
-pedantic, but has no flag analogous to Clang's
-Wgnu-zero-variadic-macro-argumnets to suppress this warning. I haven't
been able to come up with any good solution here. The closest is to turn
off -pedantic for those versions of GCC, but that seems really nasty.
For now, those versinos of GCC aren't warning clean. If anyone is broken
by this, I'll work on CMake logic to detect and disable -pedantic in
these cases.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291299 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-06 23:16:00 +00:00
Michal Gorny
1159e42199 [cmake] Canonicalize CMake booleans to 0/1 for lit interop
Canonicalize all CMake booleans to 0/1 before passing them to lit, to
ensure that the Python side handles all of them consistently
and correctly. 0/1 is a safe choice of values that trigger the same
boolean interpretation in CMake, Python and C++.

Furthermore, using them without quotes improves the chance Python will
explicitly fail when an incorrect value (such as ON/OFF, TRUE/FALSE,
YES/NO) is accidentally passed, rather than silently misinterpreting
the value.

This replaces a lot of different logics spread around lit site files,
attempting to partially reproduce the boolean logic used in CMake
and usually silently failing when an uncommon value was used instead.
In fact, some of them were never working correctly since different
values were assigned in CMake and checked in Python.

The alternative solution could be to create a common parser for CMake
booleans in lit and use it consistently throughout the site files.
However, it does not seem like the best idea to create redundant
implementation of the same logic and have to follow upstream if it ever
is extended to handle more values.

Differential Revision: https://reviews.llvm.org/D28294

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291284 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-06 21:33:48 +00:00
Bob Wilson
80617ba8c4 Disable sigaltstack on Apple platforms
Using sigaltstack on Apple platforms is a bad idea. Darwin's backtrace()
function does not work with sigaltstack, and my change in r286851 was
supposed to solve that by using _Unwind_Backtrace instead. I tested that
_Unwind_Backtrace works for crashes but then discovered that it does not
work for assertion failures when using sigaltstack, at least on macOS.
The stack trace shows only the frames on the alternate stack.
I also saw some reports of this happening for crashes, but it fails
consistently for assertion failures. I tried various things to get it to
work but the problem seems to be in _Unwind_Backtrace itself. Disabling
sigaltstack is unfortunate since it would be nice to get backtraces for
stack overflows, but at least this gets us backtraces for the more common
cases. rdar://problem/29662459

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291206 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-06 02:26:30 +00:00
Chandler Carruth
b532062f02 [gtest] Fix the way we disable a warning for unittests.
I somehow wrote this fix and then lost it prior to commit. Really sorry
about the noise. This should fix some issues with hacking add_definition
to do things with warning flags.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291033 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-04 23:40:06 +00:00
Chandler Carruth
4be13d6363 [gtest] Upgrade googletest to version 1.8.0, minimizing local changes.
This required re-working the streaming support and lit's support for
'--gtest_list_tests' but otherwise seems to be a clean upgrade.

Differential Revision: https://reviews.llvm.org/D28154

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291029 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-04 23:06:03 +00:00
Zachary Turner
7d92286ad9 Fix the MSVC version check.
I'm not sure what determines the minor version, but it appears
that it's possible for a fully updated, release version of
VS2015 with Update 3 can go (at least) as low as 19.00.24213.1.
Updating the compiler version check to account for this so we
don't generate superfluous warnings.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290914 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-03 23:12:36 +00:00
Michal Gorny
12ec8e1ce1 [cmake] Normalize LLVM_ENABLE_DIA_SDK to fix Windows tests
Attempts to fix Windows build breakage caused by r290818.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290832 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-02 20:22:45 +00:00
Michal Gorny
a50b783ab7 [cmake] Add LLVM_ENABLE_DIA_SDK option, and expose it in LLVMConfig
Add an explicit LLVM_ENABLE_DIA_SDK option to control building support
for DIA SDK-based debugging. Control its value to match whether DIA SDK
support was found and expose it in LLVMConfig (alike LLVM_ENABLE_ZLIB).

Its value is needed for LLDB to determine whether to run tests requiring
DIA support. Currently it is obtained from llvm/Config/config.h;
however, this file is not available for standalone builds. Following
this change, LLDB will be modified to use the value from LLVMConfig.

Differential Revision: https://reviews.llvm.org/D26255

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290818 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-02 18:19:35 +00:00
Chandler Carruth
3abadf484b Enable '-Wstring-conversion' and fix some bad asserts that it helped
find.

Notable is the assert in NewGVN which had no effect because of the bug.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290400 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-23 01:38:06 +00:00
Reid Kleckner
e1c9f504c6 Pass -Wa,-mbig-obj in 64-bit mingw builds
COFF has a 2**16 section limit, and on Win64, every COMDAT function
creates at least 3 sections: .text, .pdata, and .xdata. For MSVC, we
enable bigobj on a file-by-file basis, but GCC appears to hit the limit
on different files.

Fixes PR25953

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290358 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-22 19:12:14 +00:00
Reid Kleckner
36850aafe2 Fix some remaining documentation references to MSVC 2013
MSVC 2015 has been the minimum supported version of VS since October.

Differential Revision: https://reviews.llvm.org/D25710

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289854 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-15 19:08:02 +00:00
Chris Bieneman
69a678c244 [CMake] Minor change to symlink generation for LLDB
If OUTPUT_DIR is not specified we can assume the symlink is linking to a file in the same directory, so we can use $<TARGET_FILE_NAME:${target}> to create a relative symlink.

In the case of LLDB, when we build a framework, we are creating symlinks in a different directory than the file we're pointing to, and we don't install those links. To make this work in the build directory we can use $<TARGET_FILE:${target}> instead, which uses the full path to the target.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289840 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-15 18:17:07 +00:00
Petr Hosek
a923c5a134 [CMake] Multi-target builtins build
This change enables building builtins for multiple different targets
using LLVM runtimes directory.

To specify the builtin targets to be built, use the LLVM_BUILTIN_TARGETS
variable, where the value is the list of targets.  To pass a per target
variable to the builtin build, you can set BUILTINS_<target>_<variable>
where <variable> will be passed to the builtin build for <target>.

Differential Revision: https://reviews.llvm.org/D26652

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289491 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-12 23:15:10 +00:00
Kostya Serebryany
1b6cd25422 [libFuzzer] switch all libFuzzer tests to use -fsanitize-coverage=trace-pc-guard. Support for the previosly used instrumentation will be removed in the following changes
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289311 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-10 02:26:23 +00:00
Reid Kleckner
df156ba084 Remove /Zc:sizedDealloc- from the MSVC build
According to the connect bug
(https://connect.microsoft.com/VisualStudio/feedback/details/1351894),
this was only necessary with pre-release versions of MSVC 2015.

Fixes PR23513

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289257 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-09 19:20:28 +00:00
Peter Collingbourne
4b3d007c4d Re-commit r289184, "Support: Use a 64-bit seek in raw_fd_ostream::seek()." with a configure-time check for lseek64.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289187 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-09 05:20:43 +00:00
Chris Bieneman
c14b21af97 [CMake] Add check for HAVE_CRASHREPORTER_INFO
This was also explicitly undef in CMake for some unknown reason.

Hopefully this one won't kill all the bots.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288977 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-07 20:55:38 +00:00
Chris Bieneman
b7e5e7db85 [CMake] Add a check for HAVE_CRASHREPORTERCLIENT_H
The CMake build has been hardcoding this to undef forever, we shouldn't have been doing that.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288956 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-07 18:53:04 +00:00
Chris Bieneman
461b461526 [CMake] Fixing clang standalone build
I broke this in r288770.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288829 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-06 17:09:29 +00:00
Chris Bieneman
dfe568d766 [CMake] Cleanup TableGen include flags
It is kinda crazy to have llvm/include and llvm/lib/Target in the include path for every tablegen invocation for every tablegen-like tool.

This patch removes those flags from the tablgen function that is called everywhere by instead creating a variable LLVM_TABLEGEN_FLAGS which is setup in the LLVM source directories.

This removes TableGen.cmake's dependency on LLVM_MAIN_SRC_DIR, and LLVM_MAIN_INCLUDE_DIR.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288770 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-06 04:45:11 +00:00
Chris Bieneman
79adb742d1 [CMake] Fix symlink refactor for multi-configuration generators
This fix, while a bit complicated, preserves the reusability while fixing the issues reported on llvm-commits with visual studio generators.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288679 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-05 17:02:11 +00:00
Michal Gorny
02114e6a31 [cmake] Include component in Sphinx install rules
Include component in install rules for Sphinx targets. Based on
a similar suggestion for other doc targets in D24935.

Differential Revision: https://reviews.llvm.org/D24982

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288656 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-05 09:15:05 +00:00
Chris Bieneman
1ef550d3fd [CMake] Refactor add_llvm_tool_symlink for reuse
The old implementation of add_llvm_tool_symlink could fail in odd ways when building out of tree. This version solves that problem by not using the LLVM_* variables, and instead reaeding the target's properties.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288632 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-05 03:28:03 +00:00
Saleem Abdulrasool
0b69b1f43c build: allow specifying the component to llvm_install_symlink
Add an optional parameter to `llvm_install_symlink` which allows the symlink
installation to be placed into a specific component rather than the default
value.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288600 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-03 22:03:24 +00:00
Peter Collingbourne
f75edf088f cmake: Set rpath for loadable modules as well as shared libraries.
This fixes a regression introduced by r285714: we weren't setting the
rpath on LLVMgold.so correctly.

Spotted by mark@chromium.org!

Differential Revision: https://reviews.llvm.org/D27176

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288076 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-28 21:59:14 +00:00
Chris Bieneman
e208042f07 [CMake] Apply sandbox profile to target not directory
When LLVM_DEPENDENCY_DEBUGGING=On we should apply the sandbox only on the target, not the directory. This is important for directories that create more than one target, or for nested directories.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287415 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-19 01:32:09 +00:00
Yichao Yu
dc5eb2165e Add an option to disable libedit
Summary: This should provide the function similar to `--disable-libedit` with the autotools build system, which seems to be missing from the commit (r200595) that adds this.

Reviewers: pcc, beanz

Subscribers: mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D26550

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287293 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-18 01:25:49 +00:00
Petr Hosek
2545ab0251 [CMake] Error when LTO and lld are enabled on Darwin
lld on Darwin does not currently support LTO.

Differential Revision: https://reviews.llvm.org/D26715

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287256 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-17 20:22:49 +00:00
Pavel Labath
b83576ebbd [cmake] Move LLVM_BUILD_STATIC check to an earlier point
Summary:
The motivation for this is to enable correct detection of dlopen() on Android.
Android does not provide a static version of libdl, so if we add the -static flag
after performing the check, it will succeed even though subsequent link steps
will fail. With this change we correctly detect the absence of libdl in a
LLVM_BUILD_STATIC build on Android.

The link itself still does not succeed because the code does not check the result
of this check properly, but I plan to fix that in a separate change.

Reviewers: beanz

Subscribers: danalbert, mgorny, srhines, tberghammer, llvm-commits

Differential Revision: https://reviews.llvm.org/D26463

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287220 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-17 11:22:23 +00:00