[libstdc++] Inconsistent detection of __int128

[David Edelsohn]

On Fri, Jan 8, 2021 at 11:10 AM Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On 03/01/21 22:26 -0500, David Edelsohn via Libstdc++ wrote:
> >On Sun, Jan 3, 2021 at 9:45 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> >>
> >> On Mon, 4 Jan 2021, 00:44 David Edelsohn via Libstdc++, <libstdc++@gcc.gnu.org> wrote:
> >>>
> >>> Or is there some other reason that _GLIBCXX_USE_INT128 and
> >>> __SIZEOF_INT128__ are used in different contexts?
> >>
> >> Yes.
> >>
> >> I'll reply when I'm back from taking some time off. Probably Wednesday.
> >
> >If the uses of _GLIBCXX_USE_INT128 in libstdc++ headers specifically
> >are checking if __int128 type is different than "long" and "long
> >long", as opposed to the availability of the __int128, can c++config.h
>
> Yes, the test is not just "is __int128 a valid type?" but "should we
> use __int128 as a larger integer type?"
>
> We used to use it more widely, but many places that use __int128
> conditionally now check __GLIBCXX_INT_N_0 instead, because that is
> defined when __int128 is available and we're not compiling in a
> "strict ansi" dialect.
>
> Of the two remaining uses of _GLIBCXX_USE_INT128 I think one is wrong
> and should test __SIZEOF__INT128__ directly. We specifically do want
> to use unsigned __int128 in __to_chars_unsigned_type even if it's the
> same as a standard type.
>
> So that leaves one remaining use, and I think that should do as you
> suggest here ...
>
> >define _GLIBCXX_USE_INT128 by comparing __SIZEOF_INT128__ to
> >__SIZEOF_LONG_LONG__ and __SIZEOF_LONG__ instead of the libstdc++
> >configure template typename test?
>
> Yes, that seems fine. But since we only need it in one place, let's
> just do that test in that one place. It makes the purpose of the test
> more explicit, and so you don't need to look up what
> _GLIBCXX_USE_INT128 means and when it's true.
>
> Does the attached patch work for you?

Hi, Jonathan

Thanks for carefully investigating this further.

This cleanup and patch look good from an AIX-perspective.  It
definitely clarifies the purpose and it's good to remove gratuitous
differences and unnecessary macros.

Thanks, David