Re: strtod.c compilation failure on i386/Solaris 10
Jim Meyering [EMAIL PROTECTED] writes: In wading through coreutils build reports for 60+ systems, I see a new failure: strtod.c: In function `rpl_strtod': strtod.c:155: error: incompatible types in assignment strtod.c:170: error: incompatible types in assignment strtod.c:257: error: wrong type argument to unary minus make[3]: *** [strtod.o] Error 1 Here are the lines in question, each followed by cpp-translated code: num = HUGE_VAL; num = __builtin_huge_val; num = NAN; num = __builtin_nan; return negative ? -HUGE_VAL : HUGE_VAL; return negative ? -__builtin_huge_val : __builtin_huge_val; SunOS powell 5.10 Generic_127112-11 i86pc i386 i86pc Solaris gcc version 3.3 I have seen this as well, see: http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2513 I suspected that the compiler had been built on another system than the one I used though. Is this the case for you as well? Is changing it to HUGE the wrong thing? /Simon
Re: strtod.c compilation failure on i386/Solaris 10
Simon Josefsson [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: In wading through coreutils build reports for 60+ systems, I see a new failure: strtod.c: In function `rpl_strtod': strtod.c:155: error: incompatible types in assignment strtod.c:170: error: incompatible types in assignment strtod.c:257: error: wrong type argument to unary minus make[3]: *** [strtod.o] Error 1 Here are the lines in question, each followed by cpp-translated code: num = HUGE_VAL; num = __builtin_huge_val; num = NAN; num = __builtin_nan; return negative ? -HUGE_VAL : HUGE_VAL; return negative ? -__builtin_huge_val : __builtin_huge_val; SunOS powell 5.10 Generic_127112-11 i86pc i386 i86pc Solaris gcc version 3.3 I have seen this as well, see: http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2513 I suspected that the compiler had been built on another system than the one I used though. Is this the case for you as well? Hi Simon, I rarely use that system, and don't know how the tools were built -- will investigate. Thanks! Is changing it to HUGE the wrong thing? I don't know, off hand.
Re: strtod.c compilation failure on i386/Solaris 10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 4/12/2008 1:46 AM: | In wading through coreutils build reports for 60+ systems, I see a new failure: | | strtod.c: In function `rpl_strtod': | strtod.c:155: error: incompatible types in assignment | strtod.c:170: error: incompatible types in assignment | strtod.c:257: error: wrong type argument to unary minus | make[3]: *** [strtod.o] Error 1 You're not the first to report it: http://lists.gnu.org/archive/html/bug-gnulib/2008-04/msg00034.html | | Here are the lines in question, each followed by cpp-translated code: | | num = HUGE_VAL; | num = __builtin_huge_val; | | num = NAN; | num = __builtin_nan; However, you were the first to provide the information I asked for when the problem was first mentioned. So, what types exactly are __builtin_nan and __builtin_huge_val on Solaris 10 (NAN is supposed to be float, and while HUGE_VAL is supposed to be double, I suspect __builtin_huge_val might be float to feed all four of HUGE_VAL, HUGE_VALF, HUGE_VALL, and INFINITY)? Does adding an explicit cast work around the compiler bug of warning about what is supposed to be a safe implicit cast? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -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 iEYEARECAAYFAkgAqvwACgkQ84KuGfSFAYBNewCfQipNoXCV95HJFpJDlguM7Vxe fbEAoNWHynUrnqhuY9zQixp0W3yTsg2V =sz9r -END PGP SIGNATURE-
Re: strtod.c compilation failure on i386/Solaris 10
Eric Blake [EMAIL PROTECTED] wrote: According to Jim Meyering on 4/12/2008 1:46 AM: | In wading through coreutils build reports for 60+ systems, I see a new failure: | | strtod.c: In function `rpl_strtod': | strtod.c:155: error: incompatible types in assignment | strtod.c:170: error: incompatible types in assignment | strtod.c:257: error: wrong type argument to unary minus | make[3]: *** [strtod.o] Error 1 You're not the first to report it: http://lists.gnu.org/archive/html/bug-gnulib/2008-04/msg00034.html | | Here are the lines in question, each followed by cpp-translated code: | | num = HUGE_VAL; | num = __builtin_huge_val; | | num = NAN; | num = __builtin_nan; However, you were the first to provide the information I asked for when the problem was first mentioned. So, what types exactly are __builtin_nan and __builtin_huge_val on Solaris 10 (NAN is supposed to be float, and while HUGE_VAL is supposed to be double, I suspect __builtin_huge_val might be float to feed all four of HUGE_VAL, HUGE_VALF, HUGE_VALL, and INFINITY)? Does adding an explicit cast work around the compiler bug of warning about what is supposed to be a safe implicit cast? Thanks for the quick reply (yes, I owe you at least one ;-). These are from gcc, so I looked in gcc's own extend.texi and saw that they are functions. Here are examples that compile: double d = __builtin_huge_val(); double e = __builtin_nan(0x0);
Re: strtod.c compilation failure on i386/Solaris 10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 4/12/2008 6:40 AM: | Thanks for the quick reply (yes, I owe you at least one ;-). | | These are from gcc, so I looked in gcc's own extend.texi | and saw that they are functions. Here are examples that compile: | | double d = __builtin_huge_val(); | double e = __builtin_nan(0x0); Aha. Solaris 10 has a buggy math.h - it defines NAN and HUGE_VAL incorrectly (to the value of the builtin function address, and not the result of calling the function), which totally explains the compiler error message. Actually, __builtin_nan(NULL) and __builtin_nan() should compile as well; __builtin_nan() maps to POSIX nan() (not yet provided by gnulib), which POSIX specifies behaves as: nan(NULL) = strtod(NAN,NULL) nan() = strtod(NAN(),NULL) nan(0x0) = strtod(NAN(0x0),NULL) Now that we know the problem, I'll try and start hacking together a math.in.h fix. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -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 iEYEARECAAYFAkgAr3MACgkQ84KuGfSFAYBA2QCgoA+wyTQHtjhajKpZruHoMmGB nh0AoMuEXikqHg/snoB/nCd4i9KCQxwH =tVLu -END PGP SIGNATURE-
Re: strtod.c compilation failure on i386/Solaris 10
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 4/12/2008 6:47 AM:
| Aha. Solaris 10 has a buggy math.h - it defines NAN and HUGE_VAL
| incorrectly (to the value of the builtin function address, and not the
| result of calling the function), which totally explains the compiler error
| message.
I'm committing this. Can you give it a try?
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-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
iEYEARECAAYFAkgAul0ACgkQ84KuGfSFAYAVDgCePNtLrDBRg1200vlxuangRt2c
m6YAnjiiiJUcGpuP7FdmI+0vqo1jwwDg
=uHMl
-END PGP SIGNATURE-
From 83f7edfb45487d4a2cbae9f5e611c0c542cf Mon Sep 17 00:00:00 2001
From: Eric Blake [EMAIL PROTECTED]
Date: Sat, 12 Apr 2008 07:22:40 -0600
Subject: [PATCH] Work around Solaris 10 math.h bug.
* m4/math_h.m4 (gl_MATH_H): Check for bug.
(gl_MATH_H_DEFAULTS): Set up default.
* modules/math (Makefile.am): Replace new indicators.
* lib/math.in.h (NAN, HUGE_VAL): Provide replacements.
* tests/test-math.c (main): Test this.
* m4/strtod.m4 (gl_FUNC_STRTOD): Don't rely on HUGE_VAL.
* doc/posix-headers/math.texi (math.h): Mention bug.
Reported by Nelson H. F. Beebe and Jim Meyering.
Signed-off-by: Eric Blake [EMAIL PROTECTED]
---
ChangeLog | 12
doc/posix-headers/math.texi | 12 +++-
lib/math.in.h | 16 +---
m4/math_h.m4| 29 -
m4/strtod.m4|3 ++-
modules/math|2 ++
tests/test-math.c |4
7 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index d3de184..3a15015 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2008-04-12 Eric Blake [EMAIL PROTECTED]
+
+ Work around Solaris 10 math.h bug.
+ * m4/math_h.m4 (gl_MATH_H): Check for bug.
+ (gl_MATH_H_DEFAULTS): Set up default.
+ * modules/math (Makefile.am): Replace new indicators.
+ * lib/math.in.h (NAN, HUGE_VAL): Provide replacements.
+ * tests/test-math.c (main): Test this.
+ * m4/strtod.m4 (gl_FUNC_STRTOD): Don't rely on HUGE_VAL.
+ * doc/posix-headers/math.texi (math.h): Mention bug.
+ Reported by Nelson H. F. Beebe and Jim Meyering.
+
2008-04-11 Bruno Haible [EMAIL PROTECTED]
Adapt to future versions of Apple GCC.
diff --git a/doc/posix-headers/math.texi b/doc/posix-headers/math.texi
index a7c8df7..a0fa6aa 100644
--- a/doc/posix-headers/math.texi
+++ b/doc/posix-headers/math.texi
@@ -9,7 +9,17 @@ Portability problems fixed by Gnulib:
@itemize
@item
The macro @code{NAN} is not defined on some platforms:
-OpenBSD 4.0, AIX 5.1, IRIX 6.5, OSF/1 5.1, Solaris 10.
+OpenBSD 4.0, AIX 5.1, IRIX 6.5, OSF/1 5.1.
+
[EMAIL PROTECTED]
+The macro @code{NAN} is not exposed outside of C99 compilation on some
+platforms:
+glibc.
+
[EMAIL PROTECTED]
+The macros @code{NAN} and @code{HUGE_VAL} expand to a function address
+rather than a floating point constant on some platforms:
+Solaris 10.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/lib/math.in.h b/lib/math.in.h
index bb715ae..c2b8b81 100644
--- a/lib/math.in.h
+++ b/lib/math.in.h
@@ -1,6 +1,6 @@
/* A GNU-like math.h.
- Copyright (C) 2002-2003, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2002-2003, 2007-2008 Free Software Foundation, Inc.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -34,8 +34,11 @@ extern C {
/* POSIX allows platforms that don't support NAN. But all major
machines in the past 15 years have supported something close to
- IEEE NaN, so we define this unconditionally. */
-#ifndef NAN
+ IEEE NaN, so we define this unconditionally. We also must define
+ it on platforms like Solaris 10, where NAN is present but defined
+ as a function pointer rather than a floating point constant. */
+#if !defined NAN || @REPLACE_NAN@
+# undef NAN
/* The Compaq (ex-DEC) C 6.4 compiler chokes on the expression 0.0 / 0.0. */
# ifdef __DECC
static float
@@ -50,6 +53,13 @@ _NaN ()
# endif
#endif
+/* Solaris 10 defines HUGE_VAL, but as a function pointer rather
+ than a floating point constant. */
+#if @REPLACE_HUGE_VAL@
+# undef HUGE_VAL
+# define HUGE_VAL (1.0 / 0.0)
+#endif
+
/* Write x as
x = mantissa * 2^exp
where
diff --git a/m4/math_h.m4 b/m4/math_h.m4
index dd99e7f..3090b6e 100644
--- a/m4/math_h.m4
+++ b/m4/math_h.m4
@@ -1,4 +1,4 @@
-# math_h.m4 serial 9
+# math_h.m4 serial 10
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,
@@ -8,6 +8,31 @@
Re: strtod.c compilation failure on i386/Solaris 10
Eric Blake [EMAIL PROTECTED] wrote: According to Eric Blake on 4/12/2008 6:47 AM: | Aha. Solaris 10 has a buggy math.h - it defines NAN and HUGE_VAL | incorrectly (to the value of the builtin function address, and not the | result of calling the function), which totally explains the compiler error | message. I'm committing this. Can you give it a try? Thanks. Didn't work. This might help ;-) Just pushed. Trying again... * m4/math_h.m4 (gl_MATH_H): Fix typos. diff --git a/m4/math_h.m4 b/m4/math_h.m4 index 3090b6e..1e67652 100644 --- a/m4/math_h.m4 +++ b/m4/math_h.m4 @@ -1,4 +1,4 @@ -# math_h.m4 serial 10 +# math_h.m4 serial 11 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, @@ -20,7 +20,7 @@ AC_DEFUN([gl_MATH_H], return f == 0;]])], [gl_cv_header_math_nan_works=yes], [gl_cv_header_math_nan_works=no])]) - if test gl_cv_header_math_nan_works = no; then + if test $gl_cv_header_math_nan_works = no; then REPLACE_NAN=1 fi AC_CACHE_CHECK([whether HUGE_VAL works], [gl_cv_header_math_huge_val_works], @@ -30,7 +30,7 @@ AC_DEFUN([gl_MATH_H], return d == 0;]])], [gl_cv_header_math_huge_val_works=yes], [gl_cv_header_math_huge_val_works=no])]) - if test gl_cv_header_math_huge_val_works = no; then + if test $gl_cv_header_math_huge_val_works = no; then REPLACE_HUGE_VAL=1 fi ]) -- 1.5.5.41.gc63d7
Re: strtod.c compilation failure on i386/Solaris 10
Jim Meyering [EMAIL PROTECTED] wrote: Eric Blake [EMAIL PROTECTED] wrote: According to Eric Blake on 4/12/2008 6:47 AM: | Aha. Solaris 10 has a buggy math.h - it defines NAN and HUGE_VAL | incorrectly (to the value of the builtin function address, and not the | result of calling the function), which totally explains the compiler error | message. I'm committing this. Can you give it a try? Thanks. Didn't work. This might help ;-) Just pushed. Trying again... * m4/math_h.m4 (gl_MATH_H): Fix typos. Yep. That fixed the compile errors. However, now one of the test programs fails to link: (sorry, don't have time to dig for a few hours) gcc -std=gnu99 -O -Wl,-z,ignore -o test-sys_socket test-sys_socket.o libtests.a ../lib/libcoreutils.a libtests.a -lnsl -lsocket -lm Undefined first referenced symbol in file __builtin_isnan test-strtod.o ld: fatal: Symbol referencing errors. No output written to test-strtod collect2: ld returned 1 exit status make[5]: *** [test-strtod] Error 1
Re: strtod.c compilation failure on i386/Solaris 10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 4/12/2008 11:06 AM: | | Eric, this may fix it. We don't have a module yet that provides the generic | isnan() macro. But we have a module 'isnand-nolibm', which the test already | uses. | | OK to commit? Yes, please commit. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -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 iEYEARECAAYFAkgA9lAACgkQ84KuGfSFAYBLWQCfd2UsUwHIXSYgdctiCHJqlr2v oEwAnRzBVI6+C8txUkwXQYPtZmepcMhR =H1lK -END PGP SIGNATURE-
