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");