[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new snapshot, and a huge set of coreutils test results
From: |
Bruno Haible |
Subject: |
Re: new snapshot, and a huge set of coreutils test results |
Date: |
Sun, 27 Apr 2008 22:51:14 +0200 |
User-agent: |
KMail/1.5.4 |
Here's a closer look to the tests from gnulib:
> go.2008.04.14.07.01.55.log:FAIL: test-frexpl IRIX 6.5, gcc 3.4.3, NaN
> argument
> go.2008.04.14.07.01.55.log:FAIL: test-isnanl-nolibm same
> go.2008.04.14.07.01.55.log:FAIL: test-vasprintf-posix same
Apparently isnanl (0.0L / 0.0L) yields false instead of true. It does not
use the gnulib replacement. With gcc 2.95.2 on IRIX 6.5, I get the same
configuration results, i.e. it uses the gcc builtins, but no test failure.
Maybe the attached fix will do it.
> bl.2008.04.14.07.01.49.log:FAIL: test-fseeko.sh Linux/alpha
> bl.2008.04.14.07.01.49.log:FAIL: test-ftello.sh
> bl.2008.04.14.07.02.10.log:FAIL: test-fseeko.sh same
> bl.2008.04.14.07.02.10.log:FAIL: test-ftello.sh
> we.2008.04.14.07.02.38.log:FAIL: test-fseeko.sh Linux/sparc
> we.2008.04.14.07.02.38.log:FAIL: test-ftello.sh
> we.2008.04.14.07.06.15.log:FAIL: test-fseeko.sh same
> we.2008.04.14.07.06.15.log:FAIL: test-ftello.sh
These look like glibc bugs, possibly introduced by Gentoo.
> po.2008.04.14.07.04.52.log:FAIL: test-inttypes CC=/opt/SUNWspro/bin/c89
> (has no 64-bit integers?)
> ps.2008.04.14.07.05.44.log:FAIL: test-inttypes CC=c89
> so.2008.04.14.07.03.39.log:FAIL: test-inttypes CC=/opt/SUNWspro/bin/c89
> su.2008.04.14.07.05.06.log:FAIL: test-inttypes CC=/opt/SUNWspro/bin/c89
The used compiler (c89) apparently does not support 64-bit integers. A better
compiler (cc) is available in the same directory. It does not make sense to
use c89 under these conditions.
> fe.2008.04.14.07.02.40.log:FAIL: test-strtod
> fe.2008.04.14.07.06.20.log:FAIL: test-strtod
> fe.2008.04.14.09.12.15.log:FAIL: test-strtod
> fe.2008.04.14.09.12.22.log:FAIL: test-strtod
Maybe already fixed by Eric's recent changes,
> ne.2008.04.14.07.03.00.log:FAIL: test-xprintf-posix.sh
> ne.2008.04.14.07.07.46.log:FAIL: test-xprintf-posix.sh same
>
> mo.2008.04.14.07.03.36.log:FAIL: test-vasprintf-posix same
> mo.2008.04.14.07.03.36.log:FAIL: test-vfprintf-posix.sh
> mo.2008.04.14.07.03.36.log:FAIL: test-vprintf-posix.sh
> mo.2008.04.14.07.03.36.log:FAIL: test-xprintf-posix.sh
These were reported and fixed in gettext on 2007-11-28. (libintl.h had a
#define fprintf that undid the one from gnulib.)
Bruno
2008-04-27 Bruno Haible <address@hidden>
* m4/isnanl.m4 (gl_FUNC_ISNANL_WORKS): Also test the behaviour on
quiet NaNs.
*** m4/isnanl.m4.orig 2008-04-27 22:49:34.000000000 +0200
--- m4/isnanl.m4 2008-04-27 22:48:12.000000000 +0200
***************
*** 1,4 ****
! # isnanl.m4 serial 6
dnl Copyright (C) 2007-2008 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
--- 1,4 ----
! # isnanl.m4 serial 7
dnl Copyright (C) 2007-2008 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
***************
*** 134,139 ****
--- 134,143 ----
memory_long_double m;
unsigned int i;
+ /* gcc-3.4.3 on IRIX 6.5 appears to have a problem with this. */
+ if (!isnanl (0.0L / 0.0L))
+ return 1;
+
/* The isnanl function should be immune against changes in the sign bit and
in the mantissa bits. The xor operation twiddles a bit that can only be
a sign bit or a mantissa bit (since the exponent never extends to