Merge commit 740a164de from llvm git (by Richard Smith): PR46377: Fix dependence calculation for function types and typedef types. We previously did not treat a function type as dependent if it had a parameter pack with a non-dependent type -- such a function type depends on the arity of the pack so is dependent even though none of the parameter types is dependent. In order to properly handle this, we now treat pack expansion types as always being dependent types (depending on at least the pack arity), and always canonically being pack expansion types, even in the unusual case when the pattern is not a dependent type. This does mean that we can have canonical types that are pack expansions that contain no unexpanded packs, which is unfortunate but not inaccurate. We also previously did not treat a typedef type as instantiation-dependent if its canonical type was not instantiation-dependent. That's wrong because instantiation-dependence is a property of the type sugar, not of the type; an instantiation-dependent type can have a non-instantiation-dependent canonical type. Merge commit 9cf98d26e from llvm git (by Richard Smith): PR46637: Fix handling of placeholder types in trailing-return-types. Only permit a placeholder type in a trailing-return-type if it would also have been permitted in the decl-specifier sequence of a corresponding declaration with no trailing-return-type. The standard doesn't actually say this, but this is the only thing that makes sense. Also fix handling of an 'auto' in a trailing-return-type in a parameter of a generic lambda. We used to crash if we saw such a thing. Merge commit 234f51a65 from llvm git (by Richard Smith): Don't crash if we deserialize a pack expansion type whose pattern contains no packs. Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb. PR: 252892 Reported by: thierry MFC after: 3 days (cherry picked from commit e63539f)

When building natively on RISC-V, linking the bootstrap clang-tblgen fails with: ld: error: undefined symbol: llvm::EnableABIBreakingChecks >>> referenced by PrettyStackTrace.cpp >>> PrettyStackTrace.o:(.sdata+0x0) in archive /usr/obj/usr/src/freebsd-src/riscv.riscv64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a >>> referenced by Signals.cpp >>> Signals.o:(.sdata+0x8) in archive /usr/obj/usr/src/freebsd-src/riscv.riscv64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a >>> referenced by Timer.cpp >>> Timer.o:(.sdata+0x28) in archive /usr/obj/usr/src/freebsd-src/riscv.riscv64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a This is likely due to Error.h's inclusion of abi-breaking.h. It's unclear why this only affects RISC-V, but perhaps relates to its more eager use of .sdata due to the ABI's support for linker relaxations. Regardless, this is theoretically an issue for all architectures. Reported by: Dennis Clarke <dclarke@blastwave.org> Reviewed by: dim Tested by: mhorne MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D28367 (cherry picked from commit 48397f6)

Clang commit ccb4124a4172bf2cb2e1cd7c253f0f1654fce294: Fix -gz=zlib options for linker gcc translates -gz=zlib to --compress-debug-options=zlib for both assembler and linker but clang only does this for assembler. The linker needs --compress-debug-options=zlib option to compress the debug sections in the generated executable or shared library. Due to this bug, -gz=zlib has no effect on the generated executable or shared library. This patch fixes that. Clang commit 462cf39a5c180621b56f7602270ce33eb7b68d23: [Driver] Fix -gz=zlib options for linker also on FreeBSD ccb4124a4172 fixed translating -gz=zlib to --compress-debug-sections for linker invocation for several ToolChains, but omitted FreeBSD. Approved by: dim MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D29028 (cherry picked from commit 19587d7)

Otherwise, programs compiled with -fprofile-instr-generate will encounter undefined symbol errors during linking, for example __llvm_profile_counter_bias, lprofSetRuntimeCounterRelocation and a few others were missing from the profile library. Reported by: ota@j.email.ne.jp PR: 254001 MFC after: 3 days (cherry picked from commit 772c631)

