bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: minus_zero-related tests fail to compile on ppc with recent gcc


From: Eric Blake
Subject: Re: minus_zero-related tests fail to compile on ppc with recent gcc
Date: Sat, 18 Oct 2008 14:47:53 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080914 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[adding bug-gnulib, as this is more useful to the group than just me]

According to Nelson H. F. Beebe on 10/18/2008 11:47 AM:
>>> does the concept in this patch fix the issue you had with m4 1.4.12?
>>> http://lists.gnu.org/archive/html/bug-gnulib/2008-10/msg00238.html
>>> ...
>>> long double minus_zerol = -LDBL_MIN * LDBL_MIN; 
> 
> The idutils code had the initializer inside a function, and a test
> shows that the code does indeed compile on Mac OS X:
> 
> % cat foo2.c
> #include <stdio.h>
> #include <stdlib.h>
> #include <float.h>
> 
> int
> main(int argc, char* argv[])
> {
>     long double minus_zero = -LDBL_MIN * LDBL_MIN;
> 
>     return (EXIT_SUCCESS);
> }
> 
> % cc -c foo2.c
> % gcc -c foo2.c
> 
> However, this doesn't solve the general problem of having a global
> compile-time variable having the value of negative zero.

But that's not necessarily gnulib's goal.  We know it is not possible to
globally achieve a compile-time way to generate a constant -0.0L, rather,
we are interested in any reliable and maintainable way to even generate
- -0.0L at all (even if via runtime on platforms where the compiler is
lousy).  Put another way, we are more interested in testing our
replacement functions' behavior on this value than we are in initializing
data structures with it.

> 
> For inline code, one can also use copysignl(0.0L, -1.0L),
> or LDBL_MIN / (-LDBL_MAX).  

That works for MacOS, but is not portable for use in the gnulib testsuite.
 In fact, copysignl is one of the gnulib functions where we need to
achieve a -0.0L in order to test that our replacement works where the
native version was missing or broken.

> 
> In extensive tests with my features package
> 
>       http://www.math.utah.edu/pub/features
> 
> I found that many compilers fail to handle negative zeros properly,
> either compiling explicit -0.0 into +0.0, or losing the sign on
> negation of a stored zero.  Here's an example with the Portland Group
> compiler, pgCC:
> 
>       Test of zero handling in single-precision IEEE 754 arithmetic:
>               sizeof(float) = 4
>               +zero is unsigned               OK
>               -zero is unsigned               WRONG
>               0 - 0 is unsigned               OK
>               (-0) - (+0) is unsigned         WRONG
>               (+1)*(0) is unsigned            OK
>               (-1)*(0) is   signed            OK
> 
>       Test of zero handling in double-precision IEEE 754 arithmetic:
>               sizeof(double) = 8
>               +zero is unsigned               OK
>               -zero is unsigned               WRONG
>               0 - 0 is unsigned               OK
>               (-0) - (+0) is unsigned         WRONG
>               (+1)*(0) is unsigned            OK
>               (-1)*(0) is   signed            OK
> 
> For features-1.2.1, I have 182 log files of tests, and 43 contain
> the phrase "-zero is unsigned               WRONG".  That is a
> failure rate of 23%.

Yep, it's unfortunate that so many platform/compiler combinations don't
comply with C89.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkj6S3kACgkQ84KuGfSFAYA2QQCg1lX3/yzSpVkgULpleChoZ7bj
vc8An2r9hffMgGeRp1kQhhYQiy/OUT7S
=4l3d
-----END PGP SIGNATURE-----




reply via email to

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