From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jwakely@redhat.com>
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by sourceware.org (Postfix) with ESMTP id CA3ED3AA9400
 for <libstdc++@gcc.gnu.org>; Fri, 16 Jul 2021 14:39:42 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CA3ED3AA9400
Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com
 [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-304-ynhZNNUjMSOzuOg97Gr6wQ-1; Fri, 16 Jul 2021 10:39:41 -0400
X-MC-Unique: ynhZNNUjMSOzuOg97Gr6wQ-1
Received: by mail-wr1-f72.google.com with SMTP id
 d8-20020adf9c880000b0290141a87409b5so4082772wre.16
 for <libstdc++@gcc.gnu.org>; Fri, 16 Jul 2021 07:39:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=fjK2oyu7J/CnIU236Md2UHKFt0zWHaRk4AWXEkrBakE=;
 b=t/9On9LhKuXfk9J1rS1zgIflzYzbn7gvsDYs0BK1U4N5UwDVorXs8TCIzn3xiNxIvv
 jI6yPVqZUNUSPcpytVjFJqqPIJhu/y0JeElBR/ZJXMbGxUjdqQUFevPnP3gnI2NAIk2K
 lGmuUpBN8I77kWsGfVDKRLhCe5cSXA2OsLJWAs23jdTdiWljpaTGcRRFmNpIJgP/D1AJ
 gTIA8Trcx/dW8P8zCQpy8ESDzkXuIiGgVwbfc4o2MBXEPX0okGIJOj5A4LYOl1guZi1p
 6kYdR3aWbAVFmrhpJr4omalMKqJQAX1vR3gWWq+XufRmA8kZk8BztMuLWW8YREVSNETF
 xC/w==
X-Gm-Message-State: AOAM531l2idKoG1Jcexapgpe7/eWHUicxr7nSx7ktaVaTciLb3ivXSXv
 mEumYhtdbPXMm7X3vG6231xK/O9RWtWzt95x7JdwopblqtDH2MZ5p2L/GGFS7lcA5bEjqNaAuCw
 Tc91VTltdjuModd7+E3+99vBK4woansM=
X-Received: by 2002:adf:e7c6:: with SMTP id e6mr12806649wrn.221.1626446380366; 
 Fri, 16 Jul 2021 07:39:40 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJyuLlIl8gegsxzclyypFoeTiunZHb1YR3Q7/Jkpm5kg9d3XBEpteCi39sjZBjVP/PMHv3t3tElbnIJSB6o6Jw4=
X-Received: by 2002:adf:e7c6:: with SMTP id e6mr12806631wrn.221.1626446380177; 
 Fri, 16 Jul 2021 07:39:40 -0700 (PDT)
MIME-Version: 1.0
References: <YPE4Eh0zTAT/8bZt@redhat.com> <20210716082709.GD2380545@tucnak>
 <20210716082906.GE2380545@tucnak>
 <CAH6eHdTfa+uo8SCZTeNg3iWkL74CcrMbaOKyyJd53qpHr=EcqA@mail.gmail.com>
 <CAH6eHdRXkcCm7EBVKuLCnp5xgpniyNiGH=Vnd4mROKBz_o19LA@mail.gmail.com>
 <CACb0b4kHMsQErVAzg4g=m8m100Hz4A_PJ6ufcP4x=ZG37+t+2Q@mail.gmail.com>
 <CACb0b4krr4qP1LFmdVsJK9+iSZY-5eV9Ai_JCCV0UgqC3NSdRA@mail.gmail.com>
In-Reply-To: <CACb0b4krr4qP1LFmdVsJK9+iSZY-5eV9Ai_JCCV0UgqC3NSdRA@mail.gmail.com>
From: Jonathan Wakely <jwakely@redhat.com>
Date: Fri, 16 Jul 2021 15:39:29 +0100
Message-ID: <CACb0b4kT0+3dnzhLhC0zDipZRnxVRCv+whVYRoSB9A+5_5KbJw@mail.gmail.com>
Subject: Re: [PATCH] libstdc++: Use __extension__ instead of diagnostic
 pragmas (was: Suppress pedantic warnings about __int128)
To: "libstdc++" <libstdc++@gcc.gnu.org>
Cc: Jakub Jelinek <jakub@redhat.com>, gcc-patches <gcc-patches@gcc.gnu.org>
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH,
 DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW,
 RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE,
 TXREP autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: libstdc++@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libstdc++ mailing list <libstdc++.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/libstdc++>,
 <mailto:libstdc++-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/libstdc++/>
List-Post: <mailto:libstdc++@gcc.gnu.org>
List-Help: <mailto:libstdc++-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/libstdc++>,
 <mailto:libstdc++-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jul 2021 14:39:43 -0000

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.