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

"C. Neidahl via Gnupg-users" <[email protected]> Wed, 15 Jul 2026 10:54:02 +0000
Newsgroups	gmane.comp.encryption.gpg.user
Message-ID	<[email protected]>
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============9055631722804597993==
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="------63a46770d9c6944433de02ecc8524839a3b20028976d911345b044b667289e1f"; charset=utf-8

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------63a46770d9c6944433de02ecc8524839a3b20028976d911345b044b667289e1f
Content-Type: multipart/mixed;
 boundary=e39f6efb6cae30e73f5e5dedb2fbd13062f88d4acd0ca2d3f87285e16bf7
Message-ID: <[email protected]>
Date: Wed, 15 Jul 2026 12:53:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: libgpg-error 1.61: t-printf failure on powerpc64-linux
To: NIIBE Yutaka <[email protected]>, [email protected]
References: <[email protected]>
 <H2MP9gr8WbtT2UcbJKlFzcYFSLIsDS09kH9JGyICb5gD-8Qqv4unfBrDu0A7ClayvhjEXHLCDyKXZQ0zzL49pA==@protonmail.internalid>
 <[email protected]>
Content-Language: en-US
From: "C. Neidahl" <[email protected]>
Autocrypt: [email protected]; keydata=
 xjMEZvxMihYJKwYBBAHaRw8BAQdAF/ofJEuZMTh88DkqC+bDr+oirMOimun4L2cG+wJgT7nN
 QENvc2ltYSBOZWlkYWhsIChNZWluIEdudVBHLVNjaGzDvHNzZWwpIDxvcG5hMjYwOEBwcm90
 b25tYWlsLmNvbT7CkwQTFgoAOxYhBGdcyANUzt1vSy/7V2ccL0jSE1w4BQJm/EyKAhsDBQsJ
 CAcCAiICBhUKCQgLAgQWAgMBAh4HAheAAAoJEGccL0jSE1w4mxwBAJYMfsnO4ntX1zjqXAa6
 NVnxhiQOxVK8rmvdhdpoN60GAP0VqeESgHvuDlUsxyUsF4ZHaCGRSxLpdd/hbsg0KlhSBc44
 BGb8TIoSCisGAQQBl1UBBQEBB0DzRber22oJcLP29ZYnfKrHFcEvMDEA6p3BVHBmTwaQdQMB
 CAfCeAQYFgoAIBYhBGdcyANUzt1vSy/7V2ccL0jSE1w4BQJm/EyKAhsMAAoJEGccL0jSE1w4
 iNIA/3kGjlNugrxaEL0Yj6tWuHyXHMMBAhfjb8tRAkZP64tBAQCXpdzQ2SczfXcjQC8c0RQL
 t+3M5X9pdIKKxRqEBrRHDQ==
In-Reply-To: <[email protected]>

--e39f6efb6cae30e73f5e5dedb2fbd13062f88d4acd0ca2d3f87285e16bf7
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

> 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

--e39f6efb6cae30e73f5e5dedb2fbd13062f88d4acd0ca2d3f87285e16bf7
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publickey -
 [email protected] - 0xC802C863.asc"; name="publickey -
 [email protected] - 0xC802C863.asc"
Content-Type: application/pgp-keys; filename="publickey -
 [email protected] - 0xC802C863.asc"; name="publickey -
 [email protected] - 0xC802C863.asc"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCkNvbW1lbnQ6IGh0dHBzOi8vZ29w
