src/lib/Makefile, branch releng/12.2

MFC r359045 (by brooks):

2020-04-25T18:23:23+00:00

Add an internal liblua and use it in flua.

The new liblua will be used in a forthcoming import of kyua.

Reviewed by:	kevans
Obtained from:	CheriBSD
Sponsored by:	DARPA
Differential Revision:	https://reviews.freebsd.org/D24090

MFC r356356, r356358, r356422: replace gcclibs' libssp

2020-01-16T03:38:06+00:00

r356356:
Provide libssp based on libc

For libssp.so, rebuild stack_protector.c with FORTIFY_SOURCE stubs that just
abort built into it.

For libssp_nonshared.a, steal stack_protector_compat.c from
^/lib/libc/secure and massage it to maintain that __stack_chk_fail_local
is a hidden symbol.

libssp is now built unconditionally regardless of {WITH,WITHOUT}_SSP in the
build environment, and the gcclibs version has been disconnected from the
build in favor of this one.

r356358:
libssp: fix FORTIFY_SOURCE stub declarations

The LSB 4.1 that I referenced omitted the varargs, and I failed to catch it.
The __vsnprintf_chk error was from just downright misreading the page. GCC6
caught all of these, but I had only tested GCC4.2.

r356422:
Update libssp paths in various Makefile.depend* files

I've been advised that the model that uses these are fairly resilient, but
we do know the proper path to use (or remove, in the case of ^/targets/...),
so go ahead and update them to reflect that.

MFC r355034:

2020-01-08T17:23:52+00:00

libclang_rt: enable on powerpc*

Summary:
Enable on powerpc64 and in lib/libclang_rt/Makefile change
MACHINE_CPUARCH to MACHINE_ARCH because on powerpc64
MACHINE_ARCH==MACHINE_CPUARCH so the 32-bit library overwrites 64-bit
library during installworld.

This patch doesn't enable any other libclang_rt libraries because they
need to be separately ported.

I have verified that games/julius (which fails on powerpc64 elfv2
without this change because of no libclang_rt profiling library) builds.

Test Plan: Ship it, test on powerpc and powerpcspe

Submitted by:	pkubaj
Reviewed by:	dim, jhibbits
Differential Revision: https://reviews.freebsd.org/D22425

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

