There have been several mentions on our mailing lists about missing
atomic functions in our system libraries (e.g. __atomic_load_8 and
friends), and recently I saw __bswapdi2 and __bswapsi2 mentioned too.
To address this, add implementations for the functions from compiler-rt
to the system compiler support libraries, e.g. libcompiler_rt.a and and
libgcc_s.so.
This also needs a small fixup in compiler-rt's atomic.c, to ensure that
32-bit mips can build correctly.
Bump __FreeBSD_version to make it easier for port maintainers to detect
when these functions were added.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D26159
[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
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).
Do not include float interfaces when using libsa.
We don't support float in the boot loaders, so don't include
interfaces for float or double in systems headers. In addition, take
the unusual step of spiking double and float to prevent any more
accidental seepage.
This revision worked around an endless recursion when compiling clzdi2.c
and ctzdi2.c with gcc, upstream landed a different workaround for this
in https://reviews.llvm.org/rL324593, which is effective enough.
Noticed by: jrtc27
Since this is contrib code, create an upstreamable version of my
change. Now on FreeBSD and NetBSD if _STANDALONE is defined, we
include the kernel version with alloances for the quirky differences
between the two.
Sponsored by: Netflix
o Replace __riscv__ with __riscv
o Replace __riscv64 with (__riscv && __riscv_xlen == 64)
This is required to support new GCC 7.1 compiler.
This is compatible with current GCC 6.1 compiler.
RISC-V is extensible ISA and the idea here is to have built-in define
per each extension, so together with __riscv we will have some subset
of these as well (depending on -march string passed to compiler):
__riscv_compressed
__riscv_atomic
__riscv_mul
__riscv_div
__riscv_muldiv
__riscv_fdiv
__riscv_fsqrt
__riscv_float_abi_soft
__riscv_float_abi_single
__riscv_float_abi_double
__riscv_cmodel_medlow
__riscv_cmodel_medany
__riscv_cmodel_pic
__riscv_xlen
Reviewed by: ngie
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D11901
Reapply r230021 (by ed):
Add a workaround to prevent endless recursion in compiler-rt.
SPARC and MIPS CPUs don't have special instructions to count
leading/trailing zeroes. The compiler-rt library provides fallback
rountines for these. The 64-bit routines, __clzdi2 and __ctzdi2, are
implemented as simple wrappers around the compiler built-in
__builtin_clz(), assuming these will expand to either 32-bit
CPU instructions or calls to __clzsi2 and __ctzsi2.
Unfortunately, our GCC 4.2 probably thinks that because the operand is
stored in a 64-bit register, it might just be a better idea to invoke
its 64-bit equivalent, simply resulting into endless recursion. Fix this
by defining __builtin_clz and __builtin_ctz to __clzsi2 and __ctzsi2
explicitly.
Reapply r276851:
Update compiler-rt to trunk r224034. This brings a number of new
builtins, and also the various sanitizers. Support for these will be
added in a later commit.
master 2e10b7a39b9, the last commit before the llvmorg-12-init tag, from
which release/11.x was branched.
Note that for now, I rolled back all our local changes to make merging
easier, and I will reapply the still-relevant ones after updating to
11.0.0-rc1.
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 after: 3 weeks
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
This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.
Updating the vendor area to match this layout is next.
