| Age | Commit message (Collapse) | Author | Lines |
|---|
|
The reorganization PR has caused this to fail once before because every
file shows up as changed. Increase the timeout so this doesn't happen.
We now cancel the job if too many extensive tests are run unless `ci:
allow-many-extensive` is in the PR description, so this helps prevent
the limit being hit by accident.
|
|
Error out when too many extensive tests would be run unless `ci:
allow-many-extensive` is in the PR description. This allows us to set a
much higher CI timeout with less risk that a 4+ hour job gets started by
accident.
|
|
Sometimes we do refactoring that moves things around and triggers an
extensive test, even though the implementation didn't change. There
isn't any need to run full extensive CI in these cases, so add a way to
skip it from the PR message.
|
|
Jobs should just cancel automatically, it isn't ideal that extensive
jobs can continue running for multiple hours after code has been
updated. Use a solution from [1] to do this.
[1]: https://stackoverflow.com/a/72408109/5380651
|
|
Update `compiler-builtins` to 0.1.155
Includes the following changes:
* Replace `#[naked]` with `#[unsafe(naked)]` [1] [2]
* Replace `bl!` with `asm_sym` [3]
[1]: https://github.com/rust-lang/compiler-builtins/pull/817
[2]: https://github.com/rust-lang/compiler-builtins/pull/821
[3]: https://github.com/rust-lang/compiler-builtins/pull/820
try-job: armhf-gnu
try-job: aarch64-apple
try-job: dist-apple-various
|
|
sync::mpsc: prevent double free on `Drop`
This PR is fixing a regression introduced by #121646 that can lead to a double free when dropping the channel.
The details of the bug can be found in the corresponding crossbeam PR https://github.com/crossbeam-rs/crossbeam/pull/1187
|
|
Splitting into different source files by float size doesn't have any
benefit when the only content is a small function that forwards to the
generic implementation. Combine the source files for all width versions
of:
* ceil
* copysign
* fabs
* fdim
* floor
* fmaximum
* fmaximum_num
* fminimum
* fminimum_num
* ldexp
* scalbn
* sqrt
* truc
fmod is excluded to avoid conflicts with an open PR.
As part of this change move unit tests out of the generic module,
instead testing the type-specific functions (e.g. `ceilf16` rather than
`ceil::<f16>()`). This ensures that unit tests are validating whatever
we expose, such as arch-specific implementations via
`select_implementation!`, which would otherwise be skipped. (They are
still covered by integration tests).
|
|
|
|
Introduce a constant representing NaN with a negative sign bit for use
with testing. There isn't really any guarantee that `F::NAN` is positive
but in practice it always is, which is good enough for testing purposes.
|
|
Fix drop handling in `hint::select_unpredictable`
This intrinsic doesn't drop the value that is not selected so this is manually done in the public function that wraps the intrinsic.
|
|
f*::NAN: guarantee that this is a quiet NaN
I think we should guarantee that this is a quiet NaN. This then implies that programs not using `f*::from_bits` (or unsafe type conversions) are guaranteed to only work with quiet NaNs. It would be awkward if people start to write `0.0 / 0.0` instead of using the constant just because they want to get a guaranteed-quiet NaN.
This is a `@rust-lang/libs-api` change. The definition of this constant currently is `0.0 / 0.0`, which is already guaranteed to be a quiet NaN. So all this does is forward that guarantee to our users.
|
|
Includes the following changes:
* Replace `#[naked]` with `#[unsafe(naked)]` [1] [2]
* Replace `bl!` with `asm_sym` [3]
[1]: https://github.com/rust-lang/compiler-builtins/pull/817
[2]: https://github.com/rust-lang/compiler-builtins/pull/821
[3]: https://github.com/rust-lang/compiler-builtins/pull/820
|
|
|
|
|
|
This improves consistency with commonly expected CLI conventions,
avoiding a common stutter people make when running tests (trying what
they expect and then having to check the docs to then user whats
accepted).
An alternative could have been to take a value, like `--capture <value>` (e.g. `pytest` does this).
Overall, we're shifting focus for features to custom test harnesses (see #134283).
Most of `pytest`s modes will likely be irrelevant in that situation.
As for the rest, its too early to tell which, if any, may be relevant,
so we're sticking with this small, quality of life improvement.
By deprecating `--nocapture`, we intend that custom test harnesses do
not need to support it for reasons outside of their own compatibility
requirements, much like the deprecation in #134283
I'm punting for now on the naming of `RUST_TEST_NOCAPTURE`.
I feel like T-testing-devex should do a wider look at environment
variables role in lib`test` before evaluating whether to
- Deprecate it in favor of the user passing CLI flags or the test runner
providing its own config
- Deprecate in favor of `RUST_TEST_NO_CAPTURE`
- Deprecate in favor of `RUST_TEST_CAPTURE`
Other CLI flags were evaluated for casing consistency:
- `--logfile` has the same problem but was deprecated in #134283
Fixes #133073
|
|
This will help with hiding some options in `--help`
|
|
|
|
|
|
|
|
|
|
This intrinsic doesn't drop the value that is not selected so this is
manually done in the public function that wraps the intrinsic.
|
|
|
|
|
|
|
|
- `_mm512_load_si512`
- `_mm512_loadu_si512`
- `_mm512_stream_si512`
|
|
|
|
`bl!` is being used to add a leading underscore on Apple targets.
`asm_sym` has been around since 2022 and handles platform-specific
symbol names automatically, so make use of this instead.
I have verified that `armv7s-apple-ios` still builds correctly.
|
|
|
|
|
|
cfi: Remove #[no_sanitize(cfi)] for extern weak functions
Previously (https://github.com/rust-lang/rust/pull/115200, https://github.com/rust-lang/rust/pull/138002), we added `#[no_sanitize(cfi)]` to all code paths that call to a weakly linked function.
In https://github.com/rust-lang/rust/pull/138349 we fixed the root cause for this issue, which means we can now remove the corresponding attributes.
r? `@rcvalle`
|
|
Discussed at [1], there was an off-by-one mistake when converting from
the loop routine to using `leading_zeros` for normalization.
Currently, using `EXP_BITS` has the effect that `ix` after the branch
has its MSB _one bit to the left_ of the implicit bit's position,
whereas a shift by `EXP_BITS + 1` ensures that the MSB is exactly at the
implicit bit's position, matching what is done for normals (where the
implicit bit is set to be explicit). This doesn't seem to have any
effect in our implementation since the failing test cases from [1]
appear to still have correct results.
Since the result of using `EXP_BITS + 1` is more consistent with what is
done for normals, apply this here.
[1]: https://github.com/rust-lang/libm/pull/469#discussion_r2012473920
|
|
From discussion at [1] our loop count calculation is incorrect, causing
an issue with subnormal numbers. Add test cases for known failures.
[1]: https://github.com/rust-lang/libm/pull/469#discussion_r2012473920
|
|
This reverts commit 85572dc298f5222902c9b200cebf5d045e769a83.
|
|
|
|
Because the current lowest requirements to run the Linux kernel on RISC-V is
RV{32,64}IMA (with 32 general purpose registers) plus some features,
RV32E (with only 16 GPRs) is not currently supported.
Since it's not sure whether current implemented method will work for future
Linux versions even if the minimum requirements are lowered, the support for
RV32E (to be more specific, an attempt to do that) is removed for now.
|
|
|
|
Restoring what it said prior to commit 67065fe in which it was changed
incorrectly with no supporting explanation.
Closes #139835.
|
|
|
|
Until in-kernel feature detection is implemented, runtime detection of
privileged extensions is temporally removed along with features themselves
since none of such privileged features are stable.
Co-Authored-By: Taiki Endo <te316e89@gmail.com>
Co-Authored-By: Amanieu d'Antras <amanieu@gmail.com>
|
|
This commit implements `riscv_hwprobe`-based feature detection as available
on newer versions of the Linux kernel. It also queries whether the vector
extensions are enabled using `prctl` but this is not supported on QEMU's
userland emulator (as of version 9.2.3) and use the auxiliary vector
as a fallback.
Currently, all extensions discoverable from the Linux kernel version 6.14
and related extension groups (except "Supm", which reports the existence of
`prctl`-based pointer masking control and too OS-dependent) are implemented.
Co-Authored-By: Taiki Endo <te316e89@gmail.com>
|
|
This commit adds the OS-independent extension implication logic for RISC-V.
It implements:
1. Regular implication (A → B)
a. "the extension A implies the extension B"
b. "the extension A requires the extension B"
c. "the extension A depends on the extension B"
2. Extension group or shorthand (A == B1 & B2...)
a. "the extension A is shorthand for other extensions: B1, B2..."
b. "the extension A comprises instructions provided by B1, B2..."
This is implemented as (A → B1 & B2... + B1 & B2... → A)
where the former is a regular implication as required by specifications
and the latter is a "reverse" implication to improve usability.
and prepares for:
3. Implication with multiple requirements (A1 & A2... → B)
a. "A1 + A2 implies B"
b. (implicitly used to implement reverse implication of case 2)
Although it uses macros and iterators, good optimizers turn the series of
implications into fast bit-manipulation operations.
In the case 2 (extension group or shorthand; where a superset extension
is just a collection of other subextensions and provides no features by
a superset itself), specifications do specify that an extension group
implies its members but not vice versa. However, implying an extension
group from its members would improve usability on the feature detection
(especially when the feature provider does not provide existence of such
extension group but provides existence of its members).
Similar "reverse implication" on RISC-V is implemented on LLVM.
Case 3 is implicitly used to implement reverse implication of case 2 but
there's another use case: implication with multiple requirements like
"Zcf" and "Zcd" extensions (not yet implemented in this crate for now).
To handle extension groups perfectly, we need to loop implication several
times (until they converge; normally 2 times and up to 4 times when we add
most of `riscv_hwprobe`-based features).
To make implementation of that loop possible, `cache::Initializer` is
modified to implement `PartialEq` and `Eq`.
|
|
This is ported from Taiki Endo's branch and sorted by the `@FEATURE` order
as in `src/detect/arch/riscv.rs`.
Co-Authored-By: Taiki Endo <te316e89@gmail.com>
|
|
The "B" extension is once abandoned (instead, it is ratified as a collection
of "Zb*" extensions). However, it is later redefined and ratified as a
superset of "Zba", "Zbb" and "Zbs" extensions (but not "Zbc" carry-less
multiplication for limited benefits and implementation cost).
Although non-functional (because feature detection is not yet implemented),
it provides the foundation to implement this extension (along with
straightforward documentation showing subsets of "B").
|
|
The "A" extension comprises instructions provided by the "Zaamo" and
"Zalrsc" extensions. To prepare for the "Zacas" extension (which provides
compare-and-swap instructions and discoverable from Linux) which depends on
the "Zaamo" extension, it would be better to support those subsets.
|
|
As Taiki Endo pointed out, there's a problem if we continue using
`target_pointer_width` values to detect an architecture because:
* There are separate `target_arch`s already and
* There is an experimental ABI (not ratified though): RV64ILP32.
cf. <https://lpc.events/event/17/contributions/1475/attachments/1186/2442/rv64ilp32_%20Run%20ILP32%20on%20RV64%20ISA.pdf>
Co-Authored-By: Taiki Endo <te316e89@gmail.com>
|
|
This commit prepares common infrastructure for extension implication by
removing `enable_features` closure which makes each feature test longer
(because it needs extra `value` argument each time we test a feature).
It comes with the overhead to enable each feature separately but later
mitigated by the OS-independent extension implication logic.
|
|
Because this function will be no longer auxvec-only, this commit adds a
comment to mark auxvec-based part.
It *does not* add a comment to "base ISA" part because it may also use
`riscv_hwprobe`-based results.
|
|
This commit makes handling of the base ISA a separate block.
Co-Authored-By: Taiki Endo <te316e89@gmail.com>
|
|
1. Use canonical kernel.org repository instead of the GitHub mirror.
2. Refer to the fixed commit to guarantee access.
3. Use `uapi` part to ensure that the feature detection is primarily
intended for user-mode programs.
|
|
|
