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.
