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.
The active contributors and maintainers of Zig's linker code have
generally found the current linker test harness to be cumbersome. The
tests require a lot of maintenance, but do not provide a lot of
coverage, and when they fail it is painful to troubleshoot.
Furthermore, as part of working on #31691, I don't want to port over the
CheckObject step, because I don't like the code anyway.
The plan forward is to start enhancing `zig objdump` to assist in
linker development, as well as using it as the basis for snapshot
testing.
We absolutely need linker test coverage, but we need to try to improve
these things about the next attempt:
* less effort to create and maintain tests
* less CPU overhead - we should be able to add a lot of tests without
adding a lot of CI time.
* more helpful failures. A failed linker test should provide the next
steps a developer can take to understand why the test failed.
* a goal of porting over all of LLD's test suite, or at least the good
ones.
I'm not going to open an issue to track the lost linker test coverage,
because there was already so much lack of coverage for linker stuff.
However I will open issues to track this lost coverage:
* the deleted checks from test/standalone/glibc_compat/build.zig
* the deleted checks from test/standalone/compiler_rt_panic/build.zig
* the deleted checks from test/standalone/ios/build.zig
Kendall Condon