src/lib/libclang_rt, branch releng/11.3

MFC r346578:

2019-05-09T17:02:40Z

Build libclang_rt/profile on all clang-supported architectures There's no reason why a special case needs to be added specifically for amd64, arm, and i386, as the code is written in machine architecture agnostic C/C++. This will make it possible for all supporting clang architectures to produce runtime coverage with `--coverage`.

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp

2019-04-16T20:05:24Z

8.0.0 final release r356365. MFC r306265 (by emaste): Force LLVM_LIBUNWIND off if we don't have a C++11 compiler Tested by: bde Differential Revision: https://reviews.freebsd.org/D7746 MFC r308100 (by emaste): compile libunwind c source with -fexceptions When an exception is thrown the unwinder must unwind its own C source (starting with _Unwind_RaiseException in UnwindLevel1.c), so it needs to be built with unwinding data. MFC r324998 (by bdrewery): Prefix {TARGET,BUILD}_TRIPLE with LLVM_ to avoid Makefile.inc1 collision. The Makefile.inc1 TARGET_TRIPLE is for specifying which -target is used during the build of world. Reviewed by: dim, imp Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12792 MFC r329093 (by emaste): Promote llvm-cov to a standalone option Introduce WITH_/WITHOUT_LLVM_COV to match GCC's WITH_/WITHOUT_GCOV. It is intended to provide a superset of the interface and functionality of gcov. It is enabled by default when building Clang, similarly to gcov and GCC. This change moves one file in libllvm to be compiled unconditionally. Previously it was included only when WITH_CLANG_EXTRAS was set, but the complexity of a new special case for (CLANG_EXTRAS | LLVM_COV) is not worth avoiding a tiny increase in build time. Reviewed by: dim, imp Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D142645 MFC r331244 (by jhb): Add support for MIPS to LLVM's libunwind. This is originally based on a patch from David Chisnall for soft-float N64 but has since been updated to support O32, N32, and hard-float ABIs. The soft-float O32, N32, and N64 support has been committed upstream. The hard-float changes are still in review upstream. Enable LLVM_LIBUNWIND on mips when building with a suitable (C+11-capable) toolchain. This has been tested with external GCC for all ABIs and O32 and N64 with clang. Reviewed by: emaste Obtained from: CheriBSD (original N64 patch) Sponsored by: DARPA / AFRL Differential Revision: https://reviews.freebsd.org/D14701 MFC r336691 (by emaste): llvm: remove __FreeBSD_version conditionals All supported FreeBSD build host versions have backtrace.h, so we can just eliminate that test. For futimes() we can test the compiler's built-in __FreeBSD__ major version rather than relying on including osreldate.h. This should reduce the frequency with which Clang gets rebuilt when building world. Reviewed by: dim Sponsored by: The FreeBSD Foundation MFC r337379 (by andrew): Default to armv5te in LINT on arm. This should fix building LINT there. MFC r337552: Add optional LLVM BPF target support BPF (eBPF) is an independent instruction set architecture which is introduced in Linux a few years ago. Originally, eBPF execute environment was only inside Linux kernel. However, recent years there are some user space implementation (https://github.com/iovisor/ubpf, https://doc.dpdk.org/guides/prog_guide/bpf_lib.html) and kernel space implementation for FreeBSD is going on (https://github.com/YutaroHayakawa/generic-ebpf). The BPF target support can be enabled using WITH_LLVM_TARGET_BPF, as it is not built by default. Submitted by: Yutaro Hayakawa Reviewed by: dim, bdrewery Differential Revision: https://reviews.freebsd.org/D16033 MFC r337585: In r308100, an explicit -fexceptions flag was added for the C sources from LLVM's libunwind, which end up in libgcc_eh.a and libgcc_s.so. This is because the unwinder needs the unwinder data for its own functions. However, for the C++ sources in libunwind, -fexceptions is already the default, and this can have the side effect of generating a reference to __gxx_personality_v0, the so-called personality function, which is normally provided by the C++ ABI library (libcxxrt or libsupc++). If the reference ends up in the eventual libgcc_s.so, linking any non-C++ programs against it will fail with "undefined reference to `__gxx_personality_v0'". Note that at high optimization levels, the reference is usually optimized away, which is why we have never noticed this problem before. With clang 7.0.0 though, higher optimization levels don't help anymore, since the addition of address-significance tables [1] in . Effectively, this always causes a reference to __gxx_personality_v0. After discussion with the upstream author of that change, it turns out that we should compile libunwind sources with the -fno-exceptions -funwind-tables flags instead. This ensures unwind tables are generated, but no references to any personality functions are emitted. [1] https://lists.llvm.org/pipermail/llvm-dev/2018-May/123514.html Reported by: jbeich PR: 230399 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: 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 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 lldb_private::MemoryRegionInfos::MemoryRegionInfos(_InputIterator, _InputIterator, const allocator_type&)' inherited from 'std::__1::vector' using std::vector::vector; ^~~~~~ /workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: conflicts with version inherited from 'std::__1::vector' 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

Merge clang 7.0.1 and several follow-up changes

2019-02-16T15:57:29Z

MFC r318594: Add libc++experimental.a for std::experimental support This adds a separate library for supporting std::experimental features. It is purposefully static, and must be explicitly linked into programs using -lc++experimental. PLEASE NOTE: there is NO WARRANTY as to any stability or continuing existence of the features in the std::experimental parts of the C++ library! Reviewed by: ed Differential Revision: https://reviews.freebsd.org/D10840 MFC r318598: Add PICFLAG to build libc++experimental.a, so it can be used in all situations. Noticed by: kib r336969 | emaste | 2018-07-31 16:12:09 +0200 (Tue, 31 Jul 2018) | 13 lines llvm: [ELF][ARM] Add Arm ABI names for float ABI ELF Header flags The ELF for the Arm architecture document defines, for EF_ARM_EABI_VER5 and above, the flags EF_ARM_ABI_FLOAT_HARD and EF_ARM_ABI_FLOAT_SOFT. These have been defined to be compatible with the existing EF_ARM_VFP_FLOAT and EF_ARM_SOFT_FLOAT used by gcc for EF_ARM_EABI_UNKNOWN. This patch adds the flags in addition to the existing ones so that any code depending on the old names will still work. Obtained from: llvm r338370 by Peter Smith r336970 | emaste | 2018-07-31 16:14:41 +0200 (Tue, 31 Jul 2018) | 9 lines llvm: [ARM] Complete enumeration values for Tag_ABI_VFP_args The LLD implementation of Tag_ABI_VFP_args needs to check the rarely seen values of 3 (toolchain specific) and 4 compatible with both Base and VFP. Add the missing enumeration values so that LLD can refer to them without having to use the raw numbers. Obtained from: llvm r338373 by Peter Smith r336972 | emaste | 2018-07-31 17:25:03 +0200 (Tue, 31 Jul 2018) | 37 lines lld: [ELF][ARM] Implement support for Tag_ABI_VFP_args The Tag_ABI_VFP_args build attribute controls the procedure call standard used for floating point parameters on ARM. The values are: 0 - Base AAPCS (FP Parameters passed in Core (Integer) registers 1 - VFP AAPCS (FP Parameters passed in FP registers) 2 - Toolchain specific (Neither Base or VFP) 3 - Compatible with all (No use of floating point parameters) If the Tag_ABI_VFP_args build attribute is missing it has an implicit value of 0. We use the attribute in two ways: * Detect a clash in calling convention between Base, VFP and Toolchain. we follow ld.bfd's lead and do not error if there is a clash between an implicit Base AAPCS caused by a missing attribute. Many projects including the hard-float (VFP AAPCS) version of glibc contain assembler files that do not use floating point but do not have Tag_ABI_VFP_args. * Set the EF_ARM_ABI_FLOAT_SOFT or EF_ARM_ABI_FLOAT_HARD ELF header flag for Base or VFP AAPCS respectively. This flag is used by some ELF loaders. References: * Addenda to, and Errata in, the ABI for the ARM Architecture for Tag_ABI_VFP_args * Elf for the ARM Architecture for ELF header flags Fixes LLVM PR36009 PR: 229050 Obtained from: llvm r338377 by Peter Smith r337282 | alc | 2018-08-04 04:30:51 +0200 (Sat, 04 Aug 2018) | 7 lines Set the default image base on arm64 and i386 to a superpage-aligned address. Reviewed by: emaste, markj Discussed with: dim Differential Revision: https://reviews.freebsd.org/D16385 r339304 | emaste | 2018-10-11 15:19:17 +0200 (Thu, 11 Oct 2018) | 13 lines lld: set sh_link and sh_info for .rela.plt sections ELF spec says that for SHT_REL and SHT_RELA sh_link should reference the associated string table and sh_info should reference the "section to which the relocation applies." ELF Tool Chain's elfcopy / strip use this (in part) to control whether or not the relocation entry is copied to the output. LLVM PR 37538 https://bugs.llvm.org/show_bug.cgi?id=37538 Approved by: re (kib) Obtained from: llvm r344226 (backported for 6.0) MFC r341825: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_70 branch r348686 (effectively, 7.0.1 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 7.0.0 are available here: PR: 230240, 230355 Relnotes: yes MFC r342123: Update clang, llvm, lld, lldb, compiler-rt and libc++ version number to 7.0.1 release r349250. There were no functional changes since the 7.0.1 rc3 import. PR: 230240, 230355 Relnotes: yes r343429 | emaste | 2019-01-25 15:46:13 +0100 (Fri, 25 Jan 2019) | 16 lines clang: default to DWARF 4 as of FreeBSD 13 FreeBSD previously defaulted to DWARF 2 because several tools (gdb, ctfconvert, etc.) did not support later versions. These have either been fixed or are deprecated. Note that gdb 6 still exists but has been moved out of $PATH into /usr/libexec and is intended only for use by crashinfo(8). The kernel build sets the DWARF version explicitly via -gdwarf2, so this should have no effect there. PR: 234887 [exp-run] Reviewed by: markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17930 MFC r343916: Pull in r352607 from upstream llvm trunk (by Craig Topper): [X86] Add FPSW as a Def on some FP instructions that were missing it. Pull in r353141 from upstream llvm trunk (by Craig Topper): [X86] Connect the default fpsr and dirflag clobbers in inline assembly to the registers we have defined for them. Summary: We don't currently map these constraints to physical register numbers so they don't make it to the MachineIR representation of inline assembly. This could have problems for proper dependency tracking in the machine schedulers though I don't have a test case that shows that. Reviewers: rnk Reviewed By: rnk Subscribers: eraman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57641 Pull in r353489 from upstream llvm trunk (by Craig Topper): [X86] Add FPCW as a register and start using it as an implicit use on floating point instructions. Summary: FPCW contains the rounding mode control which we manipulate to implement fp to integer conversion by changing the roudning mode, storing the value to the stack, and then changing the rounding mode back. Because we didn't model FPCW and its dependency chain, other instructions could be scheduled into the middle of the sequence. This patch introduces the register and adds it as an implciit def of FLDCW and implicit use of the FP binary arithmetic instructions and store instructions. There are more instructions that need to be updated, but this is a good start. I believe this fixes at least the reduced test case from PR40529. Reviewers: RKSimon, spatel, rnk, efriedma, andrew.w.kaylor Subscribers: dim, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57735 These should fix a problem in clang 7.0 where it would sometimes emit long double floating point instructions in a slightly wrong order, leading to failures in our libm tests. In particular, the cbrt_test test case 'cbrtl_powl' and the trig_test test case 'reduction'. Also bump __FreeBSD_cc_version, to be able to detect this in our test suite. Reported by: lwhsu PR: 234040 Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=40206 MFC r344056: Pull in r339734 from upstream llvm trunk (by Eli Friedman): [ARM] Make PerformSHLSimplify add nodes to the DAG worklist correctly. Intentionally excluding nodes from the DAGCombine worklist is likely to lead to weird optimizations and infinite loops, so it's generally a bad idea. To avoid the infinite loops, fix DAGCombine to use the isDesirableToCommuteWithShift target hook before performing the transforms in question, and implement the target hook in the ARM backend disable the transforms in question. Fixes https://bugs.llvm.org/show_bug.cgi?id=38530 . (I don't have a reduced testcase for that bug. But we should have sufficient test coverage for PerformSHLSimplify given that we're not playing weird tricks with the worklist. I can try to bugpoint it if necessary, though.) Differential Revision: https://reviews.llvm.org/D50667 This should fix a possible hang when compiling sys/dev/nxge/if_nxge.c (which exists now only in the stable/11 branch) for arm.

MFC 337270: Install the 32-bit compat sanitizer libraries.

2018-09-20T16:43:58Z

The lib32 build was already building the i386 version of the clang sanitizers (libclang_rt) but they were not being installed. This enables the installation. MK_TOOLCHAIN=no was originally added to the install make environment to disable includes so that NO_INCS could be removed. The MK_TOOLCHAIN in bsd.incs.mk was subsequently renamed to MK_INCLUDES, but bsd.lib.mk doesn't even include bsd.incs.mk when LIBRARIES_ONLY is defined which the install make environment for compat libs now defines. However, setting MK_TOOLCHAIN=no forced MK_CLANG=no which disabled libclang_rt during the install32 phase. Remove MK_TOOLCHAIN=no since LIBRARIES_ONLY is now sufficient. Since the libcompat environment overrides both LIBDIR and SHLIBDIR, libclang_rt/Makefile.inc has to set both variables to force the libraries to be installed to the location expected by the compiler.

MFC r335799:

2018-07-14T14:20:30Z

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.1 release (upstream r335540). Relnotes: yes MFC r335813: Follow-up to r335799 (llvm/clang 6.0.1 update), by regenerating various headers with new version information defines. MFC r335819: More follow-up to r335799 (llvm/clang 6.0.1 update), where I forgot to update mtree files, ObsoleteFiles and a number of other paths. Sorry about all the breakage. Pointy hat to: me

Merge clang, llvm, lld, lldb, compiler-rt and libc++ 6.0.0 release, and

2018-03-31T11:38:16Z

several follow-up fixes. MFC r327952: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r321788). Upstream has branched for the 6.0.0 release, which should be in about 6 weeks. Please report bugs and regressions, so we can get them into the release. Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information. MFC r328010: Pull in r322473 from upstream llvm trunk (by Andrei Elovikov): [LV] Don't call recordVectorLoopValueForInductionCast for newly-created IV from a trunc. Summary: This method is supposed to be called for IVs that have casts in their use-def chains that are completely ignored after vectorization under PSE. However, for truncates of such IVs the same InductionDescriptor is used during creation/widening of both original IV based on PHINode and new IV based on TruncInst. This leads to unintended second call to recordVectorLoopValueForInductionCast with a VectorLoopVal set to the newly created IV for a trunc and causes an assert due to attempt to store new information for already existing entry in the map. This is wrong and should not be done. Fixes PR35773. Reviewers: dorit, Ayal, mssimpso Reviewed By: dorit Subscribers: RKSimon, dim, dcaballe, hsaito, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D41913 This should fix "Vector value already set for part" assertions when building the net/iodine and sysutils/daa2iso ports. Reported by: jbeich PR: 224867, 224868 MFC r328090: Pull in r322623 from upstream llvm trunk (by Andrew V. Tischenko): Allow usage of X86-prefixes as separate instrs. Differential Revision: https://reviews.llvm.org/D42102 This should fix parse errors when x86 prefixes (such as 'lock' and 'rep') are followed by various non-mnemonic tokens, e.g. comments, .byte directives and labels. PR: 224669, 225054 MFC r328091: Revert r327340, as the workaround for rep prefixes followed by .byte directives is no longer needed after r328090. MFC r328141 (by emaste): lld: Fix for ld.lld does not accept "AT" syntax for declaring LMA region AT> lma_region expression allows to specify the memory region for section load address. Should fix [upstream LLVM] PR35684. LLVM review: https://reviews.llvm.org/D41397 Obtained from: LLVM r322359 by George Rimar MFC r328143 (by emaste): lld: Handle parsing AT(ADDR(.foo-bar)). The problem we had with it is that anything inside an AT is an expression, so we failed to parse the section name because of the - in it. Requested by: royger Obtained from: LLVM r322801 by Rafael Espindola MFC r328144 (by emaste): lld: Fix incorrect physical address on self-referencing AT command. When a section placement (AT) command references the section itself, the physical address of the section in the ELF header was calculated incorrectly due to alignment happening right after the location pointer's value was captured. The problem was diagnosed and the first version of the patch written by Erick Reyes. Obtained from: LLVM r322421 by Rafael Espindola MFC r328145: Pull in r322016 from upstream llvm trunk (by Sanjay Patel): [ValueTracking] remove overzealous assert The test is derived from a failing fuzz test: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5008 Credit to @rksimon for pointing out the problem. This should fix "Bad flavor while matching min/max" errors when building the graphics/libsixel and science/kst2 ports. Reported by: jbeich PR: 225268, 225269 MFC r328146: Pull in r322106 from upstream llvm trunk (by Alexey Bataev): [COST]Fix PR35865: Fix cost model evaluation for shuffle on X86. Summary: If the vector type is transformed to non-vector single type, the compile may crash trying to get vector information about non-vector type. Reviewers: RKSimon, spatel, mkuper, hfinkel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41862 This should fix "Not a vector MVT!" errors when building the games/dhewm3 port. Reported by: jbeich PR: 225271 MFC r328286 (by emaste): lld: Don't mark a shared library as needed because of a lazy symbol. Obtained from: LLVM r323221 by Rafael Esp?ndola MFC r328381: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r323338). PR: 224669 MFC r328513: Pull in r322245 from upstream clang trunk (by Craig Topper): [X86] Make -mavx512f imply -mfma and -mf16c in the frontend like it does in the backend. Similarly, make -mno-fma and -mno-f16c imply -mno-avx512f. Withou this "-mno-sse -mavx512f" ends up with avx512f being enabled in the frontend but disabled in the backend. Reported by: pawel PR: 225488 MFC r328542 (by emaste): lld: Use lookup instead of find. NFC, just simpler. Obtained from: LLVM r323395 by Rafael Espindola MFC r328543 (by emaste): lld: Only lookup LMARegion once. NFC. This is similar to how we handle MemRegion. Obtained from: LLVM r323396 by Rafael Espindola MFC r328544 (by emaste): lld: Remove MemRegionOffset. NFC. We can just use a member variable in MemoryRegion. Obtained from: LLVM r323399 by Rafael Espindola MFC r328545 (by emaste): lld: Simplify. NFC. Obtained from: LLVM r323440 by Rafael Espindola MFC r328546 (by emaste): lld: Improve LMARegion handling. This fixes the crash reported at [LLVM] PR36083. The issue is that we were trying to put all the sections in the same PT_LOAD and crashing trying to write past the end of the file. This also adds accounting for used space in LMARegion, without it all 3 PT_LOADs would have the same physical address. Obtained from: LLVM r323449 by Rafael Espindola MFC r328547 (by emaste): lld: Move LMAOffset from the OutputSection to the PhdrEntry. NFC. If two sections are in the same PT_LOAD, their relatives offsets, virtual address and physical addresses are all the same. [Rafael] initially wanted to have a single global LMAOffset, on the assumption that every ELF file was in practiced loaded contiguously in both physical and virtual memory. Unfortunately that is not the case. The linux kernel has: LOAD 0x200000 0xffffffff81000000 0x0000000001000000 0xced000 0xced000 R E 0x200000 LOAD 0x1000000 0xffffffff81e00000 0x0000000001e00000 0x15f000 0x15f000 RW 0x200000 LOAD 0x1200000 0x0000000000000000 0x0000000001f5f000 0x01b198 0x01b198 RW 0x200000 LOAD 0x137b000 0xffffffff81f7b000 0x0000000001f7b000 0x116000 0x1ec000 RWE 0x200000 The delta for all but the third PT_LOAD is the same: 0xffffffff80000000. [Rafael] thinks the 3rd one is a hack for implementing per cpu data, but we can't break that. Obtained from: LLVM r323456 by Rafael Espindola MFC r328548 (by emaste): lld: Put the header in the first PT_LOAD even if that PT_LOAD has a LMAExpr The root problem is that we were creating a PT_LOAD just for the header. That was technically valid, but inconvenient: we should not be making the ELF discontinuous. The solution is to allow a section with LMAExpr to be added to a PT_LOAD if that PT_LOAD doesn't already have a LMAExpr. LLVM PR: 36017 Obtained from: LLVM r323625 by Rafael Espindola MFC r328594 (by emaste): Pull in r322108 from upstream llvm trunk (by Rafael Esp?ndola): Make one of the emitFill methods non virtual. NFC. This is just preparatory work to fix [LLVM] PR35858. MFC r328595 (by emaste): Pull in r322123 from upstream llvm trunk (by Rafael Esp?ndola): Don't create MCFillFragment directly. Instead use higher level APIs that take care of most bookkeeping. MFC r328596 (by emaste): Pull in r322131 from upstream llvm trunk (by Rafael Esp?ndola): Use a MCExpr for the size of MCFillFragment. This allows the size to be found during ralaxation. This fixes [LLVM] pr35858. Requested by: royger MFC r328753: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r323948). PR: 224669 MFC r328817: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r324090). This introduces retpoline support, with the -mretpoline flag. The upstream initial commit message (r323155 by Chandler Carruth) contains quite a bit of explanation. Quoting: Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre. Summary: First, we need to explain the core of the vulnerability. Note that this is a very incomplete description, please see the Project Zero blog post for details: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html The basis for branch target injection is to direct speculative execution of the processor to some "gadget" of executable code by poisoning the prediction of indirect branches with the address of that gadget. The gadget in turn contains an operation that provides a side channel for reading data. Most commonly, this will look like a load of secret data followed by a branch on the loaded value and then a load of some predictable cache line. The attacker then uses timing of the processors cache to determine which direction the branch took *in the speculative execution*, and in turn what one bit of the loaded value was. Due to the nature of these timing side channels and the branch predictor on Intel processors, this allows an attacker to leak data only accessible to a privileged domain (like the kernel) back into an unprivileged domain. The goal is simple: avoid generating code which contains an indirect branch that could have its prediction poisoned by an attacker. In many cases, the compiler can simply use directed conditional branches and a small search tree. LLVM already has support for lowering switches in this way and the first step of this patch is to disable jump-table lowering of switches and introduce a pass to rewrite explicit indirectbr sequences into a switch over integers. However, there is no fully general alternative to indirect calls. We introduce a new construct we call a "retpoline" to implement indirect calls in a non-speculatable way. It can be thought of loosely as a trampoline for indirect calls which uses the RET instruction on x86. Further, we arrange for a specific call->ret sequence which ensures the processor predicts the return to go to a controlled, known location. The retpoline then "smashes" the return address pushed onto the stack by the call with the desired target of the original indirect call. The result is a predicted return to the next instruction after a call (which can be used to trap speculative execution within an infinite loop) and an actual indirect branch to an arbitrary address. On 64-bit x86 ABIs, this is especially easily done in the compiler by using a guaranteed scratch register to pass the target into this device. For 32-bit ABIs there isn't a guaranteed scratch register and so several different retpoline variants are introduced to use a scratch register if one is available in the calling convention and to otherwise use direct stack push/pop sequences to pass the target address. This "retpoline" mitigation is fully described in the following blog post: https://support.google.com/faqs/answer/7625886 We also support a target feature that disables emission of the retpoline thunk by the compiler to allow for custom thunks if users want them. These are particularly useful in environments like kernels that routinely do hot-patching on boot and want to hot-patch their thunk to different code sequences. They can write this custom thunk and use `-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this case, on x86-64 thu thunk names must be: ``` __llvm_external_retpoline_r11 ``` or on 32-bit: ``` __llvm_external_retpoline_eax __llvm_external_retpoline_ecx __llvm_external_retpoline_edx __llvm_external_retpoline_push ``` And the target of the retpoline is passed in the named register, or in the case of the `push` suffix on the top of the stack via a `pushl` instruction. There is one other important source of indirect branches in x86 ELF binaries: the PLT. These patches also include support for LLD to generate PLT entries that perform a retpoline-style indirection. The only other indirect branches remaining that we are aware of are from precompiled runtimes (such as crt0.o and similar). The ones we have found are not really attackable, and so we have not focused on them here, but eventually these runtimes should also be replicated for retpoline-ed configurations for completeness. For kernels or other freestanding or fully static executables, the compiler switch `-mretpoline` is sufficient to fully mitigate this particular attack. For dynamic executables, you must compile *all* libraries with `-mretpoline` and additionally link the dynamic executable and all shared libraries with LLD and pass `-z retpolineplt` (or use similar functionality from some other linker). We strongly recommend also using `-z now` as non-lazy binding allows the retpoline-mitigated PLT to be substantially smaller. When manually apply similar transformations to `-mretpoline` to the Linux kernel we observed very small performance hits to applications running typic al workloads, and relatively minor hits (approximately 2%) even for extremely syscall-heavy applications. This is largely due to the small number of indirect branches that occur in performance sensitive paths of the kernel. When using these patches on statically linked applications, especially C++ applications, you should expect to see a much more dramatic performance hit. For microbenchmarks that are switch, indirect-, or virtual-call heavy we have seen overheads ranging from 10% to 50%. However, real-world workloads exhibit substantially lower performance impact. Notably, techniques such as PGO and ThinLTO dramatically reduce the impact of hot indirect calls (by speculatively promoting them to direct calls) and allow optimized search trees to be used to lower switches. If you need to deploy these techniques in C++ applications, we *strongly* recommend that you ensure all hot call targets are statically linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well tuned servers using all of these techniques saw 5% - 10% overhead from the use of retpoline. We will add detailed documentation covering these components in subsequent patches, but wanted to make the core functionality available as soon as possible. Happy for more code review, but we'd really like to get these patches landed and backported ASAP for obvious reasons. We're planning to backport this to both 6.0 and 5.0 release streams and get a 5.0 release with just this cherry picked ASAP for distros and vendors. This patch is the work of a number of people over the past month: Eric, Reid, Rui, and myself. I'm mailing it out as a single commit due to the time sensitive nature of landing this and the need to backport it. Huge thanks to everyone who helped out here, and everyone at Intel who helped out in discussions about how to craft this. Also, credit goes to Paul Turner (at Google, but not an LLVM contributor) for much of the underlying retpoline design. Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D41723 PR: 224669 MFC r329033: Pull in r324594 from upstream clang trunk (by Alexander Ivchenko): Fix for #31362 - ms_abi is implemented incorrectly for values >=16 bytes. Summary: This patch is a fix for following issue: https://bugs.llvm.org/show_bug.cgi?id=31362 The problem was caused by front end lowering C calling conventions without taking into account calling conventions enforced by attribute. In this case win64cc was no correctly lowered on targets other than Windows. Reviewed By: rnk (Reid Kleckner) Differential Revision: https://reviews.llvm.org/D43016 Author: belickim This fixes clang 6.0.0 assertions when building the emulators/wine and emulators/wine-devel ports, and should also make it use the correct Windows calling conventions. Bump __FreeBSD_version to make the fix easy to detect. PR: 224863 MFC r329223: Pull in r323998 from upstream clang trunk (by Richard Smith): PR36157: When injecting an implicit function declaration in C89, find the right DeclContext rather than injecting it wherever we happen to be. This avoids creating functions whose DeclContext is a struct or similar. This fixes assertion failures when parsing certain not-completely-valid struct declarations. Reported by: ae PR: 225862 MFC r329410: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r325330). PR: 224669 MFC r329983: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r325932). This corresponds to 6.0.0 rc3. PR: 224669 MFC r330384: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 release (upstream r326565). Release notes for llvm, clang and lld will be available here soon: Relnotes: yes PR: 224669 MFC r330686: Pull in r326882 from upstream llvm trunk (by Sjoerd Meijer): [ARM] Fix for PR36577 Don't PerformSHLSimplify if the given node is used by a node that also uses a constant because we may get stuck in an infinite combine loop. bugzilla: https://bugs.llvm.org/show_bug.cgi?id=36577 Patch by Sam Parker. Differential Revision: https://reviews.llvm.org/D44097 This fixes a hang when compiling one particular file in java/openjdk8 for armv6 and armv7. Reported by: swills PR: 226388 MFC r331065: Pull in r327638 from upstream llvm trunk (by Matthew Simpson): [ConstantFolding, InstSimplify] Handle more vector GEPs This patch addresses some additional cases where the compiler crashes upon encountering vector GEPs. This should fix PR36116. Differential Revision: https://reviews.llvm.org/D44219 Reference: https://bugs.llvm.org/show_bug.cgi?id=36116 This fixes an assertion when building the emulators/snes9x port. Reported by: jbeich PR: 225471 MFC r331066: Pull in r321999 from upstream clang trunk (by Ivan A. Kosarev): [CodeGen] Fix TBAA info for accesses to members of base classes Resolves: Bug 35724 - regression (r315984): fatal error: error in backend: Broken function found (Did not see access type in access path!) https://bugs.llvm.org/show_bug.cgi?id=35724 Differential Revision: https://reviews.llvm.org/D41547 This fixes "Did not see access type in access path" fatal errors when building the devel/gdb port (version 8.1). Reported by: jbeich PR: 226658 MFC r331366: Pull in r327101 from upstream llvm trunk (by Rafael Espindola): Don't treat .symver as a regular alias definition. This patch starts simplifying the handling of .symver. For now it just moves the responsibility for creating an alias down to the streamer. With that the asm streamer can pass a .symver unchanged, which is nice since gas cannot parse "foo@bar = zed". In a followup I hope to move the handling down to the writer so that we don't need special hacks for avoiding breaking names with @@@ on windows. Pull in r327160 from upstream llvm trunk (by Rafael Espindola): Delay creating an alias for @@@. With this we only create an alias for @@@ once we know if it should use @ or @@. This avoids last minutes renames and hacks to handle MS names. This only handles the ELF writer. LTO still has issues with @@@ aliases. Pull in r327928 from upstream llvm trunk (by Vitaly Buka): Object: Move attribute calculation into RecordStreamer. NFC Summary: Preparation for D44274 Reviewers: pcc, espindola Subscribers: hiraditya Differential Revision: https://reviews.llvm.org/D44276 Pull in r327930 from upstream llvm trunk (by Vitaly Buka): Object: Fix handling of @@@ in .symver directive Summary: name@@@nodename is going to be replaced with name@@nodename if symbols is defined in the assembled file, or name@nodename if undefined. https://sourceware.org/binutils/docs/as/Symver.html Fixes PR36623 Reviewers: pcc, espindola Subscribers: mehdi_amini, hiraditya Differential Revision: https://reviews.llvm.org/D44274 Together, these changes fix handling of @@@ in .symver directives when doing Link Time Optimization. Reported by: Shawn Webb MFC r331731: Pull in r328738 from upstream lld trunk (by Rafael Espindola): Strip @VER suffices from the LTO output. This fixes pr36623. The problem is that we have to parse versions out of names before LTO so that LTO can use that information. When we get the LTO produced .o files, we replace the previous symbols with the LTO produced ones, but they still have @ in their names. We could just trim the name directly, but calling parseSymbolVersion to do it is simpler. This is a follow-up to r331366, since we discovered that lld could append version strings to symbols twice, when using Link Time Optimization.

