Hi! On Fri, Apr 10, 2026 at 12:38:01AM +0530, Avinash Jayakar wrote: > Changes from v1: > * Use complete source code instead of compact macros in test cases. > * Use lp64 where __int128 type is needed.
Yeah, we never allow 128-bit integer types in the 32-bit ABIs. This would be a welcome extension, but not something for this patch. > * Add __int128 overloads. > > Bootstrapped and regtested on powerpc64-linux-gnu (with -m32 and -m64) So, on powerpc64-linux and on powerpc-linux (those two are very different ABIs). OK. > and powerpc64le-linux-gnu, with no regressions. Ok for trunk? A third ABI, pretty close to powerpc64-linux in most regard, but not all. Please send a better patch, with a better subject? We have supported "long long int" for over thirty years now, it isn't anything new. The patch adds "long long int" overloads (and/or implementions) for some "atomic builtins"? (What that term means isn't obvious at all either!) > Although the generic builtin __atomic_compare_exchange does support long > long even in 32 bit, it does not generate larx instructions in assembly, > and instead expands using internal function. Therefore decided not to > support the new builtin for this type in 32 bit. Yeah, it is a bit nasty to use "long long int" in code that can be compiled for either 32-bit or 64-bit systems. Something like __int64/ __int128 or [u]int64_t/[u]int128_t would be nicer? Those types exist and have the same meaning no matter what ABI is used. > 2026-04-10 Avinash Jayakar <[email protected]> > > gcc/ChangeLog: > PR target/124800 > * config/rs6000/rs6000-builtin.cc (rs6000_expand_builtin): Add Please don't break changelog lines early. 79 or 80 chars, not less. Segher
