Date: Fri, 3 Dec 2010 11:40:06 -0500 From: David Schultz <das@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-bugs@FreeBSD.org, abramo.bagnara@gmail.com Subject: Re: kern/133583: [libm] fma(3) does not respect rounding mode using extended precision Message-ID: <20101203164006.GB35978@zim.MIT.EDU> In-Reply-To: <20101204000948.E2687@besplex.bde.org> References: <201012030702.oB3724qN017772@freefall.freebsd.org> <20101204000948.E2687@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 04, 2010, Bruce Evans wrote: > >- The only supported architecture that can have this problem due to > > dynamic precision changes is i386, and even then only for non-SSE2 > > builds. > > SSE2 makes little difference to this problem for i386, except for clang > it makes it worse. The ABI requires using the FPU for at least returning > values, and gcc keeps using the FPU for operations too. I wasn't going to get into that, but it just makes things worse. When gcc uses some weird combination of the i387 and SSE2, you can't predict what kind of precision you'll get. > >- The cost and complexity associated with making every function in > > libm detect and adapt to dynamic precision changes is prohibitive. > > Same as for dynamic rounding direction changes. Actually, much lower > cost and complexity than for rounding direction. For rounding direction, > it is actually useful to keep the caller's mode, and supporting this > would require making sure every step of every function works right in > every mode. Many of the multiprecision tricks only work in FE_TONEAREST. (See, e.g., the fesetround() in s_fma.c.) We have to jump through these hoops for all the IEEE-754R functions where exact results are required. (Are there any where we don't?) For transcendental functions, it seems far less important, since correct rounding isn't guaranteed anyway. > For rounding precision, we can just switch to mode that > works for every function that needs it, and most don't need it except > for bizarre environments (like forcing single precision and calling > extended precision functions and expecting them to return any particular > precision). For float and double routines, you could, for instance, write a wrapper library that checks the precision and changes it if needed before calling the underlying libm function. The vast majority of apps don't change the precision, though, so it seems more appropriate to tell programmers that they have to set the FPU precision back to the default before calling library functions. Making the long double functions work correctly is harder, since gcc butchers all the constants on i386.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101203164006.GB35978>