https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #30 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to John Maddock from comment #26) > (In reply to jos...@codesourcery.com from comment #25) > > On Thu, 20 Nov 2014, john at johnmaddock dot co.uk wrote: > > > > > While we're opening cans of worms.... intmax_t should clearly be > > > __int128... > > > just saying! > > > > Existing ABIs where intmax_t in libc is 64-bit are why __int128 is what I > > call a sui generis extended type, not an integer type. > > So it's an integer that's not an integer? I'm sorry but that's just > nonesense. Of course I realise that ABI issues may trump other concerns, > but please call a spade a spade! In any case this is a glibc issue and > we're off topic here... With changes to the definition of intmax_t in C2x (and C++23) that problem is gone. __int128 can be an extended integer type, and intmax_t doesn't need to change, so there's no ABI problem. Order is restored to the galaxy.
