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
This was originally attempted at [1], but the numbers seemed to indicate
that tests weren't being run or counted completely. That issue appears
to be resolved, so add benchmarks for Aarch64.
[1]: https://github.com/rust-lang/compiler-builtins/pull/930
`iai-callgrind` was renamed to `gungraun` and had a new release. Update
everything to match.
There shouldn't be any changes to observable behavior here.
Currently, a failure in `ci-util.py` does not cause the job to fail
because the pipe eats the failure status . Set pipefail to fix this.
Fixes: ff2cc0e38e3e ("ci: Don't print output twice in `ci-util`")
Rather than setting an environment variable in the workflow job based on
whether or not the environment is non-MinGW Windows, we can just check
this in the ci script.
This was originally added in b0f19660f0 ("Add tests for UNC paths on
windows builds") and its followup commits.
This CI workflow will run the https://github.com/rust-lang/josh-sync
tool on Mondays and Thursdays. It will try to do a pull (sync stdarch
changes from rust-lang/rust into this repository). When it runs, three
things can happen:
- There are no rustc changes to be pulled, the bot does nothing.
- There are some new changes to be pulled. In that case, the bot will
either open or update an existing PR titled "Rustc pull update" on this
repository with the changes. After the PR is merged, we should ideally
do the opposite sync (push) manually.
- The pull fails (usually because of a merge conflict), or the bot
determines that a pull PR has been opened for more than a week without
being merged. In that case, it will post a ping to
https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/compiler-builtins.20subtree.20sync.20automation/with/528482375.
The `rustc` probe done in our build scripts needs to pass `--target` to
get the correct configuration, which usually comes from the `TARGET`
environment variable. However, for targets specified via a `target.json`
file, `TARGET` gets set to the file name without an extension or path.
`rustc` will check a search path to attempt to locate the file, but this
is likely to fail since the directory where Cargo invokes build scripts
(and hence where those scripts invoke `rustc`) might not have any
relation to the JSON spec file.
Resolve this for now by leaving `f16` and `f128` disabled if the `rustc`
command fails. Result of the discussion at CARGO-14208 may eventually
provide a better solution.
A CI test is also added since custom JSON files are an edge case that
could fail in other ways. I verified this fails without the fix here.
The JSON file is the output for `thumbv7em-none-eabi`, just renamed so
`rustc` doesn't identify it.
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.
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.
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.
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.
Update `run.sh` to start testing `libm`. Currently this is somewhat
inefficient because `builtins-test` gets run more than once on some
targets; this can be cleaned up later.
Apply a handful of changes to reduce the diff between the two:
* Cancel running jobs on new pushes
* Enable log color and backtraces
* Add timeouts
* Specify CI runner versions
* Add an armv7 job
* Replace the name NO_STD with BUILD_ONLY
* Update the extension to the canonical .yaml
* Set AR_ and CC_ environments in docker
* Install requirements to build MPFR
The current setup has the `Cargo.toml` for `compiler-builtins` at the
repository root, which means all support crates and other files are
located within the package root. This works for now but is not the
cleanest setup since files that should or shouldn't be included in the
package need to be configured in `Cargo.toml`. If we eventually merge
`libm` development into this repository, it would be nice to make this
separation more straightforward.
Begin cleaning things up by moving the crate source to a new
`compiler-builtins` directory and adding a virtual manifest. For now the
`libm` submodule is also moved, but in the future it can likely move
back to the top level (ideally `compiler-builtins/src` would contain a
symlink to `libm/src/math`, but unfortunately it seems like Cargo does
not like something about the submodule + symlink combination).
The fix to this issue was synced in [1] so we should no longer need to
keep aarch64 pinned.
This reverts commit b2bcfc838e2a4b72fa62b333e3eb91f250aa4539.
[1]: https://github.com/rust-lang/rust/pull/137661
