Follow-up r365662 (MFC of r365371 and r365373) by correctly setting
WITH_MALLOC_PRODUCTION for stable branches. Also add a note to UPDATING,
to inform users about the new setting.

Direct commit to stable/{11,12} as this does not apply to head.

Noticed by: imp, Ronald Klop <ronald-lists@klop.ws>

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
10.0.1 final (aka llvmorg-10.0.1-0-gef32c611aa2).

MFC r360702:

Merge commit 4ca2cad94 from llvm git (by Justin Hibbits):

[PowerPC] Add clang -msvr4-struct-return for 32-bit ELF

Summary:

Change the default ABI to be compatible with GCC. For 32-bit ELF
targets other than Linux, Clang now returns small structs in
registers r3/r4. This affects FreeBSD, NetBSD, OpenBSD. There is no
change for 32-bit Linux, where Clang continues to return all structs
in memory.

Add clang options -maix-struct-return (to return structs in memory)
and -msvr4-struct-return (to return structs in registers) to be
compatible with gcc. These options are only for PPC32; reject them on
PPC64 and other targets. The options are like -fpcc-struct-return and
-freg-struct-return for X86_32, and use similar code.

To actually return a struct in registers, coerce it to an integer of
the same size. LLVM may optimize the code to remove unnecessary
accesses to memory, and will return i32 in r3 or i64 in r3:r4.

Fixes PR#40736

Patch by George Koehler!

Reviewed By: jhibbits, nemanjai
Differential Revision: https://reviews.llvm.org/D73290

Requested by: jhibbits

MFC r361410:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.1-rc1-0-gf79cd71e145 (aka 10.0.1 rc1).

MFC r362235 (by kp):

llvm: Default to -mno-relax on RISC-V

Compiling on a RISC-V system fails with 'relocation R_RISCV_ALIGN
requires unimplemented linker relaxation; recompile with -mno-relax'.

Our default linker (ld.lld) doesn't support relaxation, so default to
no-relax so we don't generate object files the linker can't handle.

Reviewed by: mhorne
Sponsored by: Axiado
Differential Revision: https://reviews.freebsd.org/D25210

MFC r362445:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-97-g6f71678ecd2 (not quite 10.0.1 rc2, as more fixes are
still pending).

MFC r362587 (by cem):

Add WITH_CLANG_FORMAT option

clang-format is enabled conditional on either WITH_CLANG_EXTRAS or
WITH_CLANG_FORMAT. Some sources in libclang are build conditional on
either rule, and obviously the clang-format binary itself depends on the
rule.

clang-format could still use a manual page.

Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D25427

MFC r362609:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-129-gd24d5c8e308. Getting closer to 10.0.1-rc2.

MFC r362679:

Regenerate ReStructuredText based manpages for llvm-project tools:

* bugpoint.1
* clang.1
* llc.1
* lldb.1
* lli.1
* llvm-ar.1
* llvm-as.1
* llvm-bcanalyzer.1
* llvm-cov.1
* llvm-diff.1
* llvm-dis.1
* llvm-dwarfdump.1
* llvm-extract.1
* llvm-link.1
* llvm-mca.1
* llvm-nm.1
* llvm-pdbutil.1
* llvm-profdata.1
* llvm-symbolizer.1
* llvm-tblgen.1
* opt.1

Add newly generated manpages for:

* llvm-addr2line.1 (this is an alias of llvm-symbolizer)
* llvm-cxxfilt.1
* llvm-objcopy.1
* llvm-ranlib.1 (this is an alias of llvm-ar)

Note that llvm-objdump.1 is an exception, as upstream has both a plain
.1 file, and a .rst variant. These will have to be reconciled upstream
first.

MFC r362680:

Follow-up to r362679, add more entries to OptionalObsoleteFiles.inc

MFC r362719:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.1-rc2-0-g77d76b71d7d.

Also add a few more llvm utilities under WITH_CLANG_EXTRAS:

* llvm-dwp, a utility for merging DWARF 5 Split DWARF .dwo files into
.dwp (DWARF package files)
* llvm-size, a size(1) replacement
* llvm-strings, a strings(1) replacement

MFC r362733:

Remove older llvm-ranlib.1 entry from ObsoleteFiles.inc, as it has
gotten its own manpage now, and should be no longer be removed by "make
delete-old".

MFC r362734:

Fix llvm-strings.1 not installing, this was a copy/paste error.

MFC r363401:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
10.0.1 final (aka llvmorg-10.0.1-0-gef32c611aa2).

There were no changes since rc2, except in the upstream regression
tests, which we do not ship.

Relnotes: yes

Adjust UPDATING and ObsoleteFiles.inc dates to match reality.

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-0-gd32170dbd5b (aka 10.0.0 release), and a number of
follow-ups.

MFC r356479 (by bdragon):

[PowerPC] Fix libllvmminimal build when building from powerpc64 ELFv1.

When bootstrapping on powerpc64 ELFv1, it is necessary to use binutils
ld.bfd from ports for the bootstrap, as this is the only modern linker for
ELFv1 host tools.

As binutils ld.bfd is rather strict in its handling of undefined symbols,
it is necessary to pull in Support/Atomic.cpp to avoid an undefined symbol.

Reviewed by: dim, emaste
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D23072

MFC r356930:

Add more Subversion mergeinfo bootstrap information, to hopefully
increase the probability of merging in vendor changes.

MFC r358408 (by brooks):

Merge commit 7214f7a79 from llvm git (by Sam Elliott):

[RISCV] Lower llvm.trap and llvm.debugtrap

Summary:
Until this commit, these have lowered to a call to abort().

`llvm.trap()` now lowers to `unimp`, which should trap on all systems.

`llvm.debugtrap()` now lowers to `ebreak`, which is exactly what this
instruction is for.

Reviewers: asb, luismarques

Reviewed By: asb

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D69390

This fixes miscompilation resulting in linking failures with
INVARIANTS disabled.

Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D23857

MFC r358851:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
10.0.0-rc3 c290cb61fdc.

Release notes for llvm, clang, lld and libc++ 10.0.0 will become
available here:

https://releases.llvm.org/10.0.0/docs/ReleaseNotes.html
https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html
https://releases.llvm.org/10.0.0/tools/lld/docs/ReleaseNotes.html
https://releases.llvm.org/10.0.0/projects/libcxx/docs/ReleaseNotes.html

PR: 244251

MFC r358854:

Add one additional file to libllvmminimal, to help the ppc64 bootstrap.

Reported by: bdragon
PR: 244251

MFC r358857:

Move another file in libllvm from sources required for world, to sources
required for bootstrap, as the PowerPC builds need this.

Reported by: bdragon
PR: 244251

MFC r359082:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-rc4-5-g52c365aa9ca. The actual release should follow Real
Soon Now.

PR: 244251

MFC r359084:

Merge commit 00925aadb from llvm git (by Fangrui Song):

[ELF][PPC32] Fix canonical PLTs when the order does not match the PLT order

Reviewed By: Bdragon28

Differential Revision: https://reviews.llvm.org/D75394

This is needed to fix miscompiled canonical PLTs on ppc32/lld10.

Requested by: bdragon
Differential Revision: https://reviews.freebsd.org/D24109

MFC r359085:

Merge commit 315f8a55f from llvm git (by Fangrui Song):

[ELF][PPC32] Don't report "relocation refers to a discarded section"
for .got2

Similar to D63182 [ELF][PPC64] Don't report "relocation refers to a
discarded section" for .toc

Reviewed By: Bdragon28

Differential Revision: https://reviews.llvm.org/D75419

This is needed to fix compile errors when building for ppc32/lld10.

Requested by: bdragon
Differential Revision: https://reviews.freebsd.org/D24110

MFC r359086:

Merge commit b8ebc11f0 from llvm git (by Sanjay Patel):

[EarlyCSE] avoid crashing when detecting min/max/abs patterns (PR41083)

As discussed in PR41083:
https://bugs.llvm.org/show_bug.cgi?id=41083
...we can assert/crash in EarlyCSE using the current hashing scheme
and instructions with flags.

ValueTracking's matchSelectPattern() may rely on overflow (nsw, etc)
or other flags when detecting patterns such as min/max/abs composed
of compare+select. But the value numbering / hashing mechanism used
by EarlyCSE intersects those flags to allow more CSE.

Several alternatives to solve this are discussed in the bug report.
This patch avoids the issue by doing simple matching of min/max/abs
patterns that never requires instruction flags. We give up some CSE
power because of that, but that is not expected to result in much
actual performance difference because InstCombine will canonicalize
these patterns when possible. It even has this comment for abs/nabs:

/// Canonicalize all these variants to 1 pattern.
/// This makes CSE more likely.

(And this patch adds PhaseOrdering tests to verify that the expected
transforms are still happening in the standard optimization
pipelines.

I left this code to use ValueTracking's "flavor" enum values, so we
don't have to change the callers' code. If we decide to go back to
using the ValueTracking call (by changing the hashing algorithm
instead), it should be obvious how to replace this chunk.

Differential Revision: https://reviews.llvm.org/D74285

This fixes an assertion when building the math/gsl port on PowerPC64.

Requested by: pkubja

MFC r359087:

Merge commit 585a3cc31 from llvm git (by me):

Fix -Wdeprecated-copy-dtor and -Wdeprecated-dynamic-exception-spec
warnings.

Summary:
The former are like:

libcxx/include/typeinfo:322:11: warning: definition of implicit copy
constructor for 'bad_cast' is deprecated because it has a
user-declared destructor [-Wdeprecated-copy-dtor]
virtual ~bad_cast() _NOEXCEPT;
^
libcxx/include/typeinfo:344:11: note: in implicit copy constructor
for 'std::bad_cast' first required here
throw bad_cast();
^

Fix these by adding an explicitly defaulted copy constructor.

The latter are like:

libcxx/include/codecvt:105:37: warning: dynamic exception
specifications are deprecated [-Wdeprecated-dynamic-exception-spec]
virtual int do_encoding() const throw();
^~~~~~~

Fix these by using the _NOEXCEPT macro instead.

Reviewers: EricWF, mclow.lists, ldionne, #libc

Reviewed By: EricWF, #libc

Subscribers: dexonsmith, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D76150

This is because we use -Wsystem-headers during buildworld, and the two
warnings above are now triggered by default with clang 10, preventing
most C++ code from compiling without NO_WERROR.

Requested by: brooks
Differential Revision: https://reviews.freebsd.org/D24049

MFC r359333:

Merge commit f0990e104 from llvm git (by Justin Hibbits):

[PowerPC]: e500 target can't use lwsync, use msync instead

The e500 core has a silicon bug that triggers an illegal instruction
program trap on any sync other than msync. Other cores will typically
ignore illegal sync types, and the documentation even implies that
the 'illegal' bits are ignored.

Address this hardware deficiency by only using msync, like the PPC440.

Differential Revision: https://reviews.llvm.org/D76614

Requested by: jhibbits

MFC r359334:

Merge commit 459e8e948 from llvm git (by Justin Hibbits):

[PowerPC]: Don't allow r0 as a target for LD_GOT_TPREL_L/32

Summary:
The linker is free to relax this (relocation R_PPC_GOT_TPREL16)
against R_PPC_TLS, if it sees fit (initial exec to local exec). If r0
is used, this can generate execution-invalid code (converts to 'addi
%rX, %r0, FOO, which translates in PPC-lingo to li %rX, FOO). Forbid
this instead.

This fixes static binaries using locales on FreeBSD/powerpc (tested
on FreeBSD/powerpcspe).

Reviewed By: nemanjai
Differential Revision: https://reviews.llvm.org/D76662

Requested by: jhibbits

MFC r359338:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-0-gd32170dbd5b (aka 10.0.0 release).

PR: 244251

MFC r359506 (by emaste):

lldb: stop excluding bindings/ subdir

With liblua in the tree we should be able to enable lldb's lua
scripting. We'll need the files in bindings/, so start by allowing them
to come in with the next import.

Approved by: dim
Sponsored by: The FreeBSD Foundation

MFC r359578:

Merge once more from ^/vendor/llvm-project/release-10.x, to get the
lldb/bindings directory, which will be used to provide lua bindings for
lldb.

Requested by: emaste

MFC r359826:

Merge commit 30588a739 from llvm git (by Erich Keane):

Make target features check work with ctor and dtor-

The problem was reported in PR45468, applying target features to an
always_inline constructor/destructor runs afoul of GlobalDecl
construction assert when checking for target-feature compatibility.

The core problem is fixed by using the version of the check that
takes a FunctionDecl rather than the GlobalDecl. However, while
writing the test, I discovered that source locations weren't properly
set for this check on ctors/dtors. This patch also fixes constructors
and CALLED destructors.

Unfortunately, it doesn't seem too possible to get a meaningful
source location for a 'cleanup' destructor, so those are still
'frontend' level errors unfortunately. A fixme was added to the test
to cover that situation.

This should fix 'Assertion failed: (!isa<CXXConstructorDecl>(D) && "Use
other ctor with ctor decls!"), function Init, file
/usr/src/contrib/llvm-project/clang/include/clang/AST/GlobalDecl.h, line
45' when compiling the security/botan2 port.

PR: 245550

MFC r359981:

Revert commit a9ad65a2b from llvm git (by Nemanja Ivanovic):

[PowerPC] Change default for unaligned FP access for older subtargets

This is a fix for https://bugs.llvm.org/show_bug.cgi?id=40554

Some CPU's trap to the kernel on unaligned floating point access and
there are kernels that do not handle the interrupt. The program then
fails with a SIGBUS according to the PR. This just switches the
default for unaligned access to only allow it on recent server CPUs
that are known to allow this.

Differential revision: https://reviews.llvm.org/D71954

This upstream commit causes a compiler hang when building certain ports
(e.g. security/nss, multimedia/x264) for powerpc64. The hang has been
reported in https://bugs.llvm.org/show_bug.cgi?id=45186, but in the mean
time it is more convenient to revert the commit.

Requested by: jhibbits

MFC r359994:

Revert commit b6cf400aa fro llvm git (by Nemanja Ivanovic):

Fix bots after a9ad65a2b34f

In the last commit, I neglected to initialize the new subtarget
feature I added which caused failures on a few bots. This should fix
that.

This unbreaks the build after r359981, which reverted upstream commit
a9ad65a2b34f.

Reported by: jhibbits (and jenkins :)

MFC r360129:

Merge commit ce5173c0e from llvm git (by Reid Kleckner):

Use FinishThunk to finish musttail thunks

FinishThunk, and the invariant of setting and then unsetting
CurCodeDecl, was added in 7f416cc42638 (2015). The invariant didn't
exist when I added this musttail codepath in ab2090d10765 (2014).
Recently in 28328c3771, I started using this codepath on non-Windows
platforms, and users reported problems during release testing
(PR44987).

The issue was already present for users of EH on i686-windows-msvc,
so I added a test for that case as well.

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D76444

This should fix 'Assertion failed: (!empty() && "popping exception stack
when not empty"), function popTerminate, file
/usr/src/contrib/llvm-project/clang/lib/CodeGen/CGCleanup.h, line 583'
when building the net-p2p/libtorrent-rasterbar

PR: 244830
Reported by: jbeich, yuri

MFC r360134:

Merge commit 64b31d96d from llvm git (by Nemanja Ivanovic):

[PowerPC] Do not attempt to reuse load for 64-bit FP_TO_UINT without
FPCVT

We call the function that attempts to reuse the conversion without
checking whether the target matches the constraints that the callee
expects. This patch adds the check prior to the call.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=43976

Differential revision: https://reviews.llvm.org/D77564

This should fix 'Assertion failed: ((Op.getOpcode() == ISD::FP_TO_SINT
|| Subtarget.hasFPCVT()) && "i64 FP_TO_UINT is supported only with
FPCVT"), function LowerFP_TO_INTForReuse, file
/usr/src/contrib/llvm/lib/Target/PowerPC/PPCISelLowering.cpp, line 7276'
when building the devel/libslang2 port (and a few others) for PowerPC64.

