https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to H.J. Lu from comment #5) > (In reply to Jakub Jelinek from comment #1) > > Ugh no, please don't. > > This is significant ABI change. > > First of all, zeroing even for signed _BitInt is very weird, sign extension > > for that case is more natural, but when _BitInt doesn't have any unspecified > > bits, everything that computes them will need to compute even the extra > > bits. That is not the case in the current code. > > Can we compare zeroing and undefined codegen of unused bits for storing > signed _BitInt? Not easily, the bitint_info::extended support isn't there yet (as no target needed it so far). See also the discussions about it on IRC and aarch64 _BitInt support thread (aarch64 wants to have the extra bits unspecified, but arm 32 extended). > Then implement whatever appropriate in GCC and make it the de facto ABI. So what's wrong with https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5 ? Has it been discussed, or is i386-ABI dead? I'd probably go with 32-bit limbs for _BitInt(65) and higher instead of 64-bit, but under the hood that is how it will be implemented no matter what the ABI says, whether it is 32-bit limbs or 64-bit limbs only affects a) the alignment b) how much is wasted in case of say _BitInt(65) or _BitInt(129) etc. and what the sizeof is. Even if limbs are 64-bit, the question is about alignment, ia32 has 32-bit alignment for long long and double at least when used inside of structs, so it would be weird to have different alignment from struct { limb l1, l2; } and similar.
