GNU bug report logs - #78985
sort-float failure on ppc64, LDBL_MIN fraction part too long for test command to parse

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 78985 in the body.
You can then email your comments to 78985 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "C. Neidahl" <opna2608 <at> protonmail.com>
To: bug-coreutils <at> gnu.org
Subject: sort-float failure on ppc64,
 LDBL_MIN fraction part too long for test command to parse
Date: Wed, 09 Jul 2025 18:45:17 +0000

[Message part 1 (text/plain, inline)]

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

[publickey - opna2608@protonmail.com - 0xC802C863.asc (application/pgp-keys, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #10 received at 78985-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "C. Neidahl" <opna2608 <at> protonmail.com>
Cc: 78985-done <at> debbugs.gnu.org
Subject: Re: bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part
 too long for test command to parse
Date: Thu, 10 Jul 2025 10:20:11 -0700

[Message part 1 (text/plain, inline)]

Thanks for reporting that false positive in the test. I installed the 
attached patch, which should fix things.

[0001-tests-fix-integer-overflow-in-sort-float.patch (text/x-patch, attachment)]

Message #13 received at 78985 <at> debbugs.gnu.org (full text, mbox):

From: "C. Neidahl" <opna2608 <at> protonmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 78985 <at> debbugs.gnu.org
Subject: Re: bug#78985: sort-float failure on ppc64,
 LDBL_MIN fraction part too long for test command to parse
Date: Fri, 11 Jul 2025 11:28:13 +0000

[Message part 1 (text/plain, inline)]

Am 10.07.25 um 19:20 schrieb Paul Eggert:
> Thanks for reporting that false positive in the test. I installed the
> attached patch, which should fix things.

The patch fixes the error with the long fraction part being unparsable, 
but it seems like the resulting order for the test input is still wrong. 
The LDBL_MIN fraction is longer than the DBL_MIN fraction, so it appears 
as a bigger number to test/expr, and the <= comparison fails.

↪ expr 225073858507201383090232717332 '<=' 2250738585072014 >/dev/null; 
echo $?
1

So the function still determines that DBL_MIN < LDBL_MIN, and the test 
fails due to exp != out. Maybe the two fractions could be cropped/padded 
with 0's to have the same length, or all of these comparisons / the 
expected output generation in general could be done in C?

- Cosima

[publickey - opna2608@protonmail.com - 0xC802C863.asc (application/pgp-keys, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #16 received at 78985 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "C. Neidahl" <opna2608 <at> protonmail.com>
Cc: 78985 <at> debbugs.gnu.org
Subject: Re: bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part
 too long for test command to parse
Date: Fri, 11 Jul 2025 14:46:59 -0700

[Message part 1 (text/plain, inline)]

On 2025-07-11 04:28, C. Neidahl wrote:
> The LDBL_MIN fraction is longer than the DBL_MIN fraction, so it appears 
> as a bigger number to test/expr

Oh, right. Thanks. I installed the attached further patch to fix that. 
This is cleaner anyway.

[0001-tests-fix-fraction-comparison-in-sort-float.patch (text/x-patch, attachment)]

Message #19 received at 78985 <at> debbugs.gnu.org (full text, mbox):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 78985 <at> debbugs.gnu.org, "C. Neidahl" <opna2608 <at> protonmail.com>
Subject: Re: bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part
 too long for test command to parse
Date: Fri, 11 Jul 2025 15:25:22 -0700

[Message part 1 (text/plain, inline)]

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> On 2025-07-11 04:28, C. Neidahl wrote:
>> The LDBL_MIN fraction is longer than the DBL_MIN fraction, so it
>> appears as a bigger number to test/expr
>
> Oh, right. Thanks. I installed the attached further patch to fix that.
> This is cleaner anyway.

This test still fails on cfarm110 for me, logs attached.

I was looking at it the other day, but was unable to get a working
version.

I'll see if I have any ideas later.

Collin

[sort-float.log.gz (application/gzip, attachment)]

Message #22 received at 78985 <at> debbugs.gnu.org (full text, mbox):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 78985 <at> debbugs.gnu.org, "C. Neidahl" <opna2608 <at> protonmail.com>
Subject: Re: bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part
 too long for test command to parse
Date: Fri, 11 Jul 2025 20:59:43 -0700

Collin Funk <collin.funk1 <at> gmail.com> writes:

>> Oh, right. Thanks. I installed the attached further patch to fix that.
>> This is cleaner anyway.
>
> This test still fails on cfarm110 for me, logs attached.
>
> I was looking at it the other day, but was unable to get a working
> version.
>
> I'll see if I have any ideas later.

I think I see the issue now. Using this test program:

    $ cat main.c 
    #include <stdio.h>
    int
    main (void)
    {
      long double a = 2.225073858507201383090232717332e-308;
      long double b = 2.2250738585072014e-308;
      printf ("a < b:   %d\n", a < b);
      printf ("a > b:   %d\n", a > b);
      printf ("a == b:  %d\n", a == b);
      return 0;
    }
    $ gcc main.c
    $ ./a.out
    a < b:   0
    a > b:   0
    a == b:  1

And then in gdb we can see strtold returns equal numbers:

    Breakpoint 1, general_numcompare (sa=0x10051460 "2.225073858507201383090232717332e-308", sb=0x10051486 "2.2250738585072014e-308") at src/sort.c:2032
    2032	  long double a = strtold (sa, &ea);
    Missing separate debuginfos, use: debuginfo-install glibc-2.17-326.el7_9.3.ppc64
    (gdb) n
    2033	  long double b = strtold (sb, &eb);
    (gdb) n
    2036	  if (sa == ea)
    (gdb) print a
    $1 = 2.2250738585072013830902327173324041e-308
    (gdb) print b
    $2 = 2.2250738585072013830902327173324041e-308
    (gdb) print a == b
    $3 = 1

Maybe a solution would be to compare the strings instead of calling
strold? I guess that would make life harder though...

Collin

Message #25 received at 78985 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Collin Funk <collin.funk1 <at> gmail.com>
Cc: 78985 <at> debbugs.gnu.org, "C. Neidahl" <opna2608 <at> protonmail.com>
Subject: Re: bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part
 too long for test command to parse
Date: Fri, 11 Jul 2025 21:01:08 -0700

On 2025-07-11 15:25, Collin Funk wrote:
> This test still fails on cfarm110 for me, logs attached.

I guess that's a different issue, due to the problem that Gnulib defines 
LDBL_MAX to be a value greater than what one can compute from source code.

I guess a fix on that platform would be to shrink LDBL_MAX by a factor 
of 2, and similarly for LDBL_NORM_MAX. That is, go back to the GCC way 
of doing things.

Message #28 received at 78985 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Collin Funk <collin.funk1 <at> gmail.com>
Cc: 78985 <at> debbugs.gnu.org, "C. Neidahl" <opna2608 <at> protonmail.com>
Subject: Re: bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part
 too long for test command to parse
Date: Fri, 11 Jul 2025 21:10:30 -0700

On 2025-07-11 20:59, Collin Funk wrote:
> Maybe a solution would be to compare the strings instead of calling
> strold?

Yes, that's been on the 'sort' TODO list for like, forever. It'd also be 
faster than what's in there now. A bit tricky, though, given the 
vagaries of textual floating point formats in different locales.

Message #31 received at 78985 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Collin Funk <collin.funk1 <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 78985 <at> debbugs.gnu.org, "C. Neidahl" <opna2608 <at> protonmail.com>
Subject: Re: bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part
 too long for test command to parse
Date: Sat, 12 Jul 2025 12:45:49 +0100

On 12/07/2025 04:59, Collin Funk wrote:
> Collin Funk <collin.funk1 <at> gmail.com> writes:
> 
>>> Oh, right. Thanks. I installed the attached further patch to fix that.
>>> This is cleaner anyway.
>>
>> This test still fails on cfarm110 for me, logs attached.
>>
>> I was looking at it the other day, but was unable to get a working
>> version.
>>
>> I'll see if I have any ideas later.
> 
> I think I see the issue now. Using this test program:
> 
>      $ cat main.c
>      #include <stdio.h>
>      int
>      main (void)
>      {
>        long double a = 2.225073858507201383090232717332e-308;
>        long double b = 2.2250738585072014e-308;
>        printf ("a < b:   %d\n", a < b);
>        printf ("a > b:   %d\n", a > b);
>        printf ("a == b:  %d\n", a == b);
>        return 0;
>      }
>      $ gcc main.c
>      $ ./a.out
>      a < b:   0
>      a > b:   0
>      a == b:  1
> 
> And then in gdb we can see strtold returns equal numbers:
> 
>      Breakpoint 1, general_numcompare (sa=0x10051460 "2.225073858507201383090232717332e-308", sb=0x10051486 "2.2250738585072014e-308") at src/sort.c:2032
>      2032	  long double a = strtold (sa, &ea);
>      Missing separate debuginfos, use: debuginfo-install glibc-2.17-326.el7_9.3.ppc64
>      (gdb) n
>      2033	  long double b = strtold (sb, &eb);
>      (gdb) n
>      2036	  if (sa == ea)
>      (gdb) print a
>      $1 = 2.2250738585072013830902327173324041e-308
>      (gdb) print b
>      $2 = 2.2250738585072013830902327173324041e-308
>      (gdb) print a == b
>      $3 = 1
> 
> Maybe a solution would be to compare the strings instead of calling
> strold? I guess that would make life harder though...
> 
> Collin
> 
> 
> 
I wonder could you break ties with string compares?
I've not thought about edge cases, but something like this?

diff --git a/src/sort.c b/src/sort.c
index 4a1fdfd37..faeeef273 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -2043,7 +2043,7 @@ general_numcompare (char const *sa, char const *sb)
      bit-pattern, for lack of a more portable alternative.  */
   return (a < b ? -1
           : a > b ? 1
-          : a == b ? 0
+          : a == b ? numcompare (sa, sb)
           : b == b ? -1
           : a == a ? 1
           : nan_compare (a, b));

Given floating point comparison is already slow,
and this would only be in the equal case,
perf-wise it might be ok?

Testing that directly gives:

  $ eval $(src/getlimits)
  $ LDBL_ABOVE_MIN=$(echo $LDBL_MIN | sed 's/e/1e/')

  $ printf '%s\n' $LDBL_ABOVE_MIN $LDBL_MIN | src/sort -g
  3.3621031431120935063e-4932
  3.36210314311209350631e-4932

  $ printf '%s\n' $LDBL_ABOVE_MIN $LDBL_MIN | /usr/bin/sort -g
  3.36210314311209350631e-4932
  3.3621031431120935063e-4932

cheers,
Pádraig

Message #34 received at 78985 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Collin Funk <collin.funk1 <at> gmail.com>
Cc: 78985 <at> debbugs.gnu.org, "C. Neidahl" <opna2608 <at> protonmail.com>
Subject: Re: bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part
 too long for test command to parse
Date: Sat, 12 Jul 2025 08:53:10 -0700

On 2025-07-12 04:45, Pádraig Brady wrote:
> -          : a == b ? 0
> +          : a == b ? numcompare (sa, sb)

That fails for string pairs like "10" and "1e1".

Message #37 received at 78985 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Collin Funk <collin.funk1 <at> gmail.com>
Cc: 78985 <at> debbugs.gnu.org, "C. Neidahl" <opna2608 <at> protonmail.com>
Subject: Re: bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part
 too long for test command to parse
Date: Sat, 12 Jul 2025 19:59:40 +0100

On 12/07/2025 16:53, Paul Eggert wrote:
> On 2025-07-12 04:45, Pádraig Brady wrote:
>> -          : a == b ? 0
>> +          : a == b ? numcompare (sa, sb)
> 
> That fails for string pairs like "10" and "1e1".

Hah I thought of that but missed this impacts the --unique case.
I added a test case to ensure equivalency is honored.

cheers,
Pádraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.