These parameters are only ever needed when `std.builtin` is out of sync
with the compiler in which case panicking is the only valid operation
anyways. Removing them causes a domino effect of functions no longer
needing a `src` and/or a `block` parameter resulting in handling
compilation errors where they are actually meaningful becoming simpler.
These functions have a very error-prone API. They are essentially
`all(cmp(op, ...))` but that's not reflected in the name.
This renames these functions to `compareAllAgainstZero...` etc.
for clarity and fixes >20 locations where the predicate was
incorrect.
In the future, the scalar `compare` should probably be split off
from the vector comparison. Rank-polymorphic programming is great,
but a proper implementation in Zig would decouple comparison and
reduction, which then needs a way to fuse ops at comptime.
On platforms where c_longdouble is 128-bits, interop with C code
is simplified by making f128 match the alignment of c_longdouble.
I intended to make this change as part of #13257, but I missed this
part.
The larger alignment on this platform means that long double reports
a sizeof 16 bytes, but it's underlying size is really just the 10
bytes of `f80`
C doesn't give us a way to see the "underlying" size of a type, so
this has to be caught by hand or by monitoring runtime memory. Luckily,
x86 and x86-64 are the only platforms that seem to use a non-power-of-two
type like this.
This value corresponds to clang/gcc's `__alignof` (rather than
`_Alignof` which reports the minimum alignment). We don't use this
information yet, but it might be useful for implementing ABIs so it
is included here.
These updates were made by testing against the `sizeof/_Alignof` reported
by Clang for all supported arch-OS-ABI combinations and correcting any
discrepancies.
This is bound to have a few errors (the recent long double fix for i386
Android is one example), but Clang is certainly not a bad place to start,
especially for our most popular targets.
This makes the following changes for i386:
long long and unsigned long long have 4 byte alignment on non-Windows
f64 (double) has 4-byte alignment on non-Windows
long double is 80 bits and has 4 byte alignment on mingw
long double on android is 64 bits, not 80: https://www.uclibc.org/docs/psABI-i386.pdfFixes#12453Fixes#12987
I'm not sure why the other commits in this branch caused this fix to be
necessary. Also, there seems to be more fixes necessary before tests
will pass.
According to https://github.com/WebAssembly/tool-conventions/blob/main/BasicCABI.md
the size of c's long double is 16 bytes for Wasm, rather than 8 bytes
which was the value previously in the compiler. This ensures
we not only pass the correct value, but also creates the correct
function signature needed to pass the Wasm validator.
This also adds an additional test case in c_abi tests.
Previously, Zig had inconsistent semantics for an enum like this:
`enum(u8){zero = 0}`
Although in theory this can only hold one possible value, the tag
`zero`, Zig no longer will treat the type this way. It will do loads and
stores, as if the type has runtime bits.
Closes#12619
Tests passed locally:
* test-behavior
* test-cases
* riscv64: adjust alignment and size of 128-bit integers.
* take ofmt=c into account for ABI alignment of 128-bit integers and
structs.
* Type: make packed struct support intInfo
* fix f80 alignment for i386-windows-msvc
