public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: richard@wetafx.co.nz To: gcc-gnats@gcc.gnu.org Subject: optimization/9654: extra-precision fp comparisons are less accurate Date: Tue, 11 Feb 2003 04:06:00 -0000 [thread overview] Message-ID: <20030211035943.7070.qmail@sources.redhat.com> (raw) >Number: 9654 >Category: optimization >Synopsis: extra-precision fp comparisons are less accurate >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: wrong-code >Submitter-Id: net >Arrival-Date: Tue Feb 11 04:06:01 UTC 2003 >Closed-Date: >Last-Modified: >Originator: richard@wetafx.co.nz >Release: g++3 (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) >Organization: >Environment: Linux 2.4.18-xfssmp #1 SMP i686 >Description: //////////bug.cc: #include <math.h> double s(double t) throw() { double d = 0.75+t; double o = d < 1.0 ? acos(d) : 1.0/67108864.0; return sin(o*0.5)/sin(o); } int main(void) { return isnan(s(0.25-1.0/18014398509481984.0)); } //////////GNUmakefile: bug: bug.cc; g++3 -O1 -o bug bug.cc -lm >How-To-Repeat: With the two specified files, use gmake to build. With optimization turned on, the comparison between d and 1.0 on line 6 succeeds when it should fail. Essentially, the value that is computed for d is still in an fp register (with extra precision) when it is compared with 1.0. That value is less then 1.0, but by the time it is actually converted to a double, it gets rounded to 1.0. Thus, the situation that the comparison is trying to trap does not get trapped. Corresponding problems also appear with floats. This problem also shows up with: gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2) >Fix: There are various ways to work around this. Obviously, the code can be changed slightly so that the intended effect is correct. However, other similar problems may be far more subtle than generating a NaN. The problem can be avoid using the -ffloat-store option, but that has detrimental effects on performance. It would be great if floating point comparisons (float or double) were guaranteed to be on values at the precision specified by the source code, and not on values with extra precision. If this cannot be the default, perhaps there should at least be an option like -ffloat-compare so that there is a mid-ground between the performance hit of using -ffloat-store and the reliability hit of not using -ffloat-store. >Release-Note: >Audit-Trail: >Unformatted:
next reply other threads:[~2003-02-11 4:06 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-02-11 4:06 richard [this message] 2003-02-12 17:56 rearnsha 2003-02-14 3:56 Richard Addison-Wood 2003-02-14 12:26 Richard Earnshaw 2003-02-16 15:30 ebotcazou
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030211035943.7070.qmail@sources.redhat.com \ --to=richard@wetafx.co.nz \ --cc=gcc-gnats@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).