On Tue, 18 Jan 2022 at 20:01, Patrick Palka <ppa...@redhat.com> wrote:
> On Tue, 18 Jan 2022, Patrick Palka wrote: > > > On Tue, Jan 18, 2022 at 5:12 AM Jonathan Wakely <jwak...@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.