MFC r326496:

2017-12-26T14:44:02Z

Upgrade our copies of clang, llvm, lldb and libc++ to r319231 from the upstream release_50 branch. This corresponds to 5.0.1 rc2. MFC r326831: Pull in r315334 from upstream lld trunk (by Rafael Espindola): Don't create a dummy __tls_get_addr. We just don't need one with the current setup. We only error on undefined references that are used by some relocation. If we managed to relax all uses of __tls_get_addr, no relocation uses it and we don't produce an error. This is less code and fixes the case were we fail to relax. Before we would produce a broken output, but now we produce an error. Pull in r320390 from upstream lld trunk (by Rafael Espindola): Create reserved symbols early so they can be versioned. This fixes pr35570. We were creating these symbols after parsing version scripts, so they could not be versioned. We cannot move the version script parsing later because we need it for lto. One option is to move both addReservedSymbols and createSyntheticSections earlier. The disadvantage is that some sections created by createSyntheticSections replace other input sections. For example, gdb index replaces .debug_gnu_pubnames, so it wants to run after gc sections so that it can set S->Live to false. What this patch does instead is to move just the ElfHeader creation early. Pull in r320412 from upstream lld trunk (by Rafael Espindola): Handle symbols pointing to output sections. Now that gc sections runs after linker defined symbols are added it can see symbols that point to an OutputSection. Should fix a bot failure. Pull in r320431 from upstream lld trunk (by Peter Collingbourne): ELF: Do not follow relocation edges to output sections during GC. This fixes an assertion error introduced by r320390. Differential Revision: https://reviews.llvm.org/D41095 Together these fix handling of reserved symbols, in particular _end, which is needed to make brk(2) and sbrk(2) work correctly. This unbreaks the emacs ports on amd64, and also appears to unbreak most of world on i386. Differential Revision: https://reviews.freebsd.org/D13466 MFC r326879 (by emaste): lld: Simplify a boolean expression by De Morgan's laws. Cherry-pick lld r315653 by Rui Ueyama: I don't really understand what exactly this expression means, but at least I can mechanically transform it. Obtained from: LLVM r315653 MFC r326897 (by emaste): lld: Slightly simplify code and add comment. Cherry-pick lld r315658 by Rui Ueyama: This is not a mechanical transformation. Even though I believe this patch is correct, I'm not 100% sure if lld with this patch behaves exactly the same way as before on all edge cases. At least all tests still pass. I'm submitting this patch because it took almost a day to understand this function, and I don't want to lose it. This fixes jemalloc assertion failures observed at startup with i386 binaries and an lld-linked libc.so. Reviewed by: dim Obtained from: LLVM r315658 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D13503 MFC r326909: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 5.0.1 release (upstream r320880). Relnotes: yes MFC r326957 (by emaste): lld: Don't write preemptible symbol values to the .got. It is not necessary and matches what bfd and gold do. This was a regression from [LLVM] r315658. Obtained from: LLVM r321023 by Rafael Espíndola

