Reverting D57264 again, it looks like we're down to two bots that need fixing:
polly-amd64-linux
polly-arm-linux
They both have old versions of libstdc++ and recent clang.
llvm-svn: 352954
Summary:
The RFC on moving past C++11 got good traction:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html
This patch therefore bumps the toolchain versions according to our policy:
llvm.org/docs/DeveloperPolicy.html#toolchain
Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane
Differential Revision: https://reviews.llvm.org/D57264
llvm-svn: 352951
Summary: D56606 was only appending target names to the `LLVM_EXPORTS`/`LLVM_EXPORTS_BUILDTREE_ONLY` properties. Targets showed up correctly in the build-tree `LLVMExports.cmake`, but they were missing in the installed one (as we found in https://bugs.llvm.org/show_bug.cgi?id=40443), because install did not register them explicitly.
Reviewers: mgorny, smeenai, beanz, gottesmm, dschuff, tstellar, serge-sans-paille
Reviewed By: smeenai
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D57383
llvm-svn: 352869
Summary:
The RFC on moving past C++11 got good traction:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html
This patch therefore bumps the toolchain versions according to our policy:
llvm.org/docs/DeveloperPolicy.html#toolchain
Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane
Differential Revision: https://reviews.llvm.org/D57264
llvm-svn: 352834
A handful of bots are still breaking, either because I missed them in my audit,
they were offline, or something else. I'm contacting their authors, but I'll
revert for now and re-commit later.
llvm-svn: 352814
Summary:
The RFC on moving past C++11 got good traction:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html
This patch therefore bumps the toolchain versions according to our policy:
llvm.org/docs/DeveloperPolicy.html#toolchain
Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane
Differential Revision: https://reviews.llvm.org/D57264
llvm-svn: 352811
CMake 3.6 introduced CMAKE_TRY_COMPILE_PLATFORM_VARIABLES, which solves
precisely the problem that necessitated init_user_prop, so we can switch
over whenever we bump our minimum CMake requirement.
llvm-svn: 352790
Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang. They were both similar, but
different. They were both broken in their own ways, for example the one
used by Clang didn't properly handle monorepo resulting in an incorrect
version information reported by Clang.
This change unifies two the scripts by introducing a new script that's
used from both LLVM and Clang, ensures that the new script supports both
monorepo and standalone SVN and Git setups, and removes the old scripts.
Differential Revision: https://reviews.llvm.org/D57063
llvm-svn: 352729
Summary: We added support for code signing entitlements in add_llvm_executable() with D54443. In the future it would be useful to have this functionality available also for libraries.
Reviewers: beanz, bogner
Reviewed By: bogner
Subscribers: mgorny, llvm-commits, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D57334
llvm-svn: 352628
Refactor the get_llvm_lit_path() logic to respect LLVM_EXTERNAL_LIT,
and require the fallback to be defined explicitly
as LLVM_DEFAULT_EXTERNAL_LIT. This fixes building libcxx standalone
after r346888.
The old logic was using LLVM_EXTERNAL_LIT both as user-defined cache
variable and an optional pre-definition of default value from caller
(e.g. libcxx). It included a hack to make this work by assigning
the value back and forth but it was fragile and stopped working
in libcxx.
The new logic is simpler and more transparent. Default value is
provided in a separate variable, and used only when user-specified
variable is empty (i.e. not overriden).
Differential Revision: https://reviews.llvm.org/D57282
llvm-svn: 352374
llvm::is_trivially_copyable portability is verified at compile time using
std::is_trivially_copyable as the reference implementation.
Unfortunately, the latter is not available on all platforms, so introduce
a proper configure check to detect if it is available on the target platform.
In a similar manner, std::is_copy_assignable is not fully supported for gcc4.9.
Provide a portable (?) implementation instead.
Differential Revision: https://reviews.llvm.org/D57018
llvm-svn: 351820
Summary:
Capture the current agreed-upon toolchain update policy based on the following
discussions:
- LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!"
llvm.org/devmtg/2018-10/talk-abstracts.html#bof3
- A Short Policy Proposal Regarding Host Compilers
lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html
- Using C++14 code in LLVM (2018)
lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html
- Using C++14 code in LLVM (2017)
lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html
- Using C++14 code in LLVM (2016)
lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html
- Document and Enforce new Host Compiler Policy
llvm.org/D47073
- Require GCC 5.1 and LLVM 3.5 at a minimum
llvm.org/D46723
Subscribers: jkorous, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D56819
llvm-svn: 351765
This extends the CMake cross compilation logic so that AVR can be set as
the default target triple, and thus the generic codegen tests can be
run.
This used to be possible on AVR; the CMake configuration files have
since been changed.
With this patch, 'cmake -DLLVM_DEFAULT_TARGET_TRIPLE=avr-unknown-unknown' can
be passed on the command line, making the `-mcpu` argument redundant to
'llc' and friends.
llvm-svn: 351678
Summary: This change factors out compiler checking / warning, and documents LLVM_FORCE_USE_OLD_TOOLCHAIN. It doesn't introduce any functional changes nor policy changes, these will come late.
Subscribers: mgorny, jkorous, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D56799
llvm-svn: 351387
Summary:
Allow external projects to import test-related targets like FileCheck, count, not etc. and query binary paths, properties, etc.
This would be useful for LLDB, because it reduces the difference between in-tree vs. standalone builds and simplifies CMake logic.
Reviewers: chapuni, gottesmm, beanz
Reviewed By: beanz
Subscribers: mgorny, lldb-commits, llvm-commits, #lldb
Differential Revision: https://reviews.llvm.org/D56606
llvm-svn: 350959
Summary: A post-commit comment to D55116 amended that this was the correct way for code signing in Xcode.
Reviewers: beanz
Reviewed By: beanz
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D55816
llvm-svn: 350383
Summary:
This function is very similar to add_llvm_library(), so this patch merges it
into add_llvm_library() and replaces all calls to add_llvm_loadable_module(lib ...)
with add_llvm_library(lib MODULE ...)
Reviewers: philip.pfaffe, beanz, chandlerc
Reviewed By: philip.pfaffe
Subscribers: chapuni, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D51748
llvm-svn: 349839
This relands r330742:
"""
Let TableGen write output only if it changed, instead of doing so in cmake.
Removes one subprocess and one temp file from the build for each tablegen
invocation.
No intended behavior change.
"""
In particular, if you see rebuilds after this change that you didn't see
before this change, that's unintended and it's fine to revert this change
again (but let me know).
r330742 got reverted because some people reported that llvm-tblgen ran on every
build after it. This could happen if the depfile output got deleted without
deleting the main .inc output. To fix, make TableGen always write the depfile,
but keep writing the main .inc output only if it has changed. This matches what
we did in cmake before.
Differential Revision: https://reviews.llvm.org/D55842
llvm-svn: 349624
Previously, when compiling Visual Studio targets, one could see random build errors. This was caused by tablegen projects using the same build folders.
This workaround simply chains tablegen projects.
Differential Revision: https://reviews.llvm.org/D54153
llvm-svn: 349596
Previously, when compiling Visual Studio targets, one could see random build errors. This was caused by tablegen projects using the same build folders.
This workaround simply chains tablegen projects.
Differential Revision: https://reviews.llvm.org/D54153
llvm-svn: 349541
- Disable incremental linking by default. /INCREMENTAL adds extra thunks in the EXE, which makes execution slower.
- Set /MT (static CRT lib) by default instead of CMake's default /MD (dll CRT lib). The previous default /MD makes all DLL functions to be thunked, thus making execution slower (memcmp, memset, etc.)
- Adds LLVM_ENABLE_INCREMENTAL_LINK which is set to OFF by default.
Differential revision: https://reviews.llvm.org/D55056
llvm-svn: 349517
Summary:
When using Xcode to build LLVM with code signing, the post-build rule is executed even if the actual build-step was skipped. This causes double-signing errors. We can currently only avoid it by passing the `--force` flag.
Plus some polishing for my previous patch D54443.
Reviewers: beanz, kubamracek
Reviewed By: kubamracek
Subscribers: #lldb, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D55116
llvm-svn: 349070
Summary:
Allow clients to suppress setup of default RPATHs in designated library targets. This is used in LLDB when emitting liblldb as a framework bundle, which itself doesn't load further RPATH-dependent libraries.
This follows the approach in add_llvm_executable().
Reviewers: aprantl, JDevlieghere, davide, friss
Reviewed By: aprantl
Subscribers: mgorny, lldb-commits, llvm-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55316
llvm-svn: 348573
I found the pattern of setting the project_BUILD variable to OFF after
processing the project to be pretty confusing. Using global properties
to explicitly keep track of whether a project has been processed or not
seems much more straightforward, and it also allows us to convert the
macro into a function (which is required for the early return).
Factor the project+type+name combination out into a variable while I'm
here, since it's used a whole bunch of times.
I don't believe this should result in any functional changes.
Differential Revision: https://reviews.llvm.org/D55104
llvm-svn: 348180
Summary: When using `LLVM_EXTERNALIZE_DEBUGINFO` in LLDB, the default dSYM location for the shared library in LLDB.framework is inside the framework bundle. With `LLVM_EXTERNALIZE_DEBUGINFO_OUTPUT_DIR` we can easily fix that. I consider it a useful feature to be able to set a global output directory for external debug info (rather then having a target-specific one). Only implemented for Darwin so far.
Reviewers: beanz, aprantl
Reviewed By: aprantl
Subscribers: mgorny, aprantl, #lldb, lldb-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D55114
llvm-svn: 348118
The add_llvm_symbol_exports function in AddLLVM.cmake creates command
line link flags with paths containing CMAKE_CURRENT_BINARY_DIR, but that
will break if CMAKE_CURRENT_BINARY_DIR contains whitespace. This patch
adds quotes to those paths.
Fixes PR39843.
Patch by John Garvin.
Differential Revision: https://reviews.llvm.org/D55081
llvm-svn: 347937
Summary:
getLastAccessedTime() and getLastModificationTime() provided times in nanoseconds but with only 1 second resolution, even when the underlying file system could provide more precise times than that.
These changes add sub-second precision for unix platforms that support improved precision.
Also add some comments to make sure people are aware that the resolution of times can vary across different file systems.
Reviewers: labath, zturner, aaron.ballman, kristina
Reviewed By: aaron.ballman, kristina
Subscribers: lebedev.ri, mgorny, kristina, llvm-commits
Differential Revision: https://reviews.llvm.org/D54826
llvm-svn: 347530
Summary:
It will cause test tools `FileCheck`, `count`, `not` being built blindly, these
dependencies should move back to clang-tools-extra.
Reviewers: mgorny
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54797
llvm-svn: 347448
The diagnostic will trigger on code that does not have any comma operator, but instead default-constructs an object with an explicitly defaulted constructor as the array index argument.
llvm-svn: 347345
Summary:
NetBSD ships with native curses(3) and -ltinfo is a part of ncurses.
Set -lterminfo before -ltinfo, as it allows to prioritize native curses
libraries. Mixing curses and ncurses does not work well, especially
in software built on top of llvm.
Original patch by Ryo Onodera (NetBSD) in pkgsrc.
Reviewers: labath, dim, mgorny
Reviewed By: dim, mgorny
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54650
llvm-svn: 347156
Summary: Allow code-signing with entitlements. FORCE may be used to avoid an error when replacing existing signatures.
Reviewers: beanz, bogner
Reviewed By: beanz
Subscribers: mgorny, llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D54443
llvm-svn: 347068
When using multi-stage builds, we would like support cross-compilation.
Example is 2-stage build when the first stage is compiled for host while
the second stage is compiled for the target.
Normally, the second stage would be also used for compiling runtimes,
but that's not possible when cross-compiling, so we use the first stage
compiler instead. However, we still want to use the second stage paths.
To do so, we set the -resource-dir of the first stage compiler to point
to the resource directory of the second stage.
We also need compiler tools that support the target architecture. These
tools are not guaranteed to be present on the host, but in case of
multi-stage build, we can build these tools in the first stage.
Differential Revision: https://reviews.llvm.org/D54461
llvm-svn: 347025
* Create an install target for it
* Add it under tools/opt-remarks
* Add an export file for the dylib
* Install the llvm-c/OptRemarks.h header
* Add an API to query its version
rdar://45458839
llvm-svn: 346127
There are several places where we use CMAKE_CONFIGURATION_TYPES to determine if we are using an IDE generator and in turn decide not to generate some of the convenience targets (like all the install-* and check-llvm-* targets). This decision is made because IDEs don't always deal well with the thousands of targets LLVM can generate.
This approach does not work for Visual Studio 15's new CMake integration. Because VS15 uses a Ninja generator, it isn't a multi-configuration build, and generating all these extra targets mucks up the UI and adds little value.
With this change we still don't generate these targets by default for Visual Studio and Xcode generators, and LLVM_ENABLE_IDE becomes a switch that can be enabled on the VS15 CMake builds, to improve the IDE experience.
This is a re-land of r340435, with a few minor fix-ups. The issues causing the revert were addressed in r344218, r344219, and r344553.
llvm-svn: 344555
There really aren't any generator behaviors that we need to take `CMAKE_EXTRA_GENERATOR` into account for. Where we need to take different behaviors for IDEs is mostly in enabling or disabling certain build system features that are optional but trip up the IDE UIs. Like the generation of lots of utility targets.
By changing the LLVM_ENABLE_IDE default to only being on for multi-configuration generators, we allow gating where it will impact the UI presentation, while also supporting optionally disabling the generation if your tooling workflow encounters problems. Presently being able to manually disable extra target generation is useful for Visual Studio 2017's CMake integration where the IDE has trouble displaying and working with the large number of optional targets.
llvm-svn: 344553
All uses of this option have been removed, and the intent is to change the purpose and default value of this option. To prevent it from having impacts on users, this patch temporarily removes the option and purges it from CMake caches. In a few days, once this has propagated to contributors I will re-introduce the option with the new default value.
llvm-svn: 344219
Previously adding header and table gen files was conditional on using an IDE. Since these files have the `HEADER_FILE_ONLY` attribute applied they are ignored as sources by all non-IDE generators, so there is really no reason not to include them.
Additionally having the CMake always include these files allows the CMake-server to include them in the sources list for targets, which is valuable to anyone using CMake-server integrated tools.
llvm-svn: 344218
Some projects rely on using libraries from the Windows SDK with their
original casing, just with a lowercase extension. E.g. the WinSock2 lib
is named WS2_32.Lib in the Windows SDK, and we would previously only
create a ws2_32.lib symlink for it (i.e. all lowercase). Also create a
WS2_32.lib symlink (i.e. original casing with lowercase extension) to
cover users of this casing. As a drive-by fix, only create these
symlinks when they differ from the original name to reduce the amount of
noise in the library symlinks directory.
llvm-svn: 343832
