https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> --- (In reply to Jakub Jelinek from comment #7) > (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? i386 psABI is not actively maintained. > 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. Just implement what is the appropriate in GCC. We will document it.
