https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #32 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Fri, 28 Oct 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote: > > That said, if C allows us to limit to 128bits then let's do that for now. > > 32bit targets will still see all the complication when we give that a stab. > > I'm afraid once we define BITINT_MAXWIDTH, it will become part of the ABI, so > we can't increase it afterwards. I don't think it's part of the ABI; I think it's always OK to increase BITINT_MAXWIDTH, as long as the wider types don't need more alignment than the previous choice of max_align_t. Thus, starting with a 128-bit limit (or indeed a 64-bit limit on 32-bit platforms, so that all the types fix within existing modes supported for arithmetic), and adding support for wider _BitInt later, would be a reasonable thing to do. (You still have ABI considerations even with such a limit: apart from the padding question, on x86_64 the ABI says _BitInt(128) is 64-bit aligned but __int128 is 128-bit aligned.) > Anyway, I'm afraid we probably don't have enough time to implement this > properly in stage1, so might need to target GCC 14 with it. Unless somebody > spends on it > the remaining 2 weeks full time. I think https://gcc.gnu.org/pipermail/gcc/2022-October/239704.html is still current as a list of C2x language features likely not to make it into GCC 13. (I hope to get auto and constexpr done in the next two weeks, and the other C2x language features not on that list are done.)
