According to the README this file isn't used by rust, but it's currently
included which leads to these linker warnings in some cases:
```
ld: warning: linker symbol '$ld$hide$os10.5$___udivti3' hides a non-existent symbol '___udivti3'
ld: warning: linker symbol '$ld$hide$os10.4$___umoddi3' hides a non-existent symbol '___umoddi3'
ld: warning: linker symbol '$ld$hide$os10.5$___umoddi3' hides a non-existent symbol '___umoddi3'
ld: warning: linker symbol '$ld$hide$os10.4$___umodti3' hides a non-existent symbol '___umodti3'
ld: warning: linker symbol '$ld$hide$os10.5$___umodti3' hides a non-existent symbol '___umodti3'
```
This file exclusively contains macros which hides old symbols on Apple
OS versions where they don't exist.
fc10370ef7/compiler-rt/lib/builtins/apple_versioning.c
The change in 186517b3266a7bb2b2310927f7342ea7f41790c3 was intended to
affect only `arm-linux-androideabi` but also affected
`armv7-linux-androideabi` which is not a pre-ARMv6 architecture.
Fixes#449
The msvc toolchain does not support building `.s` files, clang only
supports generating out-of-line atomics on Linux and gcc does not
support aarch64 for Windows at all. Therefore, we don't need to compile
`lse.s` on `aarch64-pc-windows-msvc`.
llvm/llvm-project@a4ac434c47 saw the
addition of out-of-line aarch64 atomic intrinsics. LLVM will sometimes
emit these, so we need to ensure they're included in Rust's compiler-rt.
`AArch64` GCCs exit with an error condition when they encounter any kind of
floating point code if the `nofp` and/or `nosimd` compiler flags have been set.
Therefore, evaluate if those flags are present and set a boolean that causes any
compiler-rt intrinsics that contain floating point source to be excluded for
this target.
This patch prepares https://github.com/rust-lang/rust/pull/68334
This commit removes the `compiler-rt` submodule from this repository.
The goal here is to align the `compiler-rt` used for compiling C
intrinsics with the upstream rust-lang/rust's usage of `llvm-project`.
Currently we have both an `llvm-project` repository as well as
`compiler-rt`, but they can naturally get out of sync and it's just one
more submodule to manage.
The thinking here is that the feature `c` for this crate, when
activated, will require the user to configure where the source code for
`compiler-rt` is present. This places the onus on the builder of
`compiler-builtins` to check-out and arrange for the appropriate
`compiler-rt` source code to be placed somewhere. For rust-lang/rust
this is already done with the `llvm-project` submodule, and we can
arrange for it to happen on this crate's CI anyway.
For users of this crate this is a bit of a bummer, but `c` is disabled
by default anyway and it seems unlikely that `c` is explicitly opted in
to all that much. (given the purpose of this crate)
This should allow us to archive the `compiler-rt` repository and simply
use `llvm-project` in the rust-lang/rust repository.
This commit tweaks the implementation of the synthetic
`#[use_c_shim_if]` attribute, renaming it to
`#[maybe_use_optimized_c_shim]` in the process. This no longer requires
specifying a `#[cfg]` clause indicating when the optimized intrinsic
should be used, but rather this is inferred and printed from the build
script.
The build script will now print out appropriate `#[cfg]` directives for
rustc to indicate what intrinsics it's compiling. This should remove the
need for us to keep the build script and the source in sync, but rather
the build script can simply take care of everything.
This fixes a longstanding bug in compiler-builtins where C code was
compiled for the riscv targets but when distributed in rust-lang/rust
all the C code was actually compiled for x86_64 since there is no
configured C compiler for riscv. This was exposed by #286 by accident
but the underlying cause was somewhat unrelated.
For now we forcibly disable C code for riscv targets, and when the C
compiler story is sorted out in rust-lang/rust and with `cc-rs` we can
reenable. For now just use all the Rust definitions.
cc rust-lang/rust#60747
Some files were not assembling for the Armv8-M Mainline architecture
profile with FPU extension. Reason being the same as for Armv7-M: the
conversion intrinsics including double precision floating
point variables do not work with single precision FPUs.
Also removes from exclusion files that are assembling without errors for
Armv7-M and Armv8-M Mainline.
Armv8-M Baseline, ie thumbv8m.base-none-eabi, is a superset of the
Armv6-M architecture profile. As it shares almost the same instruction
set, this commit copies the configuration for thumbv6m-none-eabi to
enable it.
Adds generic conversion from a wider to a narrower IEEE-754
floating-point type.
Implement `__truncdfsf2` and `__truncdfsf2vfp` and associated test-cases.
This was an accidental regression introduced in #252 by removing compilation of
C files without adjusting the `#[use_c_shim_if]` directives. This restores the
compilation of the assembly files and updates the `#[use_c_shim_if]` directives.
1. Avoid undefined references as:
undefined reference to `__modsi3'
undefined reference to `__umodsi3'
2. We can't remove assembly implementations that are not in the list
Add `extend` module to implement conversion from a narrower to a wider
floating-point type.
This implementation is only intended to support *widening* operations.
Module to convert a *narrower* floating-point will be added in the future.
All tests are moved to a separate crate in this repository to enable features by
default. Additionally the test generation is moved to a seprate build script and
simplified to reduce the amount of boilerplate needed per test.
Overall this should still be testing everything, just in a different location!
Here using `"C"` the compiler will use `"aapcs"` or `"aapcs-vfp"`
depending on target configuration.
Of course this translates in a call to `__aeabi_fdiv` / `__aeabi_fmul`
on non-HF targets.
On `eabi` targets with +vfpv2/vfpv3 LLVM generate:
vmov s0, r1
vmov s2, r0
vdiv.f32 s0, s2, s0
vmov r0, s0
bx lr
On `eabihf` targets with +vfpv3-d16/d32/f32 +fp-only-sp LLVM generate:
vdiv.f32 s0, s0, s1
bx lr
That's exactly what We need for [div/mul][s/d]f3vfp.S
* I believe `__gtdf2` erroneously used `f32` instead of `f64`
* Most of these needed `#[arm_aeabi_alias]` to ensure they're correctly called
through the alias
* Some existing aliases were corrected with the right names
First of all aeabi_cdcmp and aeabi_cfcmp are never called LLVM.
Second are little-endian only, so build fail on big-endian targets.
Temporally workaround: exclude these files for big-endian targets.
This commit prepares the build script for a wasm32 target that doesn't use
Emcripten, notably forcing the `mem` feature to get activated and forcibly
ignoring the `c` feature, even if activated, for the wasm32 target.
Although compiler-rt presumably has a more optimized implementation written in
assembly, it appears buggy for whatever reason, causing #173.
For now let's see if integration into rust-lang/rust will work with the
Rust-defined implementation!
