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.
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.
Possible workaround for
https://github.com/rust-lang/compiler-builtins/pull/976#issuecomment-3085530354
Inline assembly in the body of a function currently causes the compiler
to consider that function possibly unwinding, even if said asm
originated from inlining an `extern "C"` function. This patch wraps the
problematic callsite with `#[inline(never)]`.
Silence the approximate constant lint because it is noisy and not always
correct. `single_component_path_imports` is also not accurate when built
as part of `compiler-builtins`, so that needs to be `allow`ed as well.
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
Update the last remaining image.
For this to work, the `QEMU_CPU=POWER8` configuration needed to be
dropped to avoid a new SIGILL. Doing some debugging locally, the crash
comes from an `extswsli` (per `powerpc:common64` in gdb-multiarch) in
the `ld64.so` available with PowerPC, which qemu rejects when set to
power8. Testing a build with `+crt-static` hits the same issue at a
`maddld` in `__libc_start_main_impl`.
Rust isn't needed to reproduce this:
$ cat a.c
#include <stdio.h>
int main() {
printf("Hello, world!\n");
}
$ powerpc64le-linux-gnu-gcc a.c
$ QEMU_CPU=power8 QEMU_LD_PREFIX=/usr/powerpc64le-linux-gnu/ ./a.out
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
Illegal instruction
So the cross toolchain provided by Debian must have a power9 baseline
rather than rustc's power8. Alternatively, qemu may be incorrectly
rejecting these instructions (I can't find a source on whether or not
they should be available for power8). Testing instead with the `-musl`
toolchain and ppc linker from musl.cc works correctly.
In any case, things work with the default qemu config so it seems fine
to drop. The env was originally added in 5d164a4edafb ("fix the
powerpc64le target") but whatever the problem was there appears to no
longer be relevant.
We pretty often get at least one job failed because of failure to pull
the musl git repo. Switch this to the unofficial mirror [1] which should
be more reliable.
Link: https://github.com/kraj/musl [1]
This includes a qemu update from 8.2.2 to 9.2.1 which should hopefully
fix some bugs we have encountered.
PowerPC64LE is skipped for now because the new version seems to cause a
number of new SIGILLs.
This alias was added in 9897bfb8a ("Fix memset arguments for MSP430
target"), which predates `core::ffi`. Now that it exists we can just use
`core::ffi::c_int`.
```text
warning: function `f32_to_bits` is never used
--> libm/src/math/support/float_traits.rs:367:14
|
367 | pub const fn f32_to_bits(x: f32) -> u32 {
| ^^^^^^^^^^^
|
= note: `#[warn(dead_code)]` on by default
warning: function `f64_to_bits` is never used
--> libm/src/math/support/float_traits.rs:381:14
|
381 | pub const fn f64_to_bits(x: f64) -> u64 {
| ^^^^^^^^^^^
warning: `libm` (lib) generated 2 warnings
```
This is a false positive, see RUST-144060.
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.
Disable docs for `compiler-builtins` and `sysroot`
Bootstrap already had a manual doc filter for the `sysroot` crate, but
other library crates keep themselves out of the public docs by setting
`[lib] doc = false` in their manifest. This seems like a better solution
to hide `compiler-builtins` docs, and removes the `sysroot` hack too.
Fixesrust-lang/rust#143215 (after backport)
```@rustbot``` label beta-nominated
Bootstrap already had a manual doc filter for the `sysroot` crate, but
other library crates keep themselves out of the public docs by setting
`[lib] doc = false` in their manifest. This seems like a better solution
to hide `compiler-builtins` docs, and removes the `sysroot` hack too.
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.
8521530f4938 ("Fix __divsi3 and __udivsi3 on thumbv6m targets") removed
tests that use these `thumb*-linux` target files in favor of tests that
use the `thumb*-none` targets, which are available via Rustup. The JSON
files haven't been used since then and are outdated, so remove them.
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.
`i256` and `u256`
- operators now use the same overflow convention as primitives
- implement `<<` and `-` (previously just `>>` and `+`)
- implement `Ord` correctly (the previous `PartialOrd` was broken)
- correct `i256::SIGNED` to `true`
The `Int`-trait is extended with `trailing_zeros`, `carrying_add`, and
`borrowing_sub`.
Often our short summaries will pick up a Bors "Auto merge of #xxxx ...`
commit message. Replace these with something like `rust-lang/rust#1234`
to avoid broken links when going between repositories.
Rather than re-opening the archive file for each check, add a wrapper
that keeps the data in memory. Additionally, collect the `--target`
argument so it can be used within this crate.
This PR adds a minimal `triagebot.toml` config to make contributions to
this repository respect upstream rust-lang/rust conventions and avoid
issues when syncing this subtree.
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.
