I feel that this PR has a couple of contention points
The status of PPC32 is that is a target that nobody uses
nobody is responsible for its ABI
better not touch it and break things
so what is PR author's motivation then?
oh you mean on GCC's side?
-gnuabi when applying this hack etc.
for ZSTs, the ABI spec of PPC32 is "weird", but that's how it is
we are now over time
so lets move this discussion into a dedicated separate topic
one thing I wanted to suggest during the discussion on the PR was that we "just" drop ZST support in FFI and warn about it - but @Josh Triplett pointed out to me that it can arise from C code with
#ifdefs around struct fields
For the 32-bit ELF ABI, all structs (regardless of size) are passed using a pointer allowing for call-by-value semantics. This is the source of ZSTs requiring a register. So it's clear there is an ABI that requires this behavior. (Look for the Parameter Passing Register Selection Algorithm in https://github.com/ryanarn/powerabi/blob/master/chap3-elf32abi.sgml.)
(My only real thought here is that we should just decide something, and I lean towards more conservative choices for now, e.g. extending a list of special cases, perhaps with a comment that says "we might consider genearlizing this to a rule like such-and-such" so that we notice it in the future as we add more)
I don’t have time to contribute to this discussion, gotta go walk my quadruped friend, but my broad desire to land something here stays. I don’t see much harm in generalizing over gnu&musl.
I might be fine with an approach where we derive the "ZSTs aren't passed" behavior without having to up-front force it, but it may be tricky to ensure that it "fall out" of the general logic for all targets (and testing here is annoying, I'd prefer formal proofs at this point...)
the check for that might need to happen, especially for the
sparc branch, which is the only one which has actual ABIs that aren’t "GNU".