| Age | Commit message (Collapse) | Author | Lines |
|---|
|
LLVM does not currently emit these, but it is being discussed as an
option on platforms where `f32` is not hardware supported. Glibc/libgcc
also has the comparison functions [1] already.
The generic implementations for addition, subtraction, and
multiplication work for f16 without any complications, as do
comparisons, so add them here.
[1]: https://sourceware.org/git/?p=glibc.git;a=commit;h=6ec6c77867af4ddfec7323e0ac6ede89effca852
|
|
Assembly-related configuration was added in 1621c6dbf9eb ("Use
`specialized-div-rem` 1.0.0 for division algorithms") to account for
Cranelift not yet supporting assembly. This hasn't been relevant for a
while, so we no longer need to gate `asm!` behind this configuration.
Thus, remove `cfg(not(feature = "no-asm"))` in places where there is no
generic fallback.
There are other cases, however, where setting the `no-asm` configuration
enables testing of generic version of builtins when there are platform-
specific implementations available; these cases are left unchanged. This
could be improved in the future by exposing both versions for testing
rather than using a configuration and running the entire testsuite
twice.
This is the compiler-builtins portion of
https://github.com/rust-lang/rust/pull/144471.
|
|
Emit `x86_no_sse` in the compiler-builtins (and builtins-test) build
script, and use it to simplify `all(target_arch = "x86",
not(target_fefature = "sse))` configuration.
|
|
Most of these were skipped because of a bug with the platform
implementation, or some kind of crash unwinding. Since the upgrade to
Ubuntu 25.04, these all seem to be resolved with the exception of a bug
in the host `__floatundisf` [1].
[1] https://github.com/rust-lang/compiler-builtins/pull/384#issuecomment-740413334
|
|
Currently we whether or not to build and test `f16` and `f128` support
mostly based on the target triple. This isn't always accurate, however,
since support also varies by backend and the backend version.
Since recently, `rustc` is aware of this with the unstable config option
`target_has_reliable_{f16,f128}`, which better represents when the types
are actually expected to be available and usable. Switch our
compiler-builtins and libm configuration to use this by probing `rustc`
for the target's settings.
A few small `cfg` fixes are needed with this.
|
|
Replace `build.rs` Rust generation with macros, using the unstable
`${concat(...)}`.
Fixes: https://github.com/rust-lang/compiler-builtins/issues/947
|
|
Do the same for `builtins-test-intrinsics`. Mostly this means updating
`extern` to `unsafe extern`, and fixing a few new Clippy lints.
|
|
|
|
These appeared in a later nightly. In compiler-builtins we can apply the
suggestion, but in `libm` we need to ignore them since `fx::from_bits`
is not `const` at the MSRV.
`clippy::uninlined_format_args` also seems to have gotten stricter, so
fix those here.
|
|
Apply the same formatting rules to both `libm` and `compiler-builtins`.
|
|
The repo will soon have `libm` as a top-level crate, so make it clear
that this is only the test crate for `compiler-builtins`.
|
