Most of GCC's Linux targets have a link spec
`%{!static|static-pie:--eh-frame-hdr}` that doesn't pass --eh-frame-hdr
for `-static` links. `-static` links are supposed to utilize
`__register_frame_info` (called by `crtbeginT.o`, not by crtbegin.o or
crtbeginS.o) as a replacement.
compiler-rt crtbegin (not used with GCC) has some ehframe code, which is
not utilized because Clang driver unconditionally passes --eh-frame-hdr
for Linux targets, even for -static. In addition, LLVM libunwind
implements `__register_frame_info` as an empty stub.
Furthermore, in a non-static link, the `__register_frame_info`
references can cause an undesired weak dynamic symbol.
For now, just disable the config by default.
This re-lands cc0065a7d0 in a way that
keeps existing targets working.
---------
Original commit message:
#68132 ended up removing
__multc3 & __divtc3 from compiler-rt library builds that have
QUAD_PRECISION but not TF_MODE due to missing int128 support.
I added support for QUAD_PRECISION to use the native hex float long double representation.
---------
Co-authored-by: Sean Perry <perry@ca.ibm.com>
Allow pre-release APIs on pre-release devices.
The current implementation requires __ANDROID_API_FUTURE__ to use new
APIs on pre-release system. This makes it hard to maintain the codebase
because it should be switched a concrete version (e.g. __ANDROID_API_X__
on release of X).
Instead, we can just allow pre-release APIs on pre-release system
without mandating the major version of __ANDROID_API_FUTURE__.
Note that this doesn't make API guards just no-op in pre-release builds.
We can still rely on its compile-time checks and it still works as
expected with release builds. Even with pre-release builds, it's the
same as before because we would pass __ANDROID_API_FUTURE__ to make the
calls anyway.
Prior to 885d7b759b, the builtins library
contained two chkstk implementations for each of i386 and x86_64, one
that was used in mingw environments, and one unused (with a symbol name
not matching anything that is used anywhere). Some of the functions
additionally had other, also unused, aliases.
After cleaning this up in 885d7b759b, the
unused symbol names were removed.
At the same time, symbol aliases were added for the names as they are
used by MSVC; the functions are functionally equivalent, but have
different names between mingw and MSVC style environments.
By adding a symbol alias (so that one object file contains two different
symbols for the same function), users can run into problems with
duplicate definitions, if they themselves define one of the symbols (for
various reasons), but need to link in the other one.
This happens for Wine, which provides their own definition of
"__chkstk", but when built in mingw mode does need compiler-rt to
provide the mingw specific symbol names; see
https://github.com/mstorsjo/llvm-mingw/issues/397.
To avoid the issue, remove the extra MS style names. They weren't
entirely usable as such for MSVC style environments anyway, as
compiler-rt builtins don't build these object files at all, when built
in MSVC mode; thus, the effort to provide them for MSVC style
environments in 885d7b759b was a
half-hearted step towards that.
If we really do want to provide those functions (as an alternative to
the ones provided by MSVC itself), we should do it in a separate object
file (even if the function implementation is the same), so that users
who have a definition of one of them but need a definition of the other,
won't have conflicts.
Additionally, if we do want to provide them for MSVC, those files
actually should be built when building the builtins in MSVC mode as well
(see compiler-rt/lib/builtins/CMakeLists.txt).
If we do that, there's a risk that an MSVC style build ends up linking
in and preferring our implementation over the one provided by MSVC,
which would be suboptimal. Our implementation always probes the
requested amount of stack, while the MSVC one checks the amount of
allocated stack and only probes as much as really is needed.
In short - this reverts the situation to what it was in the 17.x release
series (except for unused functions that have been removed).
The use of `#include <stdlib.h>` introduces a libc dependency. In many
build environments such a file can be found under e.g. /usr/include, but
this does not necessarily correspond to the libc in use, which may not
be available until after the builtins have been built.
So far as I understand, it's not valid to have a dependency on libc from
builtins; there are a handful of such includes in builtins, but they are
protected by ifdefs.
Instead, use <stddef.h>, which provides `size_t` and is provided by the
compiler's resource headers and so should always be available.
The patch adds support for FEAT_MOPS (Memory Copy and Memory Set
instructions) in Function Multi Versioning. The bits [19:16] of the
system register ID_AA64ISAR2_EL1 indicate whether FEAT_MOPS is
implemented in AArch64 state. This information is accessible via ELF
hwcaps.
Mark the following symbols as `static` to prevent duplicate definitions:
`__builtin_ctz`
`__builtin_clz`
`__builtin_clzll`
`__builtin_sadd_overflow`
>Without these then all of these functions show up in all object files
which include int_lib.h on Windows. This'll help prevent duplicate
symbols by ensuring they're not exported.
See:
https://github.com/rust-lang/compiler-builtins/issues/167https://reviews.llvm.org/D34599
This fixes:
```
[3334/7449] Building C object projects\compiler-rt\lib\builtins\CMakeFiles\clang_rt.builtins-x86_64.dir\extendsfdf2.c.obj
C:\git\llvm-project\compiler-rt\lib\builtins\fp_extend_impl.inc(63): warning C4018: '<': signed/unsigned mismatch
```
This variable was explicitly removed from the cache to ease transition
from existing build directories but that breaks passing
COMPILER_RT_BUILD_CRT=OFF on the command line. I was surprised to see
the CRT builds being run for my builtins-only build config (I noticed
because one of the tests was failing despite having `REQUIRES: crt`).
If I pass `-DCOMPILER_RT_BUILD_CRT=OFF` to cmake and add some prints
around the `unset` statement it shows the following:
```
-- before unset(): COMPILER_RT_BUILD_CRT=OFF
-- after unset: COMPILER_RT_BUILD_CRT=
-- after cmake_dependent_option COMPILER_RT_BUILD_CRT=ON
```
Drop this temporary workaround now that over 6 months have passed.
https://github.com/llvm/llvm-project/pull/68132 ended up removing
__multc3 & __divtc3 from compiler-rt library builds that have
QUAD_PRECISION but not TF_MODE due to missing int128 support. I added support for QUAD_PRECISION to
use the native hex float long double representation.
---------
Co-authored-by: Alexander Richardson <mail@alexrichardson.me>
After 05a4212cc7 a number of long double related declarations are
enabled in `int_types.h`, whenever the CPU architecture and platform
support it. However, this does not work with FreeBSD's standalone
environment, which disallows any use of floating point.
In add98b2462 this was made conditional with `CRT_HAS_FLOATING_POINT`,
so extend the block guarded by that define to include all floating point
related declarations.
a15532d764 landed a patch that added
support for detecting more AMD znver2 CPUs and cleaned up some of the
surrounding code, including the znver3 detection. Since one model group
is 00h-0fh, I adjusted the check to include checking if the value is
greater than zero. Since the value is unsigned, this is always true and
gcc warns on it. This patch removes the comparison with zero to get rid
of the compiler warning.
[builtins] Fix CPU feature detection for FreeBSD on AArch64
This is a follow-up to #75635 which broke the build for FreeBSD on
AArch64:
```
compiler-rt/lib/builtins/cpu_model/aarch64/lse_atomics/freebsd.inc:3:16: error: call to undeclared function 'elf_aux_info'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
3 | int result = elf_aux_info(AT_HWCAP, &hwcap, sizeof hwcap);
| ^
```
Using `elf_aux_info()` requires including `<sys/auxv.h>` first. To
prevent redeclaration issues with `hwcap.inc` attempting to define
`HWCAP_xxx` macros before `<sys/auxv.h>` does so, include `<sys/auxv.h>`
before any of the `.inc` files on FreeBSD.
This is a follow up to #75635 which broke the build on Fuchsia. We don't
support ifunc on Fuchsia so we shouldn't define __init_cpu_features. For
__init_cpu_features_resolver we have to use _zx_system_get_features as a
Zircon native solution.
This patch adds proper detection support for more znver2 CPUs.
Specifically, this adds in support for CPUs codenamed Renoir, Lucienne,
and Mendocino.
This was originally proposedfor Renoir in
https://reviews.llvm.org/D96220 and
got approved, but slipped through the cracks. However, there is still a
demand for this feature.
In addition to adding support for more znver2 CPUs, this patch also includes
some additional refactoring and comments related to cpu model
information for zen CPUs.
Fixes https://github.com/llvm/llvm-project/issues/74934.
And its follow up "fixup! [builtins][arm64] Build __init_cpu_features_resolver on Apple platforms (#73685)".
This reverts commit 5b470522cd and
212a5e1b9c.
Due to build failures on Windows:
```
C:\Users\Tcwg\llvm-worker\clang-arm64-windows-msvc-2stage\llvm\compiler-rt\lib\builtins\cpu_model.c(1571,2): error: No support for checking hwcap on this platform yet.
1571 | #error No support for checking hwcap on this platform yet.
| ^
```
https://lab.llvm.org/buildbot/#/builders/120/builds/5990
Whenever linking with -nodefaultlibs for a MinGW target, we manually
need to specify a bunch of libraries - listed in ${MINGW_LIBRARIES}; the
same is already done for sanitizers and libunwind/libcxxabi/libcxx.
Practically speaking, linking with -nodefaultlibs but manually passing
the libraries in ${MINGW_LIBRARIES} restores most of the libraries that
are linked by default, except for the potential compiler builtins and
unwind library; i.e. it has essentially the same effect as linking with
"--unwindlib=none -rtlib=none", except that -rtlib doesn't accept such a
value.
When building only compiler-rt/lib/builtins, not all of compiler-rt,
${MINGW_LIBRARIES} is unset - set it manually here for that case. This
matches what is set in
compiler-rt/cmake/config-ix.cmake, except that the builtins (libgcc or
compiler-rt builtins) is omitted; the only use within lib/buitlins is
for the standalone libatomic, which explicitly already links against the
just-built builtins.