With an out-of-tree Clang, we can use the -resource-dir flag when linking to point it at the runtime libraries from the current SYSROOT. This moves the path to the clang-internal library directory to a separate .mk file that can be used by Makefiles that want to find the sanitizer libraries. I intend to re-use this .mk file for my upcoming changes that allow building the entire base system with ASAN/UBSAN/MSAN. Reviewed By: dim Differential Revision: https://reviews.freebsd.org/D28852 (cherry picked from commit fe525d3)

Merge commit 99eca1bd9c7a from llvm git (by Mark Johnston): [Driver] Enable kernel address and memory sanitizers on FreeBSD Test Plan: using kernel ASAN and MSAN implementations in FreeBSD Reviewed By: emaste, dim, arichardson Differential Revision: https://reviews.llvm.org/D98286 Merge commit f511dc75e4c1 from llvm git (by Mark Johnston): [asan] Add an offset for the kernel address sanitizer on FreeBSD This is based on a port of the sanitizer runtime to the FreeBSD kernel that has been commited as https://cgit.freebsd.org/src/commit/?id=38da497a4dfcf1979c8c2b0e9f3fa0564035c147 and the following commits. Reviewed By: emaste, dim Differential Revision: https://reviews.llvm.org/D98285 Requested by: markj MFC after: 3 days (cherry picked from commit 1b00608)

…emaphore> I missed adding these to the libc++ Makefile, when importing llvm-project 11.0.0-rc1, even though they were supplied by upstream. While here, update OptionalObsoleteFiles.inc to add these new headers, and cleanup old cruft. Reported by: yuri Submitted by: jkim (Makefile diff) PR: 255374 MFC after: 3 days (cherry picked from commit 95aa617)

On little-endian PowerPC64, this prevented /usr/lib/clang/11.0.0 being cleaned up completely after upgrading to clang 11.0.1. Noticed by: pkubaj MFC after: 4 weeks X-MFC-With: r364284 (cherry picked from commit 7593c13)

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-12-init-17869-g8e464dd76bef, the last commit before the upstream release/12.x branch was created. PR: 255570 MFC after: 6 weeks (cherry picked from commit e8d8bef)

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-12.0.0-0-gd28af7c654d8, a.k.a. 12.0.0 release. PR: 255570 MFC after: 6 weeks (cherry picked from commit d409305)

Merge commit 5c18d1136665 from llvm git (by Qiu Chaofan) [SPE] Disable strict-fp for SPE by default As discussed in PR50385, strict-fp on PowerPC SPE has not been handled well. This patch disables it by default for SPE. Reviewed By: nemanjai, vit9696, jhibbits Differential Revision: https://reviews.llvm.org/D103235 PR: 255570 MFC after: 6 weeks (cherry picked from commit 715df83)

…-gcc Merge commit 52e9d80d5db2 from llvm git (by Jason Liu): [libc++] add `inline` for __open's definition in ifstream and ofstream Summary: When building with gcc on AIX, it seems that gcc does not like the `always_inline` without the `inline` keyword. So adding the inline keywords in for __open in ifstream and ofstream. That will also make it consistent with __open in basic_filebuf (it seems we added `inline` there before for gcc build as well). Differential Revision: https://reviews.llvm.org/D99422 PR: 255570 MFC after: 6 weeks (cherry picked from commit d099db2)

Otherwise, the lli tool (enable by WITH_CLANG_EXTRAS) won't link on arm, stating that __register_frame is undefined. This function is normally provided by libunwind, but explicitly not for the ARM Exception ABI. Reported by: oh PR: 255570 MFC after: 6 weeks (cherry picked from commit f336b45)

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-12.0.1-rc2-0-ge7dac564cd0e, a.k.a. 12.0.1 rc2. PR: 255570 MFC after: 6 weeks (cherry picked from commit 2340829)

