[libcxx-commits] [PATCH] D107036: [WIP] [libc++] [P1614] Various unimplemented parts of <compare>. [WIP]

[Arthur O'Dwyer via Phabricator via libcxx-commits]

Quuxplusone added inline comments.


================
Comment at: libcxx/include/__compare/cmp_alg.h:66
+            // These two NaNs should be ordered by their payload bits,
+            // but there's no way to get at that information portably.
+            return _VSTD::signbit(__f) <=> _VSTD::signbit(__e);
----------------
mumbleskates wrote:
> mumbleskates wrote:
> > I would hope that we can order them by union view of the data in memory if such a thing is allowed (or memcpy, if that's better) once we know that the sign and signaling bits are the same, because the specifics of the payload ordering are unspecified by totalOrder. Any way that we can look at the raw data in memory without UB should be sufficient.
> Ah I see, there are literally no standard implementation for the `isSignaling` predicate for iec559 types in C++. However, it does look like ISO C has an `issignaling` macro as part of the Floating-point extensions part 1, which I gather was accepted into the C23 standard in 2019 (ISO/IEC TS 60559-1, of interest section 7.12.3.7). Complete implementation of C++ `strong_order` for iec559 floating point types might be considered to be blocked on the implementation of this part of the standard as that seems like the best place to get it.
> 
> Implementing this just for `strong_order` is messy, very complex, and generally inadvisable. (Even for binary floating point values, ignoring the existence of decimal floating point types, some platforms -- notably PA-RISC -- use the opposite interpretation for the signaling bit in IEC559 floating point types, even though it's in the same location.) Unless we can strongly declare that we don't support any platforms other than say ARM and x86 this seems like a no-go, and it just seems better to take the platform support directly from the llvm C standard implementation.
@mumbleskates: I doubt I understand your two comments. In case it's not already obvious: the IEEE 754 "total order" predicate is well-defined and we //must// implement `std::strong_order` consistently with it, on IEEE 754 platforms, because the Standard says so. (On other platforms, C++ doesn't care so much, because those platforms are dumb. :)) `std::strong_order(x,y)` is //the// way that C++20 exposes the "total order" predicate to end-users; there is no isolable floating-point-total-order library function for us to delegate to (because WG21 doesn't do software engineering).

Is there an isolable "llvm C standard implementation" we could be exploiting here — some kind of `__builtin_totalorder` we could use when it's available? That would be really cool.
I do think that this will eventually need to use either constexpr-friendly `__builtin_memcpy`, or else `std::bit_cast`; I just haven't gotten around to revisiting it.

A bit of googling turned up this solution which maybe just needs to be tweaked a tiny bit: https://stackoverflow.com/a/20154751/1424877



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107036/new/

https://reviews.llvm.org/D107036