| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Make target pointer width in target json an integer
r? Noratrieb
cc `@RalfJung` (https://github.com/rust-lang/rust/pull/142352/files#r2230380120)
try-job: x86_64-rust-for-linux
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: d36f964125163c2e698de5559efefb8217b8b7f0
Filtered ref: 92461731ae79cfe5044e4826160665b77c0363a2
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
This updates the rust-version file to d36f964125163c2e698de5559efefb8217b8b7f0.
|
|
|
|
Extend the <target>.optimized-compiler-builtins bootstrap option to accept a
path to a prebuilt compiler-rt builtins library, and update compiler-builtins
to enable optimized builtins without building compiler-rt builtins.
|
|
|
|
LLVM does not currently emit these, but it is being discussed as an
option on platforms where `f32` is not hardware supported. Glibc/libgcc
also has the comparison functions [1] already.
The generic implementations for addition, subtraction, and
multiplication work for f16 without any complications, as do
comparisons, so add them here.
[1]: https://sourceware.org/git/?p=glibc.git;a=commit;h=6ec6c77867af4ddfec7323e0ac6ede89effca852
|
|
Like `__real@`, and `__xmm@`, Windows can emit duplicate `__ymm@`
symbols for constants.
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: ffb9d94dcf4ade0d534842be3672d5e9f47e1333
Filtered ref: 2f31646593733abae36e4c05b5a54acfb9f1f6bc
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
This updates the rust-version file to ffb9d94dcf4ade0d534842be3672d5e9f47e1333.
|
|
compiler-builtins subtree update
Subtree update of `compiler-builtins` to https://github.com/rust-lang/compiler-builtins/commit/87a66ec9699e5ddf2c660277b8078099efd01311.
Created using https://github.com/rust-lang/josh-sync.
r? ``@ghost``
|
|
This target is currently build-only. Switch to the windows-11-arm
runner, which allows us to start running tests.
|
|
i128/u128 haven't flagged `improper_ctypes` for a while, and this just
made it to stable [1]. Remove the `allow`s as they are no longer needed.
[1]: https://blog.rust-lang.org/2025/08/07/Rust-1.89.0/#i128-and-u128-in-extern-c-functions
|
|
Since [1], our object files may now contain a GDB script section. These
symbols wind up with multiple instances in the archive but are weak, so
we can safely ignore them in our duplicates check.
This resolves the current CI failures.
[1]: https://github.com/rust-lang/rust/pull/143679
|
|
Currently `SymInfo` stores a `Section`, which is just an index:
SymInfo {
section: Section(
SectionIndex(
539,
),
),
...
},
Look up and store the section name instead if possible, with a fallback
to the `Section` debug printing. This makes output more clear and will
allow us to filter by section name.
|
|
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`")
|
|
Add dynamic support for aarch64 LSE atomic ops on linux targets
when optimized-compiler-builtins is not enabled.
A hook, __enable_rust_lse, is provided for the runtime to enable
them if available. A future patch will use this to enable them
if available.
The resulting asm should exactly match that of LLVM's compiler-rt
builtins, though the symbol naming for the support function and
global does not.
|
|
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, 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`")
|
|
Introduce a new directive `ci: test-libm` to ensure tests run.
|
|
|
|
Use `tee` rather than printing to both stdout and stderr.
|
|
Replace the current system with something that is more structured and
will also catch unknown directives.
|
|
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.
|
|
|
|
So there will no longer be the need to close and reopen sync PRs in
order for CI to run.
|
|
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.
|
|
Fixes: https://github.com/rust-lang/compiler-builtins/issues/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.
|
|
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.
|
|
The fix has since made it to nightly, so the skips here can be removed.
|
|
The LLVM issue was resolved a while ago, these should no longer be a
problem.
|
|
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]
|
|
Wasm support has since been released, so we no longer need to depend on
a git version of `object`.
|
|
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.
|
|
We now have access to native runners, so make use of them for these
architectures. The existing ppc64le Docker job is kept for now.
|
|
We are getting warnings in CI about unsupported features. There isn't
any reason to use stable rustfmt so switch the channel here.
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: 82310651b93a594a3fd69015e1562186a080d94c
Filtered ref: e13c0be8f13737c64082b89ce834546079767ac4
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
This updates the rust-version file to 82310651b93a594a3fd69015e1562186a080d94c.
|
|
Fix the return type of `memcmp` and `bcmp` builtin functions on targets
with a `c_int` other than `i32`.
Linked issue: https://github.com/rust-lang/rust/issues/144076
|
|
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`.
|
|
Match the new CI-created PRs:
https://github.com/rust-lang/compiler-builtins/pull/974.
|
|
```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.
|
|
Pick up the latest version of iai-callgrind, which includes some output
improvements.
Changelog: https://github.com/iai-callgrind/iai-callgrind/releases
|
