aboutsummaryrefslogtreecommitdiffstats
path: root/UPDATING
diff options
context:
space:
mode:
authorDimitry Andric <dim@FreeBSD.org>2019-04-12 20:03:27 +0000
committerDimitry Andric <dim@FreeBSD.org>2019-04-12 20:03:27 +0000
commitb5893f02214da262ac5c79eff4d39265429c3268 (patch)
tree42c3cb83439e413180b4b9d995f510f655257c4c /UPDATING
parent6bd1b82eb46d8c144649803f59b7f637bacc09b8 (diff)
downloadsrc-b5893f02214da262ac5c79eff4d39265429c3268.tar.gz
src-b5893f02214da262ac5c79eff4d39265429c3268.zip
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
8.0.0 final release r356365. MFC r340287 (by emaste): Consolidate gcov entries in OptionalObsoleteFiles Sponsored by: The FreeBSD Foundation MFC r340289 (by emaste): llvm-cov: also install as gcov (if GNU gcov is disabled) llvm-cov provides a gcov-compatible interface when invoked as gcov. Reviewed by: dim, markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17923 MFC r340296 (by emaste): Move llvm-profdata build into MK_LLVM_COV block llvm-profdata is used with llvm-cov for code coverage (although llvm-cov can also operate independently in a gcov-compatible mode). Although llvm-profdata can be used independently of llvm-cov it makes sense to group these under one option. Also handle these in OptionalObsoleteFiles.inc while here. Sponsored by: The FreeBSD Foundation MFC r340300 (by emaste): libllvm: Move SampleProfWriter to SRCS_MIN It is required by llvm-profdata, now built by default under the LLVM_COV knob. The additional complexity that would come from avoiding building it if CLANG_EXTRAS and LLVM_COV are both disabled is not worth the small savings in build time. Sponsored by: The FreeBSD Foundation MFC r340972 (by emaste): llvm-objdump: initial man page Based on llvm-objdump's online documentation and usage information. This serves as a starting point; additional detail and cleanup still required. Also being submitted upstream in LLVM review D54864. I expect to use this bespoke copy while we have LLVM 6.0 or 7.0 in FreeBSD; when we update to LLVM 8.0 it should be upstream and we will switch to it. PR: 233437 Reviewed by: bcr (man formatting) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D18309 MFC r340973 (by emaste): llvm-objdump.1: remove invalid options Some options appear in llvm-objdump's usage information as a side effect of its option parsing implementation and are not actually llvm-objdump options. Reported in LLVM review https://reviews.llvm.org/D54864. Reported by: Fangrui Song Sponsored by: The FreeBSD Foundation MFC r340975 (by emaste): llvm-objdump.1: fix igor / mandoc -Tlint warnings Accidentally omitted from r340972. MFC r341055 (by emaste): llvm-objdump.1: remove more unintentional options Some options come from static constructors in LLVM libraries and are automatically added to llvm's usage output. They're not really supposed to be llvm-objdump options. Reported by: Fangrui Song in LLVM review D54864 Sponsored by: The FreeBSD Foundation MFC r344779: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC r344798 (by emaste): libllvm: promote WithColor and xxhash to SRCS_MIN The armv6 build failed in CI due to missing symbols (from these two source files) in the bootstrap Clang. This affected only armv6 because other Clang-using archs are using LLD as the bootstrap linker, and thus include SRCS_MIW via LLD_BOOTSTRAP. Reported by: CI, via lwhsu Sponsored by: The FreeBSD Foundation MFC r344825: Add a few missed files to the MK_LLVM_TARGET_BPF=yes case, otherwise clang and various other executables will fail to link with undefined symbols. Reported by: O. Hartmann <ohartmann@walstatt.org> MFC r344852: Put in a temporary workaround for what is likely a gcc 6 bug (it does not occur with gcc 7 or later). This should prevent the following error from breaking the head-amd64-gcc CI builds: In file included from /workspace/src/contrib/llvm/tools/lldb/source/API/SBMemoryRegionInfo.cpp:14:0: /workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: 'template<class _InputIterator> lldb_private::MemoryRegionInfos::MemoryRegionInfos(_InputIterator, _InputIterator, const allocator_type&)' inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>' using std::vector<lldb_private::MemoryRegionInfo>::vector; ^~~~~~ /workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: conflicts with version inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>' Reported by: CI MFC r344896: Pull in r354937 from upstream clang trunk (by Jörg Sonnenberger): Fix inline assembler constraint validation The current constraint logic is both too lax and too strict. It fails for input outside the [INT_MIN..INT_MAX] range, but it also implicitly accepts 0 as value when it should not. Adjust logic to handle both correctly. Differential Revision: https://reviews.llvm.org/D58649 Pull in r355491 from upstream clang trunk (by Hans Wennborg): Inline asm constraints: allow ICE-like pointers for the "n" constraint (PR40890) Apparently GCC allows this, and there's code relying on it (see bug). The idea is to allow expression that would have been allowed if they were cast to int. So I based the code on how such a cast would be done (the CK_PointerToIntegral case in IntExprEvaluator::VisitCastExpr()). Differential Revision: https://reviews.llvm.org/D58821 These should fix assertions and errors when using the inline assembly "n" constraint in certain ways. In case of devel/valgrind, a pointer was used as the input for the constraint, which lead to "Assertion failed: (isInt() && "Invalid accessor"), function getInt". In case of math/secp256k1, a very large integer value was used as input for the constraint, which lead to "error: value '4624529908474429119' out of range for constraint 'n'". PR: 236216, 236194 MFC r344951: Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branch r355677 (effectively, 8.0.0 rc4), resolve conflicts, and bump version numbers. PR: 236062 MFC r345018: Merge LLVM libunwind trunk r351319, from just before upstream's release_80 branch point. Afterwards, we will merge the rest of the changes in the actual release_80 branch. PR: 236062 MFC r345019: Merge LLVM libunwind release_80 branch r355677 (effectively, 8.0.0 rc4). PR: 236062 MFC r345021: Pull in r355854 from upstream llvm trunk (by Jonas Paulsson): [RegAlloc] Avoid compile time regression with multiple copy hints. As a fix for https://bugs.llvm.org/show_bug.cgi?id=40986 ("excessive compile time building opencollada"), this patch makes sure that no phys reg is hinted more than once from getRegAllocationHints(). This handles the case were many virtual registers are assigned to the same physreg. The previous compile time fix (r343686) in weightCalcHelper() only made sure that physical/virtual registers are passed no more than once to addRegAllocationHint(). Review: Dimitry Andric, Quentin Colombet https://reviews.llvm.org/D59201 This should fix a hang when compiling certain generated .cpp files in the graphics/opencollada port. PR: 236313 MFC r345068 (by jhb): Move libunwind out of contrib/llvm/projects. Move LLVM's libunwind to its own contrib/ directory similar to other runtime libraries like libc++ and libcxxrt. Reviewed by: dim, emaste Differential Revision: https://reviews.freebsd.org/D19534 MFC r345073: Revert r308867 (which was originally committed in the clang390-import project branch): Work around LLVM PR30879, which is about a bad interaction between X86 Call Frame Optimization on i386 and libunwind, by disallowing the optimization for i386-freebsd12. This should fix some instances of broken exception handling when frame pointers are omitted, in particular some unittests run during the build of editors/libreoffice. This hack will be removed as soon as upstream has implemented a more permanent fix for this problem. And indeed, after r345018 and r345019, which updated LLVM libunwind to the most recent version, the above workaround is no longer needed. The upstream commit which fixed this is: https://llvm.org/viewvc/llvm-project?view=revision&revision=292723 Specifically, 32 bit (i386-freebsd) executables optimized with omitted frame pointers and Call Frame Optimization should now behave correctly when a C++ exception is thrown, and the stack is unwound. Upstream PR: https://llvm.org/bugs/show_bug.cgi?id=30879 PR: 236062 MFC r345152: Merge llvm, clang, compiler-rt, libc++, libunwind, lld, and lldb release_80 branch r356034 (effectively, 8.0.0 rc5), resolve conflicts, and bump version numbers. PR: 236062 MFC r345231: Add LLVM openmp trunk r351319 (just before the release_80 branch point) to contrib/llvm. This is not yet connected to the build, the glue for that will come in a follow-up commit. PR: 236062 MFC r345232: Bootstrap svn:mergeinfo on contrib/openmp. PR: 236062 MFC r345233: Merge openmp release_80 branch r356034 (effectively, 8.0.0 rc5). PR: 236062 MFC r345234: Add openmp __kmp_gettid() wrapper, using pthread_getthreadid_np(3). This has also been submitted upstream. PR: 236062 MFC r345283: Enable building libomp.so for 32-bit x86. This is done by selectively enabling the functions that save and restore MXCSR, since access to this register requires SSE support. Note that you may run into other issues with OpenMP on i386, since this *not* yet supported upstream, and certainly not extensively tested. PR: 236062, 236582 MFC r345345: Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 8.0.0 final release r356365. There were no functional changes since the most recent merge, of 8.0.0 rc5. Release notes for llvm, clang, lld and libc++ 8.0.0 are now available: https://llvm.org/releases/8.0.0/docs/ReleaseNotes.html https://llvm.org/releases/8.0.0/tools/clang/docs/ReleaseNotes.html https://llvm.org/releases/8.0.0/tools/lld/docs/ReleaseNotes.html https://llvm.org/releases/8.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 236062 MFC r345349: Pull in r352826 from upstream lld trunk (by Fangrui Song): [ELF] Support --{,no-}allow-shlib-undefined Summary: In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking an executable. This patch implements a check to error on undefined symbols in a shared object, if all of its DT_NEEDED entries are seen. Our approach resembles the one used in gold, achieves a good balance to be useful but not too smart (ld.bfd traces all DSOs and emulates the behavior of a dynamic linker to catch more cases). The error is issued based on the symbol table, different from undefined reference errors issued for relocations. It is most effective when there are DSOs that were not linked with -z defs (e.g. when static sanitizers runtime is used). gold has a comment that some system libraries on GNU/Linux may have spurious undefined references and thus system libraries should be excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The story may have changed now but we make --allow-shlib-undefined the default for now. Its interaction with -shared can be discussed in the future. Reviewers: ruiu, grimar, pcc, espindola Reviewed By: ruiu Subscribers: joerg, emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D57385 Pull in r352943 from upstream lld trunk (by Fangrui Song): [ELF] Default to --no-allow-shlib-undefined for executables Summary: This follows the ld.bfd/gold behavior. The error check is useful as it captures a common type of ld.so undefined symbol errors as link-time errors: // a.cc => a.so (not linked with -z defs) void f(); // f is undefined void g() { f(); } // b.cc => executable with a DT_NEEDED entry on a.so void g(); int main() { g(); } // ld.so errors when g() is executed (lazy binding) or when the program is started (-z now) // symbol lookup error: ... undefined symbol: f Reviewers: ruiu, grimar, pcc, espindola Reviewed By: ruiu Subscribers: llvm-commits, emaste, arichardson Tags: #llvm Differential Revision: https://reviews.llvm.org/D57569 Together, these add support for --no-allow-shlib-undefined, and make it the default for executables, so they will fail to link if any symbols from needed shared libraries are undefined. Reported by: jbeich PR: 236062, 236141 MFC r345449: Pull in r356809 from upstream llvm trunk (by Eli Friedman): [ARM] Don't form "ands" when it isn't scheduled correctly. In r322972/r323136, the iteration here was changed to catch cases at the beginning of a basic block... but we accidentally deleted an important safety check. Restore that check to the way it was. Fixes https://bugs.llvm.org/show_bug.cgi?id=41116 Differential Revision: https://reviews.llvm.org/D59680 This should fix "Assertion failed: (LiveCPSR && "CPSR liveness tracking is wrong!"), function UpdateCPSRUse" errors when building the devel/xwpe port for armv7. PR: 236062, 236568
Notes
Notes: svn path=/stable/12/; revision=346168
Diffstat (limited to 'UPDATING')
-rw-r--r--UPDATING6
1 files changed, 6 insertions, 0 deletions
diff --git a/UPDATING b/UPDATING
index 49e71a295f04..acfa66a8be2e 100644
--- a/UPDATING
+++ b/UPDATING
@@ -16,6 +16,12 @@ from older versions of FreeBSD, try WITHOUT_CLANG and WITH_GCC to bootstrap to
the tip of head, and then rebuild without this option. The bootstrap process
from older version of current across the gcc/clang cutover is a bit fragile.
+2019mmdd:
+ Clang, llvm, lld, lldb, compiler-rt and libc++ have been upgraded to
+ 8.0.0. Please see the 20141231 entry below for information about
+ prerequisites and upgrading, if you are not already using clang 3.5.0
+ or higher.
+
20190307:
The RETPOLINE option produces non-functional ifunc-using binaries
with Clang 7.0.1, and has been forced off (via BROKEN_OPTIONS).