Re: Wrong unconditional dependency on nanl

[Corinna Vinschen <vinschen at redhat dot com>]

On Oct  8 15:06, Christophe Lyon wrote:
> Hello,
> 
> On aarch64 I've notice that a simple hello.c fails to link against
> current newlib master:
> .../aarch64-elf/libc/usr/lib/libc.a(lib_a-strtorx.o): In function `ULtox':
> .../newlib/libc/stdlib/strtorx.c:92: undefined reference to `nanl'
> 
> It seems to me that an unconditional dependency on nanl() was
> introduced by commit
> 6c212a8b7873703c4f98c6b68579b234918be83a
> Author: Masamichi Hosoda <trueroad@trueroad.jp>
> Date:   Thu Aug 16 09:18:50 2018 +0900
>     Fix strtod ("nan") and strtold ("nan") returns wrong negative NaN
> 
> but I'm not sure how to fix this as I did not follow the discussion
> around this patch.
> 
> It seems to me that nanl() is only defined if _LDBL_EQ_DBL
> (newlib/libm/common/nanl.c), but the patch above introduces a call to
> nanl() in a code path where !defined (_LDBL_EQ_DBL)
> 
> This I suspect the problem is present on other targets, too ?

Cygwin has it's own nanl implemented in winsup/cygwin/math/nanl.c.

However, dropping it there and using a patch like this:

diff --git a/newlib/libm/common/nanl.c b/newlib/libm/common/nanl.c
index 40f898109edd..b8ae63ea7539 100644
--- a/newlib/libm/common/nanl.c
+++ b/newlib/libm/common/nanl.c
@@ -38,5 +38,11 @@ nanl (const char *tagp)
 {
   return nan(tagp);
 }
+#elif __GNUC_PREREQ (3, 3)
+long double
+nanl (const char *tagp)
+{
+  return __builtin_nanl("");
+}
 #endif

should help along all targets, right?  Is there any target still using
a pre-3.3 GCC?


Corinna
 
-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature