- Nov 22, 2019
-
-
Amy Kwan authored
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
-
- Nov 21, 2019
-
-
Tom Stellard authored
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
-
- Nov 20, 2019
-
-
Eric Schweitz authored
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
-
- Nov 14, 2019
-
-
Kevin Petit authored
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>
-
Tom Stellard authored
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
-
- Nov 13, 2019
-
-
David Tenty authored
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
-
- Nov 08, 2019
-
-
Tom Stellard authored
Reviewers: phosek Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69682
-
Russell Gallop authored
This was enabled for other platforms. Added option for Windows/lld-link. Differential Revision: https://reviews.llvm.org/D69941
-
- Nov 06, 2019
-
-
David Tenty authored
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
-
- Nov 04, 2019
-
-
Sam Clegg authored
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
-
- Oct 30, 2019
-
-
David Tenty authored
This reverts commit 11c2a85d.
-
- Oct 25, 2019
-
-
Saleem Abdulrasool authored
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.
-
David Tenty authored
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
-
- Oct 17, 2019
-
-
Shoaib Meenai authored
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
-
- Oct 11, 2019
-
-
Michal Gorny authored
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
-
- Oct 03, 2019
-
-
Nico Weber authored
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
-
- Oct 02, 2019
-
-
Michal Gorny authored
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
-
- Oct 01, 2019
-
-
Simon Pilgrim authored
Revert rL349624 : Let TableGen write output only if it changed, instead of doing so in cmake, attempt 2 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
-
- Sep 30, 2019
-
-
Saleem Abdulrasool authored
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
-
- Sep 25, 2019
-
-
Justin Bogner authored
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
-
- Sep 23, 2019
-
-
Simon Pilgrim authored
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
-
- Sep 18, 2019
-
-
Russell Gallop authored
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
-
- Sep 10, 2019
-
-
David Zarzycki authored
GCC (unlike clang!) warns about C++ flags when compiling C. https://reviews.llvm.org/D67171 llvm-svn: 371521
-
- Sep 06, 2019
-
-
David Zarzycki authored
LLVM_COMPILE_FLAGS also applies to C files, otherwise tuning flags, etc. won't be picked up. https://reviews.llvm.org/D67171 llvm-svn: 371173
-
- Sep 04, 2019
-
-
Simon Pilgrim authored
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
-
Simon Pilgrim authored
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
-
- Sep 03, 2019
-
-
Simon Pilgrim authored
llvm-svn: 370772
-
- Aug 31, 2019
-
-
Jonas Devlieghere authored
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
-
- Aug 20, 2019
-
-
Simon Pilgrim authored
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
-
- Aug 19, 2019
-
-
Hubert Tong authored
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
-
- Aug 16, 2019
-
-
Hubert Tong authored
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
-
- Aug 15, 2019
-
-
Justin Bogner authored
Setting DESTDIR was erroneously buried under a condition here - if it's set it should always be used. llvm-svn: 369011
-
- Aug 14, 2019
-
-
Erich Keane authored
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
-
Chris Bieneman authored
This cleans up fallout from https://reviews.llvm.org/D66195. llvm-svn: 368897
-
JF Bastien authored
My last commit fumbled it. llvm-svn: 368892
-
JF Bastien authored
As of D66195 we support C++14 by default. llvm-svn: 368890
-
JF Bastien authored
Summary: I just bumped the minimum compiler versions to support C++14 in D66188. Following [our process](http://llvm.org/docs/DeveloperPolicy.html#toolchain) and [our previous agreement](http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html), I'm now officially bumping the C++ version to 14 and updating the documentation. Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, chandlerc, thakis, EricWF, jyknight, lhames, JDevlieghere Tags: #llvm Differential Revision: https://reviews.llvm.org/D66195 llvm-svn: 368887
-
JF Bastien authored
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
-
- Aug 09, 2019
-
-
Haibo Huang authored
Summary: libs can be installed to ../lib64. Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65972 llvm-svn: 368398
-
- Aug 08, 2019
-
-
JF Bastien authored
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
-