bug-gnulib
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]