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.
setKey used to just call rebuildIndex which allocates a new index and
inserts into it all entries. This is the only allocation that setKey
needed to do.
Instead I propose that setKey sets the key in the entries and then does
a remove of the old key from the index and insert of the new key into
the index. This eliminates the need for setKey to allocate and makes
it infallible
To achieve this I extracted a helper function for inserting a single
entry into the index. Function for removing one entry from the index
already exists. setKey now just calls these two functions.
`HINSTANCE` is `*opaque {}` so using a type that should be compatible from alternate bindings (zigwin32, for example) would be a (false positive) compile error without this ptrCast.
Largely mirrors Haiku, Serenity provides crt0 and GCC the rest (though
only crtbegin/crtend are used as per serenity's toolchain patches[1]):
```
$ find Build/aarch64/Root -iname 'crt*.o'
Build/aarch64/Root/usr/local/lib/gcc/aarch64-serenity/15.2.0/crtbeginS.o
Build/aarch64/Root/usr/local/lib/gcc/aarch64-serenity/15.2.0/crtend.o
Build/aarch64/Root/usr/local/lib/gcc/aarch64-serenity/15.2.0/crtbegin.o
Build/aarch64/Root/usr/local/lib/gcc/aarch64-serenity/15.2.0/crtfastmath.o
Build/aarch64/Root/usr/local/lib/gcc/aarch64-serenity/15.2.0/crti.o
Build/aarch64/Root/usr/local/lib/gcc/aarch64-serenity/15.2.0/crtn.o
Build/aarch64/Root/usr/local/lib/gcc/aarch64-serenity/15.2.0/crtendS.o
Build/aarch64/Root/usr/lib/crt0.o
```
Serenity has a GCC and LLVM toolchain that work equally well, support
for the latter may be added in the future.
[1]: https://github.com/SerenityOS/serenity/blob/727c4a3d1a6748221b383207dac354e564b6150d/Toolchain/Patches/gcc/0001-Add-a-gcc-driver-for-SerenityOS.patch#L120-L127
This PR merges the functionality of the `getLastOrNull` method into `getLast`, which improves consistency as its
based on methods like `front`, `back`, and `peek` in the `Deque` and `PriorityQueue` containers.
Reviewed-on: https://codeberg.org/ziglang/zig/pulls/32008
Reviewed-by: Andrew Kelley <andrew@ziglang.org>
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
Andrew Kelley