| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Enable Non-determinism of float operations in Miri and change std tests
Links to [#4208](https://github.com/rust-lang/miri/issues/4208) and [#3555](https://github.com/rust-lang/miri/issues/3555) in Miri.
Non-determinism of floating point operations was disabled in rust-lang/rust#137594 because it breaks the tests and doc-tests in core/coretests and std. This PR enables some of them.
This pr includes the following changes:
- Enables the float non-determinism but with a lower relative error of 4ULP instead of 16ULP
- These operations now have a fixed output based on the C23 standard, except the pow operations, this is tracked in [#4286](https://github.com/rust-lang/miri/issues/4286#issue-3010677983)
- Changes tests that made incorrect assumptions about the operations, not to make that assumption anymore (from `assert_eq!` to `assert_approx_eq!`.
- Changed the doctests of the stdlib of these operations to compare against fixed constants instead of `f*::EPSILON`, which now succeed with Miri and `-Zmiri-many-seeds`
- Added a constant `APPROX_DELTA` in `std/tests/floats/f32.rs` which is used for approximation tests, but with a different value when run in Miri. This is to make these tests succeed.
- Added tests in the float tests of Miri to test the C23 behaviour.
Fixes https://github.com/rust-lang/miri/issues/4208
|
|
|
|
|
|
|
|
|
|
|
|
coretests: move float tests from num to floats module and use a more flexible macro to generate them
This makes some progress on https://github.com/rust-lang/rust/issues/141726 by moving the float tests in `num` to `floats` and using a newer, more flexible macro to generate them. We also newly run these tests on f16 and f128 in const, and at runtime in Miri and for hosts where that works well enough.
I didn't yet deduplicate any tests or port the existing `floats::f*` tests to the macro, that can happen in a future PR.
try-job: x86_64-gnu-aux
|
|
|
|
|
|
Some history: The Zip TrustedRandomAccess specialization has tried
to emulate the side-effects of the naive implementation for a long time,
including backwards iteration. 82292¹ tried to fix unsoundness (82291¹) in that
side-effect-preservation code, but this introduced some panic-safety
unsoundness (86443¹), but the fix 86452¹ didn't fix it for nested Zip
iterators (137255¹).
Rather than piling yet another fix ontop of this heap of fixes this PR reduces
the number of cases in which side-effects will be preserved; the necessary
API guarantee change was approved in 83791¹ but we haven't made use of that
so far.
¹ see merge commit for linkfied issues.
|
|
flexible macro to generate them
|
|
exact_div: add tests
tracking issue: rust-lang/rust#139911
I neglected to add tests in my last PR (rust-lang/rust#141237), so I've added them here.
r? ``@workingjubilee`` (Feel free to reroll, I just picked you since you reviewed the last one.)
|
|
|
|
change tests in std, core and coretests.
|
|
|
|
|
|
Add const support for the float rounding methods floor, ceil, trunc,
fract, round and round_ties_even.
This works by moving the calculation logic from
src/tools/miri/src/intrinsics/mod.rs
into
compiler/rustc_const_eval/src/interpret/intrinsics.rs.
All relevant method definitions were adjusted to include the `const`
keyword for all supported float types: f16, f32, f64 and f128.
The constness is hidden behind the feature gate
feature(const_float_round_methods)
which is tracked in
https://github.com/rust-lang/rust/issues/141555
This commit is a squash of the following commits:
- test: add tests that we expect to pass when float rounding becomes const
- feat: make float rounding methods `const`
- fix: replace `rustc_allow_const_fn_unstable(core_intrinsics)` attribute with `#[rustc_const_unstable(feature = "f128", issue = "116909")]` in `library/core/src/num/f128.rs`
- revert: undo update to `library/stdarch`
- refactor: replace multiple `float_<mode>_intrinsic` rounding methods with a single, parametrized one
- fix: add `#[cfg(not(bootstrap))]` to new const method tests
- test: add extra sign tests to check `+0.0` and `-0.0`
- revert: undo accidental changes to `round` docs
- fix: gate `const` float round method behind `const_float_round_methods`
- fix: remove unnecessary `#![feature(const_float_methods)]`
- fix: remove unnecessary `#![feature(const_float_methods)]` [2]
- revert: undo changes to `tests/ui/consts/const-eval/float_methods.rs`
- fix: adjust after rebase
- test: fix float tests
- test: add tests for `fract`
- chore: add commented-out `const_float_round_methods` feature gates to `f16` and `f128`
- fix: adjust NaN when rounding floats
- chore: add FIXME comment for de-duplicating float tests
- test: remove unnecessary test file `tests/ui/consts/const-eval/float_methods.rs`
- test: fix tests after upstream simplification of how float tests are run
|
|
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
|
|
`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.
|
|
|
|
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
|
|
coretests: extend and simplify float tests
Also de-duplicate tests by removing a ui test that duplicates the tests in core.
r? `@tgross35`
|
|
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 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.
|
|
Rename `cfg_match!` to `cfg_select!`
[`@Nemo157` pointed out](https://github.com/rust-lang/rust/issues/115585#issuecomment-2346307605) that `cfg_match!` syntax does not actually align well with match syntax, which is a possible source of confusion. The comment points out that usage is instead more similar to ecosystem `select!` macros. Rename `cfg_match!` to `cfg_select!` to match this.
Tracking issue: https://github.com/rust-lang/rust/issues/115585
[1]: https://github.com/rust-lang/rust/issues/115585#issuecomment-2346307605
|
|
At [1] it was pointed out that `cfg_match!` syntax does not actually
align well with match syntax, which is a possible source of confusion.
The comment points out that usage is instead more similar to ecosystem
`select!` macros. Rename `cfg_match!` to `cfg_select!` to match this.
Tracking issue: https://github.com/rust-lang/rust/issues/115585
[1]: https://github.com/rust-lang/rust/issues/115585#issuecomment-2346307605
|
|
When these functions were added in
https://github.com/rust-lang/rust/pull/138087
It made a relatively common pattern for emulating
these functions using an extension trait (which
internally uses `libm`) much more fragile.
If `core::f32` happened to be imported by the user
(to access a constant, say), then that import in
the module namespace would take precedence over
`f32` in the type namespace for resolving these
functions, running headfirst into the stability
attribute.
We ran into this in Color -
https://github.com/linebender/color - and chose to
release the remedial 0.3.1 and 0.2.4, to allow
downstream crates to build on `docs.rs`.
As these methods are perma-unstable, moving them
into a new module should not have any long-term
concerns, and ensures that this breakage doesn't
adversely impact anyone else.
|
|
Add `f16` formatting and parsing
Use the same algorithms as for `f32` and `f64` to implement `f16` parsing and printing.
try-job: x86_64-gnu-aux
|
|
Extend the existing tests for `f32` and `f64` with versions that include
`f16`'s new printing and parsing implementations.
Co-authored-by: Speedy_Lex <alex.ciocildau@gmail.com>
|
|
Make some `f32`/`f64` tests also run in const-context
|
|
Initial implementation of `core_float_math`
Since [1], `compiler-builtins` makes a certain set of math symbols
weakly available on all platforms. This means we can begin exposing some
of the related functions in `core`, so begin this process here.
It is not possible to provide inherent methods in both `core` and `std`
while giving them different stability gates, so standalone functions are
added instead. This provides a way to experiment with the functionality
while unstable; once it is time to stabilize, they can be converted to
inherent.
For `f16` and `f128`, everything is unstable so we can move the inherent
methods.
The following are included to start:
* floor
* ceil
* round
* round_ties_even
* trunc
* fract
* mul_add
* div_euclid
* rem_euclid
* powi
* sqrt
* abs_sub
* cbrt
These mirror the set of functions that we have in `compiler-builtins`
since [1], with the exception of `powi` that has been there longer.
Details for each of the changes is in the commit messages.
Tracking issue: https://github.com/rust-lang/rust/issues/137578
[1]: https://github.com/rust-lang/compiler-builtins/pull/763
try-job: aarch64-gnu
tru-job: armhf-gnu
try-job: i686-msvc-1
try-job: test-various
try-job: x86_64-mingw-1
try-job: x86_64-mingw-2
|
|
Add `#[must_use]` to Array::map
The output of Array::map is intended to be an array of the same size, and does not modify the original in place nor is it intended for side-effects. Thus, under normal circumstances it should be consumed.
See [discussion](https://internals.rust-lang.org/t/array-map-annotate-with-must-use/22813/26).
Attaching to tracking issue #75243
|
|
Per [1], MinGW has an incorrect fma implementation. This showed up in
tests run with cranelift after adding float math operations to `core`.
Presumably we hadn't noticed this when running tests with LLVM because
LLVM was constant folding the result away.
Rust issue: https://github.com/rust-lang/rust/issues/140515
[1]: https://sourceforge.net/p/mingw-w64/bugs/848/
|
|
The previous commit moved all test files from `std` to `core` so git
understands the move. Not all functionality is actually testable in
`core`, however, so perform move the relevant portions back. Changes
from inherent to module methods is also done since this is the form of
math operations available in `core` (as `core_float_math`).
|
|
Many float-related tests in `std` only depend on `core`, so move the
tests there. This also allows us to verify functions from
`core_float_math`.
Since the majority of test files need to be moved to `coretests`, move
the files here without any cleanup; this is done in a followup commit.
This makes git history slightly cleaner, but coretests will not build
immediately after this commit.
|
|
The output of Array::map is intended to be an array of the same size, and does not modify the
original in place nor is it intended for side-effects. Thus, under normal circumstances it should be consumed.
See [discussion](https://internals.rust-lang.org/t/array-map-annotate-with-must-use/22813/26).
Attaching to tracking issue #75243
|
|
|
|
|
|
|
|
stabilize ptr::swap_nonoverlapping in const
Closes https://github.com/rust-lang/rust/issues/133668
The blocking issue mentioned there is resolved by documentation. We may in the future actually support such code, but that is blocked on https://github.com/rust-lang/const-eval/issues/72 which is non-trivial to implement. Meanwhile, this completes stabilization of all `const fn` in `ptr`. :)
Here's a version of the problematic example to play around with:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=6c390452379fb593e109b8f8ee854d2a
Should be FCP'd with both `@rust-lang/libs-api` and `@rust-lang/lang` since `swap_nonoverlapping` is documented to work as an "untyped" operation but due to the limitation mentioned above, that's not entirely true during const evaluation. I expect this limitation will only be hit in niche corner cases, so the benefits of having this function work most of the time outweigh the downsides of users running into this problem. (Note that unsafe code could already hit this limitation before this PR by doing cursed pointer casts, but having it hidden inside `swap_nonoverlapping` feels a bit different.)
|
|
r=workingjubilee
Stabilize `select_unpredictable`
FCP completed in tracking issue #133962.
|
|
|
|
FCP completed in tracking issue #133962.
|
|
|
