| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
The build script currently panics with `opt-level=z` or `opt-level=s`.
Account for this here.
This is the `compiler-builtins` version of [1].
Fixes: https://github.com/rust-lang/compiler-builtins/issues/742
[1]: https://github.com/rust-lang/libm/pull/417
|
|
This includes [1], which fixes a bug parsing non-numeric optimization
levels.
[1]: https://github.com/rust-lang/libm/pull/417
|
|
The build script currently panics with `opt-level=z` or `opt-level=s`.
Account for this here.
|
|
|
|
This renames variables named `str` to other names, to make sure `str`
always refers to a type.
It's confusing to read code where `str` (or another standard type name)
is used as an identifier. It also produces misleading syntax
highlighting.
|
|
Extensive tests report that the precision isn't actually 0:
---- mp_extensive_tgammaf ----
input: (-0.00063536887,) (0xba268ee2,)
expected: -1574.4668 0xc4c4cef0
actual: -1574.4667 0xc4c4ceef
Caused by:
ulp 1 > 0
Update ULP to reflect this. After this change, `tgammaf` extensive tests
pass.
|
|
[generic_assert] Constify methods used by the formatting system
cc #44838
Starts the "constification" of all the elements required to allow the execution of the formatting system in constant environments.
```rust
const _: () = { panic!("{:?}", 1i32); };
```
Further stuff is blocked by #133999.
|
|
Add support for wasm exception handling to Emscripten target
This is a draft because we need some additional setting for the Emscripten target to select between the old exception handling and the new exception handling. I don't know how to add a setting like that, would appreciate advice from Rust folks. We could maybe choose to use the new exception handling if `Ctarget-feature=+exception-handling` is passed? I tried this but I get errors from llvm so I'm not doing it right.
|
|
|
|
|
|
WASM is the only architecture we use `intrinsics::` for. We probably
don't want to do this for any other architectures since it is better to
use assembly, or work toward getting the functions available in `core`.
To more accurately reflect the relationship between arch and intrinsics,
make wasm32 an `arch` module and call the intrinsics from there.
|
|
|
|
|
|
This configuration was duplicated from `fabs` and `fabsf`, but wasm is
unlikely to have an intrinsic lowering for these float types. So, just
always use the generic.
|
|
|
|
Unlike `unstable-intrinsics`, `intrinsics_enabled` gets disabled with
`force-soft-floats` which is what we want here.
|
|
These will need to be fixed, for now just xfail them so this doesn't
block better test coverage.
|
|
MPFR does build and run correctly without SSE, but requires
`force-cross` be enabled.
|
|
On master, this fetch fails with:
fatal: refusing to fetch into branch 'refs/heads/master' checked out at '/home/runner/work/libm/libm'
Just skip the command when this shouldn't be needed.
|
|
chore: remove redundant words in comment
|
|
|
|
|
|
This provides an increase in test coverage on platforms that cannot test
against MPFR.
|
|
Gated behind an unstable `-Z emscripten-wasm-eh` flag
|
|
Update test traits to support `f16` and `f128`, as applicable. Add the
new routines (`fabs` and `copysign` for `f16` and `f128`) to the list of
all operations.
|
|
Use the generic implementations to provide these simple methods.
|
|
Additionally, read glob output as absoulte paths. This enables the
script to work properly even when invoked from a different directory.
|
|
Add a CI job with a dynamically calculated matrix that runs extensive
jobs on changed files. This makes use of the new
`function-definitions.json` file to determine which changed files
require full tests for a routine to run.
|
|
|
|
Add a generator that will test all inputs for input spaces `u32::MAX` or
smaller (e.g. single-argument `f32` routines). For anything larger,
still run approximately `u32::MAX` tests, but distribute inputs evenly
across the function domain.
Since we often only want to run one of these tests at a time, this
implementation parallelizes within each test using `rayon`. A custom
test runner is used so a progress bar is possible.
Specific tests must be enabled by setting the `LIBM_EXTENSIVE_TESTS`
environment variable, e.g.
LIBM_EXTENSIVE_TESTS=all_f16,cos,cosf cargo run ...
Testing on a recent machine, most tests take about two minutes or less.
The Bessel functions are quite slow and take closer to 10 minutes, and
FMA is increased to run for about the same.
|
|
Signed-off-by: crystalstall <crystalruby@qq.com>
|
|
Update the script to produce, in addition to the simple text list, a
JSON file listing routine names, the types they work with, and the
source files that contain a function with the routine name. This gets
consumed by another script and will be used to determine which extensive
CI jobs to run.
|
|
Add doc aliases for `libm` and IEEE names
Searching "fma" in the Rust documentation returns results for `intrinsics::fma*`, but does not point to the user-facing `mul_add`. Add aliases for `fma*` and the IEEE operation name `fusedMultiplyAdd`. Add the IEEE name to `sqrt` as well, `squareRoot`.
|
|
|
|
New random seeds seem to indicate that this test does have some more
failures, this is a recent failure on i586:
---- musl_random_jnf stdout ----
Random Musl jnf arg 1/2: 100 iterations (10000 total) using `LIBM_SEED=nLfzQ3U1OBVvqWaMBcto84UTMsC5FIaC`
Random Musl jnf arg 2/2: 100 iterations (10000 total) using `LIBM_SEED=nLfzQ3U1OBVvqWaMBcto84UTMsC5FIaC`
thread 'musl_random_jnf' panicked at crates/libm-test/tests/compare_built_musl.rs:43:51:
called `Result::unwrap()` on an `Err` value:
input: (205, 5497.891) (0x000000cd, 0x45abcf21)
expected: 7.3291517e-6 0x36f5ecef
actual: 7.331668e-6 0x36f6028c
Caused by:
ulp 5533 > 4000
It seems unlikely that `jn` would somehow have better precision than
`j0`/`j1`, so just use the same precision.
|
|
The `support` module that this feature makes public will be useful for
implementations in `compiler-builtins`, not only for testing. Give this
feature a more accurate name.
|
|
|
|
Currently, all inputs are generated and then cached. This works
reasonably well but it isn't very configurable or extensible (adding
`f16` and `f128` is awkward).
Replace this with a trait for generating random sequences of tuples.
This also removes possible storage limitations of caching all inputs.
|
|
Introduce the `KnownSize` iterator wrapper, which allows providing the
size at construction time. This provides an `ExactSizeIterator`
implemenation so we can check a generator's value count during testing.
|
|
Currently, tests use a handful of constants to determine how many
iterations to perform: `NTESTS`, `AROUND`, and `MAX_CHECK_POINTS`. This
configuration is not very straightforward to adjust and needs to be
repeated everywhere it is used.
Replace this with new functions in the `run_cfg` module that determine
iteration counts in a more reusable and documented way.
This only updates `edge_cases` and `domain_logspace`, `random` is
refactored in a later commit.
|
|
Occasionally it is useful to see some information from running tests
without making everything noisy from `--nocapture`. Add a function to
log this kind of output to a file, and print the file as part of CI.
|
|
|
|
|
|
Mark `slice::reverse` unstably const
Tracking issue #135120
This is unblocked by the stabilization of `const_swap`
|
|
This implementation comes from `rug::Float::to_f32_exp` [1].
[1]: https://docs.rs/rug/1.26.1/rug/struct.Float.html#method.to_f32_exp
|
|
Rug provides `trunc_fract_round`, which implements `modf`, use it to add
a test.
|
|
|
|
|
|
There isn't any need to cache the integer since it gets provided as an
argument anyway. Simplify this in `jn` and `yn`.
|
