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.
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.
Compilation on rustc 1.33.0-nightly (c76f3c374 2019-01-18) failed with
```
error: the feature `cfg_target_vendor` has been stable since 1.33.0 and no longer requires an attribute to enable
--> src/lib.rs:19:12
|
19 | #![feature(cfg_target_vendor)]
| ^^^^^^^^^^^^^^^^^
|
```
Removed the attribute to make it compile.
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.
Now that `73884ae` is in some nightly release We can add ledf2vfp/leds2vfp
and so these two functions be aliased to aeabi_fcmple/aeabi_dcmple on soft-float targets.
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
Be sure to do not mix hard-float and soft-float calls.
Disassembled code show exactly this.
So replace add with an explicit call to __addsf3/__adddf3
This seems the root cause of some sporadic failures.
I was able to trigger an issue extending f32::MAX or f32::MIN to a f64.
Issue was not triggered by `testcrate` mainly because f32::MAX/MIN are
not in the list of special values to generate.
This PR fix the issue and improve `testcrate` adding MAX/MIN/MIN_POSITIVE
in the list of special values.