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

[Jonathan Wakely]

On Sat, 22 Aug 2020 at 16:01, Marc Glisse <marc.glisse@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.gcc@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.