From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32680 invoked by alias); 1 Jun 2002 21:06:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 32655 invoked by uid 71); 1 Jun 2002 21:06:00 -0000 Resent-Date: 1 Jun 2002 21:06:00 -0000 Resent-Message-ID: <20020601210600.32654.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-To: nobody@gcc.gnu.org Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, Ghanashyam Date , sure@imsc.ernet.in, tprince@computer.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, 36876@bugs.debian.org Received:(qmail 32529 invoked from network); 1 Jun 2002 21:04:40 -0000 Received: from unknown (HELO hirsch.in-berlin.de) (192.109.42.6) by sources.redhat.com with SMTP; 1 Jun 2002 21:04:40 -0000 Received: from gate.local (mail@dsl-213-023-043-144.arcor-ip.net [213.23.43.144]) by hirsch.in-berlin.de (8.12.1/8.12.1/Debian -2) with ESMTP id g51L4dFR002822; Sat, 1 Jun 2002 23:04:39 +0200 Received: from doko by gate.local with local (Exim 3.35 #1 (Debian)) id 17EG0a-0006ev-00; Sat, 01 Jun 2002 23:01:56 +0200 Message-Id: Date: Sat, 01 Jun 2002 14:06:00 -0000 From: Matthias Klose Reply-To: 36876@bugs.debian.org To: gcc-gnats@gcc.gnu.org, debian-gcc@lists.debian.org X-Send-Pr-Version:3.113 X-GNATS-Notify:Ghanashyam Date , sure@imsc.ernet.in, tprince@computer.org Subject: c/6900: Floating point behaviour of gcc on pentium X-SW-Source: 2002-06/txt/msg00018.txt.bz2 List-Id: >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 >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 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: