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 ()
```
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.
It seems that the intrinsics that were generated for the functions in
example/intrinsics.rs where different implementations were given for
thumb6m-none-eabi target, have now been implemented in Rust so
configuration is not needed anymore.
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.
Dan Aloni
Alex Crichton
Ralf Jung
Goirad
John Kåre Alsaker
Hugues de Valon