Debian Bug report logs -
#36876
[PR c/6900] Floating point behaviour of gcc on pentium
Reported by: Ghanashyam Date <shyam@imsc.ernet.in>
Date: Thu, 29 Apr 1999 07:48:01 UTC
Severity: normal
Done: Matthias Klose <doko@cs.tu-berlin.de>
Bug is archived. No further changes may be made.
Forwarded to gcc-gnats@gcc.gnu.org
Toggle useless messages
Report forwarded to debian-bugs-dist@lists.debian.org
:
Bug#36876
.
(full text, mbox, link).
Acknowledgement sent to Ghanashyam Date <shyam@imsc.ernet.in>
:
New bug report received and forwarded.
Your message didn't have a Package: line at the start (in the
pseudo-header following the real mail header), or didn't have a
pseudo-header at all.
This makes it much harder for us to categorise and deal with your
problem report; please ensure that you say which package(s) and
version(s) the problem is with next time. Some time in the future the
problem reports system may start rejecting such messages.
(full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
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.
Details of versions etc:
------------------------
$ uname -a ;
Linux aspc30 2.0.36 #1 Mon Mar 29 12:46:14 IST 1999 i586 unknown
$ egcc -v ;
Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.90.29/specs
gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)
$ gcc -v ;
Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.3/specs
gcc version 2.7.2.3
$ ld -v ;
GNU ld version 2.9.1 (with BFD 2.9.1)
$ ldd /usr/bin/gcc
/lib/nfslock.so.0 => /lib/nfslock.so.0 (0x4000d000)
libc.so.6 => /lib/libc.so.6 (0x40013000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ ldd /usr/bin/egcc
/lib/nfslock.so.0 => /lib/nfslock.so.0 (0x4000d000)
libc.so.6 => /lib/libc.so.6 (0x40013000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
--------------------------------------------------------
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);
}
}
/*---------------------------------------------------------------------*/
Bug assigned to package `gcc'.
Request was from "J.H.M. Dassen" <jdassen@wi.leidenuniv.nl>
to control@bugs.debian.org
.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Debian EGCS maintainers <egcs@packages.debian.org>
:
Bug#36876
; Package gcc
.
(full text, mbox, link).
Acknowledgement sent to Matthias Klose <doko@cs.tu-berlin.de>
:
Extra info received and forwarded to list. Copy sent to Debian EGCS maintainers <egcs@packages.debian.org>
.
(full text, mbox, link).
Message #12 received at 36876@bugs.debian.org (full text, mbox, reply):
[This bug was reported to me as a co-maintainer of the Debian GNU/Linux EGCS
packages. Please Cc: 36876@bugs.debian.org in your response so it gets
archived in the Debian bugtracking system (http://www.debian.org/Bugs/).
Please Cc me as I'm not on the egcs-bugs list.]
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.
Details of versions etc:
------------------------
$ uname -a ;
Linux aspc30 2.0.36 #1 Mon Mar 29 12:46:14 IST 1999 i586 unknown
$ egcc -v ;
Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.90.29/specs
gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)
$ gcc -v ;
Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.3/specs
gcc version 2.7.2.3
$ ld -v ;
GNU ld version 2.9.1 (with BFD 2.9.1)
$ ldd /usr/bin/gcc
/lib/nfslock.so.0 => /lib/nfslock.so.0 (0x4000d000)
libc.so.6 => /lib/libc.so.6 (0x40013000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ ldd /usr/bin/egcc
/lib/nfslock.so.0 => /lib/nfslock.so.0 (0x4000d000)
libc.so.6 => /lib/libc.so.6 (0x40013000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
--------------------------------------------------------
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);
}
}
/*---------------------------------------------------------------------*/
Information forwarded to debian-bugs-dist@lists.debian.org, Debian EGCS maintainers <egcs@packages.debian.org>
:
Bug#36876
; Package gcc
.
(full text, mbox, link).
Acknowledgement sent to Matthias Klose <doko@cs.tu-berlin.de>
:
Extra info received and forwarded to list. Copy sent to Debian EGCS maintainers <egcs@packages.debian.org>
.
(full text, mbox, link).
Message #17 received at 36876@bugs.debian.org (full text, mbox, reply):
[Message part 1 (message/rfc822, inline)]
This is not a bug in egcs, but a general problem of floating point
arithmetics. If you print out (q/q0), you see that the difference of
"q" and "shift" is always zero, to within machine precision.
Tim Schmielau (tim@physik3.uni-rostock.de)
Noted your statement that bug has been forwarded to egcs-bugs@egcs.cygnus.com.
Request was from Matthias Klose <doko@cs.tu-berlin.de>
to control@bugs.debian.org
.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Debian GCC maintainers <gcc@packages.debian.org>
:
Bug#36876
; Package gcc
.
(full text, mbox, link).
Acknowledgement sent to Matthias Klose <doko@cs.tu-berlin.de>
:
Extra info received and forwarded to list. Copy sent to Debian GCC maintainers <gcc@packages.debian.org>
.
(full text, mbox, link).
Message #24 received at 36876@bugs.debian.org (full text, mbox, reply):
I am looking for some pointers / FAQ's how to use fp arithmetics on
the ix86 architecture. The background are "bug" reports as found on
http://www.debian.org/Bugs/db/36/36876.html and
http://www.debian.org/Bugs/db/40/40189.html (or appended here).
AFAIK these are issues with the machine precision, which could be
described in a FAQ added to the binary packages.
First Report:
=============
The following program inconsistently chooses minimal
array elements in case of equal elements being present.
Here is the code (ttr.c):
------------------------
#include <stdio.h>
#include <math.h>
int
main() {
double
a[4]={0.006776,2.5,3.0,0.006776},w[4]={0.000030,3.7,3.0,0.000030},t,amin;
int ir,i,nr=4;
double tol=9.31322574615479e-10*3.0;
for (i=0,ir=-1,amin=DBL_MAX;i<nr;i++)
if (a[i]>tol) {
t=w[i]/a[i];
if (t<amin || ir==-1) {
amin=t;
ir=i;
}
}
printf("ir=%d\n",ir);
for (i=0,ir=-1,amin=DBL_MAX;i<nr;i++)
if (a[i]>tol && ((t=w[i]/a[i])<amin || ir==-1)) {
amin=t;
ir=i;
}
printf("ir=%d\n",ir);
exit(0);
}
---------------
and here is the execution:
---------------
intech19:~$ egcc -g -Wall ttr.c -o ttr -lm
intech19:~$ ./ttr
ir=0
ir=3
-----------------
Second report:
==============
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.
/*---------------------------------------------------------------------*/
# 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);
}
}
/*---------------------------------------------------------------------*/
Information forwarded to debian-bugs-dist@lists.debian.org, Debian GCC maintainers <gcc@packages.debian.org>
:
Bug#36876
; Package gcc
.
(full text, mbox, link).
Acknowledgement sent to N8TM@aol.com
:
Extra info received and forwarded to list. Copy sent to Debian GCC maintainers <gcc@packages.debian.org>
.
(full text, mbox, link).
Message #29 received at 36876@bugs.debian.org (full text, mbox, reply):
re "First Report" [reported cases where compiler appears to be reversing
sense of comparison between otherwise equivalent test cases]
I assumed that #include <float.h> is intended.
If so, gcc -Os -march=pentiumpro -V2.95.2 compiliation produces at execution:
ir=0
ir=0
Same with -O2. Same with egcs-19991102, even with -ffast-math added, which
would allow for the reported variation. This result appears to be the only
correct one, unless specifying a relaxation of standards, as -ffast-math
apparently does.
re: Second 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
Information forwarded to debian-bugs-dist@lists.debian.org, Debian GCC maintainers <debian-gcc@lists.debian.org>, gcc-defaults@packages.qa.debian.org
:
Bug#36876
; Package gcc
.
(full text, mbox, link).
Acknowledgement sent to gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
:
Extra info received and forwarded to list. Copy sent to Debian GCC maintainers <debian-gcc@lists.debian.org>, gcc-defaults@packages.qa.debian.org
.
(full text, mbox, link).
Message #34 received at 36876@bugs.debian.org (full text, mbox, reply):
Thank you very much for your problem report.
It has the internal identification `c/6900'.
The individual assigned to look at your
report is: unassigned.
>Category: c
>Responsible: unassigned
>Synopsis: Floating point behaviour of gcc on pentium
>Arrival-Date: Sat Jun 01 14:06:00 PDT 2002
Forwarded-to-address changed from egcs-bugs@egcs.cygnus.com to gcc-gnats@gcc.gnu.org.
Request was from Matthias Klose <doko@klose.in-berlin.de>
to control@bugs.debian.org
.
(full text, mbox, link).
Changed Bug title.
Request was from Matthias Klose <doko@klose.in-berlin.de>
to control@bugs.debian.org
.
(full text, mbox, link).
Information forwarded to gcc-defaults@packages.qa.debian.org
:
Bug#36876
; Package gcc
.
(full text, mbox, link).
Acknowledgement sent to doko@debian.org
:
Extra info received and filed, but not forwarded. Copy sent to gcc-defaults@packages.qa.debian.org
.
(full text, mbox, link).
Message #43 received at 36876-quiet@bugs.debian.org (full text, mbox, reply):
# submitted Debian report #36876 to gcc-gnats as PR c/6900
# http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=c/6900&database=gcc
forwarded 36876 gcc-gnats@gcc.gnu.org
retitle 36876 [PR c/6900] Floating point behaviour of gcc on pentium
thanks
Information forwarded to debian-bugs-dist@lists.debian.org, Debian GCC maintainers <debian-gcc@lists.debian.org>, gcc-defaults@packages.qa.debian.org
:
Bug#36876
; Package gcc
.
(full text, mbox, link).
Acknowledgement sent to "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
:
Extra info received and forwarded to list. Copy sent to Debian GCC maintainers <debian-gcc@lists.debian.org>, gcc-defaults@packages.qa.debian.org
.
(full text, mbox, link).
Message #48 received at 36876@bugs.debian.org (full text, mbox, reply):
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
Information forwarded to debian-bugs-dist@lists.debian.org, Debian GCC maintainers <debian-gcc@lists.debian.org>, gcc-defaults@packages.qa.debian.org
:
Bug#36876
; Package gcc
.
(full text, mbox, link).
Acknowledgement sent to bangerth@dealii.org, 36876@bugs.debian.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, shyam@imsc.ernet.in, sure@imsc.ernet.in, tprince@computer.org, gcc-gnats@gcc.gnu.org
:
Extra info received and forwarded to list. Copy sent to Debian GCC maintainers <debian-gcc@lists.debian.org>, gcc-defaults@packages.qa.debian.org
.
(full text, mbox, link).
Message #53 received at 36876@bugs.debian.org (full text, mbox, reply):
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
Reply sent to Matthias Klose <doko@cs.tu-berlin.de>
:
You have taken responsibility.
(full text, mbox, link).
Notification sent to Ghanashyam Date <shyam@imsc.ernet.in>
:
Bug acknowledged by developer.
(full text, mbox, link).
Message #58 received at 36876-done@bugs.debian.org (full text, mbox, reply):
closing the Debian report as well.
Christian Ehrhardt writes:
>
> 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
Send a report that this bug log contains spam.
Debian bug tracking system administrator <owner@bugs.debian.org>.
Last modified:
Tue Apr 23 15:55:22 2024;
Machine Name:
bembo
Debian Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.