https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117584
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Manjunath S Matti from comment #6) > Created attachment 65065 [details] > _Bitint patch work in progress > > I have attached the patch for reference. Some nits: 1) GCC_16.0.0 in there needs to be GCC_17.0.0, the GCC 16.x train has departed already 2) formatting, GCC indentation is 2 columns each level, while the patch uses 4 columns in various spaces Regarding the big endian current limitations that abi_limb_mode should be limb_mode, that isn't something that can't be supported at all, just that before the asserts are removed various spots will need adjustment. If you use bitint_ext_undef (as in the patch), fewer spots than if you'd use extensions, but still in various spots. With little-endian, if there is an extra most significant limb of padding (especially when it is not extended), nothing cares about it, it is at the most significant address of the array and the only place where it matters is when it is sized/allocated. But for big-endian, if there is an extra most significant limb of padding, it is at the lowest address and all indexes need to be adjusted by that (so + 1 on array indexes or + m_limb_size on MEM_REF accesses). So, if you are ok with the psABI having different decisions between little-endian and big-endian, you can keep it as is (though, it will need to be an psABI for all compilers), if not, there is work to do in gimple-lower-bitint.cc.
