[Bug c/102989] Implement C2x's n2763 (_BitInt)

["joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989

--- Comment #13 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 25 Oct 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote:

> The x86-64 psABI has been changed for this:
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/8ca45392570e96920f8a15d903d6122f6d263cd0
> but the state of the padding bits isn't mentioned there anywhere.

I think the words "The value of the unused bits beyond the width of the 
\texttt{_BitInt(N)} value but within the size of the \texttt{_BitInt(N)} 
are unspecified when stored in memory or register." are what deals with 
padding (both padding within sizeof(_BitInt(N)) bytes, and bytes within a 
register or stack slot used for argument passing / return but outside 
sizeof(_BitInt(N)) bytes).

(Of course different architectures might make different choices for how to 
handle padding.)

I filed https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/300 in 
July to request an ABI for _BitInt on RISC-V.  I've just now filed 
https://github.com/ARM-software/abi-aa/issues/175 to request such an ABI 
for both 32-bit and 64-bit Arm, and 
https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5 to request such an ABI 
for 32-bit x86.  I don't know if there are other psABIs with public issue 
trackers where such issues can be filed (but we'll need some sensible 
default anyway for architectures where we can't get an ABI properly 
specified in an upstream-maintained ABI document).