The tests were using `rug::ln_gamma` as a reference for `libm::lgamma`,
which actually computes the natural logarithm *of the absolute value* of
the Gamma function.
This changes the range of inputs used for the icount-benchmarks of these
functions, which causes false regressions in [1].
[1]: https://github.com/rust-lang/compiler-builtins/actions/runs/21788698368/job/62864230903?pr=1075#step:7:2710.
Fixes: a1a066611dc2 ("Create interfaces for testing against MPFR")
The recent switch in default mangling meant that the check was no longer
working correctly. Resolve this by checking for both legacy- and
v0-mangled core symbols to the extent that this is possible.
The acosh functions were incorrectly returning finite values for some
negative inputs (should be NaN for any `x < 1.0`)
The bug was inherited when originally ported from musl, and this patch
follows their fix for single-precision acoshf in [1].
A similar fix is applied to acosh, though musl still has an incorrect
implementation requiring tests against that basis to be skipped.
[1]: https://git.musl-libc.org/cgit/musl/commit/?id=c4c38e6364323b6d83ba3428464e19987b981d7a
[ added context to message - Trevor ]
In recent nightlies we are hitting errors like the following:
error: an associated constant with this name may be added to the standard library in the future
--> libm/src/math/support/float_traits.rs:248:48
|
248 | const SIGN_MASK: Self::Int = 1 << (Self::BITS - 1);
| ^^^^^^^^^^
...
324 | / float_impl!(
325 | | f32,
326 | | u32,
327 | | i32,
... |
333 | | fmaf32
334 | | );
| |_- in this macro invocation
|
= warning: once this associated item is added to the standard library, the ambiguity may cause an error or change in behavior!
= note: for more information, see issue #48919 <https://github.com/rust-lang/rust/issues/48919>
= note: `-D unstable-name-collisions` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unstable_name_collisions)]`
= note: this error originates in the macro `float_impl` (in Nightly builds, run with -Z macro-backtrace for more info)
help: use the fully qualified path to the associated const
|
248 - const SIGN_MASK: Self::Int = 1 << (Self::BITS - 1);
248 + const SIGN_MASK: Self::Int = 1 << (<f32 as float_traits::Float>::BITS - 1);
|
help: add `#![feature(float_bits_const)]` to the crate attributes to enable `core::f32::<impl f32>::BITS`
--> libm/src/lib.rs:26:1
|
26 + #![feature(float_bits_const)]
|
Using fully qualified syntax is verbose and `BITS` only exists since
recently, so allow this lint instead.
fN::BITS constants for feature float_bits_const
Also enables the feature for compiler_builtins as otherwise this causes a warning and conflicts with the Float extension trait.
---
Implementation for rust-lang/rust#151073
Feature flag: `#![feature(float_bits_const)]`
Note that this is likely to conflict with some extension traits, as it has with compiler builtins. However, assuming correct values for the constants, they are either `u32`, the same type, which should not cause a problem (as shown by enabling the feature for compiler_builtins), or a different type (e.g. `usize`), which should cause a compiler error. Either way this should never change behaviour unless the extension trait implemented an incorrect value.
Also note that it doesn't seem to be possible to put multiple unstable attributes on an item, so `f128::BITS` and `f16::BITS` are gated behind the feature flags for those primitives, rather than `#![feature(float_bits_const)]`
The `fma:` label in dffma.s was being exported as a global symbol
causing a "symbol 'fma' is already defined" error when linking with
libm's `fma` function.
Unfortunately rust-lang/compiler-builtins#682 removed `.global fma` but
didn't address the implicit global export of the label itself.
--- old.txt 2026-01-30 20:31:37.265844316 -0600
+++ new.txt 2026-01-30 20:31:46.531950264 -0600
@@ -1,4 +1,3 @@
-00000000 t fma
00000000 T __hexagon_fmadf4
00000000 T __hexagon_fmadf5
00000000 T __qdsp_fmadf5
This is a PR for thumbv6-none-eabi (bere-metal Armv6k in Thumb mode)
which proposed to be added by
https://github.com/rust-lang/rust/pull/150138.
Armv6k supports atomic instructions, but they are unavailable in Thumb
mode unless Thumb-2 instructions available (v6t2).
Using Thumb interworking (can be used via `#[instruction_set]`) allows
us to use these instructions even from Thumb mode without Thumb-2
instructions, but LLVM does not implement that processing (as of LLVM
21), so this PR implements it in compiler-builtins.
The code around `__sync` builtins is basically copied from
`arm_linux.rs` which uses kernel_user_helpers for atomic implementation.
The atomic implementation is a port of my [atomic-maybe-uninit inline
assembly code].
This PR has been tested on QEMU 10.2.0 using patched compiler-builtins
and core that applied the changes in this PR and
https://github.com/rust-lang/rust/pull/150138 and the [portable-atomic
no-std test suite] (can be run with `./tools/no-std.sh
thumbv6-none-eabi` on that repo) which tests wrappers around
`core::sync::atomic`. (Note that the target-spec used in test sets
max-atomic-width to 32 and atomic_cas to true, unlike the current
https://github.com/rust-lang/rust/pull/150138.) The original
atomic-maybe-uninit implementation has been tested on real Arm hardware.
(Note that Armv6k also supports 64-bit atomic instructions, but they are
skipped here. This is because there is no corresponding code in
`arm_linux.rs` (since the kernel requirements increased in 1.64, it may
be possible to implement 64-bit atomics there as well. see also
https://github.com/taiki-e/portable-atomic/pull/82), the code becomes
more complex than for 32-bit and smaller atomics.)
[atomic-maybe-uninit inline assembly code]: https://github.com/taiki-e/atomic-maybe-uninit/blob/HEAD/src/arch/arm.rs
[portable-atomic no-std test suite]: https://github.com/taiki-e/portable-atomic/tree/HEAD/tests/no-std-qemu
Also enables the feature for compiler_builtins as otherwise
this causes a warning and conflicts with the Float extension trait
Explicitly use Float trait BITS in miri tests to
prevent warnings against upcoming BITS field for floats
This option was used to gate `f16` and `f128` when support across
backends and targets was inconsistent. We now have the rustc builtin cfg
`target_has_reliable{f16,f128}` which has taken over this usecase.
Remove no-f16-f128 since it is now unused and redundant.
Similarly to i686 and X86_64 MinGW targets, Rust needs to provide the
right chkstk symbol for AArch64 to avoid relying on the linker to
provide it.
CC https://github.com/rust-lang/rust/issues/150725
We can't drop the `unsafe` here because it is required at the `libm`
MSRV. Instead, we will need to `allow` the lint.
This reverts commit 96ac3624abc144db930d94504a9c67aad7b949ed.
stdarch subtree update
Subtree update of `stdarch` to 61119062fb.
Created using https://github.com/rust-lang/josh-sync.
r? `@sayantn`
My first josh sync, it lgtm, but let me know if I missed something.
I'm especially looking forward to the amd GPU module, which we want to use for the offload project.
Due to an erroneous overflow threshold, `expm1f` was incorrectly
returning `inf` for inputs in the range `[88.72169, 88.72283]`. This
additionally caused `sinhf` to return `NaN` for inputs in that range.
The bug was ported from the original in musl, which has since been fixed
in [1].
[1]: https://git.musl-libc.org/cgit/musl/commit/?id=964104f9f0e056cf58d9defa0b716d7756f040f6
Avoid using `Ord::clamp` in the `f16`-specific part of the generic
`scalbn`.
It turned out to be redundant anyway, as both callsites follow a pattern
like
```
if n < negative_val {
let foo = (n + positive_val).clamp(negative_val, positive_val);
}
```
and `n < negative_val < 0` implies `n + positive_val < positive_val`.
Fixes: rust-lang/compiler-builtins#1046
Enable `outline-atomics` by default on more AArch64 platforms
The baseline Armv8.0 ISA doesn't have atomics instructions, but in
practice most hardware is at least Armv8.1-A (2014), which includes
single-instruction atomics as part of the LSE feature. As a performance
optimization for these cases, GCC and LLVM have the `-moutline-atomics` flag
to turn atomic operations into calls to symbols like `__aarch64_cas1_acq`.
These can do runtime feature detection and use the LSE instructions if
available, falling back to more portable load-exclusive/store-exclusive
loops.
Since the recent 3b50253b57 ("compiler-builtins: plumb LSE support
for aarch64 on linux") our builtins support this LSE optimization, and
since 6936bb975a ("Dynamically enable LSE for aarch64 rust provided
intrinsics"), std will set the flag as part of its startup code. The first
commit in this PR configures this to work on all platforms built with
`outline-atomics`, not just Linux.
Thus, enable `outline-atomics` by default on Android, OpenBSD, Windows,
and Fuchsia platforms that don't have LSE in the baseline. The feature is
already enabled on Linux. Platform-specific details are included in each
commit message.
The current implementation can still be accessed by setting
`-Ctarget-feature=-outline-atomics`. Setting `-Ctarget-feature=+lse` or
a relevant CPU will use the single-instruction atomics without the call
overhead. https://rust.godbolt.org/z/dsdrzszoe
Link: https://learn.arm.com/learning-paths/servers-and-cloud-computing/lse/intro/
Original Clang outline-atomics benchmarks: https://reviews.llvm.org/D91157#2435844
try-job: aarch64-msvc-*
try-job: arm-android
try-job: dist-android
try-job: dist-aarch64-llvm-mingw
try-job: dist-aarch64-msvc
try-job: dist-various-*
try-job: test-various
Currently the benchmark CI jobs prints multiple pages of paths from the
extracted archive, since `tar` is run with `v`. This is a lot of output
that is usually just noise in CI.
Switch to printing the paths from python instead, limiting to a depth of
three segments (and deduplicating). Removing it completely was an
option, but it's still nice to have a hint about what gets updated.
Jorge hasn't been very involved with these crates for a while (thank you
for getting these super important projects going!). Update the `authors`
field to include, as far as I am aware, everyone who has effectively
maintained `compiler-builtins` at some point in time.
This field is dropped from non-published crates.
