From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9726 invoked by alias); 29 Apr 2012 17:32:27 -0000 Received: (qmail 9714 invoked by uid 22791); 29 Apr 2012 17:32:25 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 29 Apr 2012 17:32:12 +0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sources.redhat.com Subject: [Bug math/14034] acos (-1.0) gives -pi in round-downwards mode on x86 Date: Sun, 29 Apr 2012 17:32:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: math X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00399.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=3D14034 Rich Felker changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugdal at aerifal dot cx --- Comment #1 from Rich Felker 2012-04-29 17:32= :06 UTC --- One quick (but probably wrong; see below) solution I can think of is adding= a single fabs instruction just before return. With that said, the value of -=CF=80 returned by glibc's acos(-1) in downward-rounding mode also differs from the value of -=CF=80 obtained by -= acos(1), with a difference of 1ulp. What's significant (and probably bad) about this= is that the value is actually less than -=CF=80 (the actual value), and thus i= f you just take the absolute value, you get a result that's greater than =CF=80, = which would be rather unexpected in downward-rounding mode. It's within 1ulp so it may technically be conformant, but it seems very bad. On the other hand, inserting the fabs instruction just after the fsqrt instruction (where the only thing it can do is convert -0 to +0) seems to w= ork, and the value I get trying it is the correctly-rounded representation of = =CF=80. --=20 Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=3Demail ------- You are receiving this mail because: ------- You are on the CC list for the bug.