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 commit fixes a bug accidentally introduced in #285 where some
lingering references remained to `#[cfg(thumbv6m)]` but this, since the
historical revert, was renamed to `#[cfg(thumb_1)]`. This caused on the
thumbv6m platform for the intrinsics to be accidentally omitted because
the build script didn't actually compile them but the Rust code thought
the C code was in use.
After correcting the `#[cfg]` statements the CI configuration for the
`thumb*` family of targets was all updated. The support for xargo
testing was removed from `run.sh` since it had long since bitrotted, and
the script was updated to simply build the intrinsics example to attempt
to link for each of these targets. This in turn exposed the bug locally
and allowed to confirm a fix once the `#[cfg]` statements were
corrected.
cc rust-lang/rust#60782
Looks like our tests weren't quite testing compiler-builtins when it was
compiled with unmangled symbols, so update the tests to catch this and
then fix the compilation of the `__clzsi2` intrinsic to use the C
version if it's compiled.
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!
* Don't run `intrinsics` tests on thumb
* Disable `compiler_builtins` attribute on `feature = "gen-tests"`
* Disable mangling on `feature = "gen-tests"` instead of `cfg(test)`
- add #[no_mangle] to the panic_fmt lang item to adjust to changes in
the visibility algorithm
- adjust to changes in the layout of Cargo's target directory
- use a newer Xargo to reduce the build time of the sysroot (only core
is compiled as part of the sysroot now)
due to how Cargo works, the rustc-cfg in build.rs was picking our target
specifications rather than the one the user meant to use. Placing our
target files in any place other than the root of the Cargo project
avoids the issue.
Alex Crichton
Paolo Teti
Jorge Aparicio
Jorge Aparicio
bors