Merge clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 release.

2017-09-26T19:56:36Z

MFC r309126 (by emaste): Correct lld llvm-tblgen dependency file name MFC r309169: Get rid of separate Subversion mergeinfo properties for llvm-dwarfdump and llvm-lto. The mergeinfo confuses Subversion enormously, and these directories will just use the mergeinfo for llvm itself. MFC r312765: Pull in r276136 from upstream llvm trunk (by Wei Mi): Use ValueOffsetPair to enhance value reuse during SCEV expansion. In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion. However, const folding and sext/zext distribution can make the reuse still difficult. A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and S1 = S2 + C_a S3 = S2 + C_b where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused by the fact that S3 is generated from S1 after const folding. In order to do that, we represent ExprValueMap as a mapping from SCEV to ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to V1 - C_a + C_b. Differential Revision: https://reviews.llvm.org/D21313 This should fix assertion failures when building OpenCV >= 3.1. PR: 215649 MFC r312831: Revert r312765 for now, since it causes assertions when building lang/spidermonkey24. Reported by: antoine PR: 215649 MFC r316511 (by jhb): Add an implementation of __ffssi2() derived from __ffsdi2(). Newer versions of GCC include an __ffssi2() symbol in libgcc and the compiler can emit calls to it in generated code. This is true for at least GCC 6.2 when compiling world for mips and mips64. Reviewed by: jmallett, dim Sponsored by: DARPA / AFRL Differential Revision: https://reviews.freebsd.org/D10086 MFC r318601 (by adrian): [libcompiler-rt] add bswapdi2/bswapsi2 This is required for mips gcc 6.3 userland to build/run. Reviewed by: emaste, dim Approved by: emaste Differential Revision: https://reviews.freebsd.org/D10838 MFC r318884 (by emaste): lldb: map TRAP_CAP to a trace trap In the absense of a more specific handler for TRAP_CAP (generated by ENOTCAPABLE or ECAPMODE while in capability mode) treat it as a trace trap. Example usage (testing the bug in PR219173): % proccontrol -m trapcap lldb usr.bin/hexdump/obj/hexdump -- -Cv -s 1 /bin/ls ... (lldb) run Process 12980 launching Process 12980 launched: '.../usr.bin/hexdump/obj/hexdump' (x86_64) Process 12980 stopped * thread #1, stop reason = trace frame #0: 0x0000004b80c65f1a libc.so.7`__sys_lseek + 10 ... In the future we should have LLDB control the trapcap procctl itself (as it does with ASLR), as well as report a specific stop reason. This change eliminates an assertion failure from LLDB for now. MFC r319796: Remove a few unneeded files from libllvm, libclang and liblldb. MFC r319885 (by emaste): lld: ELF: Fix ICF crash on absolute symbol relocations. If two sections contained relocations to absolute symbols with the same value we would crash when trying to access their sections. Add a check that both symbols point to sections before accessing their sections, and treat absolute symbols as equal if their values are equal. Obtained from: LLD commit r292578 MFC r319918: Revert r319796 for now, it can cause undefined references when linking in some circumstances. Reported by: Shawn Webb MFC r319957 (by emaste): lld: Add armelf emulation mode Obtained from: LLD r305375 MFC r321369: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 5.0.0 (trunk r308421). Upstream has branched for the 5.0.0 release, which should be in about a month. Please report bugs and regressions, so we can get them into the release. Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information. MFC r321420: Add a few more object files to liblldb, which should solve errors when linking the lldb executable in some cases. In particular, when the -ffunction-sections -fdata-sections options are turned off, or ineffective. Reported by: Shawn Webb, Mark Millard MFC r321433: Cleanup stale Options.inc files from the previous libllvm build for clang 4.0.0. Otherwise, these can get included before the two newly generated ones (which are different) for clang 5.0.0. Reported by: Mark Millard MFC r321439 (by bdrewery): Move llvm Options.inc hack from r321433 for NO_CLEAN to lib/clang/libllvm. The files are only ever generated to .OBJDIR, not to WORLDTMP (as a sysroot) and are only ever included from a compilation. So using a beforebuild target here removes the file before the compilation tries to include it. MFC r321664: Pull in r308891 from upstream llvm trunk (by Benjamin Kramer): [CodeGenPrepare] Cut off FindAllMemoryUses if there are too many uses. This avoids excessive compile time. The case I'm looking at is Function.cpp from an old version of LLVM that still had the giant memcmp string matcher in it. Before r308322 this compiled in about 2 minutes, after it, clang takes infinite* time to compile it. With this patch we're at 5 min, which is still bad but this is a pathological case. The cut off at 20 uses was chosen by looking at other cut-offs in LLVM for user scanning. It's probably too high, but does the job and is very unlikely to regress anything. Fixes PR33900. * I'm impatient and aborted after 15 minutes, on the bug report it was killed after 2h. Pull in r308986 from upstream llvm trunk (by Simon Pilgrim): [X86][CGP] Reduce memcmp() expansion to 2 load pairs (PR33914) D35067/rL308322 attempted to support up to 4 load pairs for memcmp inlining which resulted in regressions for some optimized libc memcmp implementations (PR33914). Until we can match these more optimal cases, this patch reduces the memcmp expansion to a maximum of 2 load pairs (which matches what we do for -Os). This patch should be considered for the 5.0.0 release branch as well Differential Revision: https://reviews.llvm.org/D35830 These fix a hang (or extremely long compile time) when building older LLVM ports. Reported by: antoine PR: 219139 MFC r321719: Pull in r309503 from upstream clang trunk (by Richard Smith): PR33902: Invalidate line number cache when adding more text to existing buffer. This led to crashes as the line number cache would report a bogus line number for a line of code, and we'd try to find a nonexistent column within the line when printing diagnostics. This fixes an assertion when building the graphics/champlain port. Reported by: antoine, kwm PR: 219139 MFC r321723: Upgrade our copies of clang, llvm, lld and lldb to r309439 from the upstream release_50 branch. This is just after upstream's 5.0.0-rc1. MFC r322320: Upgrade our copies of clang, llvm and libc++ to r310316 from the upstream release_50 branch. MFC r322326 (by emaste): lldb: Make i386-*-freebsd expression work on JIT path * Enable i386 ABI creation for freebsd * Added an extra argument in ABISysV_i386::PrepareTrivialCall for mmap syscall * Unlike linux, the last argument of mmap is actually 64-bit(off_t). This requires us to push an additional word for the higher order bits. * Prior to this change, ktrace dump will show mmap failures due to invalid argument coming from the 6th mmap argument. Submitted by: Karnajit Wangkhem Differential Revision: https://reviews.llvm.org/D34776 MFC r322360 (by emaste): lldb: Report inferior signals as signals, not exceptions, on FreeBSD This is the FreeBSD equivalent of LLVM r238549. This serves 2 purposes: * LLDB should handle inferior process signals SIGSEGV/SIGILL/SIGBUS/ SIGFPE the way it is suppose to be handled. Prior to this fix these signals will neither create a coredump, nor exit from the debugger or work for signal handling scenario. * eInvalidCrashReason need not report "unknown crash reason" if we have a valid si_signo llvm.org/pr23699 Patch by Karnajit Wangkhem Differential Revision: https://reviews.llvm.org/D35223 Submitted by: Karnajit Wangkhem Obtained from: LLVM r310591 MFC r322474 (by emaste): lld: Add `-z muldefs` option. Obtained from: LLVM r310757 MFC r322740: Upgrade our copies of clang, llvm, lld and libc++ to r311219 from the upstream release_50 branch. MFC r322855: Upgrade our copies of clang, llvm, lldb and compiler-rt to r311606 from the upstream release_50 branch. As of this version, lib/msun's trig test should also work correctly again (see bug 220989 for more information). PR: 220989 MFC r323112: Upgrade our copies of clang, llvm, lldb and compiler-rt to r312293 from the upstream release_50 branch. This corresponds to 5.0.0 rc4. As of this version, the cad/stepcode port should now compile in a more reasonable time on i386 (see bug 221836 for more information). PR: 221836 MFC r323245: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 5.0.0 release (upstream r312559). Release notes for llvm, clang and lld will be available here soon: Relnotes: yes

