| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
It was disabled by default in fe52b7f60ef4. We planned to (but did not)
remove the option before FreeBSD 14. Remove it now, for FreeBSD 15.
Relnotes: Yes
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31558
|
|
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-19-init-18630-gf2ccf80136a0, the
last commit before the upstream release/19.x branch was created.
PR: 280562
MFC after: 1 month
|
|
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
|
|
This reverts commit 940cf92c07867bcfb1cd5648cffc5df25fd0b92a.
This wasn't ready to be committed
|
|
|
|
Don't set CRT_COMMON_F16_ARCH for arm as it's not supported by gcc13.
Differential Revision: https://reviews.freebsd.org/D45234
|
|
__extendxftf2 and __trunctfxf2 build on amd64 not aarch64 and riscv.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D45052
|
|
Clang supports __bf16 for riscv from version 18.0 onwards, so update the
checks for it. While here, rewrite the checks so they are hopefully more
readable, and also handle gcc a little better.
In addition, define COMPILER_RT_HAS_FLOAT16 and COMPILER_RT_HAS_BFLOAT16
when these features should be available, since there are some parts in
compiler-rt that check for these defines.
PR: 276104
MFC after: 1 month
|
|
Apparently libgcc_s has always included libcompiler_rt's Makefile.inc
without first including bsd.compiler.mk, even though Makefile.inc used
COMPILER_TYPE already. It looks like we were just lucky that the
expression was not malformed.
PR: 276104
Reported by: Herbert J. Skuhra <herbert@gojira.at>
MFC after: 1 month
|
|
Older versions of gcc produce "error: unknown type name '__bf16'".
PR: 276104
MFC after: 1 month
|
|
PR: 276104
MFC after: 1 month
|
|
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-18-init-15692-g007ed0dccd6a.
PR: 276104
MFC after: 1 month
|
|
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-18-init-15088-gd14ee76181fb.
PR: 276104
MFC after: 1 month
|
|
[builtins][AArch64] Implement _sync out-of-line atomics
Whilst Clang does not use these, recent GCC does, and so on systems such
as FreeBSD that wish to use compiler-rt as the system runtime library
but also wish to support building programs with GCC these interfaces are
needed.
This is a light adaptation of the code committed to GCC by Sebastian Pop
<spop@amazon.com>, relicensed with permission for use in compiler-rt.
Fixes https://github.com/llvm/llvm-project/issues/63483
Reviewed By: sebpop, MaskRay
Differential Revision: https://reviews.llvm.org/D158536
Reviewed by: dim
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41716
|
|
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
|
Fixes: 1ca12bd927d7 Remove the riscv64sf architecture.
|
|
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D39328
|
|
It was used by ancient GCC assert.h. Prior to 2001 GCC used to provide
its own assert.h The GCC assert.h required __eprintf to emit the error
message. FreeBSD's own assert.h never used this.
Reviewed by: ed (previously), imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2597
|
|
Simplify the tests for 32-bit arm soft float support. For the files
included only on arm, drop the test entirely. For others, test
MACHINE_CPUARCH against arm.
No functional change intended. File lists appear the same before / after
the change.
Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D38582
|
|
Parts of compiler-rt are also built for libgcc_eh and libgcc_s, and
these were already pointing to the libunwind unwind.h. For the sake of
consistency, also build compiler-rt itself against the libunwind
unwind.h, not the libcxxrt one.
MFC after: 3 days
|
|
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13.0.0-rc1-97-g23ba3732246a.
PR: 258209
MFC after: 2 weeks
|
|
As reported by Ronald, adding the out-of-line LSE atomics helpers for
aarch64 to compiler-rt was not sufficient to link programs using these,
as they also require a __aarch64_have_lse_atomics global. This is
initialized in compiler-rt's lib/builtins/cpu_model.c, roughly similar
to the x86 CPU model and feature detection in that file.
Since upstream does not yet have a FreeBSD specific implementation for
getting the required information, add a simple one that should work for
now, while I try to get it sorted with the LLVM people.
Reported by: Ronald Klop <ronald-lists@klop.ws>
Fixes: cc55ee8009a5
PR: 257392
MFC after: 2 weeks
|
|
Both clang >= 12 and gcc >= 10.1 now default to -moutline-atomics for
aarch64. This requires a bunch of helper functions in libcompiler_rt.a,
to avoid link errors like "undefined symbol: __aarch64_ldadd8_acq_rel".
(Note: of course you can use -mno-outline-atomics as a workaround too,
but this would negate the potential performance benefit of the faster
LSE instructions.)
Bump __FreeBSD_version so ports maintainers can easily detect this.
PR: 257392
MFC after: 2 weeks
|
|
As suggested in D27598. This also supports MK_WERROR.clang=no and
MK_WERROR.gcc=no to support the existing NO_WERROR.<compiler> uses.
Reviewed By: brooks
Differential Revision: https://reviews.freebsd.org/D27601
|
|
libcompiler_rt implements certain functions that clang and gcc emit
calls to as part of their codegen (e.g. for extended width math). Build
it without stack smashing protection (SSP, -fstack-protector) in order
to support building binaries without SSP, especially the dynamic linker.
Besides, SSP is probably not very valuable in this library.
Reviewed by: arichardson, dim, kib
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D27786
|
|
already covers the functions in compiler-rt's atomic.c, leading to
conflicts when linking.
PR: 230888
MFC after: 3 days
X-MFC-With: r364753
Notes:
svn path=/head/; revision=365588
|
|
for clang, as it uses clang specific builtins, and does not compile
correctly with gcc. Note that gcc packages usually come with their own
libatomic, providing these primitives.
PR: 230888
MFC after: 3 days
X-MFC-With: r364753
Notes:
svn path=/head/; revision=365509
|
|
warnings anymore for compiler-rt's atomic.c. This occurred because the
IS_LOCK_FREE_8 macro was not correctly defined to 0 for mips, and this
caused the compiler to emit a runtime call to __atomic_is_lock_free(),
and that triggers the warning.
MFC after: 2 weeks
X-MFC-With: r364753
Notes:
svn path=/head/; revision=364782
|
|
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
Notes:
svn path=/head/; revision=364753
|
|
This is a change in preparation for stopping to use lorder.sh (D26044) and
instead assume that we have a linker newer than ~1990. Without lorder.sh
duplicates end up being passed to the linker when building .so files and this
can result in duplicate symbol definition errors.
There is one minor change: libcompiler_rt.a will no longer provide
gcc_personality_v0 and instead we now only have it in libgcc_eh.a/libgcc_s.so.
This matches GCC's behaviour.
Reviewed By: emaste, cem
Differential Revision: https://reviews.freebsd.org/D26042
Notes:
svn path=/head/; revision=364649
|
|
Notes:
svn path=/projects/clang1000-import/; revision=357855
|
|
Notes:
svn path=/head/; revision=357798
|
|
libgcc, as these are used in a few other builtin implementations.
Notes:
svn path=/projects/clang1000-import/; revision=357221
|
|
Notes:
svn path=/projects/clang1000-import/; revision=357177
|
|
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
Notes:
svn path=/head/; revision=356104
|
|
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.
Notes:
svn path=/head/; revision=355940
|
|
Submitted by: James Clarke <jrtc27@jrtc27.com>
Reviewed by: imp
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D22660
Notes:
svn path=/head/; revision=355401
|
|
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).
Notes:
svn path=/head/; revision=354347
|
|
Notes:
svn path=/projects/clang900-import/; revision=351612
|
|
As with other archs the compiler may emit calls to the byte swap routines
under certain conditions.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Notes:
svn path=/head/; revision=351040
|
|
for softfloat mips. No need to include them here.
Notes:
svn path=/head/; revision=328768
|
|
Make armv7 as a new MACHINE_ARCH.
Copy all the places we do armv6 and add armv7 as basically an
alias. clang appears to generate code for armv7 by default. armv7 hard
float isn't supported by the the in-tree gcc, so it hasn't been
updated to have a new default.
Support armv7 as a new valid MACHINE_ARCH (and by extension
TARGET_ARCH).
Add armv7 to the universe build.
Differential Revision: https://reviews.freebsd.org/D12010
Notes:
svn path=/head/; revision=324340
|
|
SSE2 instructions, we can use them.
Suggested by: jkim
PR: 221733
MFC after: 1 week
X-MFC-With: r323001
Notes:
svn path=/head/; revision=323014
|
|
conversion functions use SSE2 instructions, but these are not guarded by
#ifdef __SSE2__, and there is no implementation using general purpose
registers. For these functions, use the generic C variants instead,
otherwise they will cause SIGILL on older processors.
Reported by: bsdpr@phoe.frmug.org
PR: 221733
MFC after: 1 week
Notes:
svn path=/head/; revision=323001
|
|
These builtins were listed in the mips-specific Symbol.map for libc but
were not implemented. Compiling mips with recent clang requires these
symbols.
Sponsored by: DARPA / AFRL
Notes:
svn path=/head/; revision=322766
|
|
Notes:
svn path=/head/; revision=322522
|
|
Notes:
svn path=/projects/clang500-import/; revision=320971
|
|
Attempting to build sparc64 world with GCC 6.3 previously failed with
zstd_compress.c:(.text+0x8fc): undefined reference to `__bswapsi2'
Notes:
svn path=/head/; revision=320735
|
|
Notes:
svn path=/projects/clang500-import/; revision=318658
|
