On Fri, 16 Jul 2021 at 12:29, Jonathan Wakely wrote:
> Hmm, in fact it seems that we can just use the __uint128_t typedef
> instead, which doesn't give a pedwarn:
>
>   using __rep = __uint128_t;
>
> Is that typedef always available if __int128 is? There's a comment in
> gcc/c-family/c-common.c that I don't understand:
>
> #if HOST_BITS_PER_WIDE_INT >= 64
>   /* Note that this is different than the __int128 type that's part of
>      the generic __intN support.  */
>   if (targetm.scalar_mode_supported_p (TImode))
>     lang_hooks.decls.pushdecl (build_decl (UNKNOWN_LOCATION,
>                        TYPE_DECL,
>                        get_identifier ("__int128_t"),
>                        intTI_type_node));
> #endif
>
> They are the same type in C++, so what is "different"? Is it possible
> for __int128 to be different from a TImode integer?

As discussed on IRC, I'm going to add a configure check that __int128
and __int128_t are the same, and similarly for the unsigned versions.
That will allow us to use __int128_t and __uint128_t to avoid the
warnings (assuming GCC doesn't change to warn consistently for the
non-standard typedefs as well as the non-standard types).

For now, I'll just use __extension__ consistently everywhere. I'm
testing the attached patch that does that.