Add an assembly implementation for roundeven which also works for
`rint`, similar to the existing `ceil` and `floor` implementations. This
resolves cases where values close to the *.5 boundary would round the
incorrect direction, such as -519629176421.49976 (tested in
`case_list`).
These no longer test just softfloat and hardfloat, but also the fallback
implementations in `mem` compared to those that make use of assembly.
Change the baseline names to be more accurate of the difference.
This was needed while some codegen backends did not support inline
assembly, or ran into circular issues using vector intrinsics. All such
issues have since been resolved with the in-tree backends. The remaining
need was to be able to toggle these features in tests, which we can do
via the enabled-by-default `arch` feature. Since there aren't any cases
requiring `force-soft-float`, remove its functionality and deprecate it.
It is possible that future codegen backends may have a similar need to
disable inline assembly until pairity with the LLVM backend can be
reached. In these cases rather than having `force-soft-float`, it would
be better to have rustc provide a `cfg(target_supports_inline_asm)`.
`build.rs` can then do something like:
let nightly = cfg!(feature = "compiler-builtins") || cfg!(feature = "unstable");
let asm_support = env::var("CARGO_CFG_TARGET_SUPPORTS_INLINE_ASM").is_ok();
let arch_enabled = cfg!(feature = "arch") && (!nightly || (nightly && asm_support));
set_cfg("arch_enabled", arch_enabled);
This is about what we have now with `cfg(target_has_reliable_f16)` and
`cfg(target_has_reliable_f128)` being set by rustc, which is
significantly easier to use than the `feature = "no-f16-f128"` that it
replaced. Having rustc directly tell us what it supports means we don't
need to bubble subtractive options up to bootstrap via a chain of Cargo
features that aren't really meant to support disabling things.
I'm sketching this out for future reference since it seems likely that
the need comes back up eventually.
Unfortunately the `gh` CLI tool can't yet download non-zipped archives.
Attempting to do so says:
error downloading baseline-icount-i686-202604011355-ba4c48868cad.tar.xz: error extracting zip archive: zip: not a valid zip file
Drop this change until the CLI is updated.
This reverts commit 0a57b9e3eda70c3673815fc47fad137a3c62da98.
Make `libm` and `compiler-builtins` use the same configuration:
* By default there is an `arch` feature which allows `core::arch` and
inline assembly.
* Disabling the `arch` feature turns these off.
Positive feature flags are easier to reason about than negative, so this
will allow for some build script cleanup as well.
`mem` only enables the unmangled names; the functions are always
available via mangled names, so this doesn't have any purpose in our
tests. Thus, remove it from `builtins-test`.
The remaining `feature = "mem"` configuration in tests is for the
`aeabi_mem*` files, which call the compiler-builtins functions via
extern definitions. Move these to builtins-test-intrinsics, which is the
home of other tests that require unmangled symbols. Unfortunately these
tests have apparently not worked for a long time; this situation is
unchanged.
Ensure that our compiler-builtins is providing the runtime, so we can
see the effect of changes in c-b on libm functions. This was happening
implicitly before because the `mangled-names` feature was not enabled in
tests, so unmangled names were exposed. In commit "c-b: Change the
`mangled-names` feature to `unmangled-names`" things were reversed,
meaning the unmangled names are no longer exposed by default, so our
benches started using the platform symbols. (Hence apparent regressions
in fmaf128, ldexpf128, powif128, and scalbnf128).
This feature is somewhat backwards because the mangled names are always
available; enabling the `mangled-names` feature disables unmangled
names. This was likely somehow related to default features when the
crate was published on crates.io.
Rename the feature and reverse the logic such that unmangled names are
exposed when the feature `unmangled-names` is enabled.
Note that this changes some benchmarking logic; see the following commit
message for details.
This isn't used anywhere in CI and there doesn't seem to be a reason
that it would need to be toggled. Enable `mangled-names` on the
`compiler-builtins` dependency by default and remove the from
`builtins-test`.
Use `Hcx`/`hcx` consistently for `StableHashingContext`.
The `HashStable` and `ToStableHashKey` traits both have a type parameter that is sometimes called `CTX` and sometimes called `HCX`. (In practice this type parameter is always instantiated as `StableHashingContext`.) Similarly, variables with these types are sometimes called `ctx` and sometimes called `hcx`. This inconsistency has bugged me for some time.
The `HCX`/`hcx` form is more informative (the `H`/`h` indicates what type of context it is) and it matches other cases like `tcx`, `dcx`, `icx`.
Also, RFC 430 says that type parameters should have names that are "concise UpperCamelCase, usually single uppercase letter: T". In this case `H` feels insufficient, and `Hcx` feels better.
Therefore, this commit changes the code to use `Hcx`/`hcx` everywhere.
r? @petrochenkov
add rustc option -Zpacked-stack
this enables `-Zpacked-stack` just as `-mpacked-stack` in clang and gcc. packed-stack is needed on s390x for kernel development.
For reference: rust-lang/rust#151154 and rust-lang/rust#150766
look at @uweigand s post for full explanation of what this does. Here a wrap-up:
https://github.com/rust-lang/rust/pull/150766#issuecomment-3729074303
> [...]
> packed-stack [...] modifies how the compiler-generated function prolog/epilog code makes use of the 160 byte register save area provided by a caller to the callee [...] this variant is not actually incompatible with the ABI - packed-stack and regular functions can freely call each other without ABI issues.
> [...]
> combination of -mpacked-stack and -mbackchain [...] the location in the stack frame where the backchain link ought to be stored is not available. [...] is not supported at all with the default ABI
> [...]
> However, in the special case of also using soft-float, our (implied) soft-float ABI provides a different location for the backchain that is compatible with -mpacked-stack, so that combination should be supported
> [...]
Update libc to v0.2.183
Follow-up of https://github.com/rust-lang/rust/pull/150484.
This PR updates libc to include the latest patches to make rtems target (and probably others) compile again.
Simplify the `cache_on_disk_if` modifier to just `cache_on_disk`
Thanks to https://github.com/rust-lang/rust/pull/154304, there is now only one remaining query with a non-trivial cache-on-disk condition (`check_liveness`). But prior experiments at https://github.com/rust-lang/rust/pull/153441#issuecomment-4009037104 indicate that `check_liveness` can also be made non-disk-caching with little or no measurable effect.
This PR takes advantage of those facts to replace the `cache_on_disk_if` modifier with a simpler `cache_on_disk` modifier:
- When combined with `separate_provide_extern`, only values for “local” keys are cached to disk.
- For any other query with `cache_on_disk`, values are cached to disk unconditionally.
r? nnethercote (or compiler)
Add a test for a now fixed ICE with `offset_of!()`
Adds a test for rust-lang/rust#125805, which was an ICE with `offset_of!()` on a field with the type of a trait object missing `dyn` and a required lifetime parameter.
Closesrust-lang/rust#125805.
misc test cleanups
These are some mixed cleanups to `tests/ui` that individually seemed too small for a PR of their own. Some duplicated tests are removed, `issues-*` tests are renamed and more FIXMEs are added to `ui/README.md`.
Reasoning for the deleted tests:
* `tests/ui/associated-types/issue-47814.rs`: duplicate of `tests/ui/associated-consts/issue-47814.rs`
* rename `tests/ui/closures/2229_closure_analysis/migrations/issue-78720.rs` to `.../nested-copy-drops-83176.rs` since rust-lang/rust#78720 was not the correct issue, rust-lang/rust#83176 was.
* `tests/ui/specialization/defaultimpl/specialization-feature-gate-default.rs`: duplicate of `tests/ui/specialization/specialization-feature-gate-default.rs`
* `fn/issue-1900.rs`: duplicate of `error-codes/E0131.rs`
r? @Kivooeo
refactor: remove `Adjust::ReborrowPin`
Followed by rust-lang/rust#149130, this PR removes `Adjust::ReborrowPin` and use an `Adjust::Deref(DerefAdjustKind::Pin)` followed by an `Adjust::Borrow(AutoBorrow::Pin)` instead.
Fix AtomicPtr::update's cfg gate
I'm *pretty* sure this is supposed to be `#[cfg(target_has_atomic = "ptr")]` like `AtomicPtr::try_update` is.
cc @GrigorenkoPV (author), @Noratrieb (r+ to rust-lang/rust#133829)
Update flate2 users to use zlib-rs
flate2 is looking to make zlib-rs the default.
Go ahead and make build-manifest and rust-installer use it, to make sure it
doesn't introduce any issues.
Take first task group for further execution
Continuing from https://github.com/rust-lang/rust/pull/153768#discussion_r2938828363.
I thought that storing a first group of tasks for immediate execution instead of pushing and immediately poping it from rayon's local task queue in par_slice would avoid overwhelming work stealing potentially blocking the original thread. So I've implemented this change.
8 threads benchmarks:
<table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>baseline~~9</b></th><td colspan="2"><b>new~take-first-group~1</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th></tr><tr><td>🟣 <b>hyper</b>:check</td><td align="right">0.1110s</td><td align="right">0.1086s</td><td align="right">💚 -2.13%</td></tr><tr><td>🟣 <b>hyper</b>:check:initial</td><td align="right">0.1314s</td><td align="right">0.1298s</td><td align="right">💚 -1.23%</td></tr><tr><td>🟣 <b>hyper</b>:check:unchanged</td><td align="right">0.0771s</td><td align="right">0.0755s</td><td align="right">💚 -2.14%</td></tr><tr><td>🟣 <b>clap</b>:check</td><td align="right">0.3787s</td><td align="right">0.3757s</td><td align="right"> -0.80%</td></tr><tr><td>🟣 <b>clap</b>:check:initial</td><td align="right">0.4680s</td><td align="right">0.4564s</td><td align="right">💚 -2.48%</td></tr><tr><td>🟣 <b>clap</b>:check:unchanged</td><td align="right">0.2337s</td><td align="right">0.2301s</td><td align="right">💚 -1.52%</td></tr><tr><td>🟣 <b>syn</b>:check</td><td align="right">0.4321s</td><td align="right">0.4265s</td><td align="right">💚 -1.31%</td></tr><tr><td>🟣 <b>syn</b>:check:initial</td><td align="right">0.5586s</td><td align="right">0.5401s</td><td align="right">💚 -3.31%</td></tr><tr><td>🟣 <b>syn</b>:check:unchanged</td><td align="right">0.3434s</td><td align="right">0.3429s</td><td align="right"> -0.14%</td></tr><tr><td>🟣 <b>regex</b>:check</td><td align="right">0.2755s</td><td align="right">0.2661s</td><td align="right">💚 -3.40%</td></tr><tr><td>🟣 <b>regex</b>:check:initial</td><td align="right">0.3350s</td><td align="right">0.3347s</td><td align="right"> -0.11%</td></tr><tr><td>🟣 <b>regex</b>:check:unchanged</td><td align="right">0.1851s</td><td align="right">0.1832s</td><td align="right">💚 -1.01%</td></tr><tr><td>Total</td><td align="right">3.5296s</td><td align="right">3.4695s</td><td align="right">💚 -1.70%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9837s</td><td align="right">💚 -1.63%</td></tr></table>
As we port more correctly rounded implementatinos from CORE-MATH, it
would be nice to keep the existing versions around since they are
simpler, typically smaller and faster, and easier to port to other float
types. The implementations have also been reasonably well tested.
Introduce an `approx` module that will serve as a home for these. As the
first member, add back the old `cbrt` implementation that was replaced
in 75a7f3df3ed7 ("Port the CORE-MATH version of `cbrt`").
Trevor Gross