| Age | Commit message (Collapse) | Author | Lines |
|---|
|
- add `-Zverify-llvm-ir` in testsuite
|
|
- use correct intrinsic for unpackl
- fix invalid use of `simd_{or,and,xor}` on floating point vectors
- `vec_search_string` should require `vector-enhancements-2`
|
|
|
|
- The 2nd argument of the LLVM intrinsic should be IMMARG
|
|
|
|
|
|
Since the bootstrap compiler of Rust is bumped to the commit
5dadfd5c417f0b66816cb7ca662859e2c8751fb3 (version 1.88.0-beta.3 2025-05-11),
some features should be safe to enable cfg checks.
RISC-V Features:
* "zicsr"
* "zicntr"
* "zihpm"
* "zifencei"
* "zihintntl"
* "zihintpause"
* "zimop"
* "zicboz"
* "zicond"
* "ztso"
* "zfa"
* "zca"
* "zcb"
* "zcmop"
* "b"
x86 Features:
* "amx-avx512"
* "amx-fp8"
* "amx-movrs"
* "amx-tf32"
* "amx-transpose"
|
|
Includes the following changes:
* Enable `__powitf2` on MSVC [1]
* Update `CmpResult` to use a pointer-sized return type [2]
* Better code reuse between `libm` and `compiler-builtins` [3], [4]
* Stop building C versions of `__netf2` [5] since we have our own
implementation
[1]: https://github.com/rust-lang/compiler-builtins/pull/918
[2]: https://github.com/rust-lang/compiler-builtins/pull/920
[3]: https://github.com/rust-lang/compiler-builtins/pull/879
[4]: https://github.com/rust-lang/compiler-builtins/pull/925
[5]: https://github.com/rust-lang/compiler-builtins/pull/828
|
|
|
|
|
|
float: Replace some approximate assertions with exact
As was mentioned at [1], we currently use `assert_approx_eq` for testing
some math functions that guarantee exact results. Replace approximate
assertions with exact ones for the following:
* `ceil`
* `floor`
* `fract`
* `from_bits`
* `mul_add`
* `round_ties_even`
* `round`
* `trunc`
This likely wasn't done in the past to avoid writing out exact decimals
that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004),
but ensuring our results are accurate seems more important here.
[1]: https://github.com/rust-lang/rust/pull/138087#issuecomment-2842069281
The first commit is a small bit of macro cleanup.
try-job: aarch64-gnu
try-job: x86_64-gnu-aux
|
|
atomic_load intrinsic: use const generic parameter for ordering
We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that!
This PR only converts `load`, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics.
The first two commits are preparation and could be a separate PR if you prefer.
`@BoxyUwU` -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer...
`@bjorn3` it seems like the cranelift backend entirely ignores the ordering?
|
|
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#137574 (Make `std/src/num` mirror `core/src/num`)
- rust-lang/rust#141384 (Enable review queue tracking)
- rust-lang/rust#141448 (A variety of improvements to the codegen backends)
- rust-lang/rust#141636 (avoid some usages of `&mut P<T>` in AST visitors)
- rust-lang/rust#141676 (float: Disable `total_cmp` sNaN tests for `f16`)
- rust-lang/rust#141705 (Add eslint as part of `tidy` run)
- rust-lang/rust#141715 (Add `loongarch64` with `d` feature to `f32::midpoint` fast path)
- rust-lang/rust#141723 (Provide secrets to try builds with new bors)
- rust-lang/rust#141728 (Fix false documentation of FnCtxt::diverges)
- rust-lang/rust#141729 (resolve target-libdir directly from rustc)
- rust-lang/rust#141732 (creader: Remove extraenous String::clone)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
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.
|
|
`assert_eq!` ignores the sign of zero, but for any tests involving zeros
we do care about this sign. Replace `assert_eq!` with `assert_biteq!`
everywhere possible for float tests to ensure we don't miss this.
`assert_biteq!` is also updated to check equality on non-NaNs, to catch
the unlikely case that bitwise equality works but our `==`
implementation is broken.
There is one notable output change: we were asserting that
`(-0.0).fract()` and `(-1.0).fract()` both return -0.0, but both
actually return +0.0.
|
|
The rounding tests are now supported, so there is no longer any reason
to skip these.
|
|
As was mentioned at [1], we currently use `assert_approx_eq` for testing
some math functions that guarantee exact results. Replace approximate
assertions with exact ones for the following:
* `ceil`
* `floor`
* `fract`
* `from_bits`
* `mul_add`
* `round_ties_even`
* `round`
* `trunc`
This likely wasn't done in the past to avoid writing out exact decimals
that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004),
but ensuring our results are accurate seems more important here.
[1]: https://github.com/rust-lang/rust/pull/138087#issuecomment-2842069281
|
|
Clean up the separate `assert_f{16,32,64,128}` macros with a single
`assert_biteq!` macro that works for all float widths.
|
|
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.
|
|
Currently we only build this, but it is possible to run the binary.
Change the CI script to do so here.
|
|
As part of this, the u256 benchmarks are reorganized to a group.
|
|
|
|
Do the same for `builtins-test-intrinsics`. Mostly this means updating
`extern` to `unsafe extern`, and fixing a few new Clippy lints.
|
|
Since a working `nm` is no longer needed as part of CI, the rustup
component can be removed.
|
|
This should be less error-prone and adaptable than the `nm` version, and
have better cross-platform support without needing LLVM `nm` installed.
|
|
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).
|
|
Add `loongarch64` with `d` feature to `f32::midpoint` fast path
This patch enables the optimized implementation of `f32::midpoint` for `loongarch64` targets that support the `d`feature. Targets with reliable 64-bit float support can safely use the faster and more accurate computation via `f64`, avoiding the fallback branchy version.
|
|
float: Disable `total_cmp` sNaN tests for `f16`
There is an LLVM bug with lowering of basic `f16` operations that mean a round trip via `__extendhfsf2` and `__truncsfhf2` may happen for simple `abs` calls or bitcasts [1]. This is problematic because the round trip quiets signaling NaNs. For most operations this is acceptable, but it is causing `total_cmp` tests to fail unless optimizations are enabled.
Disable `total_cmp` tests involving signaling NaNs until this issue is resolved.
Fixes: https://github.com/rust-lang/rustc_codegen_cranelift/issues/1578
Fixes: https://github.com/rust-lang/rust/issues/141503
[1]: https://github.com/llvm/llvm-project/issues/104915
|
|
The float modules in `std` are currently top-level but for `core`, they
are nested within the `num` directory and referenced by `#[path = ...]`.
For consistency, adjust `std` to use the same structure as `core`.
Also change the `f16` and `f128` gates from outer attributes to inner
attributes like `core` has.
|
|
Rust's 128-bit integers have historically been incompatible with C [1].
However, there have been a number of changes in Rust and LLVM that
mean this is no longer the case:
* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment
proposed at https://github.com/rust-lang/compiler-team/issues/683,
implemented at https://github.com/rust-lang/rust/pull/116672.
* LLVM version of the above: resolved in LLVM, including ABI fix.
Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]:
Rust's data layouts adjusted at
https://github.com/rust-lang/rust/pull/132422,
https://github.com/rust-lang/rust/pull/132741,
https://github.com/rust-lang/rust/pull/134115.
* LLVM version of the above: done in LLVM 20
https://github.com/llvm/llvm-project/issues/102783.
* Incorrect return convention of `i128` on Windows: adjusted to match
GCC and Clang at https://github.com/rust-lang/rust/pull/134290.
At [3], the lang team considered it acceptable to remove `i128` from
`improper_ctypes_definitions` if the LLVM version is known to be
compatible. Time has elapsed since then and we have dropped support for
LLVM versions that do not have the x86 fixes, meaning a per-llvm-version
lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes
only came in LLVM 20 but since Rust's datalayouts have also been updated
to match, we will be using the correct alignment regardless of LLVM
version.
`repr(i128)` was added to this lint in [4], but is also removed here.
Part of the decision is that `i128` should match `__int128` in C on
platforms that provide it, which documentation is updated to indicate.
We will not guarantee that `i128` matches `_BitInt(128)` since that can
be different from `__int128`. Some platforms (usually 32-bit) do not
provide `__int128`; if any ABIs are extended in the future to define it,
we will need to make sure that our ABI matches.
Closes: https://github.com/rust-lang/rust/issues/134288
Closes: https://github.com/rust-lang/rust/issues/128950
[1]: https://github.com/rust-lang/rust/issues/54341
[2]: https://github.com/rust-lang/rust/issues/128950
[3]: https://github.com/rust-lang/lang-team/issues/255#issuecomment-2088855084
[4]: https://github.com/rust-lang/rust/pull/138282
|
|
Do not get proc_macro from the sysroot in rustc
With the stage0 refactor the proc_macro version found in the sysroot will no longer always match the proc_macro version that proc-macros get compiled with by the rustc executable that uses this proc_macro. This will cause problems as soon as the ABI of the bridge gets changed to implement new features or change the way existing features work.
To fix this, this commit changes rustc crates to depend directly on the local version of proc_macro which will also be used in the sysroot that rustc will build.
|
|
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#138285 (Stabilize `repr128`)
- rust-lang/rust#139994 (add `CStr::display`)
- rust-lang/rust#141571 (coretests: extend and simplify float tests)
- rust-lang/rust#141656 (CI: Add cargo tests to aarch64-apple-darwin)
Failed merges:
- rust-lang/rust#141430 (remove `visit_clobber` and move `DummyAstNode` to `rustc_expand`)
- rust-lang/rust#141636 (avoid some usages of `&mut P<T>` in AST visitors)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Since the two crates are now in the same repo, it is easier to share
code. Begin some deduplication with the integer traits.
|
|
coretests: extend and simplify float tests
Also de-duplicate tests by removing a ui test that duplicates the tests in core.
r? `@tgross35`
|
|
add `CStr::display`
The implementation delegates to `<ByteStr as Display>::fmt`.
Link: https://github.com/rust-lang/libs-team/issues/550
Link: https://github.com/rust-lang/rust/issues/139984.
r? ```@BurntSushi```
cc ```@Darksonn``` ```@tgross35``` ```@ojeda``` ```@joshtriplett```
|
|
Add `rustc_diagnostic_item` to `sys::Mutex` methods
For an ongoing project for adding a concurrency model checker to Miri we need to be able to intercept locking/unlocking operations on standard library mutexes.
This PR adds diagnostic items to the relevant calls `lock`, `try_lock` and `unlock` for the `sys::Mutex` implementation on the targets we care about.
This PR also makes the internals of `pthread::Mutex` less public, to reduce the chance of anyone locking/unlocking a mutex without going through the intercepted methods.
r? ``@RalfJung``
|
|
core: unstably expose atomic_compare_exchange so stdarch can use it
Due to https://github.com/rust-lang/stdarch/issues/1655, cleaning up the atomic intrinsics will be a bunch of extra work: stdarch directly calls them [here](https://github.com/rust-lang/stdarch/blob/8764244589373b8b48864c0ad11fd9233c672249/crates/core_arch/src/x86_64/cmpxchg16b.rs#L58-L74).
Instead of duplicating that match, stdarch should use what we have in libcore, so let's expose that.
r? `@bjorn3`
|
|
Call out possibility of invariant result in variance markers
ref https://github.com/rust-lang/rust/issues/135806#issuecomment-2766191535
|
|
clean up old rintf leftovers
As usual stdarch needed special treatment due to https://github.com/rust-lang/stdarch/issues/1655, and apparently I forgot to clean up these leftovers here. They can be removed now.
|
|
Path::with_extension: show that it adds an extension where one did no…
…t exist
I think the times I encountered this, I had to check first if files without extensions were added, since all examples only had files with existing extensions.
Also, this replaced example already has a similar example below.
|
|
r=ChrisDenton
Test(fs): Fix `test_eq_windows_file_type` for Windows 7
Would otherwise fail on:
```
thread 'fs::tests::test_eq_windows_file_type' panicked at library/std/src/test_helpers.rs:53:20:
called `Result::unwrap()` on an `Err` value: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }
```
This came from the read-only attribute set on the test file. In order to fix this, instead of simply disabling the test, the attribute is reset before the test's end so it may still run successfully.
`@rustbot` label T-libs A-filesystem A-testsuite O-windows-7 O-windows-msvc
|
|
This patch enables the optimized implementation of `f32::midpoint` for
`loongarch64` targets that support the `d`feature. Targets with reliable
64-bit float support can safely use the faster and more accurate computation
via `f64`, avoiding the fallback branchy version.
|
|
|
|
|
|
Link to Apache License changed from htps:// to https://
|
|
|