2020-01-07T18:08:09+00:00

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 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 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 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 must be checked before access or destruction.
  Expected value was in success state. (Note: Expected 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  (in the kernel)
or  (in userland) should be used.

This changes the gets() test in libc++ to use __FreeBSD_version from
.

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 

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
  ,
  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 

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 r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346081,r346270,r346574,r346576:

2019-05-23T01:09:10+00:00

r345203:

Initial googlemock/googletest integration into the build/FreeBSD test suite

This initial integration takes googlemock/googletest release 1.8.1, integrates
the library, tests, and sample unit tests into the build.

googlemock/googletest's inclusion is optionally available via `MK_GOOGLETEST`.
`MK_GOOGLETEST` is dependent on `MK_TESTS` and is enabled by default when
built with a C++11 capable toolchain.

Google tests can be specified via the `GTESTS` variable, which, in comparison
with the other test drivers, is more simplified/streamlined, as Googletest only
supports C++ tests; not raw C or shell tests (C tests can be written in C++
using the standard embedding methods).

No dependent libraries are assumed for the tests. One must specify `gmock`,
`gmock_main`, `gtest`, or `gtest_main`, via `LIBADD` for the program.

More information about googlemock and googletest can be found on the
Googletest [project page](https://github.com/google/googletest), and the
[GoogleMock](https://github.com/google/googletest/blob/v1.8.x/googlemock/docs/Documentation.md)
and
[GoogleTest](https://github.com/google/googletest/tree/v1.8.x/googletest/docs)
docs.

These tests are originally integrated into the build as plain driver tests, but
will be natively integrated into Kyua in a later version.

Known issues/Errata:
* [WhenDynamicCastToTest.AmbiguousCast fails on FreeBSD](https://github.com/google/googletest/issues/2172)

r345205:

Integrate cddl/usr.sbin/zfds/tests into the FreeBSD test suite

This change integrates the unit tests for zfsd into the test suite using the
integration method described in r345203.

This change removes the `LOCALBASE` includes added for the port version of
googlemock/googletest, as well as unnecessary `LIBADD`/`DPADD` and `CXXFLAGS`
defines, which are included in the `GTEST_CXXFLAGS` variable, as part of
r345203.

r345353 (by asomers):

googletest: backport GTEST_SKIP to googletest 1.8.1

This commit backports revisions 00938b2b228f3b70d3d9e51f29a1505bdad43f1e and
59f90a338bce2376b540ee239cf4e269bf6d68ad from googletest's master branch to
our included version of googletest, which is based on 1.8.1. It adds the
GTEST_SKIP feature, which is very useful for a project like FreeBSD where
some tests depend on particular system configurations.

Obtained from: github.com/google/googletest

r345645:

Spam CXXFLAGS with `-I${DESTDIR}/usr/include/private`, instead of GTEST_CXXFLAGS

This makes it easier for googletest users to leverage googletest, instead of
forcing them to plug GTEST_CXXFLAGS into CXXFLAGS manually (resulting in
unnecessary duplication).

I will be following this up with a more proper fix in src.libnames.mk, as
src.libnames.mk should be automatically adding this directory to
CFLAGS/CXXFLAGS when private libraries are referenced. Not doing so can result
in mismatches between base-provided private library's and ports-provided
library's headers.

While here, tweak the comment to clarify what the intent is behind spamming
CXXFLAGS.

r345708:

Standardize `-std=c++* as `CXXSTD`

CXXSTD was added as the C++ analogue to CSTD.

CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`,
otherwise for older versions of g++.

This change standardizes the CXXSTD variable, originally added to
googletest.test.inc.mk as part of r345203.

As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.

Notes:

This value is not sanity checked in bsd.sys.mk, however, given the two
most used C++ compilers on FreeBSD (clang++ and g++) support both modes, it is
likely to work with both toolchains. This method will be refined in the future
to support more variants of C++, as not all versions of clang++ and g++ (for
instance) support C++14, C++17, etc.

Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD.
Example:

Before this commit:
```
CXXFLAGS+= -std=c++14
```

After this commit:
```
CXXSTD= c++14
```

Relnotes: yes
Tested with: make tinderbox

r345709:

Allow users to override CSTD/CXXSTD on a per-prog basis

The current logic for CSTD/CXXSTD requires homogenity as far as the
supported C/C++ standards, which is a sensible default. However, when
dealing with differing versions of C++, some code may compile with C++11, but
not C++17 (for instance). So in order to avoid having people convert over their
code to the new standard, give the users the ability to specify the standard on
a per-program basis.

This will allow a user to override the supporting standard for a set of
programs, mixing C++11 with C++14 (for instance).

Apprved by: emaste (mentor)

r345735:

Allow programs to set `NO_SHARED` on a per-PROG basis

This is particularly useful when installing programs for tests that need to be
linked statically, e.g., mini-me from capsicum-test, which is linked statically
to avoid the dynamic library lookup in the upstream project.

r345770:

Import proof-of-concept for handling `GTEST_SKIP()` in `Environment::SetUp`

Per the upstream pull-request [1]:

```
gtest prior to this change would completely ignore `GTEST_SKIP()` if
called in `Environment::SetUp()`, instead of bailing out early, unlike
`Test::SetUp()`, which would cause the tests themselves to be skipped.
The only way (prior to this change) to skip the tests would be to
trigger a fatal error via `GTEST_FAIL()`.

Desirable behavior, in this case, when dealing with
`Environment::SetUp()` is to check for prerequisites on a system
(example, kernel supports a particular featureset, e.g., capsicum), and
skip the tests. The alternatives prior to this change would be
undesirable:

- Failing sends the wrong message to the test user, as the result of the
tests is indeterminate, not failed.
- Having to add per-test class abstractions that override `SetUp()` to
test for the capsicum feature set, then skip all of the tests in their
respective SetUp fixtures, would be a lot of human and computational
work; checking for the feature would need to be done for all of the
tests, instead of once for all of the tests.

For those reasons, making `Environment::SetUp()` handle `GTEST_SKIP()`,
by not executing the testcases, is the most desirable solution.

In order to properly diagnose what happened when running the tests if
they are skipped, print out the diagnostics in an ad hoc manner.

Update the documentation to note this change and integrate a new test,
gtest_skip_in_environment_setup_test, into the test suite.

This change addresses #2189.

Signed-off-by: Enji Cooper
```

The goal with my merging in this change is to avoid requiring extensive
refactoring/retesting of test suites when ensuring prerequisites are met,
e.g., checking for a CAPABILITIES-enabled kernel before running capsicum-test
(see D19758 for more details).

The proof-of-concept is being imported before accepted by the upstream
project due to the fact that the upstream project is undergoing a potential
development freeze and the maintainers aren't responding to my PR.

1. https://github.com/google/googletest/pull/2203

r346081 (by trasz):

Make zfsd(8) build obey CFLAGS.

Obtained from: CheriBSD

r346270 (by trasz):

Drop -g from CFLAGS for zfsd(8). No idea why it was ever there.

r346574:

Rework CXXSTD setting via r345708

This change allows the user to once again override the C++ standard, restoring
high-level pre-r345708 behavior.

This also unbreaks building lib/ofed/libibnetdisc/Makefile with a non-C++11
capable compiler, e.g., g++ 4.2.1, as the library supported being built with
older C++ standards.

r346576:

Fix up CXXSTD support originally added in r345708

r345708 worked for the base system, but unfortunately, caused a lot of
disruption for third-party packages that relied on C++, since bsd.sys.mk is
used by applications outside the base system. The defaults picked didn't match
the compiler's defaults and broke some builds that didn't specify a standard,
as well as some that overrode the value by setting `-std=gnu++14` (for
example) manually.

This change takes a more relaxed approach to appending `-std=${CXXSTD}` to
CXXFLAGS, by only doing so when the value is specified, as opposed to
overriding the standard set by an end-user. This avoids the need for having
to bake NOP default into bsd.sys.mk for supported compiler-toolchain
versions.

In order to make this change possible, add CXXSTD to Makefile snippets which
relied on the default value (c++11) added in r345708.

Revert r348136

2019-05-23T00:59:05+00:00

I accidentally committed some unrelated local changes to
`.../tests/sys/opencrypto` along with this MFC set.

MFC r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346574,r346576:

2019-05-23T00:55:28+00:00

r345203:

Initial googlemock/googletest integration into the build/FreeBSD test suite

This initial integration takes googlemock/googletest release 1.8.1, integrates
the library, tests, and sample unit tests into the build.

googlemock/googletest's inclusion is optionally available via `MK_GOOGLETEST`.
`MK_GOOGLETEST` is dependent on `MK_TESTS` and is enabled by default when
built with a C++11 capable toolchain.

No dependent libraries are assumed for the tests. One must specify `gmock`,
`gmock_main`, `gtest`, or `gtest_main`, via `LIBADD` for the program.

These tests are originally integrated into the build as plain driver tests, but
will be natively integrated into Kyua in a later version.

Known issues/Errata:
* [WhenDynamicCastToTest.AmbiguousCast fails on FreeBSD](https://github.com/google/googletest/issues/2172)

r345205:

Integrate cddl/usr.sbin/zfds/tests into the FreeBSD test suite

This change integrates the unit tests for zfsd into the test suite using the
integration method described in r345203.

r345353 (by asomers):

googletest: backport GTEST_SKIP to googletest 1.8.1

Obtained from: github.com/google/googletest

r345645:

Spam CXXFLAGS with `-I${DESTDIR}/usr/include/private`, instead of GTEST_CXXFLAGS

This makes it easier for googletest users to leverage googletest, instead of
forcing them to plug GTEST_CXXFLAGS into CXXFLAGS manually (resulting in
unnecessary duplication).

While here, tweak the comment to clarify what the intent is behind spamming
CXXFLAGS.

r345708:

Standardize `-std=c++* as `CXXSTD`

CXXSTD was added as the C++ analogue to CSTD.

CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`,
otherwise for older versions of g++.

This change standardizes the CXXSTD variable, originally added to
googletest.test.inc.mk as part of r345203.

As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.

Notes:

Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD.
Example:

Before this commit:
```
CXXFLAGS+= -std=c++14
```

After this commit:
```
CXXSTD= c++14
```

Relnotes: yes
Tested with: make tinderbox

r345709:

Allow users to override CSTD/CXXSTD on a per-prog basis

This will allow a user to override the supporting standard for a set of
programs, mixing C++11 with C++14 (for instance).

Approved by: emaste (mentor)

r345735:

Allow programs to set `NO_SHARED` on a per-PROG basis

r345770:

Import proof-of-concept for handling `GTEST_SKIP()` in `Environment::SetUp`

Per the upstream pull-request [1]:

For those reasons, making `Environment::SetUp()` handle `GTEST_SKIP()`,
by not executing the testcases, is the most desirable solution.

In order to properly diagnose what happened when running the tests if
they are skipped, print out the diagnostics in an ad hoc manner.

Update the documentation to note this change and integrate a new test,
gtest_skip_in_environment_setup_test, into the test suite.

This change addresses #2189.

Signed-off-by: Enji Cooper
```

1. https://github.com/google/googletest/pull/2203

r346574:

Rework CXXSTD setting via r345708

This change allows the user to once again override the C++ standard, restoring
high-level pre-r345708 behavior.

This also unbreaks building lib/ofed/libibnetdisc/Makefile with a non-C++11
capable compiler, e.g., g++ 4.2.1, as the library supported being built with
older C++ standards.

r346576:

Fix up CXXSTD support originally added in r345708

In order to make this change possible, add CXXSTD to Makefile snippets which
relied on the default value (c++11) added in r345708.

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

2019-04-12T20:03:27+00:00

8.0.0 final release r356365.

MFC r340287 (by emaste):

Consolidate gcov entries in OptionalObsoleteFiles

Sponsored by: The FreeBSD Foundation

MFC r340972 (by emaste):

llvm-objdump: initial man page

Based on llvm-objdump's online documentation and usage information.
This serves as a starting point; additional detail and cleanup still
required.

Also being submitted upstream in LLVM review D54864. I expect to use
this bespoke copy while we have LLVM 6.0 or 7.0 in FreeBSD; when we
update to LLVM 8.0 it should be upstream and we will switch to it.

PR: 233437
Reviewed by: bcr (man formatting)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18309

MFC r340973 (by emaste):

llvm-objdump.1: remove invalid options

Some options appear in llvm-objdump's usage information as a side effect
of its option parsing implementation and are not actually llvm-objdump
options. Reported in LLVM review https://reviews.llvm.org/D54864.

Reported by: Fangrui Song
Sponsored by: The FreeBSD Foundation

MFC r340975 (by emaste):

llvm-objdump.1: fix igor / mandoc -Tlint warnings

Accidentally omitted from r340972.

MFC r341055 (by emaste):

llvm-objdump.1: remove more unintentional options

Some options come from static constructors in LLVM libraries and are
automatically added to llvm's usage output. They're not really supposed
to be llvm-objdump options.

Reported by: Fangrui Song in LLVM review D54864
Sponsored by: The FreeBSD Foundation

MFC r344779:

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The
release will follow very soon, but no more functional changes are
expected.

Release notes for llvm, clang and lld 8.0.0 will soon be available here:

PR: 236062
Relnotes: yes

MFC r344798 (by emaste):

libllvm: promote WithColor and xxhash to SRCS_MIN

The armv6 build failed in CI due to missing symbols (from these two
source files) in the bootstrap Clang.

This affected only armv6 because other Clang-using archs are using LLD
as the bootstrap linker, and thus include SRCS_MIW via LLD_BOOTSTRAP.

Reported by: CI, via lwhsu
Sponsored by: The FreeBSD Foundation

MFC r344825:

Add a few missed files to the MK_LLVM_TARGET_BPF=yes case, otherwise
clang and various other executables will fail to link with undefined
symbols.

Reported by: O. Hartmann

MFC r344852:

Put in a temporary workaround for what is likely a gcc 6 bug (it does
not occur with gcc 7 or later). This should prevent the following error
from breaking the head-amd64-gcc CI builds:

In file included from /workspace/src/contrib/llvm/tools/lldb/source/API/SBMemoryRegionInfo.cpp:14:0:
/workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: 'template lldb_private::MemoryRegionInfos::MemoryRegionInfos(_InputIterator, _InputIterator, const allocator_type&)' inherited from 'std::__1::vector'
using std::vector::vector;
^~~~~~
/workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: conflicts with version inherited from 'std::__1::vector'

Reported by: CI

MFC r344896:

Pull in r354937 from upstream clang trunk (by Jörg Sonnenberger):

Fix inline assembler constraint validation

The current constraint logic is both too lax and too strict. It fails
for input outside the [INT_MIN..INT_MAX] range, but it also
implicitly accepts 0 as value when it should not. Adjust logic to
handle both correctly.

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

Pull in r355491 from upstream clang trunk (by Hans Wennborg):

Inline asm constraints: allow ICE-like pointers for the "n"
constraint (PR40890)

Apparently GCC allows this, and there's code relying on it (see bug).

The idea is to allow expression that would have been allowed if they
were cast to int. So I based the code on how such a cast would be
done (the CK_PointerToIntegral case in
IntExprEvaluator::VisitCastExpr()).

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

These should fix assertions and errors when using the inline assembly
"n" constraint in certain ways.

In case of devel/valgrind, a pointer was used as the input for the
constraint, which lead to "Assertion failed: (isInt() && "Invalid
accessor"), function getInt".

In case of math/secp256k1, a very large integer value was used as input
for the constraint, which lead to "error: value '4624529908474429119'
out of range for constraint 'n'".

PR: 236216, 236194

MFC r344951:

Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branch
r355677 (effectively, 8.0.0 rc4), resolve conflicts, and bump version
numbers.

PR: 236062

MFC r345018:

Merge LLVM libunwind trunk r351319, from just before upstream's
release_80 branch point. Afterwards, we will merge the rest of the
changes in the actual release_80 branch.

PR: 236062

MFC r345019:

Merge LLVM libunwind release_80 branch r355677 (effectively, 8.0.0 rc4).

PR: 236062

MFC r345021:

Pull in r355854 from upstream llvm trunk (by Jonas Paulsson):

[RegAlloc] Avoid compile time regression with multiple copy hints.

As a fix for https://bugs.llvm.org/show_bug.cgi?id=40986 ("excessive
compile time building opencollada"), this patch makes sure that no
phys reg is hinted more than once from getRegAllocationHints().

This handles the case were many virtual registers are assigned to the
same physreg. The previous compile time fix (r343686) in
weightCalcHelper() only made sure that physical/virtual registers are
passed no more than once to addRegAllocationHint().

Review: Dimitry Andric, Quentin Colombet
https://reviews.llvm.org/D59201

This should fix a hang when compiling certain generated .cpp files in
the graphics/opencollada port.

PR: 236313

MFC r345068 (by jhb):

Move libunwind out of contrib/llvm/projects.

Move LLVM's libunwind to its own contrib/ directory similar to other
runtime libraries like libc++ and libcxxrt.

Reviewed by: dim, emaste
Differential Revision: https://reviews.freebsd.org/D19534

MFC r345073:

Revert r308867 (which was originally committed in the clang390-import
project branch):

Work around LLVM PR30879, which is about a bad interaction between
X86 Call Frame Optimization on i386 and libunwind, by disallowing the
optimization for i386-freebsd12.

This should fix some instances of broken exception handling when
frame pointers are omitted, in particular some unittests run during
the build of editors/libreoffice.

This hack will be removed as soon as upstream has implemented a more
permanent fix for this problem.

And indeed, after r345018 and r345019, which updated LLVM libunwind to
the most recent version, the above workaround is no longer needed. The
upstream commit which fixed this is:

https://llvm.org/viewvc/llvm-project?view=revision&revision=292723

Specifically, 32 bit (i386-freebsd) executables optimized with omitted
frame pointers and Call Frame Optimization should now behave correctly
when a C++ exception is thrown, and the stack is unwound.

Upstream PR: https://llvm.org/bugs/show_bug.cgi?id=30879
PR: 236062

MFC r345152:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, and lldb
release_80 branch r356034 (effectively, 8.0.0 rc5), resolve conflicts,
and bump version numbers.

PR: 236062

MFC r345231:

Add LLVM openmp trunk r351319 (just before the release_80 branch point)
to contrib/llvm. This is not yet connected to the build, the glue for
that will come in a follow-up commit.

PR: 236062

MFC r345232:

Bootstrap svn:mergeinfo on contrib/openmp.

PR: 236062

MFC r345233:

Merge openmp release_80 branch r356034 (effectively, 8.0.0 rc5).

PR: 236062

MFC r345234:

Add openmp __kmp_gettid() wrapper, using pthread_getthreadid_np(3).
This has also been submitted upstream.

PR: 236062

MFC r345283:

Enable building libomp.so for 32-bit x86. This is done by selectively
enabling the functions that save and restore MXCSR, since access to this
register requires SSE support.

Note that you may run into other issues with OpenMP on i386, since this
*not* yet supported upstream, and certainly not extensively tested.

PR: 236062, 236582

MFC r345345:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
8.0.0 final release r356365. There were no functional changes since the
most recent merge, of 8.0.0 rc5.

Release notes for llvm, clang, lld and libc++ 8.0.0 are now available:

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

PR: 236062

MFC r345349:

Pull in r352826 from upstream lld trunk (by Fangrui Song):

[ELF] Support --{,no-}allow-shlib-undefined

Summary:
In ld.bfd/gold, --no-allow-shlib-undefined is the default when
linking an executable. This patch implements a check to error on
undefined symbols in a shared object, if all of its DT_NEEDED entries
are seen.

Our approach resembles the one used in gold, achieves a good balance
to be useful but not too smart (ld.bfd traces all DSOs and emulates
the behavior of a dynamic linker to catch more cases).

The error is issued based on the symbol table, different from
undefined reference errors issued for relocations. It is most
effective when there are DSOs that were not linked with -z defs (e.g.
when static sanitizers runtime is used).

gold has a comment that some system libraries on GNU/Linux may have
spurious undefined references and thus system libraries should be
excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The
story may have changed now but we make --allow-shlib-undefined the
default for now. Its interaction with -shared can be discussed in the
future.

Reviewers: ruiu, grimar, pcc, espindola

Reviewed By: ruiu

Subscribers: joerg, emaste, arichardson, llvm-commits

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

Pull in r352943 from upstream lld trunk (by Fangrui Song):

[ELF] Default to --no-allow-shlib-undefined for executables

Summary:
This follows the ld.bfd/gold behavior.

The error check is useful as it captures a common type of ld.so
undefined symbol errors as link-time errors:

// a.cc => a.so (not linked with -z defs)
void f(); // f is undefined
void g() { f(); }

// b.cc => executable with a DT_NEEDED entry on a.so
void g();
int main() { g(); }

// ld.so errors when g() is executed (lazy binding) or when the program is started (-z now)
// symbol lookup error: ... undefined symbol: f

Reviewers: ruiu, grimar, pcc, espindola

Reviewed By: ruiu

Subscribers: llvm-commits, emaste, arichardson

Tags: #llvm

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

Together, these add support for --no-allow-shlib-undefined, and make it
the default for executables, so they will fail to link if any symbols
from needed shared libraries are undefined.

Reported by: jbeich
PR: 236062, 236141

MFC r345449:

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

[ARM] Don't form "ands" when it isn't scheduled correctly.

In r322972/r323136, the iteration here was changed to catch cases at
the beginning of a basic block... but we accidentally deleted an
important safety check. Restore that check to the way it was.

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

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

This should fix "Assertion failed: (LiveCPSR && "CPSR liveness tracking
is wrong!"), function UpdateCPSRUse" errors when building the devel/xwpe
port for armv7.

PR: 236062, 236568

Add support for loader veriexec

2019-04-12T01:03:00+00:00

Also sbin/veriexec for mac_veriexec

MFC r343281,344564-344568,344780,344784,345289,346070

Merge clang 7.0.1 and several follow-up changes

2019-02-16T15:43:49+00:00

MFC r341825:

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
the upstream release_70 branch r348686 (effectively, 7.0.1 rc3).  The
release will follow very soon, but no more functional changes are
expected.

Release notes for llvm, clang and lld 7.0.0 are available here:




PR:		230240, 230355
Relnotes:	yes

MFC r342123:

Update clang, llvm, lld, lldb, compiler-rt and libc++ version number to
7.0.1 release r349250.  There were no functional changes since the 7.0.1
rc3 import.

PR:		230240, 230355
Relnotes:	yes

r343429 | emaste | 2019-01-25 15:46:13 +0100 (Fri, 25 Jan 2019) | 16 lines

clang: default to DWARF 4 as of FreeBSD 13

FreeBSD previously defaulted to DWARF 2 because several tools (gdb,
ctfconvert, etc.) did not support later versions.  These have either
been fixed or are deprecated.

Note that gdb 6 still exists but has been moved out of $PATH into
/usr/libexec and is intended only for use by crashinfo(8).  The kernel
build sets the DWARF version explicitly via -gdwarf2, so this should
have no effect there.

PR:		234887 [exp-run]
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D17930

MFC r343916:

Pull in r352607 from upstream llvm trunk (by Craig Topper):

  [X86] Add FPSW as a Def on some FP instructions that were missing it.

Pull in r353141 from upstream llvm trunk (by Craig Topper):

  [X86] Connect the default fpsr and dirflag clobbers in inline
  assembly to the registers we have defined for them.

  Summary:
  We don't currently map these constraints to physical register numbers
  so they don't make it to the MachineIR representation of inline
  assembly.

  This could have problems for proper dependency tracking in the
  machine schedulers though I don't have a test case that shows that.

  Reviewers: rnk

  Reviewed By: rnk

  Subscribers: eraman, llvm-commits

  Tags: #llvm

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

Pull in r353489 from upstream llvm trunk (by Craig Topper):

  [X86] Add FPCW as a register and start using it as an implicit use on
  floating point instructions.

  Summary:
  FPCW contains the rounding mode control which we manipulate to
  implement fp to integer conversion by changing the roudning mode,
  storing the value to the stack, and then changing the rounding mode
  back. Because we didn't model FPCW and its dependency chain, other
  instructions could be scheduled into the middle of the sequence.

  This patch introduces the register and adds it as an implciit def of
  FLDCW and implicit use of the FP binary arithmetic instructions and
  store instructions. There are more instructions that need to be
  updated, but this is a good start. I believe this fixes at least the
  reduced test case from PR40529.

  Reviewers: RKSimon, spatel, rnk, efriedma, andrew.w.kaylor

  Subscribers: dim, llvm-commits

  Tags: #llvm

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

These should fix a problem in clang 7.0 where it would sometimes emit
long double floating point instructions in a slightly wrong order,
leading to failures in our libm tests.  In particular, the cbrt_test
test case 'cbrtl_powl' and the trig_test test case 'reduction'.

Also bump __FreeBSD_cc_version, to be able to detect this in our test
suite.

Reported by:    lwhsu
PR:		234040
Upstream PR:	https://bugs.llvm.org/show_bug.cgi?id=40206

MFC r344056:

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

  [ARM] Make PerformSHLSimplify add nodes to the DAG worklist correctly.

  Intentionally excluding nodes from the DAGCombine worklist is likely
  to lead to weird optimizations and infinite loops, so it's generally
  a bad idea.

  To avoid the infinite loops, fix DAGCombine to use the
  isDesirableToCommuteWithShift target hook before performing the
  transforms in question, and implement the target hook in the ARM
  backend disable the transforms in question.

  Fixes https://bugs.llvm.org/show_bug.cgi?id=38530 . (I don't have a
  reduced testcase for that bug. But we should have sufficient test
  coverage for PerformSHLSimplify given that we're not playing weird
  tricks with the worklist. I can try to bugpoint it if necessary,
  though.)

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

This should fix a possible hang when compiling sys/dev/nxge/if_nxge.c
(which exists now only in the stable/11 branch) for arm.

src/lib/Makefile, branch releng/12.2

MFC r359045 (by brooks):

MFC r356356, r356358, r356422: replace gcclibs' libssp

MFC r355034:

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

MFC r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346081,r346270,r346574,r346576:

Revert r348136

MFC r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346574,r346576:

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

Add support for loader veriexec

Merge clang 7.0.1 and several follow-up changes

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