As seen at [1], LLVM uses `long long` on LLP64 (to get a 64-bit integer
matching pointer size) and `long` on everything else, with exceptions
for AArch64 and AVR. Our current logic always uses an `i32`. This
happens to work because LLVM uses 32-bit instructions to check the
output on x86-64, but the GCC checks the full 64-bit register so garbage
in the upper half leads to incorrect results.
Update our return type to be `isize`, with exceptions for AArch64 and
AVR.
Fixes: https://github.com/rust-lang/compiler-builtins/issues/919
[1]: 0cf3c437c1/compiler-rt/lib/builtins/fp_compare_impl.inc (L11-L27)
These were deleted during refactoring in 0a2dc5d9 ("Combine the source
files for more generic implementations") but got added back by accident
in 54bac411 ("refactor: Move the libm crate to a subdirectory"). Remove
them again here.
The `feature_detect` module is currently being built on all targets, but
the use of `AtomicU32` causes a problem if atomics are not available
(such as with `bpfel-unknown-none`). Gate this module behind
`target_has_atomic = "ptr"`.
The below now completes successfully:
cargo build -p compiler_builtins --target=bpfel-unknown-none -Z build-std=core
Fixes: https://github.com/rust-lang/compiler-builtins/issues/908
Get performance closer to the glibc implementations by adding assembly
fma routines, with runtime feature detection so they are used even if
not compiled with `+fma` (as the distributed standard library is often
not). Glibc uses ifuncs, this implementation stores a function pointer
in an atomic.
Results of CPU flags are also cached in order to avoid repeating the
startup time in calls to different functions. The feature detection code
is a slightly simplified version of `std-detect`.
Musl sources were used as a reference [1].
Fixes: https://github.com/rust-lang/rust/issues/140452 once synced
[1]: c47ad25ea3/src/math/x32/fma.c
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.
Edition 2024 requires that we avoid this. There is a lot of code that
will need to be adjusted, so start the process here with a warning that
will show up in CI.
It would be nice to reuse some of the macro structure for internal
functions, like `rem_pio2`. To facilitate this, add a `public` field and
make it available in the macro's API.
The published crates fail to build with an edition less than 2024
because they are packaged with `resolver = "3"`, which is a 2024-only
option. Revert back to resolver v2 to drop this requirement.
Fixes: https://github.com/rust-lang/compiler-builtins/issues/883
`compiler-builtins` uses `public-test-deps`, `libm` uses
`unstable-public-internals`. Consolidate these under the `libm` name.
Once compiler-builtins is no longer published, this feature can probably
be dropped.
Also switch to `dep:` syntax for features that enable dependencies.
compiler-builtins currently wouldn't publish correctly because of a
relative path to `libm` that doesn't get included in the package. Fix
this by simlinking `libm` to within the `compiler-builtins` directory.
Also symlink LICENSE.txt which lets us drop the `include` array in
Cargo.toml. LICENSE.txt and compiler-rt were not being included anyway,
since Cargo silently drops items that are not within the crate
directory.
In order to disambiguate things now that libm is part of the
compiler-builtins repository, do the following:
* Mention libm in LICENSE.txt
* Clarify the default license for crates other than libm and
compiler-builtins
* Add an explicit license field to Cargo.toml for all other crates
Many contributions to compiler-builtins don't have any need to touch
libm, and could get by with the few minutes of CI for compiler-builtins
rather than the ~30 minutes for libm. We already have some scripts that
handle changed file detection, so expand its use to skip libm CI if it
doesn't need to run.
