rather unfortunate upstream workaround for an unwind header problem that
does not exist on FreeBSD, but which causes an unnecessary warning for
us, add some flags to the compiler-rt Makefile to suppress the warning.
Hardfloat is now default (use riscv64sf as TARGET_ARCH
for softfloat).
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D8529
Also switch to the style used in the clang390-import branch to reduce
future conflicts.
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8039
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
Other architectures do not use quad precision long double and don't need
these runtime support routines.
Differential Revision: https://reviews.freebsd.org/D2252
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
These are long integer (di_int/du_int) to quad precision floating point
conversions. They may be reworked based on upstream discussion. These
versions are here to support arm64 world builds.
Reviewed by: ed
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2174
This may be reworked based on upstream discussion. This version is here
to support arm64 world builds.
Reviewed by: ed
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2173
Refactor float to integer conversion to share the same code.
80bit Intel/PPC long double is excluded due to lacking support
for the abstraction. Consistently provide saturation logic.
Extend to long double on 128bit IEEE extended platforms.
Initial patch with test cases from GuanHong Liu.
Reviewed by Steve Canon.
Differential Revision: http://reviews.llvm.org/D2804
Pull in r232107 from upstream compiler-rt trunk (by Ed Maste):
Use signed int implementation for __fixint
Requested by: emaste
don't build on some ARM platforms, provide symbols we already provide in
libc, or don't exist. Remove these from the build. Some of these may
return later on specific targets.
Differential Revision: https://reviews.freebsd.org/D1468
Reviewed by: dim, imp
the oabi is still in the tree, but it is expected this will be removed
as developers work on surrounding code.
With this commit the ARM EABI is the only supported supported ABI by
FreeBSD on ARMa 32-bit processors.
X-MFC after: never
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D876
This targets the existing ARMv6 and ARMv7 SoCs that contain a VFP unit.
This is an optional coprocessors may not be present in all devices, however
it appears to be in all current SoCs we support.
armv6hf targets the VFP variant of the ARM EABI and our copy of gcc is too
old to support this. Because of this there are a number of WITH/WITHOUT
options that are unsupported and must be left as the default value. The
options and their required value are:
* WITH_ARM_EABI
* WITHOUT_GCC
* WITHOUT_GNUCXX
In addition, without an external toolchain, the following need to be left
as their default:
* WITH_CLANG
* WITH_CLANG_IS_CC
As there is a different method of passing float and double values to
functions the ABI is incompatible with existing armv6 binaries. To use
this a full rebuild of world is required. Because no floating point values
are passed into the kernel an armv6 kernel with VFP enabled will work with
an armv6hf userland and vice versa.
for ARM.
This is quite ugly, because it has to work around a clang bug that does not
allow built-in functions to be defined, even when they're ones that are
expected to be built as part of a library.
Reviewed by: ed
Clang only supports atomic operations for ARMv6. For non-ARMv6, we still
need to emit these functions.
Clang's prototype for these functions slightly differs, as it is truly
based on GCC's documentation. It requires the use of signed types, but
also requires varargs. Still, we are not allowed to simply implement
this function directly. Cleverly work around this by implementing it
under a different name and using __strong_reference().
Originally we disabled libcompiler-rt on MIPS and SPARC64, because of an
issue where __clzdi2 and __ctzdi2 would cause endless recursion. This
bug has been fixed in r230021 already, but for some reason we only
switched to libcompiler-rt on SPARC64 -- not MIPS.
This means we can finally use <stdatomic.h> on all our architectures.
