Message ID | 20220118101220.3578219-2-jwakely@redhat.com |
---|---|
State | Committed |
Commit | 8f6b62e0f0c99e421d07bf1847259744db22924b |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 982883857C4D for <patchwork@sourceware.org>; Tue, 18 Jan 2022 10:15:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 982883857C4D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1642500935; bh=T4UuKbzTWePMNIFEAtFud9hi7J+ZuK8UswtEK69aVbc=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=o0Bxuu5P7FSj8VdFW2wwFPXd01FOQG7ihU7ODDjOAVoU73kUTKLomUiVtPUas4kd3 K+veH8q1/zxRG0beCfJQIFogIyyUyV1ICUZjAiOl9jFT8zKGNT8hwpYkgXc/WJmzpk jyG0egVcgdbUVo8C+76xT/cI3SGOfUL4jVN3aNMw= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id B70AF3858020 for <gcc-patches@gcc.gnu.org>; Tue, 18 Jan 2022 10:12:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B70AF3858020 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-647-rbaqtathMo-kn3L8uS9cuw-1; Tue, 18 Jan 2022 05:12:25 -0500 X-MC-Unique: rbaqtathMo-kn3L8uS9cuw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EDF941019983; Tue, 18 Jan 2022 10:12:23 +0000 (UTC) Received: from localhost (unknown [10.33.37.93]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9DC111059172; Tue, 18 Jan 2022 10:12:23 +0000 (UTC) To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: [committed 2/2] libstdc++: Use GCC's predefined macro for endianness [PR104080] Date: Tue, 18 Jan 2022 10:12:20 +0000 Message-Id: <20220118101220.3578219-2-jwakely@redhat.com> In-Reply-To: <20220118101220.3578219-1-jwakely@redhat.com> References: <20220118101220.3578219-1-jwakely@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII" X-Spam-Status: No, score=-13.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Jonathan Wakely via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Jonathan Wakely <jwakely@redhat.com> Cc: hp@gcc.gnu.org Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
[committed,1/2] libstdc++: Fix deduction failure for std::min call [PR104080]
|
|
Commit Message
Jonathan Wakely
Jan. 18, 2022, 10:12 a.m. UTC
Tested x86_64-linux, pushed to trunk. Instead of hardcoded preprocessor conditionals with explicit target checks, just rely on the fact that __BYTE_ORDER__ is always defined by GCC. libstdc++-v3/ChangeLog: PR libstdc++/104080 * src/c++17/fast_float/LOCAL_PATCHES: Update. * src/c++17/fast_float/fast_float.h (FASTFLOAT_IS_BIG_ENDIAN): Define in terms of __BYTE_ORDER__. --- libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES | 1 + libstdc++-v3/src/c++17/fast_float/fast_float.h | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-)
Comments
On Tue, Jan 18, 2022 at 5:12 AM Jonathan Wakely <jwakely@redhat.com> wrote: > > Tested x86_64-linux, pushed to trunk. > > > Instead of hardcoded preprocessor conditionals with explicit target > checks, just rely on the fact that __BYTE_ORDER__ is always defined by > GCC. Thanks a lot for fixing these! I apparently missed removing this batch of #includes from the amalgamation in r12-6647. For completeness I suppose we should remove these #includes too. I wonder if we can rely on __BYTE_ORDER__ being defined by other compilers? > > libstdc++-v3/ChangeLog: > > PR libstdc++/104080 > * src/c++17/fast_float/LOCAL_PATCHES: Update. > * src/c++17/fast_float/fast_float.h (FASTFLOAT_IS_BIG_ENDIAN): > Define in terms of __BYTE_ORDER__. > --- > libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES | 1 + > libstdc++-v3/src/c++17/fast_float/fast_float.h | 4 +++- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES > index 447c7ed2cdb..5bb42933398 100644 > --- a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES > +++ b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES > @@ -1,3 +1,4 @@ > r12-6647 > r12-6648 > r12-6664 > +r12-6665 > diff --git a/libstdc++-v3/src/c++17/fast_float/fast_float.h b/libstdc++-v3/src/c++17/fast_float/fast_float.h > index ee129309ba3..31fb88b8aba 100644 > --- a/libstdc++-v3/src/c++17/fast_float/fast_float.h > +++ b/libstdc++-v3/src/c++17/fast_float/fast_float.h > @@ -128,7 +128,9 @@ from_chars_result from_chars_advanced(const char *first, const char *last, > #define FASTFLOAT_VISUAL_STUDIO 1 > #endif > > -#ifdef _WIN32 > +#ifdef __BYTE_ORDER__ > +#define FASTFLOAT_IS_BIG_ENDIAN (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) > +#elif defined _WIN32 > #define FASTFLOAT_IS_BIG_ENDIAN 0 > #else > #if defined(__APPLE__) || defined(__FreeBSD__) > -- > 2.31.1 >
On Tue, 18 Jan 2022, Patrick Palka wrote: > On Tue, Jan 18, 2022 at 5:12 AM Jonathan Wakely <jwakely@redhat.com> wrote: > > > > Tested x86_64-linux, pushed to trunk. > > > > > > Instead of hardcoded preprocessor conditionals with explicit target > > checks, just rely on the fact that __BYTE_ORDER__ is always defined by > > GCC. > > Thanks a lot for fixing these! I apparently missed removing this > batch of #includes from the amalgamation in r12-6647. For > completeness I suppose we should remove these #includes too. I > wonder if we can rely on __BYTE_ORDER__ being defined by other > compilers? (N.B. not just for completeness but potentially also for correctness, since floating_from_chars.cc #includes "fast_float/fast_float.h" into an anonymous namespace, and we probably shouldn't be #including system headers into an anonymous namespace..) > > > > > libstdc++-v3/ChangeLog: > > > > PR libstdc++/104080 > > * src/c++17/fast_float/LOCAL_PATCHES: Update. > > * src/c++17/fast_float/fast_float.h (FASTFLOAT_IS_BIG_ENDIAN): > > Define in terms of __BYTE_ORDER__. > > --- > > libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES | 1 + > > libstdc++-v3/src/c++17/fast_float/fast_float.h | 4 +++- > > 2 files changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES > > index 447c7ed2cdb..5bb42933398 100644 > > --- a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES > > +++ b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES > > @@ -1,3 +1,4 @@ > > r12-6647 > > r12-6648 > > r12-6664 > > +r12-6665 > > diff --git a/libstdc++-v3/src/c++17/fast_float/fast_float.h b/libstdc++-v3/src/c++17/fast_float/fast_float.h > > index ee129309ba3..31fb88b8aba 100644 > > --- a/libstdc++-v3/src/c++17/fast_float/fast_float.h > > +++ b/libstdc++-v3/src/c++17/fast_float/fast_float.h > > @@ -128,7 +128,9 @@ from_chars_result from_chars_advanced(const char *first, const char *last, > > #define FASTFLOAT_VISUAL_STUDIO 1 > > #endif > > > > -#ifdef _WIN32 > > +#ifdef __BYTE_ORDER__ > > +#define FASTFLOAT_IS_BIG_ENDIAN (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) > > +#elif defined _WIN32 > > #define FASTFLOAT_IS_BIG_ENDIAN 0 > > #else > > #if defined(__APPLE__) || defined(__FreeBSD__) > > -- > > 2.31.1 > > >
On Tue, Jan 18, 2022 at 02:44:34PM -0500, Patrick Palka via Gcc-patches wrote: > On Tue, Jan 18, 2022 at 5:12 AM Jonathan Wakely <jwakely@redhat.com> wrote: > > > > Tested x86_64-linux, pushed to trunk. > > > > > > Instead of hardcoded preprocessor conditionals with explicit target > > checks, just rely on the fact that __BYTE_ORDER__ is always defined by > > GCC. > > Thanks a lot for fixing these! I apparently missed removing this > batch of #includes from the amalgamation in r12-6647. For > completeness I suppose we should remove these #includes too. I > wonder if we can rely on __BYTE_ORDER__ being defined by other > compilers? clang++ 8 and later defines, them, ICC 16+ too. Jakub
On Tue, 18 Jan 2022 at 20:01, Patrick Palka <ppalka@redhat.com> wrote: > On Tue, 18 Jan 2022, Patrick Palka wrote: > > > On Tue, Jan 18, 2022 at 5:12 AM Jonathan Wakely <jwakely@redhat.com> > wrote: > > > > > > Tested x86_64-linux, pushed to trunk. > > > > > > > > > Instead of hardcoded preprocessor conditionals with explicit target > > > checks, just rely on the fact that __BYTE_ORDER__ is always defined by > > > GCC. > > > > Thanks a lot for fixing these! I apparently missed removing this > > batch of #includes from the amalgamation in r12-6647. For > > completeness I suppose we should remove these #includes too. I > > wonder if we can rely on __BYTE_ORDER__ being defined by other > > compilers? > > We already use it unconditionally in <bit>, for std::endian. I actually considered replacing all the FAST_FLOAT_USES_BIG_ENDIAN preprocessor checks with: if constexpr (std::endian::native == std::endian::big) But it would make the diffs from upstream bigger for no benefit. I did wonder whether some of those functions could avoid doing memcpy then byteswap, if we just swapped the bytes without the memcpy. But GCC probably optimizes that code well anyway, so I didn't even bother checking it. Upstream probably tested that already as well. > (N.B. not just for completeness but potentially also for correctness, > since floating_from_chars.cc #includes "fast_float/fast_float.h" into an > anonymous namespace, and we probably shouldn't be #including system > headers into an anonymous namespace..) > Good point.
diff --git a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES index 447c7ed2cdb..5bb42933398 100644 --- a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES +++ b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES @@ -1,3 +1,4 @@ r12-6647 r12-6648 r12-6664 +r12-6665 diff --git a/libstdc++-v3/src/c++17/fast_float/fast_float.h b/libstdc++-v3/src/c++17/fast_float/fast_float.h index ee129309ba3..31fb88b8aba 100644 --- a/libstdc++-v3/src/c++17/fast_float/fast_float.h +++ b/libstdc++-v3/src/c++17/fast_float/fast_float.h @@ -128,7 +128,9 @@ from_chars_result from_chars_advanced(const char *first, const char *last, #define FASTFLOAT_VISUAL_STUDIO 1 #endif -#ifdef _WIN32 +#ifdef __BYTE_ORDER__ +#define FASTFLOAT_IS_BIG_ENDIAN (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) +#elif defined _WIN32 #define FASTFLOAT_IS_BIG_ENDIAN 0 #else #if defined(__APPLE__) || defined(__FreeBSD__)