M-Labs/compiler-builtins-zynq

A modified version of compiler-builtins for zynq, with fast memcpy implementation adapted from newlib.

Go to file

Matt Ickstadt 2a8cca03d8 Fix apt 404s in Docker `apt update` and `apt install` should be in the same Docker RUN statement, otherwise `apt update` will be cached and `apt install` will 404 if a package no longer exists.		2016-11-12 16:08:13 -06:00
.cargo	pass -nostartfiles to the linker	2016-10-07 07:13:55 -05:00
ci	Fix apt 404s in Docker	2016-11-12 16:08:13 -06:00
compiler-rt	Update gcc-rs dependency to 0.3.36	2016-10-16 07:54:59 +02:00
gcc_s	Expand and refactor teting infrastructure	2016-09-28 22:09:55 -07:00
src	Fix a few clippy warnings	2016-10-16 13:53:31 +02:00
.gitignore	initial commit	2016-08-07 15:58:21 -05:00
.gitmodules	switch compiler-rt to rust-lang's fork	2016-10-03 23:26:49 -05:00
.travis.yml	Auto merge of #105 - japaric:mips64, r=japaric	2016-10-19 09:30:10 -07:00
appveyor.yml	Update CI configs	2016-10-14 11:58:40 -07:00
build.rs	add a rustbuild cargo feature for integration with rust-lang/rust	2016-10-10 16:18:18 -05:00
Cargo.toml	Update gcc-rs dependency to 0.3.36	2016-10-16 07:54:59 +02:00
LICENSE.TXT	Correct the license to that of upstream compiler-rt	2016-10-12 17:50:39 +00:00
README.md	mention that 'extern crate compiler_builtins' must be used	2016-10-19 11:25:16 -05:00

README.md

`compiler-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, add this crate somewhere in the dependency graph of the crate you are building:

# Cargo.toml
[dependencies]
compiler_builtins = { git = "https://github.com/rust-lang-nursery/compiler-builtins" }

extern crate compiler_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.

If you've got a C compiler available for your target then while we implement this intrinsic you can temporarily enable a fallback to the actual compiler-rt implementation as well for unimplemented intrinsics:

[dependencies.compiler_builtins]
git = "https://github.com/rust-lang-nursery/compiler-builtins"
features = ["c"]

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

The compiler-builtins crate is dual licensed under both the University of Illinois "BSD-Like" license and the MIT license. As a user of this code you may choose to use it under either license. As a contributor, you agree to allow your code to be used under both.

Full text of the relevant licenses is in LICENSE.TXT.