libgpg-error 1.61: t-printf failure on powerpc64-linux

[C. Neidahl]

> It's also in little-endian, I suppose.
Well, yes and no.

If usage of the VSX extension is enabled, then an IEEE-compliant 128-bit 
floating-point type is made available [0]. Glibc can be configured to 
use that type for long double, and i.e. Fedora has made that switch for 
its powerpc64le-linux target [1].

powerpc64-linux should be available on systems that predate the VSX 
extension though, so the default for those is generally still the IBM 
double-double. For example, the machine that I'm testing things on is an 
Apple Power Mac G5 from 2005, which lacks both VSX and the option to 
switch to little-endian mode without bricking the system. As a result of 
that, powerpc64le-linux is not something that I can test in any way, but 
I'm still *somewhat* aware of it.

 > +# ifdef __powerpc64__
 > +  if (verbose)
 > +    show ("IBM double-double - skipping LDBL_MAX test\n");

I suppose the most exact check for this situation would have to inspect 
some more LDBL_* 
defines, otherwise 128-bit IEEE-backed long double 
would end up not getting checked.

The GCC on my machine, after importing <float.h> with C23 enabled, defines:

#define __LDBL_IS_IEC_60559__ 0
#define LDBL_IS_IEC_60559 __LDBL_IS_IEC_60559__
#define __LONG_DOUBLE_IBM128__ 1

LDBL_IS_IEC_60559 of 0 indicates that the long double type does not 
match an IEC 60559 format (1: format, but not operation; 2: format and 
operation) [2]. The rest of the floating-point types have their 
corresponding defines at 1 on my system.

By comparison, a powerpc64le-linux GCC cross toolchain on my main system 
gives:

#define __LDBL_IS_IEC_60559__ 1
#define LDBL_IS_IEC_60559 __LDBL_IS_IEC_60559__
#define __LONG_DOUBLE_IEEE128__ 1

Doesn't seem like Clang itself implements LDBL_IS_IEC_60559, but you use 
gnulib, which handles that. It sets LDBL_IS_IEC_60559 to 0 with 
x86_64-linux Clang due to the 80-bit floating-point type, while 
x86_64-linux GCC sets it to 1 with the same type,
 so there's some 
discrepancies on other platforms though... So maybe:


diff --git a/tests/t-printf.c b/tests/t-printf.c
index b0a3f3f..79f6470 100644
--- a/tests/t-printf.c
+++ b/tests/t-printf.c
@@ -469,7 +469,13 @@ check_large_float (void)
      show ("format \"%%.100Lf\" with DBL_MAX: ->%s<-\n", buf);
    gpgrt_free (buf);

-# ifdef HAVE_LONG_DOUBLE_WIDER
+# if defined(__powerpc64__) && !LDBL_IS_IEC_60559
+  if (verbose)
+    show ("IBM double-double - skipping LDBL_MAX test\n");
+# elif !defined(HAVE_LONG_DOUBLE_WIDER)
+  if (verbose)
+    show ("LDBL_MAX == DBL_MAX - skipping LDBL_MAX test\n");
+# else
    ld = LDBL_MAX;
    buf = gpgrt_bsprintf ("%.100Lf\n", ld);
    if (buf)
@@ -479,9 +485,6 @@ check_large_float (void)
    else if (verbose)
      show ("format \"%%.100Lf\" with LDBL_MAX failed as expected\n");
    gpgrt_free (buf);
-# else
-  if (verbose)
-    show ("LDBL_MAX == DBL_MAX - skipping LDBL_MAX test\n");
  # endif

  #endif /*HAVE_LO
NG_DOUBLE*/


[0]: https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
[1]: 
https://fedoraproject.org/wiki/Releases/36/ChangeSet#New_128-bit_IEEE_long_double_ABI_for_IBM_64-bit_POWER_LE
[2]: 
https://github.com/gcc-mirror/gcc/blob/b77cf8f055cce3e42f09410cbbf1e4f1e196b25d/gcc/c-family/c-cppbuiltin.cc#L321-L323
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - opna2608 at protonmail.com - 0xC802C863.asc
Type: application/pgp-keys
Size: 1753 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260715/79644847/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 583 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260715/79644847/attachment-0001.sig>