Create a crate that handles pulling from and pushing to rust-lang/rust.
This can be invoked with the following:
$ cargo run -p josh-sync -- rustc-pull
$ RUSTC_GIT=/path/to/rust/checkout cargo run -p josh-sync -- rustc-push <username>
The submodule was causing issues in rust-lang/rust, so eliminiate it
here. `build-musl` is also removed from `libm-test`'s default features
so the crate doesn't need to be built by default.
compiler-builtins has a symlink to the `libm` source directory so the
two crates can share files but still act as two separate crates. This
causes problems with some sysroot-related tooling, however, since
directory symlinks seem to not be supported.
The reason this was a symlink in the first place is that there isn't an
easy for Cargo to publish two crates that share source (building works
fine but publishing rejects `include`d files from parent directories, as
well as nested package roots). However, after the switch to a subtree,
we no longer need to publish compiler-builtins; this means that we can
eliminate the link and just use `#[path]`.
Similarly, the LICENSE file was symlinked so it could live in the
repository root but be included in the package. This is also removed as
it caused problems with the dist job (error from bootstrap's
`tarball.rs`, "generated a symlink in a tarball").
If we need to publish compiler-builtins again for any reason, it would
be easy to revert these changes in a preprocess step.
`binop_common` emits a `SKIP` that is intended to apply only to
`copysign`, but is instead applying to all binary operators. Correct the
general case but leave the currently-failing `maximum_num` tests as a
FIXME, to be resolved separately in [1].
Also simplify skip logic and NaN checking, and add a few more `copysign`
checks.
[1]: https://github.com/rust-lang/compiler-builtins/pull/939
iai-callgrind now correctly exits with error if regressions were found
[1], so we no longer need to check for regressions manually. Remove this
check and instead exit based on the exit status of the benchmark run.
[1] https://github.com/iai-callgrind/iai-callgrind/issues/337
We don't actually need this for now, but eventually it would be nice to
run icount benchmarks on multiple targets. Start tagging artifact names
with the architecture, and allow passing `--tag` to `ci-util.py` in
order to retrieve the correct one.
Currently we run logspace tests for extensive tests, but there isn't any
reason we couldn't also run more kinds of tests more extensively (e.g.
more edge cases, combine edge cases with logspace for multi-input
functions, etc). As a first step toward making this possible, make
`extensive` a new field in `CheckCtx`, and rename `QuickSpaced` to
`Spaced`.
We may soon want to use some new nightly features in `compiler-builtins`
and `libm`, specifically `cfg_target_has_reliable_f16_f128` which was
added in the past few weeks. This will mean we need a newer toolchain
for benchmarks to continue building.
Bump to the current latest nightly so we are not blocked on this down
the line.
When multiple merges to `master` happen before a CI run completes, the
in-progress job is getting canceled. Fix this by using the commit sha
for the group key if a pull request number is not available, rather than
`github.ref` (which is always `refs/head/master` after merge). This
should prevent jobs running on previous commits from getting cancelled,
while still ensuring there is only ever one active run per pull request.
These are now provided by `compiler-builtins`, so there is no need to
also build the C versions. This was detected by checking for duplicate
symbols and not excluding weak symbols (like CI currently does).
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.
