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

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

Quuxplusone added inline comments.


================
Comment at: libcxx/test/std/language.support/cmp/cmp.alg/strong_order.pass.cpp:353
+        assert(std::strong_order(nq, nq) == std::strong_ordering::equal);
+        assert(std::strong_order(nq, ns) == std::strong_ordering::less);
+        for (int i=0; i < 14; ++i) {
----------------
Quuxplusone wrote:
> This fails for `float` on the 32-bit x86 buildkite:
> https://reviews.llvm.org/harbormaster/unit/view/1389305/
> (And maybe other cases would fail after this one, but buildkite won't tell us.)
> Anyone got any leads on why this might be? When I try it on Godbolt, it seems OK: https://godbolt.org/z/7eEcnWev7
Now I can reproduce it: https://godbolt.org/z/f17a5GzM9
The problem is that when `-m32`, the bit-pattern of `numeric_limits<float>::signaling_NaN()` depends on optimization level. At `-O1` the bit-pattern is `0x7fa00000`. At `-O0` it is `0x7fe00000`, which is actually //not// a signaling NaN at all!
This seems to be a problem with `__builtin_nansf("")` on `-m32`: https://godbolt.org/z/cTjqxeG1T
And googling //that// turns up: https://stackoverflow.com/questions/22816095/signalling-nan-was-corrupted-when-returning-from-x86-function-flds-fstps-of-x87

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484#c12
> This issue is unfortunately unfixable. x87 and x86-32 ABI are just not designed to handle all details of IEEE 754 standard.

So it looks like the appropriate workaround here is just to ifdef out the offending NaN tests on x86-32 targets.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110738