We've compiled it since the LLVM 13 import in 2021, but for some reason
never exported it.  A user of CheriBSD recently caused Morello LLVM to
emit a reference to it so finish the job and export it.

Reviewed by:	dim, emaste
Fixes:		6e75b2fbf9a0 ("Merge llvm-project release/13.x llvmorg-13.0.0-rc1-97-g23ba3732246a")
MFC after:	1 week
Sponsored by:	DARPA, AFRL
See also:	https://github.com/CTSRD-CHERI/cheribsd/issues/2614
Differential Revision:	https://reviews.freebsd.org/D56310

    [Driver] Enable outline atomics for FreeBSD/aarch64 (#156089)

The compiler_rt helper functions have been built since 12.4, 13.1, 14
and anything newer.

This reverts commit bd27bd1f51d049538cc7a0053be9d99110a53ae1.

Only some people (including the release manager, unfortunately) ran into
build issues with the previous iteration of this commit, because they
were bootstrapping the compiler, either via the WITHOUT_SYSTEM_COMPILER
src.conf(5) setting, or because the build system determined that their
base system compiler was out of date.

The bootstrapped compiler would then enable outline atomics and compile
libgcc_s with these, but because libgcc_s is linked with -nodefaultlibs,
it could not find the helper routines in libcompiler_rt.a.

In contrast, people who did not bootstrap the compiler never saw any
issues, because libgcc_s was built using their 'old' base system
compiler, and so libgcc_s would not contain any calls to those helper
routines.

Fix this by ensuring that libgcc_s is linked against libcompiler_rt.a
explicitly, similar to some other binaries and libraries that are built
with -nodefaultlibs.

Also, bump FREEBSD_CC_VERSION to ensure that everybody gets the updated
compiler with outline atomics enabled. (This should have been done in
the first iteration of this commit, because the error would have shown
up right away then.)

MFC after:	3 days

Export all integer and floating point __aeabi_ functions defined by
"Run-time ABI for Arm Architecture" from libgcc, excluding __aeabi_h2f_alt,
__aeabi_f2h_alt and __aeabi_d2h_alt, which are not yet implemented by
compiler-rt.

To maintain ABI backward compatibility, convert __aeabi_ floating-point
symbols previously exported from libc to an explicit non-default version.

Remove guessing of vfp/not-vfp version  for compiler-rt sources. The vfp
version needs additional runtime logic to select the right implementation
and we don't have it implemented.

MFC after:	1 month
Reviewed by:	dim
PR:		271087
Differential Revision:	https://reviews.freebsd.org/D50100

This reverts commit caab831338f4eeaa7455e981478be9fd414b7969, because
some new unresolved issues came up in bug 271087:

  Some programs depend on these symbols, when they are compiled for armv6
  or armv7. Closes #1560 (slightly changed due to sorting of the symbols).

PR:		271087
Reported by:	mmel
MFC after:	immediately

Some programs depend on these symbols, when they are compiled for armv6
or armv7. Closes #1560 (slightly changed due to sorting of the symbols).

PR:		271087
Reported by:	fuz
Submitted by:	jfc@mit.edu
MFC after:	1 week

After building packages we have a number of new
and updated Makefile.depend files

Reviewed by:	stevek

This is a residual of the $FreeBSD$ removal.

MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix

These symbols are present on amd64 or i386.

Reported by:	kaktus, jhibbits
Fixes:		98c8caafffb65 libgcc_s: 80-bit long double function are x86-only

__extendxftf2 and __trunctfxf2 build on amd64 not aarch64 and riscv.

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

Don't try to expose them on other architectures.

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