Add `extend` module to implement conversion from a narrower to a wider
floating-point type.
This implementation is only intended to support *widening* operations.
Module to convert a *narrower* floating-point will be added in the future.
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!
Here using `"C"` the compiler will use `"aapcs"` or `"aapcs-vfp"`
depending on target configuration.
Of course this translates in a call to `__aeabi_fdiv` / `__aeabi_fmul`
on non-HF targets.
On `eabi` targets with +vfpv2/vfpv3 LLVM generate:
vmov s0, r1
vmov s2, r0
vdiv.f32 s0, s2, s0
vmov r0, s0
bx lr
On `eabihf` targets with +vfpv3-d16/d32/f32 +fp-only-sp LLVM generate:
vdiv.f32 s0, s0, s1
bx lr
That's exactly what We need for [div/mul][s/d]f3vfp.S
* I believe `__gtdf2` erroneously used `f32` instead of `f64`
* Most of these needed `#[arm_aeabi_alias]` to ensure they're correctly called
through the alias
* Some existing aliases were corrected with the right names
Note that this changes semantics:
pub extern "C" fn __eqsf2(a: f32, b: f32) -> bool {
cmp(a, b).to_le_abi() != 0
}
is not the same as
pub extern "C" fn __eqsf2(a: f32, b: f32) -> i32 {
cmp(a, b).to_le_abi()
}
However, compiler-rt does the latter, so this is actually
an improvement.
Use the "volatile" option and the "memory" clobber on inline asm that does
things like return directly, to reduce the chances of compilers rearranging
the code.
This commit prepares the build script for a wasm32 target that doesn't use
Emcripten, notably forcing the `mem` feature to get activated and forcibly
ignoring the `c` feature, even if activated, for the wasm32 target.
It looks like the old `__rust_probestack` routine is incompatible with newer
linux kernels. My best guess for this is that the kernel's auto-growth logic is
failing to trigger, causing what looks like a legitimate segfault to get
delivered. My best guess for why *that's* happening is that the faulting address
is below `%rsp`, whereas previously all faulting stack addresses were above
`%rsp`. The probestack routine does not modify `%rsp` as it's probing the stack,
and presumably newer kernels are interpreting this as a legitimate violation.
This commit tweaks the probestack routine to instead update `%rsp` incrementally
as probing happens. The ABI of the function, however, requires that `%rsp`
isn't changed as part of the function so it's restored at the end to the
previous value.
Although compiler-rt presumably has a more optimized implementation written in
assembly, it appears buggy for whatever reason, causing #173.
For now let's see if integration into rust-lang/rust will work with the
Rust-defined implementation!
* 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)`
This is an attempt to tidy up the definition of intrinsics by making them more
rust-like at the definition site and using traits instead of macros for the
definition. Additionally the helper macro, `intrinsics!`, now fills in a
definition for #[cfg]'d off intrinsics when compiling with C code
on ARMv7-M processors, divmoddi4 was calling mulodi4 and mulodi4 was calling
divmoddi4 leading to infinite recursion. This commit breaks the cycle by using
wrapping multiplication in divmoddi4.
fixes#145
- multi3: there's no aeabi equivalent
- divmod{s,d}i4: these are directly called by __aeabi_{l,i}divmod
- add{s,d}f3: required by the C sub{s,d}f3 implementation
but make sure they also use the AAPCS calling convention
also, on ARM, inline(always) the actual implementation of the intrinsics so we
end with code like this:
```
00000000 <__aeabi_dadd>:
(implementation here)
```
instead of "trampolines" like this:
```
00000000 <__aeabi_dadd>:
(shuffle registers)
(call __adddf3)
00000000 <__adddf3>:
(implementation here)
```
closes#116
Two reasons:
* the C versions __divti3 and __modti3 are apparently broken,
at least when used in quickcheck. They change their own arguments.
* compiler_rt's support for mips is disabled already on clang [1].
Its desireable to support working "cargo test" on that compiler
as well, and not greet the tester with linker errors.
[1]: http://llvm.org/viewvc/llvm-project?view=revision&revision=224488