ZW5wZ3Aub3JnClZlcnNpb246IEdvcGVuUEdQIDIuOS4wCgp4c0JOQkYyekt2NEJDQURIR1VxQ0dF
Q2lkOEhwM29BVXhuSTFGYnZ2S2xuQlZuSW9QSWhIQTBVMllBT1NTV3MvCi9VMmVETGxRYkRpMzdJ
c0JMYjhQR1VLUlEyYjkwOUFrVU5oc3lrclFqek9vN01aMFZ6eGhtc0hvdTQ3ZjV2V3oKN3Boc29Y
WFFoZzNMVDZqVXhNNjZXc0U3LytZaWhmM0cxWVU5Z1dEanFRN2lvN0dOVi80dEhEa0hBbHBybXZ0
WQo3RUlZZmw5WUF1ZzRzUm5oOVFPUExsSExQRm1tQUVXT2NDRTgzSC91LzROWFVIYm5ETU5Jd3ZV
SWppcVZYM0l4CnhmbHB1bm5iQzRvcjZ6T2tremJoZUhTNENBbm4rczRTalNQc1kyM0RsNThvSFlq
QUY4MFk4ZXM3WlZ3c1M4QmgKNDQzUXh4QjhDQ1dSbms0Mmt3T3FzWjRqMDdDSzlmMXZlSXdIQUJF
QkFBSE5NVzl3Ym1FeU5qQTRRSEJ5YjNSdgpibTFoYVd3dVkyOXRJRHh2Y0c1aE1qWXdPRUJ3Y205
MGIyNXRZV2xzTG1OdmJUN0N3SFVFRUFFSUFCOEZBbDJ6Ckt2NEdDd2tIQ0FNQ0JCVUlDZ0lERmdJ
QkFoa0JBaHNEQWg0QkFBb0pFR29OR0wwSytDalV1VklILzNmODJySjMKc1pyZm1CNFVjVTczTXFu
cENRRnc2ZE9TVHM5amlFMGppeWo0TWxodW5tdnhYNmFHWFFVQkhXc1dkT1Q0YWp3QgovK0hUb2Zy
QWFSc0o3azZ1RWRIbHRNeXNscTJ5MDcrSTVueHZDU2tnRGNoeGNDMlBoR3dvME1lZzY4OHZFWjlP
CkQ3UXFsZzQ0azhWV1hZaGNwUkxPL3VQWE40QkV6ZnJhT3l1aDNxdTNCNlFPSlJ5T2xMVmFpK1pE
TTZZeDZuenQKeTZNclZQVEQvSDhhV1l2TjBWVjNGM3VrVzZXVy9uRGh5VDVDVjhEcFI4UHp3Rk1m
VTQrbW1pcnRpMnlSNjZXTgp3ckUwVkJEUFNudGtqWFhqcllvSzlSZTJuZEM2SUc4aHNIMmpWWDFH
L1NEdDdHYkNVT2xIRUlnUHJuVW9sQk94CkxVME1qNVc1ODlxMmZTTE93RTBFWGJNcS9nRUlBS0xn
RTE4NWJvZE1PdVpvRU01Tkp1aFZZaWptMU1lNjdnbWYKd0ZXQU03Z0M3WGkzb21oTFRMU2RDNWlZ
dFJ2YTNZZ3lxUjBYOTIydWR0MVVYaXVqTTZEeXlqbGJ5TkdWYXNpWgpoa1RmSlQ0dEVoZThSdjNQ
UU80SkZtVVFXb0RnWE53QU5lazE4cityWW1ibkNsUU8wYzRVV3c0cFJGVVFnTnZwCmVrTnRMNmtH
NDV6Wngwdkw5THVPQjZIaEVYalRxcENXanR5UjF6Q2p1TGh1VElsbGswQ3JucytzOVFva2FiQ2cK
Y2s2OXo2WDVpM1E2SkE4WjZTZEwvT0ZDT05IZkdsVnUwZHVNN2tXZ3U0YlpYU213N0IvVlF4QU1H
TDRYUlZSMApkYnU5RnRTTVl2T1dWUEE0R3psMW9uZHA1M3lUWGJEeTJ5czRPaGhnTWhqdTVQQlp4
bThBRVFFQUFjTEFYd1FZCkFRZ0FDUVVDWGJNcS9nSWJEQUFLQ1JCcURSaTlDdmdvMUxZOUNBQ1Bq
ck1mUktWQ204dFFMVnR2SDRYK25raksKaVArN3NHUGFueE5HcHp1NW1VVTBmalk0KzVVWm1GU1NO
eEZQUFR5ajkxVUd4RlFHc2hiL2VxZHFsUVNidFhEQQp2bnN1Z1MzSHYza1F3Mk0zUUJHYWRoQWhS
TWRxVmM3NGNnRk80K2wzS0NKK3pOVmdzb3gwamhjM1IwbGhCaFc4CnRMaXpYcGU5TkI4Y0RNaExR
Y2ZHUFlaN29SVlNxK1l5RXFFOWFNd1prVmtyUk9zdnZ1aGdJclpQeEJwUXc0d1oKRkpZWS9kV2Na
cGpnZm1nOFQycUFRL1QyK3VkdFdjc3RXODNwajdPNGFZRDZ3Zmd2R0FrQXU5MWhQNVo2SmMwYgp5
QmhaVFFvZ2hVMGlNVGU4QmhFUnF1b2RYcU5PWllNOGZXanBLUVY4SXNSQ0pzemhJMUJhTEVYTkJn
KzgKPXB3RlIKLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxPQ0stLS0tLQ==
--e39f6efb6cae30e73f5e5dedb2fbd13062f88d4acd0ca2d3f87285e16bf7--

--------63a46770d9c6944433de02ecc8524839a3b20028976d911345b044b667289e1f
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsCpBAEBCABdBYJqV2bJCRBqDRi9Cvgo1DUUAAAAAAAcABBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3Jn0CyJouRk2cW6PndMhh0rJhYhBMgCyGNmp++W
GtkCJGoNGL0K+CjUAACL5Af9ECSGE5DGnciaLjYYE+C53c5Z4g6dL4oiAyFm
nR8PKv5r+M8ilT3ls/Uw7PNm1aUzJn4v6v8z8w4tiFQqWZ1UUew4ZTuqg+lH
xzWbdlYCSirQcA3h8xWKImzjx3ab/ScbwFhGy+u80QUlavkTsvxqheouPD0H
sUASaGgzYvqMKAn2PGBnQbmafwXgqCNn0d3Cwsrak9FNIaJ7jGNrThgUYt8B
xu/N7xslcWhnk6ko3w1Y0F7h5Mbj7gCLFVm6iwzWlsdcFrZPXw0IMmezngMv
+4yByMSqw/Vp5WwhxGY7EySNYKiDmPjrx5/kScyrvc1eD24+C2bV2P3Q1AGq
+KXCIQ==
=t+2m
-----END PGP SIGNATURE-----


--------63a46770d9c6944433de02ecc8524839a3b20028976d911345b044b667289e1f--



--===============9055631722804597993==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gnupg-users mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-users

--===============9055631722804597993==--