Float division currently has a separate `div32` and `div64` for `f32`
and `f64`, respectively. Combine these to make use of generics. This
will make it easier to support `f128` division, and reduces a lot of
redundant code.
This includes a simplification of division tests.
Make the following changes:
- Add `rerun-if-changed` to the new `configure.rs`, it seems this was
causing incorrect caching.
- Change from matching `i686` to `x86`. The target triple starts with
`i686` so that is what we were checking before, but the architecture
is `x86`. This change should have been made when we added `struct
Target`, update it now instead.
Since there are more platforms that do not have symbols present, we need
to use `rustc_apfloat` for more conversion tests. Make use of the
fallback like other tests, and refactor so each test gets its own
function.
Previously we were testing both apfloat and system conversion methods
when possible. This changes to only test one or the other, depending on
whether or not the system version is available. This seems reasonable
because it is consistent with all other tests, but we should consider
updating all tests to check both at some point.
This also includes an adjustment of PowerPC configuration to account for
the linking errors at [1].
[1]: https://github.com/rust-lang/compiler-builtins/issues/655
Previously we were building the C versions of these symbols. Since we
added the Rust version and updated compiler builtins, these are no
longer available by default. This is unintentional, but it gives a
better indicator of which symbol versions are not actually provided by
the system.
Use the list of build failures to correct the list of platforms that do
not have `f16` symbols.
This is what `cc-rs` is using and should create a release PR whenever a
change to `master` is made. If the branch is merged, it should publish
the new version.
Includes configuration to disable semver checks and not keep a changelog
since this is an implementation detail.
This adds comparisons among the compiler-builtins function, system
functions if available, and optionally handwritten assembly.
These also help us identify inconsistencies between this crate and
system functions, which may otherwise go unnoticed if intrinsics get
lowered to inline operations rather than library calls.
PowerPC platforms use `kf` rather than `tf` for `f128`. Add a way to
alias this in the macro to make the code cleaner.
This also fixes the names of `fixunstf*` and `fixtf*` on Power PC
(`fixunskf*` and `fixkf*` are correct).
`as` casts are only allowed for primitives, doing the same operations
with `rustc_apfloat` requires using functions. Add a way to specify
these separately.
Currently, tests of the same kind are grouped together across all types
into a single function. This makes it difficult to understand exactly
what failed in CI.
Change test macros to create separate functions for separate types so
failures are more fine grained.
Change float test macros to fall back to testing against `rustc_apfloat`
when system implementations are not available, rather than just skipping
tests.
This allows for easier debugging where operations may not be supported.
`MinInt` contains the basic methods that are only needed by integers
involved in widening operations, i.e. big integers. `Int` retains all
other operations and convenience methods.
Trying to run testcrate on non-linux aarch64 currently hits a
compilation error. Make this test linux-only, to be consistent with the
`aarch64_linux` module that it depends on.
Additionally, enable the `aarch64_linux` module for `target_arch =
"arm64ec"` to be the same as these tests.
This has a very long history, summarized in
https://github.com/rust-lang/rust/issues/109064. This port is a very
minimal subset of `aarch64/lse.S` from LLVM's compiler-rt. In
particular, it is missing the following:
1. Any form of runtime dispatch between LL/SC and LSE.
Determining which version of the intrinsics to use
requires one of the following:
i) `getauxval` from glibc. It's unclear whether `compiler_builtins` is
allowed to depend on libc at all, and musl doesn't even support
getauxval. Don't enshrine the requirement "de-facto" by making it
required for outline-atomics.
ii) kernel support. Linux and FreeBSD have limited support, but it
requires an extremely recent kernel version and doesn't work at all under QEMU (https://github.com/rust-lang/rust/issues/109064#issuecomment-1494939904).
Instead, we hard-code LL/SC intrinsics. Users who want LSE support
should use the LLVM compiler-rt (if you're building from source in
rust-lang/rust, make sure you have `src/llvm-project` checked out
locally. the goal is to soon add a new `optimized-compiler-builtins`
option so this is easier to discover).
2. The global `___aarch64_have_lse_atomics` CTOR, required to do runtime
dispatch. Thom Chiviolani has this to say about global CTORs:
> static ctors are problems because we are pretty eager about dead code elim
> in general if you have a module that isnt directly reference we will probably not have its static ctors
> also, while llvm has a super robust way to have a static ctor (theres s special "appending global" to use for c++), we dont use that and just have people make a #[used] static in a special section
> 1. the robust way kinda requires rust knowing that the argument is a static ctor (maybe a #[rustc_static_ctor] attribute). it also would be... finnicky, since on windows we actually care beyond being a static ctor, that we run as part in a specific group of ctors, which means a very specific section (one for TLS and the other for, uh, i dont remember)
> 2. we still actually have to codegen the cgu that isn't referenced. but maybe we could remember that it has that attribute and use that
So while this is possible in theory, it's decidedly non-trivial, and
needs invasive changes to rust itself. In any case, it doesn't matter
until we decide the story around libc.
3. The 16-byte (i128) version of compare_and_swap. This wouldn't be
*too* hard to add, but it would be hard to test. The way I tested the
existing code was not just with unit tests but also by loading it as a
path dependency and running `x test core` - the latter caught several
bugs the unit tests didn't catch (because I originally wrote the tests
wrong). So I am slightly nervous about adding a 16-byte version that is
much more poorly tested than the other intrinsics.
