From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id F1A6238438A3 for ; Fri, 8 Jan 2021 20:00:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F1A6238438A3 Received: by mail-wm1-x332.google.com with SMTP id 3so9402839wmg.4 for ; Fri, 08 Jan 2021 12:00:39 -0800 (PST) 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=ywMKXHtgVNxz3X6ENnvdHB0vofEh91r7YAGDIruZIUs=; b=ZxuR/OBvUDqwWOPR9hfC/wT0UFcv1IpCpeYuhWJg5jE7BGdosg5jijYyIEoIpdOYuX 4BnkCFuwdnMnZjMb3134rhGZqeIPybNWvv2b2Kyd7UrWx1cDbGJ7IPOnbnnjULlI4T/p rNjN6kxG3kV4QAvp9Ti0gdD8+KagPuXswOxnj6x0uMicA1x41t22GMz9Yn2k8kB5LW9v dww2287sBDlZMetJY/JRLjcRhO8F2oQNiua04Y/iA3kRfpbCwguu2bQSZzED/Q4ndR4t AH0vxb+1zeImKJu65T+ZoxTD0LX4AKurGt8NJfGLoXRI3J0AZ+h2igUn2+eVpSNa5XuD z3Bg== X-Gm-Message-State: AOAM532+R8I2eGhy6mmn74T9R9VH1eC+AJG6FImHwMXZJQWfns2my5uX iIFpfY1tB8UdiNCvfJhLBte+aaJ8bPlpaG9Qi34= X-Google-Smtp-Source: ABdhPJyO8jG+1e4Jpu37ZU7+c2e1AfIwnJtFz8eQ6Ma+DCr8N+wpkQ6Z0cvkSoW1gydSi0kcI4HHbPmQsSDS6tS/NRM= X-Received: by 2002:a1c:bc57:: with SMTP id m84mr4426849wmf.163.1610136039061; Fri, 08 Jan 2021 12:00:39 -0800 (PST) MIME-Version: 1.0 References: <20210108160959.GD9471@redhat.com> In-Reply-To: <20210108160959.GD9471@redhat.com> From: David Edelsohn Date: Fri, 8 Jan 2021 15:00:27 -0500 Message-ID: Subject: Re: [libstdc++] Inconsistent detection of __int128 To: Jonathan Wakely Cc: Jonathan Wakely , "libstdc++" , Iain Sandoe , "CHIGOT, CLEMENT" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 08 Jan 2021 20:00:41 -0000 On Fri, Jan 8, 2021 at 11:10 AM Jonathan Wakely wrote: > > On 03/01/21 22:26 -0500, David Edelsohn via Libstdc++ wrote: > >On Sun, Jan 3, 2021 at 9:45 PM Jonathan Wakely wrote: > >> > >> On Mon, 4 Jan 2021, 00:44 David Edelsohn via Libstdc++, wrote: > >>> > >>> Or is there some other reason that _GLIBCXX_USE_INT128 and > >>> __SIZEOF_INT128__ are used in different contexts? > >> > >> Yes. > >> > >> I'll reply when I'm back from taking some time off. Probably Wednesday. > > > >If the uses of _GLIBCXX_USE_INT128 in libstdc++ headers specifically > >are checking if __int128 type is different than "long" and "long > >long", as opposed to the availability of the __int128, can c++config.h > > Yes, the test is not just "is __int128 a valid type?" but "should we > use __int128 as a larger integer type?" > > We used to use it more widely, but many places that use __int128 > conditionally now check __GLIBCXX_INT_N_0 instead, because that is > defined when __int128 is available and we're not compiling in a > "strict ansi" dialect. > > Of the two remaining uses of _GLIBCXX_USE_INT128 I think one is wrong > and should test __SIZEOF__INT128__ directly. We specifically do want > to use unsigned __int128 in __to_chars_unsigned_type even if it's the > same as a standard type. > > So that leaves one remaining use, and I think that should do as you > suggest here ... > > >define _GLIBCXX_USE_INT128 by comparing __SIZEOF_INT128__ to > >__SIZEOF_LONG_LONG__ and __SIZEOF_LONG__ instead of the libstdc++ > >configure template typename test? > > Yes, that seems fine. But since we only need it in one place, let's > just do that test in that one place. It makes the purpose of the test > more explicit, and so you don't need to look up what > _GLIBCXX_USE_INT128 means and when it's true. > > Does the attached patch work for you? Hi, Jonathan Thanks for carefully investigating this further. This cleanup and patch look good from an AIX-perspective. It definitely clarifies the purpose and it's good to remove gratuitous differences and unnecessary macros. Thanks, David