[libcxx-commits] [PATCH] D110738: [libc++] [P1614] Implement the first half of [cmp.alg]: strong_order, weak_order, partial_order.

[Kent Ross via Phabricator via libcxx-commits]

mumbleskates added inline comments.


================
Comment at: libcxx/test/std/language.support/cmp/cmp.alg/strong_order.pass.cpp:448
+    static_assert(test_1_3<double>());
+    // static_assert(test_1_3<long double>());  // UNIMPLEMENTED
+    static_assert(test_1_4());
----------------
Mordante wrote:
> Quuxplusone wrote:
> > @Mordante writes:
> > > For long double would it be possible to use an `__int128_t` when available? (Obviously this can't be `bit_cast`-ed.)
> > 
> > Yeah, `long double` on x86-64 has 80 value bits and 48 padding bits, so it can't be bit-casted straight to 128-bit `__int128_t`. We //can// bit-cast it to an array of char and then inspect the bytes individually; but then we have to be really confident about how they're arranged in memory (endianness? which side does the padding wind up on?) and I haven't done that homework.
> > Orthogonally, on non-IEC559 (non-IEEE754) platforms like I believe PPC64, `long double` is actually represented in memory as a //pair// of IEEE754 `double` values with different exponents, and then to find the `long double`'s value, you add them together. In which case I haven't even bothered to think about what the correct `strong_order` algorithm would look like. (It might be exactly what I've got for the non-IEEE754 codepath, and then still tiebroken by "bit_cast and memcmp." But I haven't thought about it.) 
> > So I would prefer to leave `long double` unimplemented in //this// PR; and then either we solicit an implementation from someone who claims to know what they're doing, or else eventually I get bored and submit something (and then we wait for //bugfixes// from someone who knows what they're doing). :)
> > So I would prefer to leave `long double` unimplemented in //this// PR; and then either we solicit an implementation from someone who claims to know what they're doing, or else eventually I get bored and submit something (and then we wait for //bugfixes// from someone who knows what they're doing). :)
> 
> Sounds fine to me to not do `long double` in this PR. That sounds like the SO method, do it wrong and wait for people pointing out why it's wrong ;-)
I could gin up some asserts for confirming the standard layout of an intel `long double`. Not 100% sure how to do that `constexpr` but I think it's doable.

`long double` on my ARM device(s) is a true iec559 quad precision type, and should be implementable in the same way as the others by `bit_cast`ing to `__int128_t` in this layout.

I find that layout for PPC `long double` hilarious, but thankfully the standard specifies that `strong_order` is not required at all for non-iec559 numeric types, so we can simply leave it out and don't have to worry about ever implementing those types unless it is added to the standard draft as a mandate in the future.

All this to say I'm happy to help pushing on this todo for our supported platforms, and I agree that we probably shouldn't get it in with this diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110738