From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id D29E8385AC31 for ; Fri, 16 Jul 2021 11:29:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D29E8385AC31 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-41-9lshANxgMx2E1K8w8P2GLA-1; Fri, 16 Jul 2021 07:29:48 -0400 X-MC-Unique: 9lshANxgMx2E1K8w8P2GLA-1 Received: by mail-wm1-f69.google.com with SMTP id b26-20020a7bc25a0000b0290218757e2783so3052374wmj.7 for ; Fri, 16 Jul 2021 04:29:48 -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:content-transfer-encoding; bh=dyCMoe4qdBFoXsD6jLaLmJ1vQ4MRWfMrlgNuxDHVCzU=; b=NOjIEqxGQX5O0EGDcc1+T5hUeSnvmGUuDZ2aHMWgmgRbUZIA34OMSBalBkBsnj7Jyk VglbsnNx6/KqEaTc5O/SEhq5CEJSGhZW7e7uocywdEOzLXXP9mT80X+i3/14/6t4F4EE c34EwFD0GqcYpX4K9OhpdfNco1oiyADsAL609ZPemAQYeI6i7dd6rFtw6rmUxy/I0akZ HZBR1zBm6qAV5BmzzhrvV3sxIYNAvuxynHtYkzLb2MGRVVTJ7TIZcjdIc1GnEaZwhPnl ctviwohBDPxqDlFpbDKzOk0Qxv4DdlBL3bBaCti9PWVxivNXmIX21vKTeb0p32c4ydtC EKWg== X-Gm-Message-State: AOAM533yteo9bqSbVBk4xrUsvZq34bxSJmpWZBBX9SHg9aXF+96SkfrJ fmR6Y1tzeiSThNuCXN3F0FjLf4X4rW8wkk7omTF180ZdkjCiGPgYgfK+lRWqnxYTD7n8r4y79f6 WtoCNwdVICjtZaRtM7ISIGfV9MSDT3Ew= X-Received: by 2002:a7b:c10b:: with SMTP id w11mr10404923wmi.185.1626434987159; Fri, 16 Jul 2021 04:29:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzOa5RyoQ0RvZegmfhJtY5w4+JVmfyy5zYkE5pF9R7cQh9OV1+ZhC0PSpb+YZ7KSeyykMvCa3MpjAKSAwTa7O0= X-Received: by 2002:a7b:c10b:: with SMTP id w11mr10404916wmi.185.1626434986959; Fri, 16 Jul 2021 04:29:46 -0700 (PDT) MIME-Version: 1.0 References: <20210716082709.GD2380545@tucnak> <20210716082906.GE2380545@tucnak> In-Reply-To: From: Jonathan Wakely Date: Fri, 16 Jul 2021 12:29:35 +0100 Message-ID: Subject: Re: [committed] libstdc++: Suppress pedantic warnings about __int128 To: Jonathan Wakely Cc: Jakub Jelinek , "libstdc++" , gcc-patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, KAM_NUMSUBJECT, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 11:29:51 -0000 On Fri, 16 Jul 2021 at 09:40, Jonathan Wakely wrote= : > > > > On Fri, 16 Jul 2021, 09:38 Jonathan Wakely, wrote= : >> >> >> >> On Fri, 16 Jul 2021, 09:30 Jakub Jelinek via Libstdc++, wrote: >>> >>> On Fri, Jul 16, 2021 at 10:27:09AM +0200, Jakub Jelinek via Gcc-patches= wrote: >>> > On Fri, Jul 16, 2021 at 08:41:06AM +0100, Jonathan Wakely via Gcc-pat= ches wrote: >>> > > --- a/libstdc++-v3/include/bits/max_size_type.h >>> > > +++ b/libstdc++-v3/include/bits/max_size_type.h >>> > > @@ -417,7 +417,10 @@ namespace ranges >>> > > #endif >>> > > >>> > > #if __SIZEOF_INT128__ >>> > > +#pragma GCC diagnostic push >>> > > +#pragma GCC diagnostic ignored "-Wpedantic" >>> > > using __rep =3D unsigned __int128; >>> > > +#pragma GCC diagnostic pop >>> > >>> > At least in simple cases like this, wouldn't >>> > using __rep =3D __extension__ unsigned __int128; >>> >>> __extension__ using __rep =3D unsigned __int128; >>> actually (now tested). >> >> >> Ah, thanks. I didn't find the right syntax, and I know __extension__ doe= sn't work in other cases, like quad float literals, so I assumed it doesn't= work here. I suppose the literals don't work because the warning comes fro= m the processor, which doesn't understand __extension__ (and also ignores t= he diagnostic pragma). > > > That grammar for a using-declaration makes no sense at all btw ;-) Hmm, in fact it seems that we can just use the __uint128_t typedef instead, which doesn't give a pedwarn: using __rep =3D __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 >=3D 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? We can still use __extension__ elsewhere, for defining explicit specializations using the non-standard integers, e.g. #define __INT_N(TYPE) \ + __extension__ \ template<> \ struct __is_integer \ { \ enum { __value =3D 1 }; \ typedef __true_type __type; \ };