From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 8BF063858032 for ; Tue, 18 Jan 2022 20:51:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8BF063858032 Received: from mail-yb1-f197.google.com (mail-yb1-f197.google.com [209.85.219.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-363-4k7eNqi0Ohq4rbcJt1HheA-1; Tue, 18 Jan 2022 15:51:16 -0500 X-MC-Unique: 4k7eNqi0Ohq4rbcJt1HheA-1 Received: by mail-yb1-f197.google.com with SMTP id s38-20020a252d66000000b0061291f9e395so399545ybe.15 for ; Tue, 18 Jan 2022 12:51:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PKzK+EK3QUwPnIvqRF5JyRX0vqnfaWoXeBVmzYjAVUk=; b=WrWYIlTY6iU3G/ylYlXdjpqKMIFwpdbJ7sZeYy3g8Bh/jXFg89GubLvk3+mClmhFuB vNBXXfjd08LjjJGy0gQ4oGit/2DA3D5wIcNzmJBPqsTkRUdEQIuF/hAYHURfIQexajLU lIznGjht8NlgNEPRect3GcqUGORFPOJZrRVZNXJldg70fBCa14fdCXHzm9og1Fsqm14v bf/NQ4ODx2tsnbdRHMG3bqlkr1HYsQ45p+2yRO2lP1/9qFrL4cYyUf8xgpDzmKrYwLIB ZhzWSPt5dspBBKj8Ej8QgU349reEuaAYf/MeAeA61QQmlUEzAKHnFSGsbLlWsNXpcG1v E74A== X-Gm-Message-State: AOAM531LPdr/dJESuIBpzoH0KFKM26xCoQ58kIYgMbpQd8RaAUYvtCEX VMBL80O3MkyRbZIVzzCMUIKdiidpbqQHyP+V4OnyrxwXdP3JLxBCihuA6pic9Ho4wTe5jLu8IDh utTGDtFRIgoRis72xF1cpJMEKNJixhhw= X-Received: by 2002:a25:af0b:: with SMTP id a11mr35478844ybh.667.1642539076127; Tue, 18 Jan 2022 12:51:16 -0800 (PST) X-Google-Smtp-Source: ABdhPJwOCTW5DJCEx86IFyzLzecBHXhV6BiQz8jDrDFAT5p4rsJgF4lY1CyS52XGBlGiwTloZz3huu+10Z0nfz9lodA= X-Received: by 2002:a25:af0b:: with SMTP id a11mr35478824ybh.667.1642539075934; Tue, 18 Jan 2022 12:51:15 -0800 (PST) MIME-Version: 1.0 References: <20220118101220.3578219-1-jwakely@redhat.com> <20220118101220.3578219-2-jwakely@redhat.com> <72d10922-c557-855c-4d86-3b8fca47b100@idea> In-Reply-To: <72d10922-c557-855c-4d86-3b8fca47b100@idea> From: Jonathan Wakely Date: Tue, 18 Jan 2022 20:51:05 +0000 Message-ID: Subject: Re: [committed 2/2] libstdc++: Use GCC's predefined macro for endianness [PR104080] To: Patrick Palka Cc: "Jonathan Wakely via Libstdc++" , GCC Patches , hp@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Tue, 18 Jan 2022 20:51:19 -0000 On Tue, 18 Jan 2022 at 20:01, Patrick Palka wrote: > On Tue, 18 Jan 2022, Patrick Palka wrote: > > > On Tue, Jan 18, 2022 at 5:12 AM Jonathan Wakely > 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 , 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.