Fix `compiler_rt_logbf_test.c` test failure for Builtins-i386-darwin test suite.

Summary:
It seems that compiler-rt's implementation and Darwin
libm's implementation of `logbf()` differ when given a NaN
with raised sign bit. Strangely this behaviour only happens with
i386 Darwin libm. For x86_64 and x86_64h the existing compiler-rt
implementation matched Darwin libm.

To workaround this the `compiler_rt_logbf_test.c` has been modified
to do a comparison on the `fp_t` type and if that fails check if both
values are NaN. If both values are NaN they are equivalent and no
error needs to be raised.

rdar://problem/55565503

Reviewers: rupprecht, scanon, compnerd, echristo
Subscribers: #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D67999

llvm-svn: 374109

compiler-rt/test/builtins/Unit/compiler_rt_logbf_test.c

@@ -13,15 +13,19 @@
 //===----------------------------------------------------------------------===//
 
 #define SINGLE_PRECISION
+#include "fp_lib.h"
+#include "int_math.h"
 #include <math.h>
 #include <stdio.h>
-#include "fp_lib.h"
 
 int test__compiler_rt_logbf(fp_t x) {
   fp_t crt_value = __compiler_rt_logbf(x);
   fp_t libm_value = logbf(x);
-  // Compare actual rep, e.g. to avoid NaN != the same NaN
-  if (toRep(crt_value) != toRep(libm_value)) {
+  // `!=` operator on fp_t returns false for NaNs so also check if operands are
+  // both NaN. We don't do `toRepr(crt_value) != toRepr(libm_value)` because
+  // that treats different representations of NaN as not equivalent.
+  if (crt_value != libm_value &&
+      !(crt_isnan(crt_value) && crt_isnan(libm_value))) {
     printf("error: in __compiler_rt_logb(%a [%X]) = %a [%X] !=  %a [%X]\n", x,
            toRep(x), crt_value, toRep(crt_value), libm_value,
            toRep(libm_value));