Revert commit 22b615a96593 from llvm git (by Daniel Kiss): [libunwind] Support for leaf function unwinding. Unwinding leaf function is useful in cases when the backtrace finds a leaf function for example when it caused a signal. This patch also add the support for the DW_CFA_undefined because it marks the end of the frames. Ryan Prichard provided code for the tests. Reviewed By: #libunwind, mstorsjo Differential Revision: https://reviews.llvm.org/D83573 Reland with limit the test to the x86_64-linux target. Bisection has shown that this particular upstream commit causes programs using backtrace(3) on aarch64 to segfault. This affects the lang/rust port, for instance. Until we can upstream to fix this problem, revert the commit for now. Reported by: mikael PR: 256864 (cherry picked from commit 5866c36)

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-12.0.1-0-gfed41342a82f, a.k.a. 12.0.1 release. PR: 255570 MFC after: 6 weeks (cherry picked from commit 4652422)

Both clang >= 12 and gcc >= 10.1 now default to -moutline-atomics for aarch64. This requires a bunch of helper functions in libcompiler_rt.a, to avoid link errors like "undefined symbol: __aarch64_ldadd8_acq_rel". (Note: of course you can use -mno-outline-atomics as a workaround too, but this would negate the potential performance benefit of the faster LSE instructions.) Bump __FreeBSD_version so ports maintainers can easily detect this. PR: 257392 MFC after: 2 weeks (cherry picked from commit cc55ee8)

This is needed in order to build various LLVM binutils (e.g. addr2line) as well as clang/lld/lldb. Co-authored-by: Jessica Clarke <jrtc27@FreeBSD.org> Test Plan: Compiles on ubuntu 18.04 and macOS 11.4 Reviewed By: dim Differential Revision: https://reviews.freebsd.org/D31057 (cherry picked from commit 31ba4ce)

This is needed for -DWITH_CLEAN builds since the cleandir phase does not include bsd.linker.mk from bsd.compiler.mk (cherry picked from commit 9f1db6c)

Merge commit c6ebc651b6fa from llvm git (by Simon Atanasyan): [LLD] Support compressed input sections on big-endian targets This patch enables compressed input sections on big-endian targets by checking the target endianness and selecting an appropriate `Chdr` structure. Fixes PR51369 Differential Revision: https://reviews.llvm.org/D107635 Reported by: emaste MFC after: 3 days (cherry picked from commit d69d075)

This makes it easier to detect that lld's support for compressed input sections on BE targets is fixed. MFC after: 3 days X-MFC-With: d69d075 (cherry picked from commit cd38d9c)

Fixes: 31ba4ce ("Allow bootstrapping llvm-tblgen on macOS and Linux") MFC after: 1 week (cherry picked from commit 5ff5d11)

Merge commit 5033f0793fe6 from llvm git (by Dimitry Andric): [lldb] Avoid unhandled Error in TypeSystemMap::GetTypeSystemForLanguage When assertions are turned off, the `llvm::Error` value created at the start of this function is overwritten using the move-assignment operator, but the success value is never checked. Whenever a TypeSystem cannot be found or created, this can lead to lldb core dumping with: Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Fix this by not creating a `llvm::Error` value in advance, and directly returning the result of `llvm::make_error` instead, whenever an error is encountered. See also: <https://bugs.freebsd.org/253881> and <https://bugs.freebsd.org/257829>. Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D108088 Reported by: dmgk, ota@j.email.ne.jp PR: 253881, 257829 MFC after: 3 days (cherry picked from commit c1a5407)

Sponsored by: DellEMC (cherry picked from commit 48da57b)

…MK_TESTS. X-MFC-With: r349065 Sponsored by: DellEMC (cherry picked from commit 8e0c373)

