Your message dated Sun, 16 Nov 2003 22:40:15 +0100 with message-id <[EMAIL PROTECTED]> and subject line Bug#216616: gcc-3.2: floating point problem with athlon thunderbird has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -------------------------------------- Received: (at submit) by bugs.debian.org; 19 Oct 2003 23:51:13 +0000 >From [EMAIL PROTECTED] Sun Oct 19 18:51:13 2003 Return-path: <[EMAIL PROTECTED]> Received: from mail.libertysurf.net [213.36.80.91] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1ABNKK-000835-00; Sun, 19 Oct 2003 18:51:12 -0500 Received: from argos.server.maison (212.129.22.46) by mail.libertysurf.net (6.5.026) id 3F8D6D760075518B; Mon, 20 Oct 2003 01:49:59 +0200 Received: from prahal by argos.server.maison with local (Exim 3.36 #1 (Debian)) id 1ABNKS-000252-00; Mon, 20 Oct 2003 01:51:20 +0200 Date: Mon, 20 Oct 2003 01:51:19 +0200 From: Alban Browaeys <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: gcc-3.2: floating point problem with athlon thunderbird Message-ID: <[EMAIL PROTECTED]> Reply-To: Alban Browaeys <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline X-Reportbug-Version: 2.34 User-Agent: Mutt/1.5.4i Sender: Alban Browaeys <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-5.0 required=4.0 tests=HAS_PACKAGE version=2.53-bugs.debian.org_2003_10_18 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_10_18 (1.174.2.15-2003-03-30-exp) --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7Bit Package: gcc-3.2 Version: 1:3.2.3-8 Severity: normal I am not used to go this deep in code, i would appreciate any critisicm regarding this report and the time you use on it.i If you think this have nothing to do with gcc , i d be happy with this being reassigned to the proper maintenair. Is it ok that double operators give diferents results with athlon TB than with other processors ? Following some mozilla debugging i ended on a "if (10*double)" test in a while statement. The test work with the same binary under Athlon XP/Pentium porcessors but not with Athlon Thunderbird. I isolated the whole conditional test in a file: mozjstest.c: the bad behaviour appear for testlimit >=5 using print or a temporary variable round the d value correctly and fix the problem, i found out the wrong values with gdb print. to have the bug as in mozilla i multiplied d by 10 (as the mozilla code do) , then even print is not able to round d value correctly (why on athlon TB only ?). extract from the real mozilla code (cf bug #203100): d, ds are double; L a long L = (Long) (d / ds); d -= L*ds; on athlon "d - d != 0" (especially d -= L*ds) though it is on other processors (still same binary) the loop is ended by: if (!(d *= 10.)) break; and d never equals 0 Alban -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux argos 2.6.0-test8 #12 Sun Oct 19 04:44:52 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Versions of packages gcc-3.2 depends on: ii binutils 2.14.90.0.6-3 The GNU assembler, linker and bina ii cpp-3.2 1:3.2.3-8 The GNU C preprocessor ii gcc-3.2-base 1:3.2.3-8 The GNU Compiler Collection (base ii libc6 2.3.2-8 GNU C Library: Shared libraries an ii libgcc1 1:3.3.2-0pre5 GCC support library -- no debconf information --J2SCkAp4GZ/dPZZf Content-Type: text/x-csrc; charset=iso-8859-1 Content-Disposition: attachment; filename="mozjstest.c" Content-Transfer-Encoding: Quoted-Printable #include <stdio.h> // d is calculated through my use of he c temp double to fix the rounding= error // dold does exactly what the code in gecko does // note that d/dold are tested in gecko as the breaking condition after b= eing multiplied by ten. // i set L as long (on my platform it s equal to uint32 whiwh is the Long= type used by mozilla int main(){ // those values are those i got from my instance of mozilla double d=3D5000340000.; double dold=3D5000340000.; double ds=3D1000000000.; long L; double c; int testlimit =3D 6; int i =3D 1; =20 for(i=3D1;i<testlimit;i++){ L =3D (long) (d/ds); c=3D L*ds; d -=3D c; d*=3D10; printf("d n=B0%d: %f\n",i,d); } =20 for(i=3D1;i<testlimit;i++){ L =3D (long) (dold/ds); dold -=3D L*ds; dold*=3D10; printf("dold n=B0%d: %f\n",i,dold); }=20 =20 printf("%f %f %f \n",d, dold, c); return 0; } --J2SCkAp4GZ/dPZZf-- --------------------------------------- Received: (at 216616-done) by bugs.debian.org; 16 Nov 2003 21:42:06 +0000 >From [EMAIL PROTECTED] Sun Nov 16 15:41:57 2003 Return-path: <[EMAIL PROTECTED]> Received: from mail.cs.tu-berlin.de [130.149.17.13] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1ALUea-0002ev-00; Sun, 16 Nov 2003 15:41:56 -0600 Received: from bolero.cs.tu-berlin.de ([EMAIL PROTECTED] [130.149.19.1]) by mail.cs.tu-berlin.de (8.9.3p2/8.9.3) with ESMTP id WAA14604; Sun, 16 Nov 2003 22:40:15 +0100 (MET) Received: (from [EMAIL PROTECTED]) by bolero.cs.tu-berlin.de (8.12.10+Sun/8.12.8/Submit) id hAGLeFsU011764; Sun, 16 Nov 2003 22:40:15 +0100 (MET) From: Matthias Klose <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <[EMAIL PROTECTED]> Date: Sun, 16 Nov 2003 22:40:15 +0100 To: Alban Browaeys <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: Bug#216616: gcc-3.2: floating point problem with athlon thunderbird In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-6.7 required=4.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT version=2.53-bugs.debian.org_2003_11_15 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_11_15 (1.174.2.15-2003-03-30-exp) Closing the report as Falk suggested: > Comparing floating point values with =3D=3D and !=3D is nearly always= a > mistake, especially on x86 where registers have more precision than > stored values, you cannot expect to get anything sensible from it. > Please read http://www.validlab.com/goldberg/paper.ps. >=20 > IMHO we should close this bug. Alban Browaeys writes: > Package: gcc-3.2 > Version: 1:3.2.3-8 > Severity: normal >=20 > I am not used to go this deep in code, i would appreciate any critisi= cm > regarding this report and the time you use on it.i If you think this > have nothing to do with gcc , i d be happy with this being reassigned= to > the proper maintenair. >=20 > Is it ok that double operators give diferents results with athlon > TB than with other processors ? >=20 > Following some mozilla debugging i ended on a "if (10*double)" test i= n a > while statement. > The test work with the same binary under Athlon XP/Pentium porcessors= but not with Athlon Thunderbird. >=20 > I isolated the whole conditional test in a file: > mozjstest.c: the bad behaviour appear for testlimit >=3D5 > using print or a temporary variable round the d value correctly and= > fix the problem, i found out the wrong values with gdb print. >=20 > to have the bug as in mozilla i multiplied d by 10 (as the mozilla > code do) , then even print is not able to round d value correctly=20= > (why on athlon TB only ?). >=20 > extract from the real mozilla code (cf bug #203100): > d, ds are double; L a long > L =3D (Long) (d / ds); > d -=3D L*ds; > on athlon "d - d !=3D 0" (especially d -=3D L*ds) though it is on= other > processors (still same binary) > =20 > the loop is ended by: > if (!(d *=3D 10.)) > break; > and d never equals 0=20 >=20 >=20 > Alban >=20 > -- System Information: > Debian Release: testing/unstable > Architecture: i386 > Kernel: Linux argos 2.6.0-test8 #12 Sun Oct 19 04:44:52 CEST 2003 i68= 6 > Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] >=20 > Versions of packages gcc-3.2 depends on: > ii binutils 2.14.90.0.6-3 The GNU assembler, linke= r and bina > ii cpp-3.2 1:3.2.3-8 The GNU C preprocessor > ii gcc-3.2-base 1:3.2.3-8 The GNU Compiler Collect= ion (base=20 > ii libc6 2.3.2-8 GNU C Library: Shared li= braries an > ii libgcc1 1:3.3.2-0pre5 GCC support library >=20 > -- no debconf information >=20 > #include <stdio.h> >=20 > // d is calculated through my use of he c temp double to fix the roun= ding error > // dold does exactly what the code in gecko does > // note that d/dold are tested in gecko as the breaking condition aft= er being multiplied by ten. > // i set L as long (on my platform it s equal to uint32 whiwh is the = Long type used by mozilla >=20 > int main(){ > // those values are those i got from my instance of mozilla > double d=3D5000340000.; > double dold=3D5000340000.; > double ds=3D1000000000.; > long L; > double c; > int testlimit =3D 6; > int i =3D 1; > =20 > for(i=3D1;i<testlimit;i++){ > L =3D (long) (d/ds); > c=3D L*ds; > d -=3D c; > d*=3D10; > printf("d n=B0%d: %f\n",i,d); > } > =20 > for(i=3D1;i<testlimit;i++){ > L =3D (long) (dold/ds); > dold -=3D L*ds; > dold*=3D10; > printf("dold n=B0%d: %f\n",i,dold); > }=20 > =20 > printf("%f %f %f \n",d, dold, c); > return 0; > }