GNU bug report logs - #7228
coreutils-8.6 sort-float failure on ppc

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 7228 in the body.
You can then email your comments to 7228 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: "Gilles Espinasse" <g.esp <at> free.fr>
To: <bug-coreutils <at> gnu.org>
Subject: coreutils-8.6 sort-float failure on ppc
Date: Sat, 16 Oct 2010 16:46:56 +0200

Just tested 8.6 on linux glibc-2.11.1/gcc-4.4.5 LFS build on x86, sparc and
ppc

First a good news is that on sparc (32-bits), 8.6 test suite is now passing
I didn't report yet a failure on misc/stty which was
Failure was
+ stty -icanon
stty: standard input: unable to perform all requested operations


The bad news is that it fail now on ppc in FAIL: misc/sort-float

+ LC_ALL=C
+ sort -sg
+ compare out exp
+ diff -u out exp
--- out 2010-10-16 13:40:44.000000000 +0000
+++ exp 2010-10-16 13:40:44.000000000 +0000
@@ -2,11 +2,11 @@
 -1.797693e+308
 -3.402823e+38
 -1.175494e-38
--2.004168e-292
 -2.225074e-308
+-2.004168e-292
 0
-2.225074e-308
 2.004168e-292
+2.225074e-308
 1.175494e-38
 3.402823e+38
 1.797693e+308
+ fail=1
...
+ LC_ALL=fr_FR
+ sort -sg
+ compare out exp
+ diff -u out exp
--- out 2010-10-16 13:40:44.000000000 +0000
+++ exp 2010-10-16 13:40:44.000000000 +0000
@@ -2,11 +2,11 @@
 -1,797693e+308
 -3,402823e+38
 -1,175494e-38
--2,004168e-292
 -2,225074e-308
+-2,004168e-292
 0
-2,225074e-308
 2,004168e-292
+2,225074e-308
 1,175494e-38
 3,402823e+38
 1,797693e+308
+ fail=1
+ Exit 1

Gilles

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

From: Jim Meyering <jim <at> meyering.net>
To: "Gilles Espinasse" <g.esp <at> free.fr>
Cc: 7228 <at> debbugs.gnu.org
Subject: Re: bug#7228: coreutils-8.6 sort-float failure on ppc
Date: Sat, 16 Oct 2010 21:14:48 +0200

Gilles Espinasse wrote:
> Just tested 8.6 on linux glibc-2.11.1/gcc-4.4.5 LFS build on x86, sparc and
> ppc
>
> First a good news is that on sparc (32-bits), 8.6 test suite is now passing
> I didn't report yet a failure on misc/stty which was
> Failure was
> + stty -icanon
> stty: standard input: unable to perform all requested operations

Is that consistently reproducible?
If so, you might want to investigate, but it's probably not a big deal.

> The bad news is that it fail now on ppc in FAIL: misc/sort-float
>
> + LC_ALL=C
> + sort -sg
> + compare out exp
> + diff -u out exp
> --- out 2010-10-16 13:40:44.000000000 +0000
> +++ exp 2010-10-16 13:40:44.000000000 +0000
> @@ -2,11 +2,11 @@
>  -1.797693e+308
>  -3.402823e+38
>  -1.175494e-38
> --2.004168e-292
>  -2.225074e-308
> +-2.004168e-292
>  0
> -2.225074e-308
>  2.004168e-292
> +2.225074e-308
>  1.175494e-38
>  3.402823e+38
>  1.797693e+308
> + fail=1
> ...
> + LC_ALL=fr_FR
> + sort -sg
> + compare out exp
> + diff -u out exp
> --- out 2010-10-16 13:40:44.000000000 +0000
> +++ exp 2010-10-16 13:40:44.000000000 +0000
> @@ -2,11 +2,11 @@
>  -1,797693e+308
>  -3,402823e+38
>  -1,175494e-38
> --2,004168e-292
>  -2,225074e-308
> +-2,004168e-292
>  0
> -2,225074e-308
>  2,004168e-292
> +2,225074e-308
>  1,175494e-38
>  3,402823e+38
>  1,797693e+308
> + fail=1
> + Exit 1

Thank you for the report.
The expected output ("exp") above was generated via this:

      printf -- "\
    -$LDBL_MAX
    -$DBL_MAX
    -$FLT_MAX
    -$FLT_MIN
    -$DBL_MIN
    -$LDBL_MIN
    0
    $LDBL_MIN
    $DBL_MIN
    $FLT_MIN
    $FLT_MAX
    $DBL_MAX
    $LDBL_MAX
    " ...

Along with the diff output above, you can see that
your system's LDBL_MIN is *larger* than its DBL_MIN.
The test did not account for that possibility, since
LDBL_MIN is usually smaller than DBL_MIN.

We'll adjust the test to allow for that.

