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
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
This bug report was last modified 33 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.