Date: Mon, 16 Jan 2012 15:07:08 -0500 From: David Schultz <das@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r230193 - head/lib/libc/sparc64/fpu Message-ID: <20120116200708.GC87187@zim.MIT.EDU> In-Reply-To: <20120116235547.P3191@besplex.bde.org> References: <201201160409.q0G49kHt014841@svn.freebsd.org> <20120116235547.P3191@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 17, 2012, Bruce Evans wrote: > On Mon, 16 Jan 2012, David Schultz wrote: > > >Log: > > Computations on NaNs are supposed to return one of the input NaNs > > unchanged. > > Fix a few places in the sparc64 floating-point emulator where this wasn't > > being handled properly. > > > > Submitted by: bde > > Thanks. The only remaining large bug that I noticed near this is that > without -mhard-quad-float, signaling NaNs are not quieted and (IIRC) > FE_INVALID is not raised. > > BTW, NetBSD in 2005 uses Hauser soft-float for long doubles on sparc64, > and at least the MI parts of it are almost identical with the Hauser > soft-float in FreeBSD. But FreeBSD uses a completely different version > of soft-float for sparc64. It was apparently what NetBSD was using > in 2002 when it was imported into FreeBSD. Perhaps the Hauser version > is better (more correct or faster). However, the other version is > much simpler and looks much nicer -- it was originally from Berkeley > and has almost perfect KNF formatting (over 95% of lines are perfectly > formatted accoring to knfom; that is much better than 4.4BSD-Lite2 > sys/kern/*.c (88%) and FreeBSD-current sys/kern/*.c (89%, not counting > kern_intr.c which is about 0% after a single C++ comment in it confuses > indent(1)) and contrib/nvi/*/*.c (94%). Hauser soft-float has a Gnuish > style with 4-char indents amd is 26% KNF (probably mainly for the the > empty lines and some comments). softfloat is probably better. The style of contrib sources is what it is, and we have worse in the tree. That said, I don't have the cycles right now to fix what ain't broken. Moving all of the libc/quad/ floating-point routines to softfloat is more important, because that stuff *is* broken.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120116200708.GC87187>