On Sat, 22 Aug 2020 at 16:01, Marc Glisse <marc.gli...@inria.fr> wrote: > > On Sat, 22 Aug 2020, Jonathan Wakely via Gcc-patches wrote: > > > 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. > > IIRC, those macros were introduced specifically to help libstdc++. If > libstdc++ wants them defined in different circumstances, it should be fine > to change the condition from "!flag_iso || int_n_data[i].bitsize == > POINTER_SIZE" to whatever you need.
Hmm, IIRC the purpose of the patch series adding those macros was to make it possible to use __int20 on a target that needed that. The macros were added so that libstdc++ support could be enabled, to support that target. So IIRC the primary purpose was to improve that target, not to help libstdc++. Allowing libstdc++ to use those types was just a necessary step for improving the target. But I can check with DJ.
