Crates.io | compiler_builtins |
lib.rs | compiler_builtins |
version | |
source | src |
created_at | 2018-11-21 19:13:56.864043 |
updated_at | 2024-11-03 23:36:42.278999 |
description | Compiler intrinsics used by the Rust compiler. Also available for other targets if necessary! |
homepage | https://github.com/rust-lang/compiler-builtins |
repository | https://github.com/rust-lang/compiler-builtins |
max_upload_size | |
id | 98016 |
Cargo.toml error: | TOML parse error at line 30, column 1 | 30 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
compiler-builtins
Porting
compiler-rt
intrinsics to Rust
See rust-lang/rust#35437.
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/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/compiler-builtins"
features = ["c"]
examples/intrinsics.rs
to verify it can be linked on
all targets.== !=
) before bitwise operations (& | ^
), while Rust evaluates the other way.The easiest way to test locally is using Docker. This can be done by running
./ci/run-docker.sh [target]
. If no target is specified, all targets will be
run.
In order to run the full test suite, you will also need the C compiler runtime
to test against, located in a directory called compiler-rt
. This can be
obtained with the following:
curl -L -o rustc-llvm-19.1.tar.gz https://github.com/rust-lang/llvm-project/archive/rustc/19.1-2024-09-17.tar.gz
tar xzf rustc-llvm-19.1.tar.gz --strip-components 1 llvm-project-rustc-19.1-2024-09-17/compiler-rt
Local targets may also be tested with ./ci/run.sh [target]
.
Note that testing may not work on all hosts, in which cases it is acceptable to rely on CI.
These builtins are needed to support 128-bit integers.
These builtins are needed to support f16
and f128
, which are in the process
of being added to Rust.
addtf3.c
comparetf2.c
divtf3.c
extenddftf2.c
extendhfsf2.c
extendhftf2.c
extendsftf2.c
fixtfdi.c
fixtfsi.c
fixtfti.c
fixunstfdi.c
fixunstfsi.c
fixunstfti.c
floatditf.c
floatsitf.c
floattitf.c
floatunditf.c
floatunsitf.c
floatuntitf.c
multf3.c
powitf2.c
subtf3.c
truncdfhf2.c
truncsfhf2.c
trunctfdf2.c
trunctfhf2.c
trunctfsf2.c
These builtins are used by the Hexagon DSP
These builtins are for x87 f80
floating-point numbers that are not supported
by Rust.
These builtins are for IBM "extended double" non-IEEE 128-bit floating-point numbers.
These builtins are for 16-bit brain floating-point numbers that are not supported by Rust.
These builtins involve complex floating-point types 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.
Miscellaneous functionality that is not used by Rust.
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.
Unsupported in any current target: used on old versions of 32-bit iOS with ARMv5.
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.