Previously HWCAP_ATOMIC and others were being used before checking if
they were defined. This moves up all the ifndef checks to define these
macros if they are not yet defined.
Differential Revision: https://reviews.llvm.org/D141285
This commit adds compiler-rt cmake option COMPILER_RT_DISABLE_AARCH64_FMV
which, when enabled, doesn't include function multiversioning features
initilization code in 'builtins' build.
Differential Revision: https://reviews.llvm.org/D141199
- GCC does not recognize $fcsr0, uses $r0 instead.
- GCC does not implement __builtin_thread_pointer, which can be
obtained directly through $tp.
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D140545
This reverts commit e43924a75145d2f9e722f74b673145c3e62bfd07.
Reason: Patch broke the MSan buildbots. More information is available on
the original phabricator review: https://reviews.llvm.org/D127812
The main thing that needed changing was excluding functionality that
isn't supported on armv4t. So excluding Arm specific builtin assembly files.
In the process some files were renamed and the source was annotated where
appropriate, so it's a bit easier to follow what group of files are meant for
what purpose.
Reviewed By: peter.smith, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D138725
LLVM runtimes build already loads the LLVM config and sets all
appropriate variables, no need to do it again.
Differential Revision: https://reviews.llvm.org/D137870
syscall makes it failed to build on mips64 for mipsel:
```
compiler-rt/lib/builtins/clear_cache.c:97:3: error:
call to undeclared function 'syscall'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
syscall(__NR_cacheflush, start, (end_int - start_int), BCACHE);
```
In this patch, we use `rdhwr` to get synci_step.
If synci_step is zero, it means that the hardware will maintain the coherence. We need to do nothing.
Then for r6+, `synci` is required to keep icache global.
So we can use `synci` to flush icache.
The ISA documents ask a `sync` and a `jr.hb` after `synci`.
For pre-r6, we can use cacheflush libc function, which is same on Linux and FreeBSD.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D135565
Fixes warnings (or errors, if someone injects -Werror in their build system,
which happens in fact with some folks vendoring LLVM too) with Clang 16:
```
+/var/tmp/portage.notmp/portage/sys-devel/llvm-15.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: warning: a function declaration without a prototype
is deprecated in all versions of C [-Wstrict-prototypes]
-/var/tmp/portage.notmp/portage/sys-devel/llvm-14.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: error: a function declaration without a prototype is
deprecated in all versions of C [-Werror,-Wstrict-prototypes]
int main() {return 0;}
^
void
```
Differential Revision: https://reviews.llvm.org/D137503
When building libstd on Rust for a riscv32 target, `compiler-rt` fails to build with the following error:
```
running: "riscv-none-elf-gcc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-march=rv32imac" "-mabi=ilp32" "-mcmodel=medany" "-fno-builtin" "-fvisibility=hidden" "-ffreestanding" "-fomit-frame-pointer" "-ffile-prefix-map=E:\\Code\\Xous\\rust-next\\src\\llvm-project\\compiler-rt=." "-DVISIBILITY_HIDDEN" "-o" "E:\\Code\\Xous\\rust-next\\target\\riscv32imac-unknown-xous-elf\\release\\build\\compiler_builtins-b0d7dd25c6999904\\out\\absvdi2.o" "-c" "E:\\Code\\Xous\\rust-next\\src\\llvm-project\\compiler-rt\\lib/builtins\\absvdi2.c"
cargo:warning=In file included from E:\Code\Xous\rust-next\src\llvm-project\compiler-rt\lib/builtins\int_lib.h:99,
cargo:warning= from E:\Code\Xous\rust-next\src\llvm-project\compiler-rt\lib/builtins\absvdi2.c:13:
cargo:warning=E:\Code\Xous\rust-next\src\llvm-project\compiler-rt\lib/builtins\int_types.h:79:1: error: unable to emulate 'TI'
cargo:warning= 79 | typedef int ti_int __attribute__((mode(TI)));
cargo:warning= | ^~~~~~~
cargo:warning=E:\Code\Xous\rust-next\src\llvm-project\compiler-rt\lib/builtins\int_types.h:80:1: error: unable to emulate 'TI'
cargo:warning= 80 | typedef unsigned tu_int __attribute__((mode(TI)));
cargo:warning= | ^~~~~~~
exit code: 1
```
This is because 128-bit support is gated on the `__riscv` compiler macro which is valid for both rv32 and rv64. However, only rv64 has 128-bit support, so this fails when building for rv32.
Add a check for `__SIZEOF_INT128__` to ensure that 128-bit support is only enabled on targets that support it.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D137485
The lowercase __ppc__ is not defined by Linux GCC, therefore it lures
users to write code which is not portable to GCC. Migrate to __powerpc__ in
preparation for undefining __ppc__. __powerpc__ is much more common than
__PPC__.
There are two failures in the current builtins,
Failed Tests (2):
Builtins-loongarch64-linux :: clear_cache_test.c
Builtins-loongarch64-linux :: enable_execute_stack_test.c
It is caused by __clear_cache not being implemented and triggering `abort`.
"__clear_cache" is implemented in the same way as "clear_cache" in gcc (
in gcc/config/loongarch/loongarch.md)
Differential Revision: https://reviews.llvm.org/D136921
Initial builtins for LoongArch.
Add loongarch64 to ALL_CRT_SUPPORTED_ARCH list.
Support fe_getround and fe_raise_inexact in builtins.
Differential Revision: https://reviews.llvm.org/D136338
that can lead to security vulnerabilities
Also, fix a few places that were causing -Wshadow and
-Wformat-nonliteral warnings to be emitted.
This reapplies the patch that was reverted in caaafe4ae250 because it
broke Fuchsia builders.
I reverted the changes I made to InstrProfData.inc and instead renamed
the variables in InstrProfilingWriter.c. Also fixed a bug in function
add_security_warnings that was causing it to pass -Wformat-nonliteral
when the compiler doesn't support it.
that can lead to security vulnerabilities
Also, fix a few places that were causing -Wshadow and
-Wformat-nonliteral warnings to be emitted.
This reapplies the patch that was reverted in 0d66dc57e8c7 because it
broke a few bots.
I made changes so that cmake checks whether some of the flags are
supported by the compiler that is used before adding them to the list.
Also, I moved function add_security_warnings to CompilerRTUtils.cmake so
that it is defined before it's used.
Differential Revision: https://reviews.llvm.org/D131714
that can lead to security vulnerabilities
Also, fix a few places that were causing -Wshadow and
-Wformat-nonliteral warnings to be emitted.
Differential Revision: https://reviews.llvm.org/D131714
This reverts commit 0729d00135ccbe1514a49168bbf26986823235c2.
Buildbot https://lab.llvm.org/buildbot/#/builders/19/builds/11989 failed
with "error: ISO C requires a translation unit to contain at least one declaration [-Werror,-Wempty-translation-unit]"
#56854 shows a backwards compatibility problem when builtins of compiler-rt don't follow ABI. We need to prevent to fall into the trap again for BF16.
Reviewed By: bkramer
Differential Revision: https://reviews.llvm.org/D131147
As mentioned in https://reviews.llvm.org/D121379#3690593, this
change broke the build of compiler-rt targeting powerpc using GCC.
The 32-bit powerpc target is not supposed to emit 128-bit libcalls
-- if it does, then that's a backend bug and needs to be fixed there.
This reverts commit 8f24a56a3a9363f353c8da318d97491a6818781d.
Differential Revision: https://reviews.llvm.org/D130988
Instead of detecting `_Float16` support at CMake configuration time,
detect it at compile time by checking for the predefined (by the
compiler) macro `__FLT16_MAX__` instead.
This solves the issue where compiler-rt is built simultaneously for both
x86_64 and i386 targets, and the CMake configuration uses x86_64
compilation to detect `_Float16` support, while it may not be supported
by the i386 target (if it does not have SSE2).
While here, rename `COMPILERT_RT_HAS_FLOAT16` to `CRT_HAS_FLOAT16`, to
conform more to the naming style used in `int_lib.h` and `int_types.h`.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D130718
This is modeled after the half-precision fp support. Two new nodes are
introduced for casting from and to bf16. Since casting from bf16 is a
simple operation I opted to always directly lower it to integer
arithmetic. The other way round is more complicated if you want to
preserve IEEE semantics, so it's handled by a new __truncsfbf2
compiler-rt builtin.
This is of course very bare bones, but sufficient to get a semi-softened
fadd on x86.
Possible future improvements:
- Targets with bf16 conversion instructions can now make fp_to_bf16 legal
- The software conversion to bf16 can be replaced by a trivial
implementation under fast math.
Differential Revision: https://reviews.llvm.org/D126953
ARM EHABI isn't signalled by any specific compiler builtin define,
but is implied by the lack of defines specifying any other
exception handling mechanism, `__USING_SJLJ_EXCEPTIONS__` or
`__ARM_DWARF_EH__`.
As Windows SEH also can be used for unwinding, check for the
`__SEH__` define too, in the same way.
This is the same change as 4a3722a2c3dff1fe885cc38bf43d3c095c9851e7 /
D126866, applied on the compiler-rt builtins gcc_personality_v0
function.
Differential Revision: https://reviews.llvm.org/D126863
Don't build atomic fetch nand libcall functions when the required
compiler builtin isn't available. Without this compiler-rt can't be
built with LLVM 13 or earlier.
Not building the libcall functions isn't optimal, but aligns with the
usecase in FreeBSD where compiler-rt from LLVM 14 is built with an LLVM
13 clang and no LLVM 14 clang is built.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D126710
GCC recently started setting constructor priority on init_have_lse_atomics [1]
to avoid undefined initialization order with respect to other initializers,
causing accidental use of ll/sc intrinsics on targets where this was not
intended (which presents a minor performance problem as well as a
compatibility problem for users wanting to use the rr debugger). I initially
thought compiler-rt does not have the same issue as libgcc, since it looks
like we're already setting init priority on the constructor.
Unfortuantely, it does not appear that the HAVE_INIT_PRIORITY check is ever
performed anyway, so despite appearances the init priority was not actually
applied. Fix that by applying the init priority unconditionally. It has been
supported in clang ever since it was first introduced and in any case for
more than 14 years in both gcc and clang. MSVC is already excluded from this
code path and we're already using constructors with init priority elsewhere
in compiler-rt without additional check (though mostly in the sanitizer
runtime, which may have more narrow target support). Regardless, I believe
that for our supported compilers, if they support the constructor attribute,
they should also support init priorities.
While we're here, change the init priority from 101, which is the highest
priority for end user applications, to instead use one of the priority levels
reserved for implementations (1-100; lower integers are higher priority).
GCC ended up using `90`, so this commit aligns the value in compiler-rt
to the same value to ensure that there are no subtle initialization order
differences between libgcc and compiler-rt.
[1] 75c4e4909a
Differential Revision: https://reviews.llvm.org/D126424
The spinlock requires that lock-free operations are available;
otherwise, the implementation just calls itself. As discussed in
D120026.
Differential Revision: https://reviews.llvm.org/D123080
D123200 did not include the generic sources, which means that only the
AVR-specific sources were compiled. With this change, generic sources
are included as expected.
Tested with the following commands:
cmake -G Ninja -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE=avr -DCOMPILER_RT_BAREMETAL_BUILD=1 -DCMAKE_C_COMPILER=clang-14 -DCMAKE_C_FLAGS="--target=avr -mmcu=avr5 -nostdlibinc -mdouble=64" ../path/to/builtins
ninja
Differential Revision: https://reviews.llvm.org/D124969
Previously the default was long, which is 32-bit on AVR. But avr-gcc
expects a smaller value: it reads the return value from r24.
This is actually a regression from https://reviews.llvm.org/D98205.
Before D98205, the return value was an enum (which was 2 bytes in size)
which was compatible with the 1-byte return value that avr-gcc was
expecting. But long is 4 bytes and thus places the significant return
value in a different register.
Differential Revision: https://reviews.llvm.org/D124939
