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 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.
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.
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
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!
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