summaryrefslogtreecommitdiffstats
path: root/llvm/cmake
Commit message (Collapse)AuthorAgeFilesLines
...
* [CMake] Move ninja job pool options to HandleLLVMOptionsChris Bieneman2017-02-071-0/+24
| | | | | | 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. llvm-svn: 294334
* Fix LLDB Android AArch64 GCC debug info buildOmair Javaid2017-02-021-0/+1
| | | | | | | | | 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 llvm-svn: 293850
* Remove LLVM_CONFIG from config headersReid Kleckner2017-01-311-2/+0
| | | | | | | It appears to be dead, and it needlessly caused me to rebuild all of LLVM when I changed CMAKE_INSTALL_PREFIX. llvm-svn: 293574
* CMake is funky on detecting Intel 17 as GCC compatible.Yichao Yu2017-01-261-0/+2
| | | | | | | | | | | | | | 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 llvm-svn: 293230
* cmake: Only sanitize use-after-scope if the host compiler supports itJustin Bogner2017-01-181-1/+2
| | | | | | | | | 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. llvm-svn: 292423
* Enabled -fsanitize-address-use-after-scope for -DLLVM_USE_SANITIZER=AddressVitaly Buka2017-01-171-0/+3
| | | | | | | | Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D28823 llvm-svn: 292256
* [cmake] Update SOVERSION for the new versioning schemeMichal Gorny2017-01-171-5/+3
| | | | | | | | | | | | | | | 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 llvm-svn: 292255
* Add a LLVM_USE_LINKER that defines the linker to use when building LLVMMehdi Amini2017-01-151-3/+13
| | | | | | | | | | | | | | | 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 llvm-svn: 292047
* Fix UBSan bots by blacklisting bits/stl_tree.h.Ivan Krasin2017-01-131-0/+2
| | | | | | | | | | | | | | | | 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 llvm-svn: 291918
* Add -Wl,-color-diagnostics if a linker supports the option.Rui Ueyama2017-01-112-0/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D28046 llvm-svn: 291719
* Add the 'googlemock' component of Google Test to LLVM's unittest libraries.Chandler Carruth2017-01-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 291606
* [gtest] Detect warning flags using the positive spelling.Chandler Carruth2017-01-062-5/+5
| | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 291299
* [cmake] Canonicalize CMake booleans to 0/1 for lit interopMichal Gorny2017-01-062-7/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 291284
* Disable sigaltstack on Apple platformsBob Wilson2017-01-061-1/+4
| | | | | | | | | | | | | | | | | 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 llvm-svn: 291206
* [gtest] Fix the way we disable a warning for unittests.Chandler Carruth2017-01-041-0/+4
| | | | | | | | 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. llvm-svn: 291033
* [gtest] Upgrade googletest to version 1.8.0, minimizing local changes.Chandler Carruth2017-01-041-0/+2
| | | | | | | | | 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 llvm-svn: 291029
* Fix the MSVC version check.Zachary Turner2017-01-031-2/+2
| | | | | | | | | | 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. llvm-svn: 290914
* [cmake] Normalize LLVM_ENABLE_DIA_SDK to fix Windows testsMichal Gorny2017-01-021-0/+7
| | | | | | Attempts to fix Windows build breakage caused by r290818. llvm-svn: 290832
* [cmake] Add LLVM_ENABLE_DIA_SDK option, and expose it in LLVMConfigMichal Gorny2017-01-022-1/+10
| | | | | | | | | | | | | | | 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 llvm-svn: 290818
* Enable '-Wstring-conversion' and fix some bad asserts that it helpedChandler Carruth2016-12-231-0/+3
| | | | | | | | find. Notable is the assert in NewGVN which had no effect because of the bug. llvm-svn: 290400
* Pass -Wa,-mbig-obj in 64-bit mingw buildsReid Kleckner2016-12-221-0/+7
| | | | | | | | | | | 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 llvm-svn: 290358
* Fix some remaining documentation references to MSVC 2013Reid Kleckner2016-12-151-7/+7
| | | | | | | | MSVC 2015 has been the minimum supported version of VS since October. Differential Revision: https://reviews.llvm.org/D25710 llvm-svn: 289854
* [CMake] Minor change to symlink generation for LLDBChris Bieneman2016-12-151-2/+7
| | | | | | | | 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. llvm-svn: 289840
* [CMake] Multi-target builtins buildPetr Hosek2016-12-121-0/+9
| | | | | | | | | | | | | | 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 llvm-svn: 289491
* [libFuzzer] switch all libFuzzer tests to use ↵Kostya Serebryany2016-12-101-1/+1
| | | | | | -fsanitize-coverage=trace-pc-guard. Support for the previosly used instrumentation will be removed in the following changes llvm-svn: 289311
* Remove /Zc:sizedDealloc- from the MSVC buildReid Kleckner2016-12-091-5/+0
| | | | | | | | | | 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 llvm-svn: 289257
* Re-commit r289184, "Support: Use a 64-bit seek in raw_fd_ostream::seek()." ↵Peter Collingbourne2016-12-091-0/+3
| | | | | | with a configure-time check for lseek64. llvm-svn: 289187
* [CMake] Add check for HAVE_CRASHREPORTER_INFOChris Bieneman2016-12-071-0/+8
| | | | | | | | This was also explicitly undef in CMake for some unknown reason. Hopefully this one won't kill all the bots. llvm-svn: 288977
* [CMake] Add a check for HAVE_CRASHREPORTERCLIENT_HChris Bieneman2016-12-071-0/+1
| | | | | | The CMake build has been hardcoding this to undef forever, we shouldn't have been doing that. llvm-svn: 288956
* [CMake] Fixing clang standalone buildChris Bieneman2016-12-061-0/+4
| | | | | | I broke this in r288770. llvm-svn: 288829
* [CMake] Cleanup TableGen include flagsChris Bieneman2016-12-061-10/+4
| | | | | | | | | | 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. llvm-svn: 288770
* [CMake] Fix symlink refactor for multi-configuration generatorsChris Bieneman2016-12-051-3/+23
| | | | | | This fix, while a bit complicated, preserves the reusability while fixing the issues reported on llvm-commits with visual studio generators. llvm-svn: 288679
* [cmake] Include component in Sphinx install rulesMichal Gorny2016-12-051-0/+2
| | | | | | | | | 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 llvm-svn: 288656
* [CMake] Refactor add_llvm_tool_symlink for reuseChris Bieneman2016-12-051-13/+24
| | | | | | 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. llvm-svn: 288632
* build: allow specifying the component to `llvm_install_symlink`Saleem Abdulrasool2016-12-031-4/+8
| | | | | | | | 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. llvm-svn: 288600
* cmake: Set rpath for loadable modules as well as shared libraries.Peter Collingbourne2016-11-281-0/+1
| | | | | | | | | | | 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 llvm-svn: 288076
* [CMake] Apply sandbox profile to target not directoryChris Bieneman2016-11-191-5/+5
| | | | | | 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. llvm-svn: 287415
* Add an option to disable libeditYichao Yu2016-11-181-1/+3
| | | | | | | | | | | | 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 llvm-svn: 287293
* [CMake] Error when LTO and lld are enabled on DarwinPetr Hosek2016-11-171-0/+3
| | | | | | | | lld on Darwin does not currently support LTO. Differential Revision: https://reviews.llvm.org/D26715 llvm-svn: 287256
* [cmake] Move LLVM_BUILD_STATIC check to an earlier pointPavel Labath2016-11-171-4/+0
| | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 287220
* [CMake] [Darwin] Add support for debugging tablegen dependenciesChris Bieneman2016-11-171-1/+23
| | | | | | | | This patch adds an option to the build system LLVM_DEPENDENCY_DEBUGGING. Over time I plan to extend this to do more complex verifications, but the initial patch causes compile errors wherever there is missing a dependency on intrinsics_gen. Because intrinsics_gen is a compile-time dependency not a link-time dependency, everything that relies on the headers generated in intrinsics_gen needs an explicit dependency. llvm-svn: 287207
* Reverting r285406, which was a temporary workaround to get one of the ↵Aaron Ballman2016-11-141-5/+3
| | | | | | documentation bots upgraded to something newer than GCC 4.7. This restores the check for GCC 4.8. llvm-svn: 286822
* CMake: make LLVM_OPTIMIZED_TABLEGEN friendly with LLVM_EXTERNAL_CLANG_SOURCE_DIRMehdi Amini2016-11-111-0/+5
| | | | | | | | This is need because of clang-tblgen Differential Revision: https://reviews.llvm.org/D26483 llvm-svn: 286560
* cmake: Don't try to install exports if there aren't anyJustin Bogner2016-11-082-2/+8
| | | | | | | | | When using LLVM_DISTRIBUTION_COMPONENTS, it's possible for LLVM's export list to be empty. If this happens the install(EXPORTS) command will fail, but since there isn't anything to install anyway we really just want to skip it. llvm-svn: 286209
* [CMake] Fix llvm_setup_rpath functionMandeep Singh Grang2016-11-081-16/+16
| | | | | | | | | | | | | | | | | | | Summary: Set _install_rpath to CMAKE_INSTALL_RPATH if it is defined, so that eventually INSTALL_RPATH is set to CMAKE_INSTALL_RPATH. The "if(NOT DEFINED CMAKE_INSTALL_RPATH)" was missing a corresponding else clause. This also cleans up the fix made in r285908. Patch by Azharuddin Mohammed Reviewers: john.brawn, sgundapa, beanz Subscribers: chapuni, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D26289 llvm-svn: 286184
* cmake: When using LLVM_DISTRIBUTION_COMPONENTS, adjust LLVMExports accordinglyJustin Bogner2016-11-042-8/+29
| | | | | | | This Makes sure we only export targets that we're distributing, since cmake will fail to import the file otherwise due to missing targets. llvm-svn: 286024
* [CMake] Make CMAKE_INSTALL_RPATH work againJohn Brawn2016-11-031-4/+6
| | | | | | | | r285714 made it so that when CMAKE_INSTALL_RPATH is set _install_rpath is not set, but that means INSTALL_RPATH gets set to an empty string which isn't what we want. Fix this by setting INSTALL_RPATH only when _install_rpath is set. llvm-svn: 285908
* [CMake] Disable rpath for UnitTestsJonas Hahnfeld2016-11-031-3/+5
| | | | | | | | This was broken since rL285714. Differential Revision: https://reviews.llvm.org/D26246 llvm-svn: 285881
* [CMake] Fix rpath construction for out-of-tree buildsChris Bieneman2016-11-011-0/+37
| | | | | | | | This patch was produced in conjunction with Michał Górny. It should resolve the issues that were trying to be solved by D25304. This moves rpath handling into `llvm_add_library` and `add_llvm_executable` so that it is available to all projects using AddLLVM whether built in-tree or out-of-tree. llvm-svn: 285714
* cmake: Enable the lto cache when building with -flto=thin on darwinJustin Bogner2016-10-281-0/+5
| | | | llvm-svn: 285450
OpenPOWER on IntegriCloud