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

Previous Next

Full log

View this message in rfc822 format

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: 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

Previous Next

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