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
use AAPCS calling convention on all aeabi intrinsics
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
cc #66
r? @alexcrichton
cc @mattico
- 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
i128 intrinsics
Adds i128 intrinsics.
Note that this PR doesn't do float intrinsics, due to the missing presence of macros, those are however still required in order for rustc to switch to this crate.
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
mul.rs: use wrapping_mul to avoid infinite recursion
rustc in debug mode with a plain multiplication will call @llvm.umul.with.overflow.* which may call the builtin resulting in infinite recursion.
Fixes#127.
Cc @nezza this should be the fix you can try. Note I made this patch in github's web Ui so it's completely untested.
CI: use a recent nightly
- add #[no_mangle] to the panic_fmt lang item to adjust to changes in
the visibility algorithm
- adjust to changes in the layout of Cargo's target directory
- use a newer Xargo to reduce the build time of the sysroot (only core
is compiled as part of the sysroot now)
r? @alexcrichton
- add #[no_mangle] to the panic_fmt lang item to adjust to changes in
the visibility algorithm
- adjust to changes in the layout of Cargo's target directory
- use a newer Xargo to reduce the build time of the sysroot (only core
is compiled as part of the sysroot now)
