On Fri, 16 Jul 2021 at 14:02, Jonathan Wakely wrote:
>
> 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.
Pushed to trunk now.
