This turns the following backtrace,
```
>> bt
#0 0x0000555555576f73 in __rust_probestack () at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.14/src/probestack.rs:55
Backtrace stopped: Cannot access memory at address 0x7fffff7fedf0
```
To this:
```
>>> bt
#0 0x0000555555574e47 in __rust_probestack ()
#1 0x00005555555595ba in test::main ()
#2 0x00005555555594f3 in std::rt::lang_start::{{closure}} ()
#3 0x0000555555561ae3 in std::panicking::try::do_call ()
#4 0x000055555556595a in __rust_maybe_catch_panic ()
#5 0x000055555555af9b in std::rt::lang_start_internal ()
#6 0x00005555555594d5 in std::rt::lang_start ()
#7 0x000055555555977b in main ()
```
The -Zlower-128bit-ops feature is completely broken, as libcore needs
those lang items to compile with this feature, but they are only
provided by compiler_builtins, which itself depends on libcore.
According to rust-lang/rust#58969 the feature never got finished.
This commit removes the associated lang items and replaces them with
normal unmangled functions, when there is no existing intrinsic. This
makes it easier for alternative codegen backends to implement 128bit
integer support.
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
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.
Looks like LLVM optimizes programs like:
fn foo(a: u8) -> f32 {
2.0f32.powf(a as f32)
}
to actually invoking `ldexpf`, so let's be sure to include bindings so
there's not undefined symbols.
