M-Labs/compiler-builtins-zynq

Alex Crichton 8e161a791a Expand and refactor teting infrastructure

This commit moves over most of the testing infrastructure to in-tree docker
images that are all dispatched to from Travis (no other test configuration).
This allows versioning modifications to the test infrastructure as well as the
code itself. Additionally separate docker images allows for easy modification of
one without worrying about tampering of others as well as easy addition of new
targets by simply adding a new `Dockerfile`.

Additionally this commit bundles the master version of the `compiler-rt` source
repository from `llvm-mirror/compiler-rt` to test against. The compiler-rt
library itself is compiled as a `cdylib` which is then dynamically located at
runtime and we look for symbols in. There's a few hoops here, but they currently
get the job done.

All tests now execute against both gcc_s and compiler-rt, and this
testing strategy is now all hidden behind a macro as well (refactoring
all existing tests along the way).

2016-09-28 22:09:55 -07:00

10 KiB

Raw Blame History

`rustc-builtins`

[WIP] Porting compiler-rt intrinsics to Rust

See rust-lang/rust#35437.

When and how to use this crate?

If you are working with a target that doesn't have binary releases of std available via rustup (this probably means you are building the core crate yourself) and need compiler-rt intrinsics (i.e. you are probably getting linker errors when building an executable: undefined reference to __aeabi_memcpy), you can use this crate to get those intrinsics and solve the linker errors. To do that, simply add this crate as a Cargo dependency (it doesn't matter where in the dependency graph this crate ends up, as long as it's there):

[dependencies]
rustc-builtins = { git = "https://github.com/japaric/rustc-builtins" }

If you still get an "undefined reference to $INTRINSIC" error after that change, that means that we haven't ported $INTRINSIC to Rust yet! Please open an issue with the name of the intrinsic and the LLVM triple (e.g. thumbv7m-none-eabi) of the target you are using. That way we can prioritize porting that particular intrinsic.

Contributing

Pick one or more intrinsics from the [pending list][#progress].
Fork this repository
Port the intrinsic(s) and their corresponding unit tests from their C implementation to Rust.
Send a Pull Request (PR)
Once the PR passes our extensive testing infrastructure, we'll merge it!
Celebrate 🎉

Porting Reminders

Rust and C have slightly different operator precedence. C evaluates comparisons (== !=) before bitwise operations (& | ^), while Rust evaluates the other way.
C assumes wrapping operations everywhere. Rust panics on overflow when in debug mode. Consider using the Wrapping type or the explicit wrapping_* functions where applicable.
Note C implicit casts, especially integer promotion. Rust is much more explicit about casting, so be sure that any cast which affects the output is ported to the Rust implementation.
Rust has many functions for integer or floating point manipulation in the standard library. Consider using one of these functions rather than porting a new one.

Progress

These builtins are needed to support 128-bit integers, which are in the process of being added to Rust.

ashlti3.c
ashrti3.c
divti3.c
fixdfti.c
fixsfti.c
fixunsdfti.c
fixunssfti.c
floattidf.c
floattisf.c
floatuntidf.c
floatuntisf.c
lshrti3.c
modti3.c
muloti4.c
multi3.c
udivmodti4.c
udivti3.c
umodti3.c

Unimplemented functions

These builtins involve floating-point types ("f128", "f80" and complex numbers) that are not supported by Rust.

These builtins are never called by LLVM.

Rust only exposes atomic types on platforms that support them, and therefore does not need to fall back to software implementations.

~~arm/sync_fetch_and_add_4.S~~
~~arm/sync_fetch_and_add_8.S~~
~~arm/sync_fetch_and_and_4.S~~
~~arm/sync_fetch_and_and_8.S~~
~~arm/sync_fetch_and_max_4.S~~
~~arm/sync_fetch_and_max_8.S~~
~~arm/sync_fetch_and_min_4.S~~
~~arm/sync_fetch_and_min_8.S~~
~~arm/sync_fetch_and_nand_4.S~~
~~arm/sync_fetch_and_nand_8.S~~
~~arm/sync_fetch_and_or_4.S~~
~~arm/sync_fetch_and_or_8.S~~
~~arm/sync_fetch_and_sub_4.S~~
~~arm/sync_fetch_and_sub_8.S~~
~~arm/sync_fetch_and_umax_4.S~~
~~arm/sync_fetch_and_umax_8.S~~
~~arm/sync_fetch_and_umin_4.S~~
~~arm/sync_fetch_and_umin_8.S~~
~~arm/sync_fetch_and_xor_4.S~~
~~arm/sync_fetch_and_xor_8.S~~
~~arm/sync_synchronize.S~~
~~atomic.c~~
~~atomic_flag_clear.c~~
~~atomic_flag_clear_explicit.c~~
~~atomic_flag_test_and_set.c~~
~~atomic_flag_test_and_set_explicit.c~~
~~atomic_signal_fence.c~~
~~atomic_thread_fence.c~~

Miscellaneous functionality that is not used by Rust.

~~apple_versioning.c~~
~~clear_cache.c~~
~~emutls.c~~
~~enable_execute_stack.c~~
~~eprintf.c~~
~~gcc_personality_v0.c~~
~~trampoline_setup.c~~

Floating-point implementations of builtins that are only called from soft-float code. It would be better to simply use the generic soft-float versions in this case.

~~i386/floatdidf.S~~
~~i386/floatdisf.S~~
~~i386/floatundidf.S~~
~~i386/floatundisf.S~~
~~x86_64/floatundidf.S~~
~~x86_64/floatundisf.S~~
~~x86_64/floatdidf.c~~
~~x86_64/floatdisf.c~~

License

Licensed under either of

Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.