If MK_DEBUG_FILES=no then the Clang link rule has clang as .TARGET, rather than clang.full, causing the implicit ${CFLAGS.${.TARGET:T}} to be CFLAGS.clang, and thus pull in flags intended for when your compiler is Clang, not when linking Clang itself. This doesn't matter if your compiler is in fact Clang, but it breaks using GCC as, for example, bsd.sys.mk adds -Qunused-arguments to CFLAGS.clang. This is seen when trying to build a bootstrap toolchain on Linux where GCC is the system compiler. Thus, introduce a new internal NO_TARGET_FLAGS variable that is set by Clang to disable the addition of these implicit flags. This is a bigger hammer than necessary, as flags for .o files would be safe, but that is not needed for Clang. Note that the same problem does not arise for LDFLAGS when building LLD with BFD, since our build produces a program called ld.lld, not plain lld (unlike upstream, where ld.lld is a symlink to lld so they can support multiple different flavours in one binary). Suggested by: sjg Fixes: 31ba4ce ("Allow bootstrapping llvm-tblgen on macOS and Linux") MFC after: 1 week Reviewed by: dim, imp, emaste Differential Revision: https://reviews.freebsd.org/D31532 (cherry picked from commit c8edd05)

Somewhat ironically, there are strict aliasing violations in Clang, which can result in the following assertion failure: Assertion `*(NamedDecl **)&Data == ND && "PointerUnion mangles the NamedDecl pointer!"' failed. Upstream's clang/CMakeLists.txt specifically (not LLVM as a whole) passes -fno-strict-aliasing if the compiler is not Clang, and this fixes the above issue. This was seen when cross-building from Linux using a bootstrap compiler, but likely also affects worlds built with a new enough external GCC toolchain. MFC after: 1 week Reviewed by: dim Differential Revision: https://reviews.freebsd.org/D31533 (cherry picked from commit c1f7d8d)

Amends LLVM commit 2518433f861fcb877d0a7bdd9aec1aec1f77505a that was pointed as the source of regression on LLVM12. This affects powerpc64*, making binaries crash with segmentation fault due to bad code generation around "__stack_chk_guard" Root cause and/or proper fix is under investigation by: https://bugs.llvm.org/show_bug.cgi?id=51590 Reviewed by: dim MFC after: 2 days Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br) Differential Revision: https://reviews.freebsd.org/D31698 (cherry picked from commit 9a4d48a)

…ction for InitLoopCount." Reverts llvm commit 42eaf4fe0adef3344adfd9fbccd49f325cb549ef, pointed from bisect as source of regression that causes liblzma to compress/ uncompress incorrectly. It's know to affect powerpc64 BE only. The patch unbreaks FreeBSD powerpc64 installation media, since bsdinstall can't uncompress the *.txz produced by FreeBSD CI. It's probably miscompiling other software bas well. Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=51714 Reviewed by: dim MFC after: 2 days Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br) Differential Revision: https://reviews.freebsd.org/D31804 (cherry picked from commit f21fcae)

The tablegen binaries are only needed to build software that uses LLVM's infrastructure for command line options, disassembler tables, etc. They are not user-facing binaries and should therefore not be installed by default. Reviewed By: emaste Differential Revision: https://reviews.freebsd.org/D31058 (cherry picked from commit 8e1c989)

Split out from D31060. Reviewed by: emaste (cherry picked from commit c5d1d88)

Because MK_LLDB=no is in BSARGS, the bootstrap-tools recursive make does not add lldb-tblgen to _clang_tblgen, causing it to not be built. This means that the build currently always uses the host's lldb-tblgen (which, whilst currently it appears to work, could in future break if TableGen backends are added or altered) and, if it doesn't exist (either because the current FreeBSD system was built with it disabled, or you're building on macOS/Linux), fails. Linux and macOS cross-builds used to work simply because LLDB was previously in BROKEN_OPTIONS when building on non-FreeBSD. Instead, move MK_LLDB=no from BSARGS to XMAKE. This ensures that the lib/clang build in cross-tools continues to not build LLDB parts for the bootstrap toolchain (both to save time/space on FreeBSD, and because our vendored LLDB does not include the macOS and Linux host files so those would fail to build). The DIRDEPS target is updated to move MK_LLDB=no from the BSARGS block that mirrors Makefile.inc1 to the line that disables additional toolchain components. The DIRDEPS build likely suffers from the same issue currently, but having never used it and not being familiar with how it works I am leaving that as-is. If it does suffer from the same issue it should be easily reproducible by renaming /usr/bin/lldb-tblgen or moving it to a directory not in PATH. Fixes: 31ba4ce ("Allow bootstrapping llvm-tblgen on macOS and Linux") MFC after: 1 week Reviewed by: dim, emaste, imp Differential Revision: https://reviews.freebsd.org/D31531 (cherry picked from commit 1e4c802)

When WITH_LLVM_BINUTILS is set, we will install the LLVM binutils as ar/ranlib/nm/objcopy/etc. instead of the elftoolchain ones. Having the LLVM binutils instead of the elftoolchain ones allows us to use features such as LTO that depend on binutils that understand LLVM IR. Another benefit will be an improved user-experience when compiling with AddressSanitizer, since ASAN does not symbolize backtraces correctly if addr2line is elftoolchain addr2line instead of llvm-symbolizer. See https://lists.freebsd.org/archives/freebsd-toolchain/2021-July/000062.html for more details. This is currently off by default but will be turned on by default at some point in the near future. Reviewed By: emaste Differential Revision: https://reviews.freebsd.org/D31060 (cherry picked from commit 021385a)

As reported by Ronald, adding the out-of-line LSE atomics helpers for aarch64 to compiler-rt was not sufficient to link programs using these, as they also require a __aarch64_have_lse_atomics global. This is initialized in compiler-rt's lib/builtins/cpu_model.c, roughly similar to the x86 CPU model and feature detection in that file. Since upstream does not yet have a FreeBSD specific implementation for getting the required information, add a simple one that should work for now, while I try to get it sorted with the LLVM people. Reported by: Ronald Klop <ronald-lists@klop.ws> Fixes: cc55ee8 PR: 257392 MFC after: 2 weeks (cherry picked from commit efe67f3)

Just as elftoolchain's objcopy doubles as strip, so does LLVM's. This ensures that a strip binary is still present for WITH_LLVM_BINUTILS builds. Note that we do not currently have a committed copy of the manpage generated from the rST source so no manpage is installed for (llvm-)strip. Reported by: Shawn Webb <shawn.webb@hardenedbsd.org> Tested by: Shawn Webb <shawn.webb@hardenedbsd.org> MFC after: 1 week (cherry picked from commit f28c1d0)

The corresponding 32-bit int and 128-bit int functions were added in 790a6be, as were all combinations of the float to int functions, but these two were overlooked. __floatditf is needed to build curl for riscv as there's a signed 64-bit int to 128-bit float conversion in lib/progress.c's trspeed as of 7.77.0. Reviewed by: dim MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D31997 (cherry picked from commit 7047568)

I forgot to update this file so make delete-old would incorrectly remove the newly-installed LLVM binutils. While touching the file also update for 8e1c989 since ObsoleteFiles.inc now inludes the tablegen binaries. Reported by: Herbert J. Skuhra <herbert@gojira.at> Reviewed By: emaste, imp Differential Revision: https://reviews.freebsd.org/D32022 (cherry picked from commit 88c0273)

Also install it as readelf when MK_LLVM_BINUTILS is set. Reviewed By: dim, arichardson Differential Revision: https://reviews.freebsd.org/D32058 (cherry picked from commit 1b85b68)

Reported by: Michael Butler, jenkins (cherry picked from commit 367ec75)

In some configurations (e.g. powerpc64) the llvm-readobj tool also needs contrib/llvm-project/llvm/BinaryFormat/MsgPackWriter.cpp, so add it to libllvm. Reported by: Shawn Webb <shawn.webb@hardenedbsd.org> Fixes: 1b85b68 (cherry picked from commit 79239b5)

Merge commit 2d8c18fbbdd1 from llvm git (by Jessica Clarke): [X86] Don't add implicit REP prefix to VIA PadLock xstore Commit 8fa3e8fa1492 added an implicit REP prefix to all VIA PadLock instructions, but GNU as doesn't add one to xstore, only all the others. This resulted in a kernel panic regression in FreeBSD upon updating to LLVM 11 (https://bugs.freebsd.org/259218) which includes the commit in question. This partially reverts that commit. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D112355 MFC after: 3 days (cherry picked from commit 4b97251)

Otherwise, linking llvm binaries with this target enabled (which is not the default) will fail with a number of undefined symbol errors: ld: error: undefined symbol: llvm::initializeBPFAdjustOptPass(llvm::PassRegistry&) ld: error: undefined symbol: llvm::initializeBPFCheckAndAdjustIRPass(llvm::PassRegistry&) ld: error: undefined symbol: llvm::createBPFCheckAndAdjustIR() ld: error: undefined symbol: llvm::createBPFAdjustOpt() ld: error: undefined symbol: llvm::BPFAdjustOptPass::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) Reported by: Michael Dexter <editor@callfortesting.org> MFC after: 3 days (cherry picked from commit d30dc78)

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before the upstream release/13.x branch was created. PR: 258209 MFC after: 2 weeks (cherry picked from commit fe6060f)

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-13.0.0-rc1-97-g23ba3732246a. PR: 258209 MFC after: 2 weeks (cherry picked from commit 6e75b2f)

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-13.0.0-rc2-43-gf56129fe78d5. PR: 258209 MFC after: 2 weeks (cherry picked from commit 69ade1e)

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-13.0.0-rc3-8-g08642a395f23. PR: 258209 MFC after: 2 weeks (cherry picked from commit 8c6f6c0)

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-13.0.0-0-gd7b669b3a303, aka 13.0.0 release. PR: 258209 MFC after: 2 weeks (cherry picked from commit 28a4118)

Merge commit c9539f957f57 from llvm git (by Nemanja Ivanovic): [PowerPC] Define XL-compatible macros only for AIX and Linux Since XLC only ever shipped on PowerPC AIX and Linux, it is not reasonable to provide the compatibility macros on any target other than those two. This patch restricts those macros to AIX/Linux. Differential revision: https://reviews.llvm.org/D110213 PR: 258209 (cherry picked from commit 39dadd0)

Merge commit f5755c0849a5 from llvm git (by Jessica Clarke): [Mips] Add glue between CopyFromReg, CopyToReg and RDHWR nodes for TLS The MIPS ABI requires the thread pointer be accessed via rdhwr $3, $r29. This is currently represented by (CopyToReg $3, (RDHWR $29)) followed by a (CopyFromReg $3). However, there is no glue between these, meaning scheduling can break those apart. In particular, PR51691 is a report where PseudoSELECT_I was moved to between the CopyToReg and CopyFromReg, and since its expansion uses branches, it split the def and use of the physical register between two basic blocks, resulting in the def being eliminated and the use having no def. It also seems possible that a similar situation could arise splitting up the CopyToReg from the RDHWR, causing the RDHWR to use a destination register other than $3, violating the ABI requirement. Thus, add glue between all three nodes to ensure they aren't split up during instruction selection. No regression test is added since any test would be implictly relying on specific scheduling behaviour, so whilst it might be testing that glue is preventing reordering today, changes to scheduling behaviour could result in the test no longer being able to catch a regression here, as the reordering might no longer happen for other unrelated reasons. Fixes PR51691. Reviewed By: atanasyan, dim Differential Revision: https://reviews.llvm.org/D111967 (cherry picked from commit 4e117af)

Merge commit 029f1a534489 from llvm git (by Arthur Eubanks): [LazyCallGraph] Skip blockaddresses blockaddresses do not participate in the call graph since the only instructions that use them must all return to someplace within the current function. And passes cannot retrieve a function address from a blockaddress. This was suggested by efriedma in D58260. Fixes PR50881. Reviewed By: nickdesaulniers Differential Revision: https://reviews.llvm.org/D112178 (cherry picked from commit a18c616)

Commits on Dec 25, 2021