From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id 8CB5A3861812; Fri, 30 Apr 2021 20:18:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8CB5A3861812 Received: by mail-lf1-x12b.google.com with SMTP id n138so112071751lfa.3; Fri, 30 Apr 2021 13:18:32 -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=nAvI6AIK5XCVded7mCNhmOjRrQUyQnUxdH3Vh2lwkBo=; b=OCYSqh4qywncwDB4Zws524MEYjpplTQL7iwvPHjbHm6G6ii61kWtlxAZQffIjkI2f6 god4t0DEFdEZ3XWDeWDcRpqQHuW0ieysc+RJmQiNUPTo0g7gC+gC13iDPCoMnRuw1B7Z euvDw0R46PyhyK/r+WdUKfKsHuOVG6JgbZsnWyFsoPmqaeJbPA9FiYh1OfvAxInSLtWC E1ksydkrFU8Q4NgV+XPEx83IP7o+KQxeacSxmFyh0aJDLeRDvsPySHg2z4wycIOpIuU3 QgGQ+rolHs75nd1DSe9VPoDYK65qxz4vFKZP2r3qxXJDc2Enuaqsh8OfTRG9ytb1Llgj aGWg== X-Gm-Message-State: AOAM531+0PutPldORtIa/3Y3OzAKbkLo9nlnS1vFi2VfPCvV1ODB8be1 EjKW7fiQqa7hWGONiQHc0ep73cweMK0eudAJz+s= X-Google-Smtp-Source: ABdhPJyA0a8o7va1GYQjLSIwHTnTFr2rnGeBb/kOL4GGXwo9Ed03I/5RSC1ZPkC3mCUe4eIEYYlONuOvYDxFWHahl6g= X-Received: by 2002:ac2:41c4:: with SMTP id d4mr4343424lfi.334.1619813911226; Fri, 30 Apr 2021 13:18:31 -0700 (PDT) MIME-Version: 1.0 References: <20210106193746.GD725145@tucnak> <20210106214159.GF725145@tucnak> <20210106233937.GH725145@tucnak> <20210106234549.GA3748@tucnak> <20210108183703.GF9471@redhat.com> <20210430193129.GC3008@redhat.com> In-Reply-To: <20210430193129.GC3008@redhat.com> From: David Edelsohn Date: Fri, 30 Apr 2021 16:18:20 -0400 Message-ID: Subject: Re: [PATCH, libstdc++] GLIBCXX_HAVE_INT64_T To: Jonathan Wakely Cc: Jakub Jelinek , Iain Sandoe , "libstdc++" , GCC Patches , "CHIGOT, CLEMENT" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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: Fri, 30 Apr 2021 20:18:34 -0000 On Fri, Apr 30, 2021 at 3:31 PM Jonathan Wakely wrote: > > On 29/04/21 16:06 -0400, David Edelsohn wrote: > >On Fri, Jan 8, 2021 at 1:37 PM Jonathan Wakely wrote: > >> > >> On 06/01/21 19:41 -0500, David Edelsohn wrote: > >> >Thanks for clarifying the issue. > >> > > >> >As you implicitly point out, GCC knows the type of INT64 and defines > >> >the macro __INT64_TYPE__ . The revised code can use that directly, > >> >such as: > >> > > >> >#if defined(_GLIBCXX_HAVE_INT64_T_LONG) \ > >> > || defined(_GLIBCXX_HAVE_INT64_T_LONG_LONG) > >> > typedef __INT64_TYPE__ streamoff; > >> > #elif defined(_GLIBCXX_HAVE_INT64_T) > >> > typedef int64_t streamoff; > >> > #else > >> > typedef long long streamoff; > >> > #endif > >> > > >> >Are there any additional issues not addressed by that approach, other > >> >than possible further simplification? > >> > >> That avoids the ABI break that Jakub pointed out. But I think we can > >> simplify it further, as in the attached patch. > >> > >> This uses __INT64_TYPE__ if that's defined, and long long otherwise. I > >> think that should be equivalent in all practical cases (I can imagine > >> some strange target where __INT64_TYPE__ is defined by the compiler, > >> but int64_t isn't defined when the configure checks look for it, and > >> so the current code would use long long and with my patch would use > >> __INT64_TYPE__ which could be long ... but I think in practice that's > >> unlikely. It was probably more likely in older releases where the > >> configure test would have been done with -std=gnu++98 and so int64_t > >> might not have been declared by libc's , but if that was the > >> case then any ABI break it caused happened years ago. > > > >Hi, Jonathan > > > >Polite ping. > > > >Now that GCC 11.1 has been released, can this patch be applied to > >libstdc++? As I replied at the time to Jakub's concerns, both Clang > >(since 3.0.0) and ICC (since at least 16.0.0) have defined > >__INT64_TYPE__ . > > Pushed to trunk after testing on x86_64-linux and powerpc-aix. Hi, Jonathan Thanks very much! It's very helpful to remove the multilib differences. I'll follow up about the int128 change in a separate email. Thanks, David