Update clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 release:

2017-04-02T17:24:58Z

MFC r309142 (by emaste): Add WITH_LLD_AS_LD build knob If set it installs LLD as /usr/bin/ld. LLD (as of version 3.9) is not capable of linking the world and kernel, but can self-host and link many substantial applications. GNU ld continues to be used for the world and kernel build, regardless of how this knob is set. It is on by default for arm64, and off for all other CPU architectures. Sponsored by: The FreeBSD Foundation MFC r310840: Reapply 310775, now it also builds correctly if lldb is disabled: Move llvm-objdump from CLANG_EXTRAS to installed by default We currently install three tools from binutils 2.17.50: as, ld, and objdump. Work is underway to migrate to a permissively-licensed tool-chain, with one goal being the retirement of binutils 2.17.50. LLVM's llvm-objdump is intended to be compatible with GNU objdump although it is currently missing some options and may have formatting differences. Enable it by default for testing and further investigation. It may later be changed to install as /usr/bin/objdump, it becomes a fully viable replacement. Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D8879 MFC r312855 (by emaste): Rename LLD_AS_LD to LLD_IS_LD, for consistency with CLANG_IS_CC Reported by: Dan McGregor MFC r313559 | glebius | 2017-02-10 18:34:48 +0100 (Fri, 10 Feb 2017) | 5 lines Don't check struct rtentry on FreeBSD, it is an internal kernel structure. On other systems it may be API structure for SIOCADDRT/SIOCDELRT. Reviewed by: emaste, dim MFC r314152 (by jkim): Remove an assembler flag, which is redundant since r309124. The upstream took care of it by introducing a macro NO_EXEC_STACK_DIRECTIVE. http://llvm.org/viewvc/llvm-project?rev=273500&view=rev Reviewed by: dim MFC r314564: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 (branches/release_40 296509). The release will follow soon. Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information. Also note that as of 4.0.0, lld should be able to link the base system on amd64 and aarch64. See the WITH_LLD_IS_LLD setting in src.conf(5). Though please be aware that this is work in progress. Release notes for llvm, clang and lld will be available here: Thanks to Ed Maste, Jan Beich, Antoine Brodin and Eric Fiselier for their help. Relnotes: yes Exp-run: antoine PR: 215969, 216008 MFC r314708: For now, revert r287232 from upstream llvm trunk (by Daniil Fukalov): [SCEV] limit recursion depth of CompareSCEVComplexity Summary: CompareSCEVComplexity goes too deep (50+ on a quite a big unrolled loop) and runs almost infinite time. Added cache of "equal" SCEV pairs to earlier cutoff of further estimation. Recursion depth limit was also introduced as a parameter. Reviewers: sanjoy Subscribers: mzolotukhin, tstellarAMD, llvm-commits Differential Revision: https://reviews.llvm.org/D26389 This commit is the cause of excessive compile times on skein_block.c (and possibly other files) during kernel builds on amd64. We never saw the problematic behavior described in this upstream commit, so for now it is better to revert it. An upstream bug has been filed here: https://bugs.llvm.org/show_bug.cgi?id=32142 Reported by: mjg MFC r314795: Reapply r287232 from upstream llvm trunk (by Daniil Fukalov): [SCEV] limit recursion depth of CompareSCEVComplexity Summary: CompareSCEVComplexity goes too deep (50+ on a quite a big unrolled loop) and runs almost infinite time. Added cache of "equal" SCEV pairs to earlier cutoff of further estimation. Recursion depth limit was also introduced as a parameter. Reviewers: sanjoy Subscribers: mzolotukhin, tstellarAMD, llvm-commits Differential Revision: https://reviews.llvm.org/D26389 Pull in r296992 from upstream llvm trunk (by Sanjoy Das): [SCEV] Decrease the recursion threshold for CompareValueComplexity Fixes PR32142. r287232 accidentally increased the recursion threshold for CompareValueComplexity from 2 to 32. This change reverses that change by introducing a separate flag for CompareValueComplexity's threshold. The latter revision fixes the excessive compile times for skein_block.c. MFC r314907 | mmel | 2017-03-08 12:40:27 +0100 (Wed, 08 Mar 2017) | 7 lines Unbreak ARMv6 world. The new compiler_rt library imported with clang 4.0.0 have several fatal issues (non-functional __udivsi3 for example) with ARM specific instrict functions. As temporary workaround, until upstream solve these problems, disable all thumb[1][2] related feature. MFC r315016: Update clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 release. We were already very close to the last release candidate, so this is a pretty minor update. Relnotes: yes MFC r316005: Revert r314907, and pull in r298713 from upstream compiler-rt trunk (by Weiming Zhao): builtins: Select correct code fragments when compiling for Thumb1/Thum2/ARM ISA. Summary: Value of __ARM_ARCH_ISA_THUMB isn't based on the actual compilation mode (-mthumb, -marm), it reflect's capability of given CPU. Due to this: - use __tbumb__ and __thumb2__ insteand of __ARM_ARCH_ISA_THUMB - use '.thumb' directive consistently in all affected files - decorate all thumb functions using DEFINE_COMPILERRT_THUMB_FUNCTION() --------- Note: This patch doesn't fix broken Thumb1 variant of __udivsi3 ! Reviewers: weimingz, rengolin, compnerd Subscribers: aemerson, dim Differential Revision: https://reviews.llvm.org/D30938 Discussed with: mmel

MFC r313009:

2017-03-07T02:01:02Z

Expose symbols in lib/libclang_rt/profile to fix --coverage The symbols currently hidden in libprofile_rt are needed for linking with `clang --coverage` to add coverage counters at link time and produce coverage numbers at runtime. In collaboration with: dim