Requested by: pkubaj

MFC r360350:

Tentatively apply https://reviews.llvm.org/D78877 (by Dave Green):

[ARM] Only produce qadd8b under hasV6Ops

When compiling for a arm5te cpu from clang, the +dsp attribute is
set. This meant we could try and generate qadd8 instructions where we
would end up having no pattern. I've changed the condition here to be
hasV6Ops && hasDSP, which is what other parts of ARMISelLowering seem
to use for similar instructions.

Fixed PR45677.

This fixes "fatal error: error in backend: Cannot select: t37: i32 =
ARMISD::QADD8b t43, t44" when compiling sys/dev/sound/pcm/feeder_mixer.c
for armv5. For some reason we do not encounter this on head, but this
error popped up while building universes for stable/12.

MFC r360697:

In r358396 I merged llvm upstream commit 2e24219d3, which fixed "error:
unsupported relocation on symbol" when assembling arm 'adr' pseudo
instructions. However, the upstream commit did not take big-endian arm
into account.

Applying the same changes to the big-endian handling is straightforward,
thanks to Andrew Turner and Peter Smith for the hint. This will also be
submitted upstream.

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
9.0.1 final release c1a0a213378a458fbea1a5c77b315c7dce08fd05, and a
number of follow-ups.

MFC r355948:

Bootstrap mergeinfo for contrib/llvm-project

Merge (record-only) the following paths to contrib/llvm-project:
* ^/vendor/llvm-project/master
* ^/vendor/llvm-project/release-8.x
* ^/vendor/llvm-project/release-9.x

MFC r355951:

Merge empty dir updates from r355950 in vendor/llvm-project.

MFC r355957:

Merge diff elimination updates from r355953 into vendor/llvm-project.

MFC r355959:

Consolidate FREEBSD-Xlist files of different llvm sub-projects into one.

MFC r356004:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
9.0.1 final release c1a0a213378a458fbea1a5c77b315c7dce08fd05.

Release notes for llvm, clang, lld and libc++ 9.0.1 will become
available here:

https://releases.llvm.org/9.0.1/docs/ReleaseNotes.html
https://releases.llvm.org/9.0.1/tools/clang/docs/ReleaseNotes.html
https://releases.llvm.org/9.0.1/tools/lld/docs/ReleaseNotes.html
https://releases.llvm.org/9.0.1/projects/libcxx/docs/ReleaseNotes.html

PR: 240629

MFC r356005:

Merge commit f97936fab from llvm git (by Eric Fiselier):

[libc++] Cleanup and enable multiple warnings.

Too many warnings are being disabled too quickly. Warnings are
important to keeping libc++ correct. This patch re-enables two
warnings: -Wconstant-evaluated and -Wdeprecated-copy.

In future, all warnings disabled for the test suite should require an
attached bug. The bug should state the plan for re-enabling that
warning, or a strong case why it should remain disabled.

This should fix a number of new g++ 9 warnings.

Requested by: rlibby

MFC r356100:

Merge commit d3aeac8e2 from llvm git (by Justin Hibbits)

[PowerPC] Only use PLT annotations if using PIC relocation model

Summary:
The default static (non-PIC, non-PIE) model for 32-bit powerpc does
not use @PLT annotations and relocations in GCC. LLVM shouldn't use
@PLT annotations either, because it breaks secure-PLT linking with
(some versions of?) GNU LD.

Update the available-externally.ll test to reflect that default mode
should be the same as the static relocation, by using the same check
prefix.

Reviewed by: sfertile
Differential Revision: https://reviews.llvm.org/D70570

Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D22913

MFC r356104 (by jhibbits):

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.

On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.

This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.

Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim

Differential Revision: https://reviews.freebsd.org/D22549

MFC r356112 (by jhibbits):

[PowerPC64] Starting from FreeBSD 13.0, default to ELFv2 ABI

This changes the LLVM default powerpc64 ABI to ELFv2, if target OS is
FreeBSD >= 13.0

This will also be sent upstream.

Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: dim, luporl
Relnotes: YES
Differential Revision: https://reviews.freebsd.org/D20383

MFC r356256:

Merge commit 468a0cb5f from llvm git (by Craig Topper):

[X86] Add X87 FCMOV support to X86FlagsCopyLowering.

Fixes PR44396

Merge commit 86f48999f from llvm git (by Craig Topper):

[X86] Fix typo in getCMovOpcode.

The 64-bit HasMemoryOperand line was using CMOV32rm instead of
CMOV64rm. Not sure how to test this. We have no test coverage that
passes true for HasMemoryOperand.

This fixes 'Assertion failed: (MI.findRegisterDefOperand(X86::EFLAGS) &&
"Expected a def of EFLAGS for this instruction!"), function
runOnMachineFunction' when compiling the misc/gpsim port for i386.

Reported by: yuri
Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=44396

MFC r356329:

Merge commit 41449c58c from llvm git (by Roger Ferrer Ibanez):

[RISCV] Fix evaluation of %pcrel_lo

The following testcase

function:
.Lpcrel_label1:
auipc a0, %pcrel_hi(other_function)
addi a1, a0, %pcrel_lo(.Lpcrel_label1)
.p2align 2 # Causes a new fragment to be emitted

.type other_function,@function
other_function:
ret

exposes an odd behaviour in which only the %pcrel_hi relocation is
evaluated but not the %pcrel_lo.

$ llvm-mc -triple riscv64 -filetype obj t.s | llvm-objdump -d -r -

<stdin>: file format ELF64-riscv

Disassembly of section .text:
0000000000000000 function:
0: 17 05 00 00 auipc a0, 0
4: 93 05 05 00 mv a1, a0
0000000000000004: R_RISCV_PCREL_LO12_I other_function+4

0000000000000008 other_function:
8: 67 80 00 00 ret

The reason seems to be that in RISCVAsmBackend::shouldForceRelocation
we only consider the fragment but in RISCVMCExpr::evaluatePCRelLo we
consider the section. This usually works but there are cases where
the section may still be the same but the fragment may be another
one. In that case we end forcing a %pcrel_lo relocation without any
%pcrel_hi.

This patch makes RISCVAsmBackend::shouldForceRelocation use the
section, if any, to determine if the relocation must be forced or
not.

Differential Revision: https://reviews.llvm.org/D60657

This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.

Requested by: jhb

MFC r356330:

Merge commit da7b129b1 from llvm git (by James Clarke):

[RISCV] Don't force Local Exec TLS for non-PIC

Summary:

