Subject: sort-float failure on ppc64, LDBL_MIN fraction part too long for test command to parse

From: "C. Neidahl" <[email-masked]>
Date: Wed, 09 Jul 2025 18:45:17 +0000

I have a set of patches that resulted from a gnulib thread [1], which 
affect the values of some compiler definitions for the IBM long double 
format on powerpc64. Applying these to the vendored copy of gnulib in 
the coreutils 9.7 release tarball is necessary to fix a failure in the 
gnulib test suite.

These patches are resulting in a failure of the sort-float test from the 
coreutils test suite, with the following output:

./tests/sort/sort-float.sh: line 49: test: 
225073858507201383090232717332: integer expression expected
--- exp 2025-07-09 14:38:32.521404281 +0000
+++ out 2025-07-09 14:38:32.551404251 +0000
@@ -2,11 +2,11 @@
  -1.7976931348623157e+308
  -3.4028235e+38
  -1.1754944e-38
--2.225073858507201383090232717332e-308
  -2.2250738585072014e-308
+-2.225073858507201383090232717332e-308
  0
-2.2250738585072014e-308
  2.225073858507201383090232717332e-308
+2.2250738585072014e-308
  1.1754944e-38
  3.4028235e+38
  1.7976931348623157e+308
./tests/sort/
sort-float.sh: line 58: warning: setlocale: LC_ALL: cannot 
change locale (none): No such file or directory
--- exp 2025-07-09 14:38:32.571404231 +0000
+++ out 2025-07-09 14:38:32.601404202 +0000
[same list of values as above]
FAIL tests/sort/sort-float.sh (exit status: 1)

The issue seems to be that one of the test calls in the dbl_minima_order 
function is failing due to the fractional part of LDBL_MIN on this 
platform being too long for the test command to parse as an integer, so 
the call fails and the function incorrectly determines that DBL_MIN is 
smaller.

This test call would in theory also fail before the set of gnulib 
patches, but the exponent-testing call gives a result first, so it never 
got that far on this platform before.

- Cosima

[1] https://lists.gnu.org/archive/html/bug-gnulib/2025-07/msg00021.html