This logic existed when actually analyzing a `nav_ty` unit directly; it
was just missing in the code path which resolves a `nav_ty` unit due to
a `nav_val` being resolved.
Resolves: #35307
Fixes a regression where this conversion crashes. When the conversion was
still possible it would produce a slice with a length of zero, which doesn't
really make a lot of sense either. There's no way to determine the length
of the destination slice from a pointer to an opaque type, so it's a compile
error now. Users should just cast to a many-item pointer and slice to the
desired length manually instead.
These are the last PowerPC cross targets that still use the IBM 128-bit long
double format. I'm not convinced anyone cares enough about them to justify
keeping them around, so this drops support. powerpc-linux-musleabi(hf), which
use the IEEE format, are still fully supported for people who want to use old
32-bit PowerPC hardware.
Since `packed` containers are now internally represented by a `bitpack`,
they need special handling on initialization: they need to be either
bitpacked or bitcasted to their backing integer. `Sema` already did this,
but `LowerZon` didn't yet.
Because this syntax is not heavily used, and the migration can be done
with a simple text substitution, I do not believe a `zig fmt` fixup is
necessary for this change.
Resolves: https://github.com/ziglang/zig/issues/15213
It's a fairly straightforward port of `musl`'s `rintl`, like `rint` and `rintf` were. `libc-test` tests for `rintl` are uncommented since they're now passing.
I've also covered special cases for `rint` with tests, and broke down the current `rint` and `modf` test declarations into multiple -- so each libc function get its own test declaration at the very least.
Contributes to #30978
Reviewed-on: https://codeberg.org/ziglang/zig/pulls/31791
Reviewed-by: Andrew Kelley <andrew@ziglang.org>
glibc has never officially supported ELFv2 on big-endian PowerPC, and we do not
(and likely never will) support linking ELFv1. So just drop this target instead
of pretending we actually have anything resembling usable support for it. This
is a dying target anyway; IBM have been pushing people to powerpc64le for years
now, and most distros have dropped big endian.
glibc headers and abilists are not updated as part of this; I'll just let that
happen automatically on the next glibc update. Size savings are expected to be
very minimal anyway since there's large overlap between powerpc64 and
powerpc64le.
This commit also fixes a couple of bad assumptions in std.Target:
* The dynamic linker path should be /lib64/ld64.so.1. We should get this right
even if the Zig compiler doesn't support the target.
* cCallingConvention() was picking powerpc64_elf_v2 only for musl targets. In
reality, for the targets we support in std.Target, it should pick v2 for all
except powerpc64-linux-gnu.
Finally, this switches LLVM codegen to use ELFv2 data layout for all targets
except ps3.
Andrew Kelley