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.
Out-of-tree testing is broken with the most recent update from
rust-lang/rust because it makes `compiler-builtins` depend on `core` by
path, which isn't usually available. In order to enable testing outside
of rust-lang/rust, add a new crate `builtins-shim` that uses the same
source as `compiler-builtins` but drops the `core` dependency. This has
replaced `compiler-builtins` as the workspace member and entrypoint for
tests.
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 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.
`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.
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
This crate doesn't need to be a default member since it requires the
opposite settings from everything else. Exclude it from the workspace
and run it only when explicitly requested.
This also makes `cargo t --no-default-features` work without additional
qualifiers. `--no-default-features` still needs to be passed to ensure
`#![compiler_builtins]` does not get set.
compiler-builtins needs doctests disabled in order for everything to
work correctly, since this causes an error running rustdoc that is
unrelated to features (our `compiler_builtins` is getting into the crate
graph before that from the sysroot, but `#![compiler_builtins]` is not
set).
We can also remove `test = false` and `doctest = false` in
`builtins-test` since these no longer cause issues. This is unlikely to
be used but it is better to not quietly skip if anything ever gets added
by accident.
