This is the mail archive of the
mailing list for the glibc project.
Re: Fix x86 sqrt rounding (bug 14032)
- From: Rich Felker <dalias at aerifal dot cx>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Wed, 27 Nov 2013 20:17:48 -0500
- Subject: Re: Fix x86 sqrt rounding (bug 14032)
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1311271803540 dot 7837 at digraph dot polyomino dot org dot uk> <52966555 dot 20603 at twiddle dot net> <20131127232338 dot GP24286 at brightrain dot aerifal dot cx> <5296979A dot 9030604 at twiddle dot net>
On Thu, Nov 28, 2013 at 02:08:42PM +1300, Richard Henderson wrote:
> On 11/28/2013 12:23 PM, Rich Felker wrote:
> >> Surely this is much more complex than simply setting the rounding precision to
> >> double before using fsqrt.
> > Setting the rounding precision is likely to be much slower, and has
> > issues with signals (signal handlers could be invoked with wrong
> > rounding precision, resulting in completely wrong results).
> I thought signal handlers always have this problem; if the user expects
> to be able to use any floating point from a signal handler one must always set
> a complete floating point environment. E.g. the program could be in the middle
> of an integer conversion and have set round-to-zero.
Indeed, that's an issue I hadn't considered. However, at present due
to bug 16068 an application trying to handle this correctly/portably
can't fix the precision because loading the default environment does
not load the precision.