From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) by sourceware.org (Postfix) with ESMTPS id 744A9385701E; Sat, 22 Aug 2020 12:13:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 744A9385701E Received: by mail-il1-x135.google.com with SMTP id f75so3273392ilh.3; Sat, 22 Aug 2020 05:13: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=5QSwUIkCLjsPuFu71p3ZF0BYG4hvWfeWlchf2LA4UcI=; b=H/k1EUNVwTCUgYkLrBIDzIDl8N5wS6u1JsU4hUvlc25X+VX/FbRImnBSnUH2g6RDG0 CzFwafcS8wXGRDgT/cO1NOGdyHYVrkN9lPJ+5lSlZB1vJlnTOs8f9tdGd4/zewKsxq85 OQdryjlmHhUYhdsJfSZm8pV6worRUVXwvp78szF3wA0NHBYV+dnLKFiQ8daoBr0eL3x6 Ss5hRaEiIfzNZTcFgGkkLieE6+Bes4apzI1e6TY2VildK38gdr6xeafuvTzMTgpqNbPf rwbZs9+cWcKYXmS0wpgefs3QoHltb/PYepEI/o/d6eeNp/Z9qRyNcr+uD3RYqCkdn6/Z eebg== X-Gm-Message-State: AOAM533xQJ/k0eEj2SdnEt14+mX46nO2fa99zpDjOusuQ4XDyDl//Lhb z4Ul0fKV4VoR/zaetWchMY4lPVHTIcC2EZLFlkmp5uslzeDjpg== X-Google-Smtp-Source: ABdhPJxmfA0QvdWbbcpMlat9ItL1jdr89JHbRqJPFeXPbdxgoo7qEygwIHldDN/L9a7I3lS091xrZxQTvZbGnJqurVg= X-Received: by 2002:a05:6e02:13ee:: with SMTP id w14mr6347553ilj.4.1598098420724; Sat, 22 Aug 2020 05:13:40 -0700 (PDT) MIME-Version: 1.0 References: <20200819160004.GA11512@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Sat, 22 Aug 2020 13:13:29 +0100 Message-ID: Subject: Re: [committed] libstdc++: Make __int128 meet integer-class requirements [PR 96042] To: "libstdc++" Cc: gcc-patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2020 12:13:42 -0000 On Sat, 22 Aug 2020 at 10:52, Marc Glisse wrote: > is there a particular reason to handle only __int128 this way, and not all > the non-standard integer types? It looks like it would be a bit simpler to > avoid a special case. I have no objection to doing it for all of them, it just wasn't necessary to solve the immediate problem that the library now uses __int128 even when integral<__int128> is false. (Hmm, or is size_t an alias for __int20 on one arch, which would mean we do use it?) In case you didn't see it, I've created https://gcc.gnu.org/PR96710 to try and make our treatment of __int128 a bit more useful and consistent. Even if it's not a standard integer type, it's definitely an object type. And although it doesn't fit the standard's definition of a scalar type, I think it should (I prefer to think of scalar types as objects that aren't classes or arrays, rather than the list of specific types in the standard that attempts to be exhaustive). What we do for __int128 could/should be done for the other non-standard integers. I really wish WG14 would just fix the intmax_t mess so we can make them integral types unconditionally.