Forcing Local Exec TLS requires the use of copy relocations. Copy
relocations need special handling in the runtime linker when being
used against TLS symbols, which is present in glibc, but not in
FreeBSD nor musl, and so cannot be relied upon. Moreover, copy
relocations are a hack that embed the size of an object in the ABI
when it otherwise wouldn't be, and break protected symbols (which are
expected to be DSO local), whilst also wasting space, thus they
should be avoided whenever possible. As discussed in D70398, RISC-V
should move away from forcing Local Exec, and instead use Initial
Exec like other targets, with possible linker relaxation to follow.
The RISC-V GCC maintainers also intend to adopt this
more-conventional behaviour (see
https://github.com/riscv/riscv-elf-psabi-doc/issues/122).

Reviewers: asb, MaskRay

Reviewed By: MaskRay

Subscribers: emaste, krytarowski, hiraditya, rbar, johnrusso,
simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng,
edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe,
PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng,
sameer.abuasal, apazos, llvm-commits, bsdjhb

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D70649

This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.

Requested by: jhb

MFC r356331:

?Merge commit c6b09bff5 from llvm git (by Lu?s Marques):

[RISCV] Fix wrong CFI directives

Summary: Removes CFI CFA directives that could incorrectly propagate
beyond the basic block they were inteded for. Specifically it removes
the epilogue CFI directives. See the branch_and_tail_call test for an
example of the issue. Should fix the stack unwinding issues caused by
the incorrect directives.

Reviewers: asb, lenary, shiva0217
Reviewed By: lenary
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69723

This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.

Requested by: jhb

MFC r356332:

?Merge commit d7be3eab5 from llvm git (by Lu?s Marques):

[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32)

Summary: Adds tablegen patterns to explicitly handle fcopysign where
the magnitude and sign arguments have different types, due to the
sign value casts being removed the by DAGCombiner. Support for RV32IF
follows in a separate commit. Adds tests for all relevant scenarios
except RV32IF.

Reviewers: lenary
Reviewed By: lenary
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70678

This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.

Requested by: jhb

MFC r356333:

?Merge commit 189b7393d from llvm git (by John Baldwin):

[lld][RISCV] Use an e_flags of 0 if there are only binary input files.

Summary:
If none of the input files are ELF object files (for example, when
generating an object file from a single binary input file via "-b
binary"), use a fallback value for the ELF header flags instead of
crashing with an assertion failure.

Reviewers: MaskRay, ruiu, espindola

Reviewed By: MaskRay, ruiu

Subscribers: kevans, grimar, emaste, arichardson, asb, rbar,
johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217,
zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o,
rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton,
pzheng, sameer.abuasal, apazos, luismarques, llvm-commits, jrtc27

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D71101

This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.

Requested by: jhb

MFC r356701:

Merge commit f46ba4f07 from llvm git (by Simon Atanasyan):

[mips] Use less registers to load address of TargetExternalSymbol

There is no pattern matched `add hi, (MipsLo texternalsym)`. As a
result, loading an address of 32-bit symbol requires two registers
and one more additional instruction:
```
addiu $1, $zero, %lo(foo)
lui $2, %hi(foo)
addu $25, $2, $1
```

This patch adds the missed pattern and enables generation more
effective set of instructions:
```
lui $1, %hi(foo)
addiu $25, $1, %lo(foo)
```

Differential Revision: https://reviews.llvm.org/D66771

llvm-svn: 370196

Merge commit 59bb3609f from llvm git (by Simon Atanasyan):

[mips] Fix 64-bit address loading in case of applying 32-bit mask to
the result

If result of 64-bit address loading combines with 32-bit mask, LLVM
tries to optimize the code and remove "redundant" loading of upper
32-bits of the address. It leads to incorrect code on MIPS64 targets.

MIPS backend creates the following chain of commands to load 64-bit
address in the `MipsTargetLowering::getAddrNonPICSym64` method:
```
(add (shl (add (shl (add %highest(sym), %higher(sym)),
16),
%hi(sym)),
16),
%lo(%sym))
```

If the mask presents, LLVM decides to optimize the chain of commands.
It really does not make sense to load upper 32-bits because the
0x0fffffff mask anyway clears them. After removing redundant commands
we get this chain:
```
(add (shl (%hi(sym), 16), %lo(%sym))
```

There is no patterns matched `(MipsHi (i64 symbol))`. Due a bug in
`SYM_32` predicate definition, backend incorrectly selects a pattern
for a 32-bit symbols and uses the `lui` instruction for loading
`%hi(sym)`.

As a result we get incorrect set of instructions with unnecessary
16-bit left shifting:
```
lui at,0x0
R_MIPS_HI16 foo
dsll at,at,0x10
daddiu at,at,0
R_MIPS_LO16 foo
```

This patch resolves two problems:
- Fix `SYM_32/SYM_64` predicates to prevent selection of patterns
dedicated to 32-bit symbols in case of using N64 ABI.
- Add missed patterns for 64-bit symbols for `%hi/%lo`.

Fix PR42736.

Differential Revision: https://reviews.llvm.org/D66228

llvm-svn: 370268

These two commits fix a miscompilation of the kernel for mips64, and
should allow clang to be used as the default compiler for mips64.

Requested by: arichards

MFC r356789 (by arichardson):

Merge commit 894f742acb from llvm git (by me):

[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible

When compiling position-independent executables, we now use
DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a
64-bit PC-relative ELF relocation so we cannot use sdata8 for the large
code model case. When using the large code model, we fall back to the
previous behaviour of generating absolute relocations.

With this change clang-generated .o files can be linked by LLD without
having to pass -Wl,-z,notext (which creates text relocations).
This is simpler than the approach used by ld.bfd, which rewrites the
.eh_frame section to convert absolute relocations into relative references.

I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations
for MIPS ouput at some point. However, I also checked that recent ld.bfd
can process the clang-generated .o files so this no longer seems true.

Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D72228

Merge commit 8e8ccf47 from llvm git (by me)

[MIPS] Don't emit R_(MICRO)MIPS_JALR relocations against data symbols

The R_(MICRO)MIPS_JALR optimization only works when used against functions.
Using the relocation against a data symbol (e.g. function pointer) will
cause some linkers that don't ignore the hint in this case (e.g. LLD prior
to commit 5bab291) to generate a relative branch to the data symbol
which crashes at run time. Before this patch, LLVM was erroneously emitting
these relocations against local-dynamic TLS function pointers and global
function pointers with internal visibility.

Reviewers: atanasyan, jrtc27, vstefanovic
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D72571

These two changes should allow using lld for MIPS64 (and maybe also MIPS32)
by default.
The second commit is not strictly necessary for clang+lld since LLD9 will
not perform the R_MIPS_JALR optimization (it was only added for 10) but it
is probably required in order to use recent ld.bfd.

Reviewed By: dim, emaste
Differential Revision: https://reviews.freebsd.org/D23203

MFC r356929:

Merge commit bc4bc5aa0 from llvm git (by Justin Hibbits):

Add 8548 CPU definition and attributes

8548 CPU is GCC's name for the e500v2, so accept this in clang. The
e500v2 doesn't support lwsync, so define __NO_LWSYNC__ for this as
well, as GCC does.

Differential Revision: https://reviews.llvm.org/D67787

Merge commit ff0311c4b from llvm git (by Justin Hibbits):

[PowerPC]: Add powerpcspe target triple subarch component

Summary:
This allows the use of '-target powerpcspe-unknown-linux-gnu' or
'powerpcspe-unknown-freebsd' to be used, instead of '-target
powerpc-unknown-linux-gnu -mspe'.

Reviewed By: dim
Differential Revision: https://reviews.llvm.org/D72014

Merge commit ba91dffaf from llvm git (by Fangrui Song):

[Driver][PowerPC] Move powerpcspe logic from cc1 to Driver

Follow-up of D72014. It is more appropriate to use a target feature
instead of a SubTypeArch to express the difference.

Reviewed By: #powerpc, jhibbits

Differential Revision: https://reviews.llvm.org/D72433

commit 36eedfcb3 from llvm git (by Justin Hibbits):

[PowerPC] Fix powerpcspe subtarget enablement in llvm backend

Summary:

As currently written, -target powerpcspe will enable SPE regardless
of disabling the feature later on in the command line. Instead,
change this to just set a default CPU to 'e500' instead of a generic
CPU.

As part of this, add FeatureSPE to the e500 definition.

Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D72673

These are needed to unbreak the build for powerpcspe.

Requested by: jhibbits

MFC r358711:

Merge commit f75939599 from llvm git (by Erich Keane):

Reland r374450 with Richard Smith's comments and test fixed.

The behavior from the original patch has changed, since we're no
longer allowing LLVM to just ignore the alignment. Instead, we're
just assuming the maximum possible alignment.

Differential Revision: https://reviews.llvm.org/D68824

llvm-svn: 374562

This fixes 'Assertion failed: (Alignment != 0 && "Invalid Alignment"),
function CreateAlignmentAssumption', when building recent versions of
v8, which invoke __builtin_assume_aligned() with its alignment argument
set to 4GiB or more.

Clang will now report a warning, and show the maximum possible alignment
instead, e.g.:

huge-align.cpp:1:27: warning: requested alignment must be 536870912 bytes or smaller; maximum alignment assumed [-Wbuiltin-assume-aligned-alignment]
void *f(void *g) { return __builtin_assume_aligned(g, 4294967296); }
^ ~~~~~~~~~~

Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=43839
Reported by: cem

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
9.0.0 final release r372316.

(NOTE: This does not yet consolidate all the llvm project sources under
contrib/llvm-project (e.g., MFC r355940), due to Subversion limitations.
It will be done in a follow-up MFC.)

MFC r348610 (by emaste):

build llvm-ar and llvm-nm with Clang (promote out of CLANG_EXTRAS)

To facilitate experimentation with LTO we require an ar that supports
LLVM IR, and to a lesser degree also an nm. As a first step always
install llvm-ar and llvm-nm.

Sponsored by: The FreeBSD Foundation

MFC r350453 (by asomers):

Add a CXXWARNFLAGS variable

Some warning flags are valid for C++ but not C. GCC 8 complains if you pass
such flags when building a C file. Using a separate variable for these
flags allows building both C and C++ files in the same directory (such as
the fusefs tests) under GCC.

Reviewed by: cem, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D21116

MFC r350467 (by luporl):

[PPC64] Backport fix for missing IRELATIVE relocations

This is a backport of LLVM commit 8331f61a51a7a0a1efbf5ed398e181593023d151,
llvm-svn: 353981:

ELF: Allow GOT relocs pointing to non-preemptable ifunc to resolve to an
IRELATIVE where possible.

This is needed in order to make ifuncs work correctly on PPC64.

It fixes an issue with lld, in which it would skip emitting necessary IRELATIVE
relocations. Without this change, indirect calls to ifuncs would result in a
segmentation fault, in static binaries or when defined in the main binary
(outside shared libraries).

This change also reverts the local
"Preserve relocations against ifuncs when -zifunc-noplt" commit and
replaces it by its upstream version, as part of the merge.

Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D21102

MFC r351662 (by emaste):

lldb: shorten thread names to make logs easier to follow

lldb prepends the thread name to log entries, and the existing thread
name for the FreeBSD ProcessMonitor thread was longer than the kernel's
supported thread name length, and so was truncated. This made logs hard
to read, as the truncated thread name ran into the log message. Shorten
"lldb.process.freebsd.operation" to just "freebsd.op" so that logs are
more readable.

(Upstreaming to lldb still to be done).

MFC r352095 (by emaste):

compiler-rt: use more __sanitizer_time_t on FreeBSD

A few structs were using long for time_t members.

Obtained from: LLVM r370755

MFC r352096 (by emaste):

compiler-rt: use 64-bit time_t for all FreeBSD archs except i386

Obtained from: LLVM r370756

MFC r352167 (by imp):

Remove dir empty since r276851

MFC r352168 (by imp):

Remove dirs empty since r280031

MFC r352169 (by imp):

Remove dir empty since r314564

MFC r352170 (by imp):

Remove dir empty since r327952

MFC r352171 (by imp):

Remove dirs (and their now-empty parents) empty since r344779

MFC r352792 (by emaste):

compiler-rt: correct RISC-V struct_kernel_stat64_sz

The value of struct_kernel_stat64_sz introduced by review D5021 for
RISC-V was incorrect.

Also add a __riscv_xlen == 64 conditional as the 32-bit ABI is not yet
finalized.

Submitted by: Luís Marques
Differential Revision: https://reviews.freebsd.org/D21684

MFC r353018 (by kevans):

clang: use -mxgot for 32-bit mips

Various bits in usr.bin/clang/* will fail to compile without -mxgot due to
truncated relocations. -mxgot entails a speed penalty, but I suspect we
don't care as much about compiler performance in 32-bit mips land.

Reviewed by: arichardson
Differential Revision: https://reviews.freebsd.org/D21698

MFC r353358:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
9.0.0 final release r372316.

Release notes for llvm, clang, lld and libc++ 9.0.0 are available here:

https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html
https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html
https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html
https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html

PR: 240629

MFC r353363:

Put in a band-aid fix for lldb 9 exiting with "Expected<T> must be
checked before access or destruction" when launching executables, while
we sort this out with upstream.

Reported by: jbeich
PR: 241137

MFC r353415:

Revert r353363 in preparation for applying upstream fix:

Put in a band-aid fix for lldb 9 exiting with "Expected<T> must be
checked before access or destruction" when launching executables, while
we sort this out with upstream.

PR: 241137

MFC r353416:

Pull in r374444 from upstream lldb trunk (by me):

Fix process launch failure on FreeBSD after r365761

Summary:
After rLLDB365761, and with `LLVM_ENABLE_ABI_BREAKING_CHECKS`
enabled, launching any process on FreeBSD crashes lldb with:

```
Expected<T> must be checked before access or destruction.
Expected<T> value was in success state. (Note: Expected<T> values in
success mode must still be checked prior to being destroyed).
```

This is because `m_operation_thread` and `m_monitor_thread` were
wrapped in `llvm::Expected<>`, but this requires the objects to be
correctly initialized before accessing them.

To fix the crashes, use `llvm::Optional<>` for the members (as
indicated by labath), and use local variables to store the return
values of `LaunchThread` and `StartMonitoringChildProcess`. Then,
only assign to the member variables after checking if the return
values indicated success.

Reviewers: devnexen, emaste, MaskRay, mgorny

Reviewed By: devnexen

Subscribers: jfb, labath, krytarowski, lldb-commits

Differential Revision: https://reviews.llvm.org/D68723

PR: 241137

MFC r353579 (by jhb):

Use __FreeBSD_version to determine if gets() has been removed.

GCC compilers set __FreeBSD__ statically to a build-time determined
targeted version (which in ports always matches the build host's
version). This means that when building any version (12 or 13, etc.)
of riscv or some other architecture via GCC on a 12.x host,
__FreeBSD__ will always be set to 12. As a result, __FreeBSD__ cannot
be used to reliably detect the target FreeBSD version being built.
Instead, __FreeBSD_version from either <sys/param.h> (in the kernel)
or <osreldate.h> (in userland) should be used.

This changes the gets() test in libc++ to use __FreeBSD_version from
<osreldate.h>.

Reported by: jenkins (riscv64 and amd64-gcc)
Reviewed by: dim, imp
Differential Revision: https://reviews.freebsd.org/D22034

MFC r353711 (by mhorne):

Fix build of LLVM RISC-V backend

Reviewed by: dim
MFC with: r353358
Differential Revision: https://reviews.freebsd.org/D21963

MFC r353738:

Pull in r372651 from upstream lld trunk (by Simon Atanasyan):

[mips] Support elf32btsmipn32_fbsd / elf32ltsmipn32_fbsd emulations

Patch by Kyle Evans.

Requested by: kevans

MFC r353739:

Pull in r374154 from upstream clang trunk (by Simon Atanasyan):

[mips] Set default float ABI to "soft" on FreeBSD

Initial patch by Kyle Evans.

Fix PR43596

Requested by: kevans

MFC r353936:

Bump clang's default target CPU for the i386 architecture (aka "x86") to
i686, as per the discussion on the freebsd-arch mailing list. Earlier
in r352030, I had already bumped it to i586, to work around missing
atomic 64 bit functions for the i386 architecture.

Relnotes: yes

MFC r354097:

Pull in r372186 from upstream llvm trunk (by Eli Friedman):

[ARM] VFPv2 only supports 16 D registers.

r361845 changed the way we handle "D16" vs. "D32" targets; there used
to be a negative "d16" which removed instructions from the
instruction set, and now there's a "d32" feature which adds
instructions to the instruction set. This is good, but there was an
oversight in the implementation: the behavior of VFPv2 was changed.
In particular, the "vfp2" feature was changed to imply "d32". This is
wrong: VFPv2 only supports 16 D registers.

In practice, this means if you specify -mfpu=vfpv2, the compiler will
generate illegal instructions.

This patch gets rid of "vfp2d16" and "vfp2d16sp", and fixes "vfp2"
and "vfp2sp" so they don't imply "d32".

Differential Revision: https://reviews.llvm.org/D67375

Pull in r372187 from upstream clang trunk (by Eli Friedman):

[ARM] Update clang for removal of vfp2d16 and vfp2d16sp

Matching fix for https://reviews.llvm.org/D67375 (r372186).

Differential Revision: https://reviews.llvm.org/D67467

This should fix clang generating invalid opcodes for floating point
operations on armv6.

Requested by: mmel

MFC r354146:

Pull in r373338 from upstream llvm trunk (by Simon Pilgrim):

Revert rL349624 : Let TableGen write output only if it changed,
instead of doing so in cmake, attempt 2

Differential Revision: https://reviews.llvm.org/D55842
-----------------
As discussed on PR43385 this is causing Visual Studio msbuilds to
perpetually rebuild all tablegen generated files

Pull in r373664 from upstream llvm trunk (by Nico Weber):

Reland r349624: Let TableGen write output only if it changed, instead
of doing so in cmake

Move the write-if-changed logic behind a flag and don't pass it with
the MSVC generator. msbuild doesn't have a restat optimization, so
not doing write-if-change there doesn't have a cost, and it should
fix whatever causes PR43385.

This should fix the scenario where an incremental build from before
r353358 (the clang 9.0.0 upgrade) to r353358 or later fails to update
the timestamp of the generated lib/clang/headers/arm_fp16.h header.

After such a build, installing world from read-only source and object
directories would attempt to generate the header again, leading to
"clang-tblgen: error opening arm_fp16.h.d:Read-only file system".

Reported by: avg, np
PR: 241402

MFC r354339:

Merge commit 97e362607 from llvm git (by Nemanja Ivanovic):

[PowerPC] Do not emit HW loop if the body contains calls to
lrint/lround

These two intrinsics are lowered to calls so should prevent the
formation of CTR loops. In a subsequent patch, we will handle all
currently known intrinsics and prevent the formation of HW loops if
any unknown intrinsics are encountered.

Differential revision: https://reviews.llvm.org/D68841

This should fix an "invalid CRT loop" assertion when building the
www/node port for powerpc64.

Requested by: Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br>

MFC r354347 (by cem):

Fix llvm-libunwind userspace build on ARM

GCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, or
EHABI or whatever it's called. Export the same ones from LLVM-libunwind's
libgcc_s, on ARM. As part of this, convert libgcc_s from a direct
Version.map to one constructed from component Symbol.map files. This allows
the ARM-specific Symbol.map to be included only on ARM.

Fix ARM-only oddities in struct name/aliases in LLVM-libunwind to match
non-ARM definitions and ARM-specific expectations in libcxxrt /
libcompiler_rt.

No functional change intended for non-ARM architectures.

This commit does not actually flip the switch for ARM defaults from libgcc
to llvm-libunwind, but makes it possible (to compile, anyway).

MFC r354418 (by cem):

clang: Enable unwind tables on !amd64

There doesn't seem to be much sense in defaulting "on" unwind tables on
amd64 and not on other arches. It causes surprising differences between
platforms, such as the PR below.

Prior to this change, FreeBSD inherited the default implementation of the
method from the Gnu.h Generic_Elf => Generic_GCC parent class, which
returned true only for amd64 targets. Override that and opt on always,
similar to, e.g., NetBSD.

PR: 241562
Reported by: lwhsu
Reviewed by: dim
Discussed with: emaste
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D22252

MFC r354429:

Merge commit 8e34dd941 from llvm git (by Sanjay Patel):

[x86] avoid crashing when splitting AVX stores with non-simple type
(PR43916)

The store splitting transform was assuming a simple type (MVT), but
that's not necessarily the case as shown in the test.

This should fix 'Assertion failed: (isSimple() && "Expected a
SimpleValueType!")' when building the security/openssl111 port targeting
a CPU that supports AVX, but not AVX2, such as sandybridge.

PR: 241747

MFC r354469:

Merge commit f596f4507 from llvm git (by Sam Elliott):

[RISCV] Add Custom Parser for Atomic Memory Operands

Summary:
GCC Accepts both (reg) and 0(reg) for atomic instruction memory
operands. These instructions do not allow for an offset in their
encoding, so in the latter case, the 0 is silently dropped.

Due to how we have structured the RISCVAsmParser, the easiest way to
add support for parsing this offset is to add a custom AsmOperand and
parser. This parser drops all the parens, and just keeps the
register.

This commit also adds a custom printer for these operands, which
matches the GCC canonical printer, printing both `(a0)` and `0(a0)`
as `(a0)`.

Reviewers: asb, lewis-revill

Reviewed By: asb

Subscribers: s.egerton, hiraditya, rbar, johnrusso, simoncook,
apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay,
zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o,
rkruppe, jfb, PkmX, jocewei, psnobl, benna, Jim, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D65205

llvm-svn: 367553

Merge commit f596f4507 from llvm git (by Sam Elliott):

[RISCV] Add FreeBSD targets

Reviewers: asb

Reviewed By: asb

Subscribers: simoncook, s.egerton, lenary, psnobl, benna, mhorne,
emaste, kito-cheng, shiva0217, rogfer01, rkruppe, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D57795

Patch by James Clarke (jrtc27)

llvm-svn: 367557

Merge commit f596f4507 from llvm git (by Hsiangkai Wang):

[DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame.

It is necessary to generate fixups in .debug_frame or .eh_frame as
relaxation is enabled due to the address delta may be changed after
relaxation.

There is an opcode with 6-bits data in debug frame encoding. So, we
also need 6-bits fixup types.

Differential Revision: https://reviews.llvm.org/D58335

llvm-svn: 366524

Merge commit f596f4507 from llvm git (by Hsiangkai Wang):

[DebugInfo] Some fields do not need relocations even relax is enabled.

In debug frame information, some fields, e.g., Length in CIE/FDE and
Offset in FDE are attributes to describe the structure of CIE/FDE.
They are not related to the relaxed code. However, these attributes
are symbol differences. So, in current design, these attributes will
be filled as zero and LLVM generates relocations for them.

We only need to generate relocations for symbols in executable
sections. So, if the symbols are not located in executable sections,
we still evaluate their values under relaxation.

Differential Revision: https://reviews.llvm.org/D61584

llvm-svn: 366531

Merge commit f596f4507 from llvm git (by Alex Bradbury):

[RISCV] Don't force absolute FK_Data_X fixups to relocs

The current behavior of shouldForceRelocation forces relocations for
the majority of fixups when relaxation is enabled. This makes sense
for fixups which incorporate symbols but is unnecessary for simple
data fixups where the fixup target is already resolved to an absolute
value.

Differential Revision: https://reviews.llvm.org/D63404
Patch by Edward Jones.

llvm-svn: 369257

Merge commit f596f4507 from llvm git (by Alex Bradbury):

[RISCV] Implement getExprForFDESymbol to ensure RISCV_32_PCREL is
used for the FDE location

Follow binutils in using RISCV_32_PCREL for the FDE initial location.
As explained in the relevant binutils commit
<https://github.com/riscv/riscv-binutils-gdb/commit/a6cbf936e3dce68114d28cdf60d510a3f78a6d40>,
the ADD/SUB pair of relocations is problematic in the presence of
linker relaxation.

This patch has the same end goal as D64715 but includes test changes
and avoids adding a new global VariantKind to MCExpr.h (preferring
RISCVMCExpr VKs like the rest of the RISC-V backend).

Differential Revision: https://reviews.llvm.org/D66419

llvm-svn: 369375

This series of merges will permit riscv64 kernels and riscv64sf worlds
to build with clang instead of gcc (but still using the bfd linker).

Requested by: jhb
Obtained from: https://github.com/freebsd/freebsd/compare/master...bsdjhb:riscv_clang

MFC r354662 (by jhb):

Sync target triple generation with the version in Makefile.inc1.

Reviewed by: dim
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D22333

MFC r354692 (by emaste):

llvm: use AT_EXECPATH from ELF auxiliary vectors for getExecutablePath

/proc/curproc/file and the KERN_PROC_PATHNAME sysctl may not return the
desired path if there are multiple hardlinks to the file.

PR: 241932
Tested by: ler
Sponsored by: The FreeBSD Foundation

MFC r354707 (by emaste):

llvm: use elf_aux_info to get executable's path, if available

Obtained from: LLVM a0a38b81ea
MFC with: r354692
Sponsored by: The FreeBSD Foundation

MFC r354979:

Merge commit 7bed381ea from llvm git (by Simon Atanasyan):

[mips] Implement Octeon+ `saa` and `saad` instructions

`saa` and `saad` are 32-bit and 64-bit store atomic add instructions.

memory[base] = memory[base] + rt

These instructions are available for "Octeon+" CPU. The patch adds
support for both instructions to MIPS assembler and diassembler and
introduces new CPU type - "octeon+".

Next patches will implement `.set arch=octeon+` directive and
`AFL_EXT_OCTEONP` ISA extension flag support.

Differential Revision: https://reviews.llvm.org/D69849

This is one of the upstream changes needed for adding support for the
OCTEON+ CPU type, so that we can test Clang builds using the most
commonly available FreeBSD/mips64 reference platform, the Edge Router
Lite.

Requested by: kevans

MFC r354980:

Merge commit 3718102d4 from llvm git (by Simon Atanasyan):

[mips] Support `octeon+` CPU in the `.set arch=` directive

Differential Revision: https://reviews.llvm.org/D69850

This is one of the upstream changes needed for adding support for the
OCTEON+ CPU type, so that we can test Clang builds using the most
commonly available FreeBSD/mips64 reference platform, the Edge Router
Lite.

Requested by: kevans

MFC r354981:

Merge commit bf996f761 from llvm git (by Simon Atanasyan):

[mips] Write `AFL_EXT_OCTEONP` flag to the `.MIPS.abiflags` section

Differential Revision: https://reviews.llvm.org/D69851

This is one of the upstream changes needed for adding support for the
OCTEON+ CPU type, so that we can test Clang builds using the most
commonly available FreeBSD/mips64 reference platform, the Edge Router
Lite.

Requested by: kevans

MFC r354982:

Merge commit 3552d3e0f from llvm git (by Simon Atanasyan):

[mips] Add `octeon+` to the list of CPUs accepted by the driver

This is one of the upstream changes needed for adding support for the
OCTEON+ CPU type, so that we can test Clang builds using the most
commonly available FreeBSD/mips64 reference platform, the Edge Router
Lite.

Requested by: kevans

MFC r354983:

Merge commit e578d0fd2 from llvm git (by Simon Atanasyan):

[mips] Fix `__mips_isa_rev` macros value for Octeon CPU

This is one of the upstream changes needed for adding support for the
OCTEON+ CPU type, so that we can test Clang builds using the most
commonly available FreeBSD/mips64 reference platform, the Edge Router
Lite.

Requested by: kevans

MFC r354984:

Merge commit 0d14656b9 from llvm git (by Simon Atanasyan):

[mips] Set __OCTEON__ macros

This is one of the upstream changes needed for adding support for the
OCTEON+ CPU type, so that we can test Clang builds using the most
commonly available FreeBSD/mips64 reference platform, the Edge Router
Lite.

Requested by: kevans

MFC r354985:

Merge commit a751f557d from llvm git (by Simon Atanasyan):

[mips] Set macros for Octeon+ CPU

This is one of the upstream changes needed for adding support for the
OCTEON+ CPU type, so that we can test Clang builds using the most
commonly available FreeBSD/mips64 reference platform, the Edge Router
Lite.

Requested by: kevans

MFC r355397:

Merge commit 241cbf201 from llvm git (by Nemanja Ivanovic):

[PowerPC] Fix crash in peephole optimization

When converting reg+reg shifts to reg+imm rotates, we neglect to
consider the CodeGenOnly versions of the 32-bit shift mnemonics. This
means we produce a rotate with missing operands which causes a crash.

Committing this fix without review since it is non-controversial that
the list of mnemonics to consider should include the 64-bit aliases
for the exact mnemonics.

Fixes PR44183.

This should fix "Assertion failed: (idx < size()), function operator[],
file /usr/src/contrib/llvm/include/llvm/ADT/SmallVector.h, line 153"
when building the graphics/mesa-dri port for the PowerPC64 ELFv2 ABI.

Reported by: Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br>

MFC r355602:

Add a few missed source files to libllvm, for the MK_LLVM_TARGET_BPF=yes
case. Otherwise, linking of clang and other llvm based executables
would complain about missing symbols.

Reported by: rstone

MFC r355645 (by cem):

arm: libgcc_s: Fix ABI breakage introduced in r354347

Provide the symbol version for llvm-libunwind's _Unwind_Backtrace that libgcc
has historically provided on arm, in addition to the (default) standard version
used on all other arch.

Reported by: mmel

MFC r355803 (by mmel):

Fix LLVM libunwnwind _Unwind_Backtrace symbol version for ARM.
In original GNU libgcc, _Unwind_Backtrace is published with GCC_3.3 version
for all architectures but ARM. For ARM should be publishes with GCC_4.3.0
version. This was originally omitted in r255095, fixed in r318024 and omitted
aging in LLVM libunwind implementation in r354347.

For ARM _Unwind_Backtrace should be published as default with GCC_4.3.0
version , (because this is right original version) and again as
normal(not-default) with GCC_3.3 version (to maintain ABI compatibility
compiled/linked with wrong pre r318024 libgcc)

PR: 233664

MFC r355423: UPDATING: Add [less] long-belated note about certs in base

While the interaction between this and the ETCSYMLINK option of
security/ca_root_nss isn't necessarily fatal, one should be aware and
attempt to understand the ramifications of mixing the two.

ports-secteam will be contacted to discuss the default option for branches
where certs are being included in base.

Update to indicate this is for stable/11, not current.

Direct commit because it's not relevant to any other branch.

Reported by: Jamie Landeg-Jones

MFC r352304, r352540

r352304:
No longer mlock() ntpd pages by default in memory thus allowing its
pages to page as necessary.

To restore historic BSD behaviour add the following to ntp.conf:
rlimit memlock 32

Discussed on: freebsd-current@ between Sept 6-9, 2019
Reported by: Users using ASLR with stack gap != 0
Reviewed by: ian, kib, rgrimes (all previous versions)
Differential Revision: https://reviews.freebsd.org/D21581

r352540:
Follow up on r352304 which disabled default mlockall() at startup.
Unfortunately though the original tarball supports this in ./configure
(for Linux), to fully support disabling of mlockall() by default requires
a little extra help otherwise the following is logged in syslog:

Cannot set RLIMIT_MEMLOCK: Operation not permitted

MFC r348504 (by kevans):

llvm-symbolizer: Move out of CLANG_EXTRAS, into CLANG

ASAN reports become a lot more useful with llvm-symbolizer in $PATH, and the
build is not much more time-consuming. The added benefit is that the
resulting reports will actually include symbol information; without, thread
trace information includes a bunch of addresses that immediately resolve to
an inline function in
^/contrib/compiler-rt/lib/sanitizer_common/sanitizer_common.h and take a
little more effort to examine.

Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D20484

MFC r348689 (by emaste):

Use CLANG knob to remove llvm-symbolizer man page

r348504 moved llvm-symbolizer from the CLANG_EXTRAS knob to CLANG, but
the man page was still in the CLANG_EXTRAS section in
OptionalObsoleteFiles.inc.

Reported by: jhb

MFC r349004:

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++,
libunwind and openmp to the upstream release_80 branch r363030
(effectively, 8.0.1 rc2). The 8.0.1 release should follow this within a
week or so.

MFC r349351 (by jhibbits, partially):

powerpc: Transition to Secure-PLT, like most other OSs (Toolchain part)

Summary:
Toolchain follow-up to r349350. LLVM patches will be submitted upstream for
9.0 as well.

The bsd.cpu.mk change is required because GNU ld assumes BSS-PLT if it
cannot determine for certain that it needs Secure-PLT, and some binaries do
not compile in such a way to make it know to use Secure-PLT.

Reviewed By: nwhitehorn, bdragon, pfg
Differential Revision: https://reviews.freebsd.org/D20598

MFC r349793:

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++,
libunwind and openmp to the upstream release_80 branch r364487
(effectively, 8.0.1 rc3). The 8.0.1 release will most likely
have no further changes.

MFC r350177:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
8.0.1 final release r366581. The only functional change is a fix for a
mismerge of upstream r360816, which properly restores the r2 register
when unwinding on PowerPC64 (See https://reviews.freebsd.org/D20337).

Relnotes: yes
PR: 236062

MFC r349876:

Apply a workaround to be able to build clang 8.0.0 headers with clang
3.4.1, which is still in the stable/10 branch.

It looks like clang 3.4.1 implements static_asserts by instantiating a
temporary static object, and if those are in an anonymous union, it
results in "error: anonymous union can only contain non-static data
members".

To work around this implementation limitation, move the static_asserts
in question out of the anonymous unions.

This should make building the latest stable/11 from stable/10 possible
again.

Reported by: Mike Tancsa <mike@sentex.net>

Refine the advice for upgrading from 10.x

Simplify the advice to highlight the 3.5 minimum requirement (and note
that RELENG_10 has 3.4.1). The other issues I highlighted were just
the tip of the iceberg and not as helpful as I thought.

Add note about upgrading from RELENG_10.

When upgrading from RELENG_10, you need to upgrade to r346291 first
(or older on RELENG_11, but we know r346291 works so recommend that)
before upgrading to the latest on RELENG_11. RELENG_10's
static_assert implementation is used during bootstrapping with the new
compiler, and turns out to be incompatible with the new compiler. It's
unclear if this can be fixed easily but in the mean time add a note
here.

MFC r335837 (by kp): carp: Set DSCP value CS7

Update carp to set DSCP value CS7(Network Traffic) in the flowlabel field of
packets by default. Currently carp only sets TOS_LOWDELAY in IPv4 which was
deprecated in 1998. This also implements sysctl that can revert carp back to
it's old behavior if desired.

This will allow implementation of QOS on modern network devices to make sure
carp packets aren't dropped during interface contention.

Submitted by: Nick Wolff <darkfiberiru AT gmail.com>
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D14536

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
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 <yhayakawa3720@gmail.com>
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
<https://reviews.llvm.org/rL337339>. 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:
<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

MFC r345442:
Add UPDATING note for geom_uzip(4)/xz, and bump geom_uzip(4) man page date.

MFC 343048:
Update the note about the need for COMPAT_FREEBSD<n> kernel options.

Rather than mentioning the requirement for 4.x binaries but not
explaining why (it was assuming an upgrade from 4.x to 5.0-current),
explain when compat options are needed (for running existing host
binaries) in a more general way while using a more modern example
(COMPAT_FREEBSD11 for 11.x binaries). While here, explicitly mention
that a GENERIC kernel should always work.

UPDATING: Restore the missing period with another direct commit

Reported by: rgrimes

Direct commit for some clarification/correction

The notice in UPDATING stated the wrong direction for the link.

Additionally, it's decidedly not a bad idea to throw in a comment mandating
that the ordering of LOADER_DEFAULT_INTERP bits remains the same in this
branch. This makes it even more obvious from diff review (against head) that
this difference is intentional and creates merge conflicts if someone tries
to apply the original commit manually. I suspect this won't be a problem
given the set of people that maintain loader bits in stable/11, but it does
offer a peace of mind.

Reported by: rgrimes

Direct commit for post-mortem UPDATING update regarding lualoader

Indicate that it's been merged (after some delay since lua came back to this
branch) and how one can test lua, both by swapping build knobs and creating
links in /boot.

MFC GELI Loader Improvements: r336252, r336254, r336256, r336354,
r336532-r336534, r336537, r336626, r337326, r337349, r341071, r341160,
r341420, r341473, r341651, r342793

Note that this MFC contains some seemingly unrelated zfsloader bits -- this
was needed in order to pull in some later fixes for GELI hand-off w/ ZFS
bits included.

r336252:
Extend loader(8) geli support to all architectures and all disk-like devices.

This moves the bulk of the geli support from lib386/biosdisk.c into a new
geli/gelidev.c which implements a devsw-type device whose dv_strategy()
function handles geli decryption. Support for all arches comes from moving
the taste-and-attach code to the devopen() function in libsa.

After opening any DEVT_DISK device, devopen() calls the new function
geli_probe_and_attach(), which will "attach" the geli code to the open_file
struct by creating a geli_devdesc instance to replace the disk_devdesc
instance in the open_file. That routes all IO for the device through the
geli code.

A new public geli_add_key() function is added, to allow arch/vendor-specific
code to add keys obtained from custom hardware or other sources.

With these changes, geli support will be compiled into all variations of
loader(8) on all arches because the default is WITH_LOADER_GELI.

r336254:
Use if rather than case for a simple boolean. gcc thinks blks is
undefined sometimes with the case, but enc is always 0 or 1, so
and if / else is better anyway.

r336256:
Fix glitched indentation (and rewrap as needed due to deeper indent).
No functional changes.

r336354:
zfsboot: fix build with WITHOUT_LOADER_GELI

r336532:
Collapse zfsloader functionality back down into loader.

We no longer really need a separate zfsloader. It was useful when we
were first supporting ZFS and had limited ability to properly boot off
of ZFS without the special boot loader. Now that the boot loader has
matured, go the way loader.efi pioneered and just build one
binary. Change the name of the loader to load in the secondary boot
blocks to be just /boot/loader. Provide a symbolic link from zfsloader
to loader so people who have not upgraded their boot blocks are not
affected. This has the happy benefit of making coexistence easier as
well (fewer binaries in the matrix).

r336533:
Eliminate zfsloader man page.

Remove all cross references to zfsloader.8 and /boot/zfsloader.
Move ZFS specific info into loader.8.

r336534:
NM and OBJCOPY are already defined for all builds. There's no need to
conditionally define them here.

r336537:
Mention zfsloader being folded into loader in UPDATING.

r336626:
Older zfs boot blocks don't support symlinks. install the link to
zfsloader as a hard link. While newer ones do, the whole point of the
link was to transition to the new world order smoothly. A hard link is
less flexible, but it works and will result in fewer bumps. Adjust
UPDATING entry to match.

r337326:
loader: biosdisk.c has leftover geli header.

A small cleanup, remove unneeded #include.

r337349:
zfsboot: Fix startup crash

On a FreeNAS mini XL, with geli encrypted drives the loader crashed in
geli_read().

When we iterate over the list of disks and allocate the zfsdsk structures we
don’t zero out the gdev pointer. In one case that resulted in geli_read()
(called on the bogus pointer) dividing by zero.

Use calloc() to ensure the zfsdsk structure is always zeroed, so the pointer is
initialised to NULL. As a side benefit it gets rid of one #ifdef
LOADER_GELI_SUPPORT.

r341071:
Restore the ability to override the disk unit/partition at the boot: prompt
in gptboot.

When arch-independent geli support was added, a new static 'gdsk' struct
was added, but there was still a static 'dsk' struct, and when you typed
in an alternate disk/partition, the string was parsed into that struct,
which was then never used for anything. Now the string gets parsed into
gdsk.dsk, the struct that's actually used.

r341160:
Add comments describing the bootargs handoff between loader(8) and gptboot
or zfsboot, when loader(8) is the BTX loader. No functional changes.

r341420:
Eliminate duplicated code and struct member definitions in the handoff
of args data between gptboot/zfsboot and loader(8).

Despite what seems like a lot of changes here, there are no actual
changes in behavior, or in the data layout in the structures involved.
This is just eliminating identical code pasted into multiple locations.

In detail, the changes are...

- Move struct zfs_boot_args definition from libsa/zfs/libzfs.h to
i386/common/bootargs.h because it is specific to x86 booting and the
handoff between zfsboot and loader, and has no relation to the zfs
library code in general.

- The geli_boot_args and zfs_boot_args structs both contain an identical
set of member variables containing geli information. Extract this out
to a new geli_boot_data struct, and embed it in the arg-passing structs.

- Provide new routines geli_import_boot_data() and geli_export_boot_data()
that can be shared between gptboot, zfsboot, and loader instead of
pasting identical code into several different .c files.

- Remove some checks for a NULL pointer that can never be true because the
pointer being tested was set using pointer math (kargs + 1) and that can
never result in NULL in this code.

r341473:
Fix args cross-threading between gptboot(8) and loader(8) with zfs support.

When loader(8) is built with zfs support enabled, it assumes that any extarg
data present is a zfs_boot_args struct, but if the first-stage loader was
gptboot(8) the extarg data is actually a geli_boot_args struct. Luckily,
zfsboot(8) and gptzfsboot(8) have always passed KARGS_FLAGS_ZFS along with
KARGS_FLAGS_EXTARG, so we can use KARGS_FLAGS_ZFS to decide whether the
extarg data is a zfs_boot_args struct.

To avoid similar problems in the future, gptboot(8) now passes a new
KARGS_FLAGS_GELI to indicate that extarg data is geli_boot_args. In
loader(8), if the neither KARGS_FLAGS_ZFS nor KARGS_FLAGS_GELI is set but
extarg data is present (which will be the case for gptboot compiled before
this change), we now check for the known size of the geli_boot_args struct
passed by the older versions of gptboot as a way of confirming what type of
extarg data is present.

In a semi-related tidying up, since loader's main() has already decided
what type of extarg data is present and set the global 'zargs' var
accordingly, don't repeat the check in extract_currdev, just check whether
zargs is NULL or not.

r341651:
Don't reference zfs-specific variables if LOADER_ZFS_SUPPORT is undefined
because the variables will be undefined too.

r342793:
MK_ZFS -> {MK_ZFS|MK_LOADER_ZFS}, this is so we can diable userland / kernel
ZFS but keep the boot-loaders when using ZoL port.

Relnotes: yes (GELI support extended)
Relnotes: yes (zfsloader has been collapsed into loader and may be
removed after boot blocks have been updated)

MFC lualoader: r326353, r328440, r328443, r329166-r329167, r329274, r329329,
r329349-r329352, r329355-r329359, r329366-r329369, r329386-r329387, r329393,
r329413-r329415, r329417, r329424-r329436, r329457, r329473-r329474,
r329496-r329501, r329503-r329504, r329543, r329547-r329551, r329576-r329578,
r329580, r329583, r329585-r329590, r329592-r329596, r329609-r329611,
r329614, r329619, r329621-r329622, r329624, r329626-r329627,
r329629-r329632, r329640-r329641, r329643-r329646, r329649-r329650, r329654,
r329656, r329662, r329669-r329671, r329673-r329674, r329680,
r329684-r329689, r329692-r329693, r329696-r329700, r329709, r329716,
r329731, r329733-r329734, r329747-r329748, r329756, r329779, r329782,
r329784, r329786, r329804, r329806, r329809, r329811, r329836,
r329850-r329852, r329854, r329856-r329858, r329861, r329895,
r329897-r329899, r329901-r329903, r329922-r329924, r329927-r329928,
r329944-r329949, r329986-r329987, r330008-r330010, r330012, r330020,
r330082-r330084, r330087-r330088, r330098-r330101, r330138-r330139,
r330261-r330263, r330267-r330269, r330281-r330284, r330287, r330339-r330342,
r330345-r330346, r330369-r330370, r330434-r330435, r330564, r330616-r330618,
r330620, r330625, r330690, r330701, r330703, r330825, r331211, r331257,
r331259, r331281-r331282, r331304, r331314, r331476-r331477,
r331563-r331564, r331854-r331857, r331859-r331860, r332106, r334723,
r334879, r334891, r334907, r334912, r334939, r334986, r335009, r335371,
r336759, r337711, r337807-r337810, r338054, r338063, r338065-r338067,
r338083, r338085-r338086, r338108, r338167-r338168, r338173, r338203,
r338255, r338259, r338309, r338394, r338438, r338886, r338893, r339173,
r339200, r339218, r339222, r339301, r339307, r339677-r339678, r339702,
r339805, r339831, r339849, r340040, r340152

Some notes for this MFC:
- This is still pre-forth/lua coexistance; that will come shortly-ish so
that forth/lua may be installed together (with forth remaining the default)

- module_blacklist support for lualoader has been MFC'd, but the drm modules
are not blacklisted in this stable branch.

r326353: Import lua 5.3.4 to contrib
r328440: Preserve the original luaconf.h in a convenient place. Clients will
r328443: Gross hack to omit printing hex floating point when the lua number
r329166: Add Lua as a scripting langauge to /boot/loader
r329167: Add the lua scripts from the lua-bootloader SoC
r329274: stand/lua: Exit sub-menus on backspace
r329329: stand/lua: Always boot on 'enter' keypress in menus
r329349: stand/lua: Reduce magic numbers
r329350: stand/lua: Don't descend into an empty kernels submenu
r329351: stand/lua: Set reasonable ACPI default based on presence
r329352: stand/lua: Consistently use semicolons for line endings
r329355: stand/lua: Move kernel selection into main menu
r329356: stand/lua: Allow menu items to not have explicit aliases
r329357: stand/lua: Remove explicit alias from "Back to main menu"
r329358: stand/lua: Say "loader prompt" instead of "lua interpreter"
r329359: stand/lua: Remove a magic number/string (not a trivial literal)
r329366: stand/lua: Set ACPI's default the proper way (setACPI)
r329367: stand/lua: Create a "carousel" menu entry type
r329368: stand/lua: Create/use some MENU_ constants where applicable
r329369: stand/lua: Remove sneaky kernel assignment
r329386: stand/lua: Correct usage and acceptance of BACKSPACE/DELETE keys
r329387: stand/lua: Chop off the decimal for numbers passed to setcursor
r329393: stand/lua: Use escaped dot instead of single character class
r329413: stand/lua: Allow MENU_RETURN items to have func, fix esc. to prompt
r329414: stand/lua: Don't try to divide by 0; do nothing
r329415: stand/lua: Don't reload kernel config if we only have one kernel
r329417: stand/lua: Make CAROUSEL_ENTRY func parameters consistent with name
r329424: stand/lua: Don't set autoboot_delay=NO in menu autoboot sequence
r329425: stand/lua: Enable menu autoboot; it seems to work
r329426: stand/lua: Correct interpretation of autoboot_delay
r329427: stand/lua: Color non-default kernels blue
r329428: stand/lua: Correct some trivial errors in config
r329429: stand/lua: Add debug method to dump modules
r329430: stand/lua: Address some nits
r329431: stand/lua: Correct test sense, this should have been 'not nil'
r329432: stand/lua: Try to load alternate kernels as directories first
r329433: stand/lua: Add optional GELI passphrase prompt
r329434: stand/lua: Check for nil (GELI prompt)
r329435: stand/lua: Style pass
r329436: stand/lua: Debugging string snuck in...
r329457: stand/lua: dumpModules => lsModules
r329473: liblua: Clean up io/loader C module registration
r329474: liblua: Emulate DIR, opendir, fdopendir, closedir
r329496: stand/lua: Fix verbiage and some typos
r329497: stand/lua: Fix module_path handling with multiple kernels
r329498: stand/lua: Remove some debugging bits that snuck in... gr...
r329499: interp_lua: Register io/loader with regular Lua module system
r329500: Lua loader: Add barebones "lfs" module
r329501: lua loader: Auto detect eligible list of kernels to boot
r329503: liblua: Fix missing '}' in lutil.c after r329499
r329504: stand/lua: More style nits, config.lua
r329543: Create style.lua(9)
r329547: stand/lua: Allow menu items to be conditionally (in)visible
r329548: stand/lua: Addres style.lua(9) concern
r329549: stand/lua: Clear the screen before prompting for passwords
r329550: stand/lua: Store the loaded kernel as config.kernel_loaded
r329551: stand/lua: reload previously loaded kernel at config-load/reload
r329576: stand/lua: Defer kernel/module loading until boot or menu escape
r329577: stand/lua: Rename bootserial for clarity
r329578: stand/lua: Menu style.lua(9) nits
r329580: stand/lua: Remove some unused local declarations
r329583: stand/lua: Store menu entries in an "entries" table
r329585: stand/lua: Add core.isSingleUserBoot
r329586: stand/lua: Call menu_entries if it's a function
r329587: stand/lua: Swap single-/multi- user boot entries as needed
r329588: stand/lua: Re-wrap menu.lua now that I've added indentation...
r329589: stand/lua: Track env changes that come in via loader.conf(5)
r329590: stand/lua: Restore environment upon config reload
r329592: stand/lua: Remove inaccurate comment after r329590
r329593: stand/lua: Change boot menu items' names when swapped
r329594: stand/lua: Round up some more style.lua(9) concerns
r329595: stand/lua: Re-order locals after copyright notice; require first
r329596: stand/lua: Add copyright notice in places
r329609: stand/lua: Cache swapped menu, and don't create locals for swapping
r329610: style.lua(9): Note that wrapping at 80-columns is not rigid
r329611: stand/lua: Wrap tuple assignment earlier for readability
r329614: stand/lua: Don't set ACPI off just because we can't detect it.
r329619: stand/lua: Extract menu handlers out into menu.handlers table
r329621: stand/lua: Add and use drawer.menu_name_handlers
r329622: stand/lua: Move drawer.menu_name_handlers further up
r329624: stand/lua: Reduce exposure of the drawer module
r329626: stand/lua: Refactor logos into drawer.logodefs table
r329627: stand/lua: Refactor brands into drawer.branddefs
r329629: stand/lua: Use 'graphic' instead of 'logo' for depicting graphics
r329630: stand/lua: Stick a copyright notice on drawer.lua
r329631: stand/lua: Insert helpful comment for drawer.branddefs
r329632: style.lua(9): Clarify local variable guideline
r329640: stand/lua: Consistently declare local functions at module scope
r329641: stand/lua: Consistently organize modules
r329643: Implement loader.command
r329644: lualoader: Add ability to intercept cli commands
r329645: lualoader: Move carousel storage out into config
r329646: lualoader: Eliminate global namespace pollution in loader.lua
r329649: Lua lfs.attributes: Provide a more consistent error return
r329650: liblua: Add loader.machine and loader.machine_arch properties
r329654: lualoader: Ignore ACPI bits on !i386
r329656: loader.lua: Expose errno table to lua
r329662: lualoader: Replace invalid construct with valid construct
r329669: lualoader: Prefer selected kernel to currently loaded
r329670: lualoader: Don't try so hard to load a kernel
r329671: lualoader: Prepare for interception of "boot" CLI cmd
r329673: lualoader: Intercept boot cli command
r329674: lualoader: Intercept the 'autoboot' cli command
r329680: lualoader: When restoring environment, only restore unchanged vars
r329684: lualoader: Drop terminating semicolons
r329685: lualoader: Drop excessive parenthesizing
r329686: style.lua(9): Drop notes about semicolons
r329687: lualoader: Drop explicit boolean tests; b or not b
r329688: lualoader: Don't return false for failure to open config on silent
r329689: lualoader: Output "Failed to parse" messages
r329692: lualoader: Bring in local.lua module if it exists
r329693: lualoader: Return only argstr if with_kernel not requested
r329696: lualoader: Add "menu.default", initialized to menu.welcome
r329697: lualoader: Drop name requirement for menu separators
r329698: lualoader: Directly reference submenu definition with submenu key
r329699: lualoader: Simplify menu definitions a little further
r329700: lualoader: Allow carousel 'items' to be a table as well
r329709: lualoader: Don't autodetect kernels if 'kernels' is explicitly set
r329716: lualoader: Use the key that interrupts autoboot as a menu choice
r329731: lualoader: Add boot environment support
r329733: lualoader: Make kernel autodetect. contingent on loader.conf(5) var
r329734: lualoader: Don't execute menu.autoboot() for every opened menu
r329747: lualoader: Replace 8-space indentation with a single tab
r329748: lualoader: Drop password length restrictions
r329756: lualoader: Remove nasty hack for not printing out ".0"
r329779: lualoader: Split cli bits out into a cli module
r329782: lualoader: Unbreak 'boot [kernel]' by including config
r329784: lualoader: Pull argument extraction for cli funcs to cli.arguments
r329786: lualoader: Attach cli command functions to cli module
r329804: lualoader: Eliminate some unused locals
r329806: lualoader: Consistently use double quotes
r329809: lualoader: Address some 'luacheck' concerns
r329811: lualoader: Clear up an empty conditional branch
r329836: lualoader: Attend to some 80-col issues, pointed out by luacheck
r329850: lualoader: Drop unused return values; we'll only use the first
r329851: Add SPDX tags to lua files
r329852: Add copyright notice to core.lua
r329854: lualoader: shallowCopyTable => deepCopyTable
r329856: lualoader: Use "local function x()" instead "local x = function()"
r329857: Centralize lua defines
r329858: When the LUA_FLOAT_TYPE != LUA_FLOAT_INT64, we can't ref. float
r329861: lualoader: Track effective line number, use it for drawing
r329895: liblua: Implement write support
r329897: lualoader: Add nextboot support
r329898: lualoader: Plug file handle not properly closed
r329899: lualoader: Correct test and name
r329901: lualoader: Add comment on trailing space, don't operate on nil
r329902: lualoader: Remove unused variable; we now use effective line number
r329903: lualoader: Explain nextboot stuff a little bit more
r329922: lualoader: Split config file I/O out into a separate function
r329923: lualoader: Strip config.parse of its I/O privileges
r329924: lualoader: throw out nextboot's usage of standard config processing
r329927: lualoader: Clean up naming conventions a little bit
r329928: lualoader: Remove inaccurate part of comment
r329944: lualoader: Don't explicitly index tables without reason
r329945: lualoader: menu: Terminate final values in tables with a comma
r329946: lualoader: Clean up menu handling a little bit
r329947: lualoader: Pull menu redrawing specifics out of menu.process
r329948: lualoader: Pull autoboot handling out into menu.run()
r329949: lualoader: Explain deviation from naming guidelines
r329986: lualoader: Invalidate the screen from menu perspective mnu exit
r329987: lualoader: Track the menu currently drawn, instead of validity
r330008: lualoader: A little more general menu cleanup
r330009: lualoader: More argument name expansion, part 2
r330010: lualoader: screen argument fixes
r330012: style.lua(9): Add some additional notes about naming and commas
r330020: lualoader: Re-work menu skipping bits
r330082: lualoader: Add a twiddle at password prompt
r330083: lualoader: Remove remnants of testing...
r330084: lualoader: Replace instances of \027 with KEYSTR_ESCAPE
r330087: lualoader: Convert instances of KEYSTR_ESCAPE .. "[" -> KEYSTR_CSI
r330088: lualoader: Correct test sense, comments, and add some more comments
r330098: lualoader: Re-do twiddle
r330099: lualoader: Further screen cleanup
r330100: lualoader: Remove debug function
r330101: lualoader: Add note that \027 is a decimal representation
r330138: lualoader: Dedup these "Return to main menu" entries
r330139: lualoader: config: Pull some messages out into constants
r330261: lualoader: Fix some lint-mentioned errors
r330262: lualoader: Use #str instead of tracking length with 'n'
r330263: lualoader: Use string literal \xNN instead of string.char()
r330267: Add core.lua(8), but do not add to distribution
r330268: Add menu.lua(8), but do not add to distribution
r330269: core.lua(8): Add missing note about core.KEYSTR_CSI
r330281: lualoader: Steamroll the box-drawing
r330282: lualoader: Register loader.printc as global printc
r330283: lualoader: Use global printc instead of loader.printc
r330284: liblua: Use putc instead of printf for printc
r330287: lualoader: Reset the cursor position after the menu is drawn
r330339: liblua: Add loader.interpret
r330340: lualoader: Execute menu_timeout_command at the end of menu autoboot
r330341: lualoader: Respect loader_menu_title, prepare for align
r330342: lualoader: Respect loader_menu_title_align
r330345: lualoader: Tweak positioning and fix an off-by-one
r330346: lualoader: Shift menu+brand even for logo=none with customized pos
r330369: lualoader: Return meaningful value in cli_execute
r330370: lualoader: logdef -> logodef typo
r330434: lualoader: Add note about importance of including cli module early
r330435: lualoader: Use FILESDIR instead of BINDIR
r330564: lualoader: Only loadelf before boot/autoboot if no kernel loaded
r330616: lualoader: Expose loader.parse and add cli_execute_unparsed
r330617: lualoader: Fix name, cli.execute_unparsed -> cli_execute_unparsed
r330618: lualoader: Use cli_execute_unparsed instead of loader.interpret
r330620: lualoader: Use cli_execute_unparsed for commands via loader.conf
r330625: lualoader: Return status in cli_execute_unparsed properly
r330690: stand: Fix copy-paste-o, unbreaks libi386 lualoader build
r330701: lualoader: Don't redraw the autoboot message every .05s
r330703: lualoader: Cache kernel list
r330825: lualoader: Sprinkle some verbose_loading salt
r331211: lualoader: Setup default color scheme if we're using colors
r331257: lualoader: Reset attributes and color scheme with color.highlight()
r331259: lualoader: Use less atomic options for resetting colors/attributes
r331281: lualoader: Add primitive hook module to untangle bogus reference
r331282: core.lua(8): Update to reflect recently added function
r331304: lualoader: Clear up some possible naming confusion
r331314: lualoader: Use printc when we expect ANSI escape sequences
r331476: lualoader: Make config env-related bits private API
r331477: lualoader: Privatize some more config.lua bits
r331563: lualoader: Implement try_include and use it for including local
r331564: lualoader: Actually re-raise error in try_include
r331854: lualoader: Do case-insensitive comparison of "yes"
r331855: lualoader: Don't assume that {module}_load is set
r331856: lualoader: revert whitespace change that snuck in
r331857: lualoader: Simplify some expressions
r331859: lualoader: Split logodefs out into logo-* files
r331860: lualoader: Don't try to lookup a nil logo
r332106: lualoader: Fix menu skipping with loader.conf(5) vars
r334723: lualoader: Add a loaded hook for others to execute upon config load
r334879: lualoader: Add hook.lua(8) to tree
r334891: lualoader: Add cli.lua(8) to the tree
r334907: lualoader: Process loader_conf_files properly
r334912: lualoader: Support variable substitution in env var settings
r334939: lualoader: Allow brand-*.lua for adding new brands
r334986: lualoader: More black-on-white fixes
r335009: lualoader: Match Forth module-loading behavior w.r.t flags
r335371: lualoader: Correct kernel_options handling
r336759: lualoader: "nextboot_file" should be spelled "nextboot_conf"
r337711: lualoader: Fix parsing of negative number loader.conf(5) variables
r337807: Prevent a wanring about checkdp being unused.
r337808: When the LUA floating point model is INT64, we don't need to do the
r337809: For our INT64 implementation, we can compare integers and numbers
r337810: MFV r337586: lua: Update to 5.3.5
r338054: Add config.lua(8) to the tree
r338063: lualoader: Stop exporting drawer.draw
r338065: lualoader: Hide most of the internal drawing functions
r338066: lualoader: Hide the rest of the private interfaces
r338067: lualoader: Add drawer-exported variables for default logodefs
r338083: Add drawer.lua(8)
r338085: Add color.lua(8), password.lua(8), and screen.lua(8)
r338086: lualoader: Install all manpages
r338108: Serial console menus for lua.
r338167: lualoader: Just compare expression directly
r338168: lualoader: Refactor config line expressions
r338173: lualoader: Fix loader.conf(5) EOL validation for 'exec' lines
r338203: Turn off LOADER_GELI and LOADER_LUA for sparc64, until functional
r338255: lualoader: Fix (add) Xen support
r338259: lualoader: Accept that people use unquoted values in loader.conf
r338309: lualoader: Fix override of module_path on loader prompt
r338394: lualoader: fix color usage
r338438: lualoader: Handle comma-separated kernels as well
r338886: Improve loader passwords:
r338893: Set the default loader for powerpc(32- and 64-bit) back to to forth
r339173: Set the default loader for powerpc64 back to to forth too.
r339200: lualoader: Don't draw loader menu with autoboot_delay=-1
r339218: lualoader: Create a module blacklist, add DRM modules to it
r339222: lualoader: Honor boot_* variables at lua init
r339301: Loader GELI support, like lua loader, seems to be broken on PowerPC
r339307: lualoader: Provide a 'menu' command to redraw the menu at prompt
r339677: lualoader: unload upon kernel change if a kernel was loaded
r339678: menu.lua: Abort autoboot sequence on failed command
r339702: lualoader: Improve module loading diagnostics
r339805: lualoader: Always return a proper dictionary for blacklist
r339831: Move LUA_ROOT to /boot/lua
r339849: lualoader: Fix try_include error handling
r340040: lualoader: Implement boot-conf
r340152: lualoader: Add chainload menu entry

Relnotes: yes ("lualoader has been merged to stable/11, off by
default, to facilitate testing")

Merge clang 7.0.1 and several follow-up changes

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:
<http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html>
<http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html>
<http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html>

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.

Add an UPDATING entry for r342562.

This is a direct commit.

MFC r335844:

core(5): overwrite the oldest core dump

The '%I' format in the kern.corefile sysctl limits the number of
core files that a process can generate to the number stored in the
debug.ncores sysctl. The '%I' format is replaced by the single digit
index. Previously, if all indexes were taken the kernel would overwrite
only a core file with the highest index in a filename.
Currently the system will create a new core file if there is a free
index or if all slots are taken it will overwrite the oldest one.

Reviewed by: kib(code), bcr (updating)
Differential Revision: https://reviews.freebsd.org/D15991
Differential Revision: https://reviews.freebsd.org/D16084

MFC r336570:
Enable OFED build (without extras) by default.
For stable/11, this is only done on amd64.

Relnotes: yes
Sponsored by: Mellanox Technologies

Retrospectively document SVN branch points for stable-11 and its releases.

This is a direct commit to stable/11 because the releases are taken
from this branch.

Approved by: jhb (mentor)
Differential Revision: https://reviews.freebsd.org/D16264

MFC r335799:

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

MFC r325107, r335665:
r325107 (eadler, partial):
Update the updating URL in UPDATING.

r335665:
Use the 'Updating from Source' Handbook section in UPDATING.

PR: 229345
Submitted by: Niels Bakker
Approved by: re (marius, insta-MFC)
Sponsored by: The FreeBSD Foundation

MFC r333247: Import tzdata 2018e

North Korea switches back to +09 on 2018-05-05.

This version more correctly models time stamps in time zones with
negative DST such as Europe/Dublin (from 1971 on), Europe/Prague
(1946/7), and Africa/Windhoek (1994/2017). This does not affect the
UT offsets, only time zone abbreviations and the tm_isdst flag.

Approved by: re (kib)

MFC r327559:

Disabled the use of flowid for lagg by default

Sponsored by: Multiplay

Merge clang, llvm, lld, lldb, compiler-rt and libc++ 6.0.0 release, and
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 <mateusz.belicki@intel.com>

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:
<http://releases.llvm.org/6.0.0/docs/ReleaseNotes.html>
<http://releases.llvm.org/6.0.0/tools/clang/docs/ReleaseNotes.html>
<http://releases.llvm.org/6.0.0/tools/lld/docs/ReleaseNotes.html>

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 <shawn.webb@hardenedbsd.org>

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 Loader Fixes 2017q4p6: r324649,r324650,r324651,r324652,r324653,r324654,
r324700,r324702,r324709,r324717,r324719,r324841,r324842,r324843,r324845,
r324850,r324876,r324877,r324878,r324879,r324880,r324881,r324883,r324980,
r324981,r324982,r324995,r325014,r325093,r325094,r325114,r325170,r325171,
r325172,r325173,r325174,r325175,r325176,r325248,r325286,r325310,r325332,
r325338,r325339,r325376,r325377,r325379,r325380,r325382,r325478,r325479,
r325480,r325482,r325483,r325484,r325485,r325556,r325641,r325681,r325685,
r325686,r325687,r325688,r325689,r325690,r325691,r325692,r325693,r325694,
r325743,r325744,r325748,r325775,r325779,r325780

r324649: Move common/Makefile.inc to sys/boot/loader.mk.

r324650: tweak style

r324651: create defs.mk for common definitions

r324652: Move all the ficl common code into ficl.mk

r324653: LOADER_foo_SUPPORTED

r324654: Explicitly inlcude SYSDIR in the include path

r324700: loader: initialize dv_cleanup in md.c to eliminate clang warning

r324702: We need to include disk.o in libuboot.a when we're building with
support for disk access.

r324709: Revert "Unify boot1 with loader" change r324646

r324717: libsa/ip.c: misplaced comment, ip_v is half char, not ip_p

r324719: libsa/ip: stop read loop on bad fragments

r324841: Use BOOTDIR more consistently in defs.mk rather than repeat
sys/boot.

r324842: Introduce BOOTOBJ: The top level object directory for the boot tree

r324843: Stopgap fix to the mistmatch between LOADER_GELI_SUPPORT and
LOADER_NO_GELI_SUPPORT.

r324845: Use BOOTOBJ and BOOTDIR to find geli includes and libraries.

r324850: Define LIBSA32 to LIBSA on i386 to fix build.

r324876: Move fdt and uboot defines into common uboot.mk.

r324877: End source directories with SRC rather than a hodgepodge of names

r324878: Make at91 boot loader compile again.

r324879: Prefer SRCTOP paths for bits we're grabbing from libc.

r324880: Use BOOTSRC here.

r324881: Use SYSDIR instead of ${.CURDIR}/../..<etc>/sys.

r324883: Use preferred defined paths, rather than relative paths in fdt.

r324980: Use BOOTDIR consistently.

r324981: Move BINDIR definition to defs.mk, and override where it isn't
/boot

r324982: Remove sys/boot/arm/at91 and ixp425

r324995: loader.efi: Make framebuffer commands available for arm64

r325014: Add a 'place holder' arm struct efi_fb until a real one comes

r325093: Define new EFI variables

r325094: Cleanup non-arch Makefiles

r325114: Use defs.mk defins in most MD code

r325170: Use defs.mk values for userboot

r325171: Use defs.mk name and prefer bsd.init.mk

r325172: Remove the -nostdlib stuff I added. Instead, fix LDFLAGS to be
honored correctly with the new Makefile.inc include order.

r325173: We don't need to build a special ficl for userboot.

r325174: Minor cleanup

r325175: For amd64, compile both zfs and zfs32 libraries.

r325176: Actually add zfs32/Makefile

r325248: loader ptblread() is broken with >512B sectors

r325286: efipart_strategy is using wrong offset with >512B sectors

r325310: zfs.c:vdev_read() needs to be careful about large sectors

r325332: loader: re-enable gzip support for x86

r325338: loader: fix BOOTSRC -> BOOTOBJ in a library path

r325339: This used to have bzip2 support too.

r325376: WIP: centralize machine links

r325377: mostly libsa

r325379: Revert "mostly libsa"

r325380: Revert "WIP: centralize machine links"

r325382: Cleanup stray libstand names to be libsa names.

r325478: Powerpc is a 32-bit boot loader.

r325479: Define LIBFICL32 to be libficl.a on i386 and libficl32.a on amd64.

r325480: Use DO32 for all the places that we need to flag we're building a
32-bit version of a library.

r325482: Move machine and other link creation to defs.mk

r325483: MACHINE can never be powerpc64, so cleanup code that thinks it can.

r325484: Prefer bsd.init.mk to src.opts.mk

r325485: Centralize all 32-bit builds on 64-bit platform stuff.

r325556: loader: set options before including bsd.init.mk

r325641: loader.efi: efi_devpath_is_prefix should return bool

r325681: boot1: avoid using NULL device path

r325685: libsa32 isn't needed for i386. It's already a 32-bit platform.

r325686: Simplify this if to a direct assignment.

r325687: Remove all the empty help files from the powerpc build.

r325688: FDT support doesn't make sense for ps3, remove it.

r325689: Remove LOADER_FDT_SUPPORT as a Makefile variable.

r325690: Remove LOADER_ZFS_SUPPORT as a Makefile variable

r325691: Remove useless PNP define here.

r325692: Replace LOADER_FIREWIRE_SUPPORT variable

r325693: Move LOADER_{NO,}_GELI_SUPPORT to MK_LOADER_GELI

r325694: Install the 4th files in sys/boot/forth instead of each loader

r325743: Make sure the proper loader.rc gets installed.

r325744: boot1: also check for NULL device

r325748: Use proper include file.

r325775: Add loader.conf to the list of files that are MD.

r325779: Add /boot/dts to the list of default modules.

r325780: Don't add /boot/dt*s* but /boot/dt*b*. Stupid think-o.

MFC Loader Fixes 2017q3: r320547,r320553,r321621,r321844,r321969,r321991,
r322037,r322038,r322039,r322040,r322056,r322074,r322542,r322592,r322593,
r322896,r322923,r323671,r322930,r322931,r322932,r322933,r322934,r322935,
r322936,r322937,r322938,r322939,r322941,r323062,r323063,r323064,r323065,
r323100,r323131,r323174,r323258,r323261,r323272,r323367,r323379,r323389,
r323407,r323428,r323436,r323494,r323496,r323497,r323541,r323554,r323589,
r323707,r323867,r323885,r323886,r323895,r323896,r323897,r323905,r323906,
r323907,r323908,r323909,r323952,r323991,r324099,r324558,r326445,r326609,
r326610

This batch includes a special kludge to fix powerpc loader build; <stdlib.h>
was included after <stand.h> there, causing problems with DEBUG_MALLOC bits.
Include <stdlib.h> a little bit earlier to fix the build with the intention
of removing this when eventually libsa silently replaces stdlib.h with
stand.h.

r320547: Link EFI/uboot loaders with -znotext

r320553: Integer underflow in efipart_realstrategy when I/O starts after end
of disk

r321621: Always set the receive mask in loader.efi.

r321844: Clean up style in print_state(..) and pager_printf(..)

r321969: Fix the return types for printf and putchar to match their libc

r321991: Revert r321969

r322037: Add stpcpy and stpncpy to libstand

r322038: Add definitions and utilities for EFI drivers

r322039: Move EFI ZFS functions to libefi

r322040: Add EFI utility functions to libefi

r322056: Move EFI fmtdev functionality to libefi

r322074: libefi/time.c cstyle cleanup

r322542: loader.efi: repace XXX with real comments in trap.c

r322592: Remove unused defines.

r322593: Define proposed GUID for FreeBSD boot loader variables.

r322896: Make spinconsole platform independent and hook it up into EFI
loader

r322923: Hide length of geli passphrase during boot.

r323671: Fix language used in the r322923.

r322930: Move efi_main into efi/loader

r322931: Cleanup efi_main return type

r322932: Use the loader.efi conventions for the various EFI tables.

r322933: No need for MK_ZFS around these: they are by their nature only
active when MK_ZFS is true.

r322934: _STAND is sometimes defined on the command line. Make the define
here match.

r322935: Fix warnings due to type mismatch.

r322936: Remove useless 'static' for an enum definition.

r322937: Forward declare struct dsk to avoid warnings when building libi386.

r322938: Link in libefi for boot1

r322939: Use efi_devpath_str for debug path info.

r322941: Eliminate redunant device path matching.

r323062: Make efichar.c routines available to libefi.

r323063: boot1.efi: print more info about where boot1.efi is loaded from

r323064: Exit rather than panic for most errors.

r323065: Save where we're booted from

r323100: libstand: nfs_readlink() should return proper return code

r323131: Revert r322941: Eliminate redundant device matching functions

r323174: Fix loader bug causing too many pages allocation when bootloader
is U-Boot

r323258: ucs2len

r323261: Fix armv6 build

r323272: Be consistent and do return (1);

r323367: Mark init_chroot and init_script variables as deprecated.

r323379: It's been pointed out that init_script at least is useful w/o

r323389: loader.efi: chain loader should provide proper device handle

r323407: boot1 generate-fat: generate all templates at once

r323428: r323389 breaks the kernel build when WITHOUT_ZFS is defined in
src.conf

r323436: boot1: remove BOOT1_MAXSIZE default value

r323494: loader should support large_dnode

r323496: libstand: tftp_open() can leak pkt on error

r323497: libefi: efipart_open should check the status from disk_open

r323541: libefi: efipart_realstrategy rsize pointer may be NULL

r323554: Increase EFI boot file size frok 128k to 384k

r323589: loader: biosmem.c cstyle cleanup

r323707: loader: biosmem allocate heap just below 4GB

r323867: libefi: devicename.c cleanups

r323885: libefi: efi_devpath_match() should return bool

r323886: libefi: efipart.c should use calloc()

r323895: libefi: efi_devpath_match local len should be unsigned

r323896: r323885 did miss efilib.h update

r323897: efilib.h: typo in structure member description

r323905: libefi: pdinfo_t pd_unit and pd_open should be unsigned

r323906: libefi: efipart_strategy() should return ENXIO when there is no
media

r323907: libefi: efipart.c cstyle fix for efipart_print_common()

r323908: libefi: efipart_hdinfo_add_filepath should check strtol result

r323909: libefi: define EISA PNP constants

r323952: After the r317886 support for TFTP and NFS can be enable
simultaneously.

r323991: libefi: efipart_floppy() will should not pass acpi pointer if the
HID test fails

r324099: Compile loader as Little-Endian on PPC64/POWER8

r324558: Define prototype for exit and ensure references

r326445: Fix random() and srandom() prototypes to match the standard.

r326609: Make putenv and getenv match the userland definition

r326610: Fix random() prototype to match the system.

PR: 219000 221001 222215
Relnotes: yes ("The length of the geli passphrase is hidden during boot")

Add info about SW_WATCHDOG change to be dynamic in the common case.

Do not build lint(1) by default on stable-11, add WITH_LINT to enable
building it.

lint(1) is required on the host build system to build lint(1) libraries, and
it is no longer available on FreeBSD 12. This prevents using a 12 or later
host to build an 11 or earlier system, which causes problems for building
jails and using poudriere. The problem could be fixed by treating lint as a
bootstrap tool when building on 12+, but that just adds complexity and build
time to build a broken tool that virtually nobody uses anymore.

This is a direct commit to 11-stable because lint no longer exists in later
branches.

PR: 223892
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D13799

MFC r324248:

hen building multiple kernels using KERNCONF, non-existent KERNCONF
files will produce an error and buildkernel will fail. Previously missing
KERNCONF files silently failed giving no indication as to why, only to
subsequently discover during installkernel that the desired kernel was
never built in the first place.

This is a rework of r302865.

This is the correct patch.

Reviewed by: ngie (previous version, r302865)
Differential Revision: https://reviews.freebsd.org/D7167

Belatedely fill in the dates for clang 5.0.0 update in UPDATING and
ObsoleteFiles.inc.

Noticed by: garga

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

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 <shawn.webb@hardenedbsd.org>

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:
<http://releases.llvm.org/5.0.0/docs/ReleaseNotes.html>
<http://releases.llvm.org/5.0.0/tools/clang/docs/ReleaseNotes.html>
<http://releases.llvm.org/5.0.0/tools/lld/docs/ReleaseNotes.html>

Relnotes: yes

MFC of 322298 noting MFC 322806 in UPDATING

MFC r314659,r314676:

r314659:

usr.sbin: normalize paths using SRCTOP-relative paths or :H when possible

This simplifies make logic/output

r314676:

Fix build after r314656

Some of the changes I introduced to use .ALLSRC were correct in spirit,
but incorrect in reality -- in particular, ../Makefile.inc hadn't been
pulled in via bsd.init.mk (via bsd.lib.mk, bsd.prog.mk), so the value
of .ALLSRC (evaluated immediately) was empty. .include bsd.init.mk
explicitly so we can be certain that the values used as dependencies in
the targets are defined when the target recipe has been evaluated.

Reminder: thou shalt separate out separate functional changes before
committing them.

(YUGE) Pointyhat to: ngie
In collaboration with: bdrewery

MFC r318863:
Replace stale handbook URL with the proper one.

MFC LLD changes and enable LLD as /usr/bin/ld on arm64 by default

MFC r316629: do not require binutils port when using lld as ld

r279908 added logic to Makefile.inc1 to automatically set
CROSS_BINUTILS_PREFIX for architectures not supported by the in-tree
binutils: arm64 when first introduced, and later riscv64 as well.

LLVM's LLD linker is now included in the base system, and is enabled by
default for arm64 and capable of linking world and kernel. Thus, avoid
automatically setting CROSS_BINUTILS_PREFIX and requiring the binutils
port if WITH_LLD_IS_LD is true.

--

MFC r317608: revert r313473 (Disable LLD_IS_LD option combinations that fail)

r316647 corrected the build of tblgen and libllvm as dependencies for
LLD so undo the temporary seat-belt.

We still want to extend the build infrastructure to automatically detect
the case where the host LLD can be used instead of building a bootstrap
LLD, and likely extend libllvmminimal to meet LLD's needs for cases
where the build includes LLD but not Clang.

--

MFC r316684: Make WITHOUT_TOOLCHAIN imply WITHOUT_LLD.

LLD is a toolchain component.

--

MFC r316647: Introduce LLD_BOOTSTRAP to control lld as bootstrap linker

Add WITH_LLD_BOOTSTRAP and WITHOUT_LLD_BOOTSTRAP knobs, similar to the
Clang bootstrap knobs.

Reviewed by: andrew
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D10793

MFC: r312939, r313250, r314811 (partial), r314887 (partial), r315760,
r315845, 315430, r317981, r315466

o Fix some overly long lines, whitespace and other bugs according to
style(9) as well as spelling etc. in mmc(4), mmcsd(4) and sdhci(4).

o In the mmc(4) bridges and sdhci(4) (bus) front-ends:
- Remove redundant assignments of the default bus_generic_print_child
device method,
- use DEVMETHOD_END,
- use NULL instead of 0 for pointers.

o Trim/adjust includes.

o Add and use a MMC_DECLARE_BRIDGE macro for declaring mmc(4) bridges
as kernel drivers and their dependency onto mmc(4).

o Add support for eMMC "partitions". Besides the user data area, i. e.
the default partition, eMMC v4.41 and later devices can additionally
provide up to:
1 enhanced user data area partition
2 boot partitions
1 RPMB (Replay Protected Memory Block) partition
4 general purpose partitions (optionally with a enhanced or extended
attribute)

Besides simply subdividing eMMC devices, some Intel NUCs having UEFI
code in the boot partitions etc., another use case for the partition
support is the activation of pseudo-SLC mode, which manufacturers of
eMMC chips typically associate with the enhanced user data area and/
or the enhanced attribute of general purpose partitions.

CAVEAT EMPTOR: Partitioning eMMC devices is a one-time operation.

o Now that properly issuing CMD6 is crucial (so data isn't written to
the wrong partition for example), make a step into the direction of
correctly handling the timeout for these commands in the MMC layer.
Also, do a SEND_STATUS when CMD6 is invoked with an R1B response as
recommended by relevant specifications.

o Add an IOCTL interface to mmcsd(4); this is sufficiently compatible
with Linux so that the GNU mmc-utils can be ported to and used with
FreeBSD (note that due to the remaining deficiencies outlined above
SANITIZE operations issued by/with `mmc` currently most likely will
fail). These latter have been added to ports as sysutils/mmc-utils.
Among others, the `mmc` tool of mmc-utils allows for partitioning
eMMC devices (tested working).

o For devices following the eMMC specification v4.41 or later, year 0
is 2013 rather than 1997; so correct this for assembling the device
ID string properly.

o Let mmcsd.ko depend on mmc.ko. Additionally, bump MMC_VERSION as at
least for some of the above a matching pair is required.

o In the ACPI front-end of sdhci(4) describe the Intel eMMC and SDXC
controllers as such in order to match the PCI one.
Additionally, in the entry for the 80860F14 SDXC controller remove
the eMMC-only SDHCI_QUIRK_INTEL_POWER_UP_RESET.

MFC r316810, r316814, r316816, r316991:

Keep state incorrectly assumes keep frags. This is counter to the
ipfilter man pages. This also currently restricts keep frags to only when
keep state is used, which is redundant because keep state currently
assumes keep frags. This commit fixes this.

To the user this change means that to maintain the current behaviour
one must add keep frags to any ipfilter keep state rule (as documented
in the man pages).

This patch also allows the flexability to specify and use keep frags
separate from keep state, as documented in an example in ipf.conf.5,
instead of the currently broken behaviour.

MFC suggested by: rgrimes
Relnotes: yes

MFC r316313, r316328:

Allow explicitly assigned IPv4 & IPv6 loopback addresses to be used in
jails.

Relnotes: Yes
Sponsored by: Multiplay

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

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 <dan.mcgregor usask.ca>

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:
<http://releases.llvm.org/4.0.0/docs/ReleaseNotes.html>
<http://releases.llvm.org/4.0.0/tools/clang/docs/ReleaseNotes.html>
<http://releases.llvm.org/4.0.0/tools/lld/docs/ReleaseNotes.html>

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

add UPDATING entry for r315842, MFC of re-worked .zfs code

Add a note about IPsec update to the UPDATING. This is direct commit.

MFC r309124:

Upgrade our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.9.0
release, and add lld 3.9.0. Also completely revamp the build system for
clang, llvm, lldb and their related tools.

Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
support to build; see UPDATING for more information.

Release notes for llvm, clang and lld are available here:
<http://llvm.org/releases/3.9.0/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.9.0/tools/clang/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.9.0/tools/lld/docs/ReleaseNotes.html>

Thanks to Ed Maste, Bryan Drewery, Andrew Turner, Antoine Brodin and Jan
Beich for their help.

Relnotes: yes

MFC r309147:

Pull in r282174 from upstream llvm trunk (by Krzysztof Parzyszek):

[PPC] Set SP after loading data from stack frame, if no red zone is
present

Follow-up to r280705: Make sure that the SP is only restored after
all data is loaded from the stack frame, if there is no red zone.

This completes the fix for
https://llvm.org/bugs/show_bug.cgi?id=26519.

Differential Revision: https://reviews.llvm.org/D24466

Reported by: Mark Millard
PR: 214433

MFC r309149:

Pull in r283060 from upstream llvm trunk (by Hal Finkel):

[PowerPC] Refactor soft-float support, and enable PPC64 soft float

This change enables soft-float for PowerPC64, and also makes
soft-float disable all vector instruction sets for both 32-bit and
64-bit modes. This latter part is necessary because the PPC backend
canonicalizes many Altivec vector types to floating-point types, and
so soft-float breaks scalarization support for many operations. Both
for embedded targets and for operating-system kernels desiring
soft-float support, it seems reasonable that disabling hardware
floating-point also disables vector instructions (embedded targets
without hardware floating point support are unlikely to have Altivec,
etc. and operating system kernels desiring not to use floating-point
registers to lower syscall cost are unlikely to want to use vector
registers either). If someone needs this to work, we'll need to
change the fact that we promote many Altivec operations to act on
v4f32. To make it possible to disable Altivec when soft-float is
enabled, hardware floating-point support needs to be expressed as a
positive feature, like the others, and not a negative feature,
because target features cannot have dependencies on the disabling of
some other feature. So +soft-float has now become -hard-float.

Fixes PR26970.

Pull in r283061 from upstream clang trunk (by Hal Finkel):

[PowerPC] Enable soft-float for PPC64, and +soft-float -> -hard-float

Enable soft-float support on PPC64, as the backend now supports it.
Also, the backend now uses -hard-float instead of +soft-float, so set
the target features accordingly.

Fixes PR26970.

Reported by: Mark Millard
PR: 214433

MFC r309212:

Add a few missed clang 3.9.0 files to OptionalObsoleteFiles.

MFC r309262:

Fix packaging for clang, lldb and lld 3.9.0

During the upgrade of clang/llvm etc to 3.9.0 in r309124, the PACKAGE
directive in the usr.bin/clang/*.mk files got dropped accidentally.

Restore it, with a few minor changes and additions:
* Correct license in clang.ucl to NCSA
* Add PACKAGE=clang for clang and most of the "ll" tools
* Put lldb in its own package
* Put lld in its own package

Reviewed by: gjb, jmallett
Differential Revision: https://reviews.freebsd.org/D8666

MFC r309656:

During the bootstrap phase, when building the minimal llvm library on
PowerPC, add lib/Support/Atomic.cpp. This is needed because upstream
llvm revision r271821 disabled the use of std::call_once, which causes
some fallback functions from Atomic.cpp to be used instead.

Reported by: Mark Millard
PR: 214902

MFC r309835:

Tentatively apply https://reviews.llvm.org/D18730 to work around gcc PR
70528 (bogus error: constructor required before non-static data member).
This should fix buildworld with the external gcc package.

Reported by: https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc/

MFC r310194:

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
3.9.1 release.

Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
support to build; see UPDATING for more information.

Release notes for llvm, clang and lld will be available here:
<http://releases.llvm.org/3.9.1/docs/ReleaseNotes.html>
<http://releases.llvm.org/3.9.1/tools/clang/docs/ReleaseNotes.html>
<http://releases.llvm.org/3.9.1/tools/lld/docs/ReleaseNotes.html>

Relnotes: yes

MFC r308104: add iic interface to ig4 driver, move isl and cyapa to iicbus

MFC r305855, r306297, r306300, r306312-r306313

When MAKEOBJDIRPREFIX points to a case-insensitive file system, the
build can break when different source files create the same object
files (case-insensitivity speaking). This is the case for object
files compiled with -fpic and shared libraries. The former uses
an extension of ".So", and the latter an extension ".so". Rename
shared object files from *.So to *.pico to match what NetBSD does.

Also:
o Compile _Exit.c as C99_Exit.c, as it conflicts with _exit.s
o Add entry to UPDATING
o Document .pico extension

MFC r303103:

Minor wording improvements to the note about pipe(2) removal.

Approved by: re (gjb)
Sponsored by: DARPA, AFRL

- Remove debugging from GENERIC* kernel configurations
- Enable MALLOC_PRODUCTION
- Default dumpdev=NO
- Remove UPDATING entry regarding debugging features

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation