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 integers. I really wish WG14 would just fix the intmax_t mess so we can make them integral types unconditionally.
