Re: Wrong unconditional dependency on nanl

Corinna Vinschen <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
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 <[email protected]>
> 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
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlu9ySMACgkQ9TYGna5E
T6C3Xw//TZawDWCAfpQMb2+Msj2T1RKIBgHOTzcgXh/rsCkmh812FTJeOaeAYs3R
nA2wLyyn5KC+TabzWpdDS+MnMAfdr41r4d8ouCpsIFKcuA7Cp3POgVPWazHcVNWu
H79DLyELacn0qsjxQ1WD8SilUL72gbLvoZcXSc6kZ01DVCOSijMbal+LGS0g0dLd
gBvwrs5QoPDykfJ0wrefQjwePa1S6wRPxK3TY5JfrW4pyshIXK5zbNg8jTC8WRZi
S3SF3vpbGfHEn6texTHQ9NkHyIewqR/MOoJCQed41VAeTTH3j6Rn29D1wPrGD/p5
P5jG7mIkEBM2oUJd3szK24Ez+qMDXrimFqa3KRI8dhfuK7zQ3mrYLfAvNf9/vkkY
GoaJqCB22p5jYM10EdwMtGBgwAqC3MeZuz+MjNtu/Y95YlGTafaAx3LC9HyRiiUx
/0TVqxNH0QcxjTnAS1t42G8vJjMAh7myVGNyBUXd9+Ws93wiE4Gk8xrrxijLx1h0
mqzqkfAOLO8wOKChXQxBMc7ZEGqT25g8bxZONjybOYErnTcmWirs61N2r335CWUh
dqutkolqAlivQtWwJL7NBP2wPHUUBKt/BfTKuwY6TViAyblp8J59fROah7oHu6+5
1RxYqwDvWI1nTN7hZYgwCaHw1qlVvuUr8cJE3EnDzrcdceSt2Qs=
=CqOX
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.