One way would be to compare $LDBL_MIN and $DBL_MIN manually,
extracting and comparing the exponents, the whole part of each mantissa
and finally the fractional part of each mantissa, stopping whenever
you find a difference.
While using awk would be cleaner, it may be more likely to fail
for values at the extremes.

Apply the following patch and the test should pass:

From 3cce70f0a4fd06954430faf86efd4a53a606a88a Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Sat, 16 Oct 2010 20:18:19 +0200
Subject: [PATCH] tests: sort-float: avoid spurious test failure on ppc64

* tests/misc/sort-float: On systems with DBL_MIN < LDBL_MIN,
this test would fail because the expected output was not sorted.
Detect that case, and if needed, reverse those two values.
---
 tests/misc/sort-float |   41 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 41 insertions(+), 0 deletions(-)

diff --git a/tests/misc/sort-float b/tests/misc/sort-float
index 639cd7e..f9e0e69 100755
--- a/tests/misc/sort-float
+++ b/tests/misc/sort-float
@@ -23,6 +23,39 @@ fi

 . $srcdir/test-lib.sh

+# Return 0 if LDBL_MIN is smaller than DBL_MIN, else 1.
+# Dissect numbers like these, comparing first exponent, then
+# whole part of mantissa, then fraction, until finding enough
+# of a difference to determine the relative order of the numbers.
+# These are "reversed":
+#   $ ./getlimits |grep DBL_MIN
+#   DBL_MIN=2.225074e-308
+#   LDBL_MIN=2.004168e-292
+#
+# These are in the expected order:
+#   $ ./getlimits|grep DBL_MIN
+#   DBL_MIN=2.225074e-308
+#   LDBL_MIN=3.362103e-4932
+
+dbl_minima_order()
+{
+  LC_ALL=C getlimits_
+  set -- $(echo $LDBL_MIN | tr .e- '   ')
+  local ldbl_whole=$1 ldbl_frac=$2 ldbl_exp=$3
+
+  set -- $(echo $DBL_MIN |tr .e- '   ')
+  local dbl_whole=$1 dbl_frac=$2 dbl_exp=$3
+
+  test "$dbl_exp" -lt "$ldbl_exp" && return 0
+  test "$ldbl_exp" -lt "$dbl_exp" && return 1
+  test "$dbl_whole" -lt "$ldbl_whole" && return 0
+  test "$ldbl_whole" -lt "$dbl_whole" && return 1
+  test "$dbl_frac" -le "$ldbl_frac" && return 0
+  return 1
+}
+
+dbl_minima_order; reversed=$?
+
 for LOC in C $LOCALE_FR; do

   LC_ALL=$LOC getlimits_
@@ -31,6 +64,14 @@ for LOC in C $LOCALE_FR; do
   grep '^#define HAVE_C99_STRTOLD 1' $CONFIG_HEADER > /dev/null ||
     { LDBL_MAX="$DBL_MAX"; LDBL_MIN="$DBL_MIN"; }

+  # If DBL_MIN happens to be smaller than LDBL_MIN, swap them,
+  # so that out expected output is sorted.
+  if test $reversed = 1; then
+    t=$LDBL_MIN
+    LDBL_MIN=$DBL_MIN
+    DBL_MIN=$t
+  fi
+
   printf -- "\
 -$LDBL_MAX
 -$DBL_MAX
--
1.7.3.1.526.g2ee4

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

From: "Gilles Espinasse" <g.esp <at> free.fr>
To: "Jim Meyering" <jim <at> meyering.net>
Cc: 7228 <at> debbugs.gnu.org
Subject: Re: bug#7228: coreutils-8.6 sort-float failure on ppc
Date: Sat, 16 Oct 2010 23:15:45 +0200

----- Original Message ----- 
From: "Jim Meyering" <jim <at> meyering.net>
To: "Gilles Espinasse" <g.esp <at> free.fr>
Cc: <7228 <at> debbugs.gnu.org>
Sent: Saturday, October 16, 2010 9:14 PM
Subject: Re: bug#7228: coreutils-8.6 sort-float failure on ppc


> Gilles Espinasse wrote:
> > Just tested 8.6 on linux glibc-2.11.1/gcc-4.4.5 LFS build on x86, sparc
and
> > ppc
> >
> > First a good news is that on sparc (32-bits), 8.6 test suite is now
passing
> > I didn't report yet a failure on misc/stty which was
> > Failure was
> > + stty -icanon
> > stty: standard input: unable to perform all requested operations
>
> Is that consistently reproducible?
> If so, you might want to investigate, but it's probably not a big deal.
>
Each time I run the 8.5 test suite on sparc.
Not so easy to reproduce and that disappear now running the test suite with
8.6.
I was testing that week looking how to reproduce.
At  the 5 attempts I try entering the LFS compilation chroot with 8.5, when
I try to run  'stty -icanon', it fail the first time but not after the first
try. When I reboot, it fail again the first time and not later. I looked
with strace and did not see a reason why the first attempt fail and not the
second.

> > The bad news is that it fail now on ppc in FAIL: misc/sort-float
> >
It's ok now with the patch on ppc.
It's ppc32, not 64 (gcc have --with-long-double-128 option if that matter)

Gilles

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

From: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
To: jim <at> meyering.net (Jim Meyering)
Cc: 7228 <at> debbugs.gnu.org, Gilles Espinasse <g.esp <at> free.fr>
Subject: Re: bug#7228: coreutils-8.6 sort-float failure on ppc
Date: Sat, 16 Oct 2010 18:47:25 -0500 (GMT+5)

Jim Meyering writes:
> 
> Gilles Espinasse wrote:
> > Just tested 8.6 on linux glibc-2.11.1/gcc-4.4.5 LFS build on x86, sparc and
> > ppc
> >
> > First a good news is that on sparc (32-bits), 8.6 test suite is now passing
> > I didn't report yet a failure on misc/stty which was
> > Failure was
> > + stty -icanon
> > stty: standard input: unable to perform all requested operations
> 
> Is that consistently reproducible?
> If so, you might want to investigate, but it's probably not a big deal.

I've seen that error message before, and I did investigate. It was caused by
glibc's tcsetattr()/tcgetattr() being too clever, trying to support fields
that didn't exist in the kernel's termios struct. The kernel struct is
arch-specific so it's not surprising that an arch-specific bug would show up
here.

I've only seen it with speed changes. stty 115200 </dev/ttyS0 makes the
change succesfully, but complains. The kernel termios struct may or may not
have separate speed fields for input and output, but glibc likes to pretend
that they're both there, and somehow stty gets confused by glibc's fakery.
strace doesn't give any clues because it shows the real kernel structures.

See sysdeps/unix/sysv/linux/{speed,tc[gs]etattr}.c in glibc source for the
full ugliness.

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

From: Jim Meyering <jim <at> meyering.net>
To: "Gilles Espinasse" <g.esp <at> free.fr>
Cc: 7228 <at> debbugs.gnu.org
Subject: Re: bug#7228: coreutils-8.6 sort-float failure on ppc
Date: Sun, 17 Oct 2010 09:20:20 +0200

Gilles Espinasse wrote:
>> > The bad news is that it fail now on ppc in FAIL: misc/sort-float
>> >
> It's ok now with the patch on ppc.
> It's ppc32, not 64 (gcc have --with-long-double-128 option if that matter)

Thanks.  Adjusted.  I reproduced the failure also on ppc64.

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

From: Jim Meyering <jim <at> meyering.net>
To: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
Cc: 7228 <at> debbugs.gnu.org, Gilles Espinasse <g.esp <at> free.fr>
Subject: Re: bug#7228: coreutils-8.6 sort-float failure on ppc
Date: Sun, 17 Oct 2010 09:20:44 +0200

Alan Curry wrote:
> Jim Meyering writes:
>> Gilles Espinasse wrote:
>> > Just tested 8.6 on linux glibc-2.11.1/gcc-4.4.5 LFS build on x86, sparc and
>> > ppc
>> >
>> > First a good news is that on sparc (32-bits), 8.6 test suite is now passing
>> > I didn't report yet a failure on misc/stty which was
>> > Failure was
>> > + stty -icanon
>> > stty: standard input: unable to perform all requested operations
>>
>> Is that consistently reproducible?
>> If so, you might want to investigate, but it's probably not a big deal.
>
> I've seen that error message before, and I did investigate. It was caused by
> glibc's tcsetattr()/tcgetattr() being too clever, trying to support fields
> that didn't exist in the kernel's termios struct. The kernel struct is
> arch-specific so it's not surprising that an arch-specific bug would show up
> here.
>
> I've only seen it with speed changes. stty 115200 </dev/ttyS0 makes the
> change succesfully, but complains. The kernel termios struct may or may not
> have separate speed fields for input and output, but glibc likes to pretend
> that they're both there, and somehow stty gets confused by glibc's fakery.
> strace doesn't give any clues because it shows the real kernel structures.
>
> See sysdeps/unix/sysv/linux/{speed,tc[gs]etattr}.c in glibc source for the
> full ugliness.

Thanks for the explanation.

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

From: Jim Meyering <jim <at> meyering.net>
To: "Gilles Espinasse" <g.esp <at> free.fr>
Cc: 7228-done <at> debbugs.gnu.org
Subject: Re: bug#7228: coreutils-8.6 sort-float failure on ppc
Date: Tue, 31 May 2011 23:26:27 +0200

Jim Meyering wrote:
> Gilles Espinasse wrote:
>>> > The bad news is that it fail now on ppc in FAIL: misc/sort-float
>>> >
>> It's ok now with the patch on ppc.
>> It's ppc32, not 64 (gcc have --with-long-double-128 option if that matter)
>
> Thanks.  Adjusted.  I reproduced the failure also on ppc64.

This was resolved, afaics, so closing.

Previous Next

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