From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sourceware.org (Postfix) with ESMTPS id 65E0F393C85F; Sat, 22 Aug 2020 15:01:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 65E0F393C85F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=inria.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=marc.glisse@inria.fr X-IronPort-AV: E=Sophos;i="5.76,341,1592863200"; d="scan'208";a="357042073" Received: from 85-171-191-139.rev.numericable.fr (HELO stedding) ([85.171.191.139]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2020 17:00:59 +0200 Date: Sat, 22 Aug 2020 17:00:59 +0200 (CEST) From: Marc Glisse X-X-Sender: glisse@stedding.saclay.inria.fr Reply-To: libstdc++@gcc.gnu.org To: Jonathan Wakely cc: libstdc++ , gcc-patches Subject: Re: [committed] libstdc++: Make __int128 meet integer-class requirements [PR 96042] In-Reply-To: Message-ID: References: <20200819160004.GA11512@redhat.com> User-Agent: Alpine 2.23 (DEB 453 2020-06-18) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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 15:01:17 -0000 On Sat, 22 Aug 2020, Jonathan Wakely via Gcc-patches wrote: > On Sat, 22 Aug 2020 at 13:13, Jonathan Wakely wrote: >> >> 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?) > > Oh I remember why I didn't do that now. I did actually want to do it > that way initially. > > The macros like __GLIBCXX_TYPE_INT_N_0 are not defined in strict mode, > so we have no generic way to name those types. IIRC, those macros were introduced specifically to help libstdc++. If libstdc++ wants them defined in different circumstances, it should be fine to change the condition from "!flag_iso || int_n_data[i].bitsize == POINTER_SIZE" to whatever you need. But now I understand why you did this, thanks. -- Marc Glisse