[committed] libstdc++: Make __int128 meet integer-class requirements [PR 96042]

Jonathan Wakely jwakely.gcc@gmail.com
Sat Aug 22 12:13:29 GMT 2020

On Sat, 22 Aug 2020 at 10:52, Marc Glisse wrote:
> is there a particular reason to handle only __int128 this way, and not all
> the non-standard integer types? It looks like it would be a bit simpler to
> avoid a special case.

I have no objection to doing it for all of them, it just wasn't
necessary to solve the immediate problem that the library now uses
__int128 even when integral<__int128> is false. (Hmm, or is size_t  an
alias for __int20 on one arch, which would mean we do use it?)

In case you didn't see it, I've created https://gcc.gnu.org/PR96710 to
try and make our treatment of __int128 a bit more useful and
consistent. Even if it's not a standard integer type, it's definitely
an object type. And although it doesn't fit the standard's definition
of a scalar type, I think it should (I prefer to think of scalar types
as objects that aren't classes or arrays, rather than the list of
specific types in the standard that attempts to be exhaustive). What
we do for __int128 could/should be done for the other non-standard

I really wish WG14 would just fix the intmax_t mess so we can make
them integral types unconditionally.

More information about the Libstdc++ mailing list