-
Notifications
You must be signed in to change notification settings - Fork 13.6k
compiler-builtins subtree update #144974
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
tgross35
wants to merge
24
commits into
rust-lang:master
Choose a base branch
from
tgross35:update-builtins
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
compiler-builtins subtree update #144974
+464
−533
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We are getting warnings in CI about unsupported features. There isn't any reason to use stable rustfmt so switch the channel here.
We now have access to native runners, so make use of them for these architectures. The existing ppc64le Docker job is kept for now.
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.
Wasm support has since been released, so we no longer need to depend on a git version of `object`.
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]
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.
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] rust-lang/compiler-builtins#384 (comment)
The LLVM issue was resolved a while ago, these should no longer be a problem.
The fix has since made it to nightly, so the skips here can be removed.
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.
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.
Possible workaround for rust-lang/compiler-builtins#976 (comment) 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)]`.
Fixes: rust-lang/compiler-builtins#837 The assembly is based on - https://github.com/NetBSD/src/blob/20433927938987dd64c8f6aa46904b7aca3fa39e/lib/libm/arch/i387/s_floor.S - https://github.com/NetBSD/src/blob/20433927938987dd64c8f6aa46904b7aca3fa39e/lib/libm/arch/i387/s_ceil.S Which both state /* * Written by J.T. Conklin <jtc@NetBSD.org>. * Public domain. */ Which I believe means we're good in terms of licensing.
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 rust-lang#144471.
So there will no longer be the need to close and reopen sync PRs in order for CI to run.
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.
Replace the current system with something that is more structured and will also catch unknown directives.
Use `tee` rather than printing to both stdout and stderr.
Introduce a new directive `ci: test-libm` to ensure tests run.
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`")
Currently, attributes for `no-panic` are gated behind both the `test` config and `assert_no_panic`, because `no-panic` is a dev dependency (so only available with test configuration). However, we only emit `assert_no_panic` when the test config is also set anyway, so there isn't any need to gate on both. Replace gates on `all(test, assert_no_panic)` with only `assert_no_panic`. This is simpler, and also has the benefit that attempting to check for panics without `--test` errors.
Currently we run the `rustc` from the `RUSTC` environment variable to figure out whether or not to enable `f16` and `f128`, based on the `target_has_reliable_{f16,f128}` config. However, this does not know about the codegen backend used, and the backend isn't trivial to check in a build script (usually it gets set via `RUSTFLAGS`). It turns out we don't actually need to run `rustc` here: Cargo unconditionally emits all config from the relevant compiler as `CARGO_CFG_*` variables, regardless of whether or not they are known options. Switch to checking these for setting config rather than invoking `rustc`. As an added advantage, this will work with target.json files without any special handling. Fixes: ed17b95715dd ("Use the compiler to determine whether or not to enable `f16` and `f128`")
|
@bors r+ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-compiler-builtins
Area: compiler-builtins (https://github.com/rust-lang/compiler-builtins)
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Subtree update of
compiler-builtins
to rust-lang/compiler-builtins@87a66ec.Created using https://github.com/rust-lang/josh-sync.
r? @ghost