We are now getting this warning:
warning: the variable `j` is used as a loop counter
--> libm/src/math/rem_pio2_large.rs:268:5
|
268 | for i in 0..=m {
| ^^^^^^^^^^^^^^ help: consider using: `for (j, i) in ((jv as i32) - (jx as i32)..).zip((0..=m))`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#explicit_counter_loop
= note: `#[warn(clippy::explicit_counter_loop)]` on by default
warning: `libm` (lib) generated 1 warning
Where the suggestion is definitely not an improvement.
`div!` looks innocuous but is actually unsafe. Replace it with function
calls that require us to actually use `unsafe`, and add the precondition
notes. These can likely be removed completely in the near future.
There is one case in `rem_pio2_large` and one in `exp2` where
preconditions aren't as easy to define, but fortunately it seems like we
are able to just use regular division there without affecting codegen.
Replace the use of intrinsics with `core::hint::cold_path` which has
been unstably available for a while, and is on track to become stable in
the next release.
Enable aarch64 outline-atomics in tests via the mangled-names feature
gate, and add comprehensive compare-and-swap tests that run both with
LSE enabled and disabled. Improve assertion messages to better describe
expected behavior.
Co-authored-by: Trevor Gross <tmgross@umich.edu>
Replace signed integer types (i8, i16, i32, i64, i128) with their
unsigned equivalents (u8, u16, u32, u64, u128) in function declarations
and the int_ty! macro, avoiding the need for sign extension in emitted
assembly.
Add support for ELF and Mach-O AArch64 relocation specifiers for symbol
access, enabling outline-atomics to work on Apple targets. Remove the
Linux-only OS gate in tests.
Co-authored-by: Trevor Gross <tmgross@umich.edu>
The current implementation of lgammaf evaluates to f32::MAX at the first
input that would overflow if correctly rounded. This is still well within
allowed error, so special case it.
PRs are now getting the following:
Traceback (most recent call last):
File "/home/runner/work/compiler-builtins/compiler-builtins/ci/ci-util.py", line 510, in <module>
main()
File "/home/runner/work/compiler-builtins/compiler-builtins/ci/ci-util.py", line 496, in main
ctx.emit_workflow_output()
File "/home/runner/work/compiler-builtins/compiler-builtins/ci/ci-util.py", line 294, in emit_workflow_output
pr = PrInfo.from_env()
^^^^^^^^^^^^^^^^^
File "/home/runner/work/compiler-builtins/compiler-builtins/ci/ci-util.py", line 152, in from_env
return cls.from_pr(pr_env)
^^^^^^^^^^^^^^^^^^^
File "/home/runner/work/compiler-builtins/compiler-builtins/ci/ci-util.py", line 174, in from_pr
return cls(**json.loads(pr_info), cfg=PrCfg(pr_json["body"]))
^^^^^^^^^^^^^^^^^^^^^^
File "/home/runner/work/compiler-builtins/compiler-builtins/ci/ci-util.py", line 134, in __init__
pprint.pp(self)
File "/usr/lib/python3.12/pprint.py", line 66, in pp
pprint(object, *args, sort_dicts=sort_dicts, **kwargs)
...
AttributeError: 'PrCfg' object has no attribute 'extra_extensive'. Did you mean: 'skip_extensive'?
Resolve this by using `__post_init__` rather than `__init__`.
Fixes: bba024d20464 ("ci: Allow specifying extra extensive tests to run")
For cases where we would like to run tests that aren't automatically
detected, allow the following syntax in PR descriptions:
ci: extra-extensive=copysignf,sqrtf16
Currently Criterion is always built with the test crates, but it doesn't
really need to be. It wasn't a problem before but did start showing up
with the latest version bump since it added a C dependency, and for the
Miri CI runs we don't have the C toolchains. To resolve this and speed
up compilation time, move criterion behind a new feature `walltime`.
I'd rather have named this `runtime` but don't want to confuse my future
self with "what runtime?".
Values like 0.5 that have an exponent but not a mantissa are currently
being reported as OK rather than INEXACT for ceil, floor, and trunc. Fix
this and clean up the test cases.
This tries to keep the algorithm diff as simple as possible, which
introduces some small performance regressions. This is improved in a
future commit.
This will support `frexpf16` and should allow `generic::frexp` to be
inlined into the non-generic `frexp*` functions.
Additionally remove an unneeded `as` cast.
Implement the following logic:
* For elf executable binaries, check for PT_GNU_STACK with PF_X. This
combination tells the kernel to make the stack executable.
* For elf intermediate objects, check for `.note.GNU-stack` with
SHF_EXECINSTR. This combination in an object file tells the linker to
give the final binary PT_GNU_STACK PF_X.
* For elf intermediate objects with no `.note.GNU-stack`, assume the
legacy behavior that assumes an executable stack is required.
* For non-elf binaries, don't check anything. In a follow up it may be
possible to check for `MH_ALLOW_STACK_EXECUTION` on Mach-O binaries,
but it doesn't seem possible to get the latest compiler to emit this.
This appears to match what is done by `scanelf` to emit `!WX` [1], which
seems to be the tool used to create the output in the issue. The ld
manpage [2] also has some useful notes about these flags, as does the
presentation at [3].
Closes: https://github.com/rust-lang/compiler-builtins/issues/183
[1]: https://github.com/gentoo/pax-utils/blob/9ef54b472e42ba2c5479fbd86b8be2275724b064/scanelf.c
[2]: https://man7.org/linux/man-pages/man1/ld.1.html
[3]: https://www.ndss-symposium.org/wp-content/uploads/6D-s0924-ye.pdf
PE executables don't seem to have anything in the symbol table. Don't
assert that we find any symbols in this case, which allows using
symcheck for executable binaries.
It would be nice to support a few more flags here, but the current
implementation is a bit limited. Switch to `getopts` which should make
things a bit easier in the future.
The tests were using `rug::ln_gamma` as a reference for `libm::lgamma`,
which actually computes the natural logarithm *of the absolute value* of
the Gamma function.
This changes the range of inputs used for the icount-benchmarks of these
functions, which causes false regressions in [1].
[1]: https://github.com/rust-lang/compiler-builtins/actions/runs/21788698368/job/62864230903?pr=1075#step:7:2710.
Fixes: a1a066611dc2 ("Create interfaces for testing against MPFR")
The recent switch in default mangling meant that the check was no longer
working correctly. Resolve this by checking for both legacy- and
v0-mangled core symbols to the extent that this is possible.
Trevor Gross