On Sat, 22 Aug 2020 at 13:13, Jonathan Wakely <jwakely....@gmail.com> wrote: > > 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?)
Oh I remember why I didn't do that now. I did actually want to do it that way initially. The macros like __GLIBCXX_TYPE_INT_N_0 are not defined in strict mode, so we have no generic way to name those types. It's possible to special case __int128 because I know its name, and I know the macro to test for its existence (__SIZEOF_INT128__). To do it for all the other possible non-standard types I'd need to know all the possible names they can have. I know __int20 is one possible name on one target, but I don't know of the others. Since __int128 is the only one we're actually relying on, I just solved the problem for signed/unsigned __int128.
