public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c/6900: Floating point behaviour of gcc on pentium
@ 2002-12-04 7:02 bangerth
0 siblings, 0 replies; 3+ messages in thread
From: bangerth @ 2002-12-04 7:02 UTC (permalink / raw)
To: 36876, gcc-bugs, gcc-prs, nobody, shyam, sure, tprince
Synopsis: Floating point behaviour of gcc on pentium
State-Changed-From-To: open->closed
State-Changed-By: bangerth
State-Changed-When: Wed Dec 4 07:01:59 2002
State-Changed-Why:
Christian explained why.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6900
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: c/6900: Floating point behaviour of gcc on pentium
@ 2002-12-04 6:56 Christian Ehrhardt
0 siblings, 0 replies; 3+ messages in thread
From: Christian Ehrhardt @ 2002-12-04 6:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c/6900; it has been noted by GNATS.
From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, tprince@computer.org,
sure@imsc.ernet.in, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org,
36876@bugs.debian.org, shyam@imsc.ernet.in
Cc:
Subject: Re: c/6900: Floating point behaviour of gcc on pentium
Date: Wed, 4 Dec 2002 15:51:45 +0100
Hi,
This is not a bug. Comparing floating point numbers with == may yield
unexpected results due to rounding errors. Someone please close this PR.
regards Christian
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6900
^ permalink raw reply [flat|nested] 3+ messages in thread
* c/6900: Floating point behaviour of gcc on pentium
@ 2002-06-01 14:06 Matthias Klose
0 siblings, 0 replies; 3+ messages in thread
From: Matthias Klose @ 2002-06-01 14:06 UTC (permalink / raw)
To: gcc-gnats, debian-gcc
>Number: 6900
>Category: c
>Synopsis: Floating point behaviour of gcc on pentium
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: unassigned
>State: open
>Class: wrong-code
>Submitter-Id: net
>Arrival-Date: Sat Jun 01 14:06:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: Ghanashyam Date <shyam@imsc.ernet.in>
>Release: 3.1 (Debian) (Debian unstable)
>Organization:
The Debian Project
>Environment:
System: Debian GNU/Linux (unstable)
Architecture: i686
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii gcc-3.1 3.1-2 The GNU C compiler.
ii binutils 2.12.90.0.7-1 The GNU assembler, linker and binary utiliti
ii libc6 2.2.5-6 GNU C Library: Shared libraries and Timezone
host: i386-linux
configured with: /mnt/data/gcc-3.1/gcc-3.1-3.1ds2/src/configure -v --enable-languages=c,c++,java,f77,proto,objc,ada --prefix=/usr --mandir=$\(prefix\)/share/man --infodir=$\(prefix\)/share/info --with-gxx-include-dir=$\(prefix\)/include/g++-v3-3.1 --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --enable-clocale=gnu --enable-threads=posix --enable-java-gc=boehm --enable-objc-gc i386-linux
>Description:
[ Reported to the Debian BTS as report #36876.
Please CC 36876@bugs.debian.org on replies.
Log of report can be found at http://bugs.debian.org/36876 ]
The following program gives erratic/correct answers under different
conditions. The program is self explanatory.
The expected behaviour is to get the value of the variable 'q' to equal the
value of the variable 'shift' . Erratic behaviour refers to deviation from
this equality. The deviation can be controlled by increasing/decreasing the
value of 'factor' . The variable take GENERIC values.
The expected behaviour is seen on SGI and SPARC machines with their native
compilers and also with gcc (2.7x), with or without optimization.
On pentium with gcc/egcs the following happens:
Without optimization: only those x which are powers of 2 give q = shift.
With optimization: all give q = shift.
The deviations are NOT an artifact of printf formats. If subsequents
iterations are done with further code, these deviations actually get
amplified, and thus are genuine. In a non trivial code, this uncontrolled
error accumulation is a disaster.
While it is true that beyond 15 decimal places, one has garbage bits in the
internal representation, a suitable round-off/truncation etc should discard
these bits correctly and consistantly for generic values. (Other platforms
mentioned above seem to take care of this so also optimization on pentium
platform.)
In another context, with a somewhat different program, the expected behaviour
resulted WITH-OUT optimization but WITH optimization, the behaviour was
erratic.
--------------------------------------------------------
PLEASE ADVISE.
-G. Date (shyam@imsc.ernet.in)
--------------------------------------------------------
/*---------------------------------------------------------------------*/
# include <stdio.h>
main(argc, argv)
int argc;
char **argv ;
{
double q, q0, x, factor, shift;
factor = 100000000.000001L ; /* Choose any typical fraction */
shift = 0.0L ;
for(x = 0.0L; x < 257.0L; x = x + 1.0L ) {
q0 = (factor)*x ;
q = q0 - factor*x + shift ;
if( q == shift )
printf(" TRUE:\t%20.8E%20.8E%20.8E\n", x, q0, q);
else
printf("FALSE:\t%20.8E%20.8E%20.8E\n", x, q0, q);
}
}
/*---------------------------------------------------------------------*/
Tim Prince commented:
report [case where an assignment sometimes rounds off to declared
precision, sometimes not, according to chosen level of optimization]
q0 = (factor)*x ;
q = q0 - factor*x + shift ;
Both egcs-2.96 and gcc-2.95.2 exhibit the reported behavior, where q0 is
rounded to double when not optimized, so that q0 - factor*x is non-zero.
When optimized, the same expression turns up zero. From my personal point of
view, I might expect the small change
q = q0 - (double)(factor*x) + shift ;
to make a difference, but it does not.
BTW, it is even more difficult to predict the result of this when running on
machines without normal extended precision but with a multiply-accumulate
instruction which does not round off between multiplication and subtraction.
I assume that the C9X draft shows the committee's consensus that should be
modified with the new math library functions if one wishes to produce
predictable results in future versions of C in such a case.
Tim
tprince@computer.org
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-12-04 15:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-04 7:02 c/6900: Floating point behaviour of gcc on pentium bangerth
-- strict thread matches above, loose matches on Subject: below --
2002-12-04 6:56 Christian Ehrhardt
2002-06-01 14:06 Matthias Klose
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).