Date: Wed, 29 Sep 2010 09:59:47 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Mark Blackman <mark@exonetric.com> Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/147599: [libm] [patch] Import netbsd complex functions into our libm Message-ID: <20100929094142.B1129@besplex.bde.org> In-Reply-To: <201009282110.o8SLA7ls078983@freefall.freebsd.org> References: <201009282110.o8SLA7ls078983@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Sep 2010, Mark Blackman wrote: > The following reply was made to PR kern/147599; it has been noted by GNATS. > > From: Mark Blackman <mark@exonetric.com> > To: bug-followup@FreeBSD.org, > db@db.net > Cc: > Subject: Re: kern/147599: [libm] [patch] Import netbsd complex functions into our libm > Date: Tue, 28 Sep 2010 21:44:11 +0100 > > I'm guessing that gcc has moved on from the issues in 2005? and wouldn't = > NetBSD have these same > issues? Maybe, but FreeBSD still use an old gcc (from 2007?), and now FreeBSD has clang which seems to be even further from supporting fenv (it does invalid optimizations in nonstandard rounding modes, and seems to have the same amount of fenv pragmas as gcc, that is, none, for turning this off). > In any case, perhaps the apple version is more likely to be suitable? > > = > http://www.opensource.apple.com/source/Libm/Libm-315/Source/Intel/complex.= > c This is much better. Its ccosh() has many similarities to the one that Steve and I wrote many years ago, but is more sophisticated. We only handled special values (Infs, NaNs and +-0) specially. The apple version also avoid overflow and loss of precision by using things like expm1(). The NetBSD version just evaluates the infinite-precision formula. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100929094142.B1129>