On Sun, Jul 26, 2026 at 12:09:57PM -0500, Manjunath S Matti wrote: > The changes have been bootstrapped and regression tested on > powerpc64le-linux and powerpc64-linux (m64/m32). > > This patch implements the powerpc64le/ppc64 target hook and > libgcc runtime support needed for GCC's existing C23 > _BitInt front-end/middle-end machinery to work on rs6000. > Previously TARGET_C_BITINT_TYPE_INFO was unimplemented on > this target, so _BitInt was entirely unsupported. > > For n > 128 the ABI limb mode differs from the internal limb mode > on little-endian ppc64 only: TImode 128-bit ABI chunks, matching > aarch64's. On big-endian ppc64, gimple-lower-bitint.cc does not > support abi_limb_mode != limb_mode(PR117584 comment 3), so the > ABI limb equals the internal DImode limb there, matching what > s390x (the only other big-endian _BitInt target) already does. > ppc32 uses SImode limbs throughout with no ABI/internal split. > > The extended (padding-bit) field also differs by endianness: little- > endian uses bitint_ext_undef (padding bits undefined, matching > x86_64/aarch64). Big-endian uses bitint_ext_full, because > gimple-lower-bitint.cc's __builtin_*_overflow lowering only > sign/zero-extends the top limb's padding bits when bitint_extended > is set; with bitint_ext_undef those bits are left unclean and > combine incorrectly with the big-endian storage-order translation > in that file, producing wrong overflow results for multi-limb > (> 128-bit) _BitInt. s390x uses bitint_ext_full for the same > reason, so ppc64 BE now matches it.
I need to look into this more, but given TImode integer support is more limited in the PowerPC, I wonder if maybe we should use DImode for limbs on 64-bit systems (and possibly SImode if we do BitInt for the older 32-bit systems). -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: [email protected]
