[libc++] Replace __ppc64__ with __powerpc64__ and fix is_iec559 for non-ibm128

[MaskRay]

Summary

The lowercase __ppc64__ is not defined by non-darwin powerpc64 GCC, therefore
it lures users to write code which is not portable to GCC. Migrate to
__powerpc64__ in preparation for undefining __ppc64__. __powerpc64__ is
much more common than __PPC64__.

Update alignment_of.pass.cpp to use 1 unconditionally:
on powerpc-unknown-linux-gnu alignof(bool) = _Alignof(bool) = __alignof(bool) = 1.
The value 4 might be derived from an ancient Clang.

Change is_iec559 to true when long double uses uses IEEE 754 quadruple or double
precision (i.e. not ibm128).

[q66]

how about fixing this properly while at it?

the reason is_iec559 is false for powerpc is that on glibc, the IBM 128-bit double-double format is not compliant; however, on musl, long double is 64-bit and equal to double, which means the value should be true there

in chimera i have the following patch: https://github.com/chimera-linux/cports/blob/master/main/llvm/patches/0017-libc-treat-long-doubles-as-IEEE754-on-musl-ppc.patch

i am not sure if there is some better way to make this work...

[q66]

(this patch also accounts for glibc setups that use the real quad-precision ieee754 long doubles, which is possible since some time ago, natively in hardware starting with POWER9 - e.g. fedora defaults to that now, as far as i know - the logic here checks for two conditions - having a larger exponent indicates real ieee754 quad float as double-double's is identical to double, while having the same amount of mantissa digits indicates that long double is equal to double)

[MaskRay]

In D137513#3912878, @q66 wrote:

(this patch also accounts for glibc setups that use the real quad-precision ieee754 long doubles, which is possible since some time ago, natively in hardware starting with POWER9 - e.g. fedora defaults to that now, as far as i know - the logic here checks for two conditions - having a larger exponent indicates real ieee754 quad float as double-double's is identical to double, while having the same amount of mantissa digits indicates that long double is equal to double)

I think there are 3 modes.

• -mlong-double-64
• -mlong-double-128 -mabi=ieeelongdouble
• -mlong-double-128 -mabi=ibmlongdouble

If -mlong-double-128 -mabi=ieeelongdouble should define is_iec559 as well, we can detect IBM128 with defined(__LONG_DOUBLE_IBM128__).

[q66]

yes, my patch effectively accounts for both modes; -mabi=ieeelongdouble is accounted for with the first expression (__LDBL_MAX_EXP__ > __DBL_MAX_EXP__; with ibmlongdouble, it is true that __LDBL_MAX_EXP__ == __DBL_MAX_EXP__) while -mlong-double-64 is accounted for with the second expression (__LDBL_MANT_DIG__ == __DBL_MANT_DIG__)

[q66]

but you are right; that means you can simply change you patch to use #if defined(__powerpc__) && defined(__LONG_DOUBLE_IBM128__) instead of #ifdef __powerpc__ and it will be fully correct

i was not aware of the existence of that macro

[MaskRay]

Use #if defined(__powerpc__) && defined(__LONG_DOUBLE_IBM128__).

Technically __powerpc__ is redundant but the check makes it clear it's powerpc specific.

[MaskRay]

Ping #libc

[ldionne]

The CI failure looks unrelated. LGTM, thanks for the cleanup.

libcxx/include/limits

protected:
     static _LIBCPP_CONSTEXPR const bool has_signaling_NaN = true;
     static _LIBCPP_CONSTEXPR const float_denorm_style has_denorm = denorm_present;
     static _LIBCPP_CONSTEXPR const bool has_denorm_loss = false;
     _LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type infinity() _NOEXCEPT {return __builtin_huge_vall();}
     _LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type quiet_NaN() _NOEXCEPT {return __builtin_nanl("");}
     _LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type signaling_NaN() _NOEXCEPT {return __builtin_nansl("");}
     _LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type denorm_min() _NOEXCEPT {return __LDBL_DENORM_MIN__;}
 
-#if (defined(__ppc__) || defined(__ppc64__))
+#if defined(__powerpc__) && defined(__LONG_DOUBLE_IBM128__)
     static _LIBCPP_CONSTEXPR const bool is_iec559 = false;
 #else
     static _LIBCPP_CONSTEXPR const bool is_iec559 = true;
 #endif
     static _LIBCPP_CONSTEXPR const bool is_bounded = true;
     static _LIBCPP_CONSTEXPR const bool is_modulo = false;
 
     static _LIBCPP_CONSTEXPR const bool traps = false;

libcxx/test/std/language.support/support.limits/limits/numeric.limits.members/is_iec559.pass.cpp

#endif
     test<long long, false>();
     test<unsigned long long, false>();
 #ifndef TEST_HAS_NO_INT128
     test<__int128_t, false>();
     test<__uint128_t, false>();
 #endif
     test<float, true>();
     test<double, true>();
-#if (defined(__ppc__) || defined(__ppc64__))
+#if defined(__powerpc__) && defined(__LONG_DOUBLE_IBM128__)
     test<long double, false>();
 #else
     test<long double, true>();
 #endif
 
   return 0;
 }

libcxx/test/std/utilities/meta/meta.unary.prop.query/alignment_of.pass.cpp

 int main(int, char**)
 {
     test_alignment_of<int&, 4>();
     test_alignment_of<Class, 1>();
     test_alignment_of<int*, sizeof(intptr_t)>();
     test_alignment_of<const int*, sizeof(intptr_t)>();
     test_alignment_of<char[3], 1>();
     test_alignment_of<int, 4>();
-    // The test case below is a hack. It's hard to detect what golden value
-    // we should expect. In most cases it should be 8. But in i386 builds
-    // with Clang >= 8 or GCC >= 8 the value is '4'.
     test_alignment_of<double, TEST_ALIGNOF(double)>();
-#if (defined(__ppc__) && !defined(__ppc64__) && !defined(_AIX))
-    test_alignment_of<bool, 4>();   // 32-bit PPC has four byte bool, except on AIX.
-#else
     test_alignment_of<bool, 1>();
-#endif
     test_alignment_of<unsigned, 4>();
 
   return 0;
 }