[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#216616: marked as done (gcc-3.2: floating point problem with athlon thunderbird)



Your message dated Sun, 16 Nov 2003 22:40:15 +0100
with message-id <16311.61119.111825.421535@gargle.gargle.HOWL>
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 abrowaeys@libertysurf.fr Sun Oct 19 18:51:13 2003
Return-path: <abrowaeys@libertysurf.fr>
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 <albanbrowaeys@oreka.com>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: gcc-3.2: floating point problem with athlon thunderbird
Message-ID: <20031019235119.GA7753@argos.server>
Reply-To: Alban Browaeys <albanbrowaeys@oreka.com>
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 <abrowaeys@libertysurf.fr>
Delivered-To: submit@bugs.debian.org
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: LANG=fr_FR@euro, LC_CTYPE=fr_FR@euro

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 doko@cs.tu-berlin.de Sun Nov 16 15:41:57 2003
Return-path: <doko@cs.tu-berlin.de>
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 (doko@bolero.cs.tu-berlin.de [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 doko@localhost)
	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 <doko@cs.tu-berlin.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <16311.61119.111825.421535@gargle.gargle.HOWL>
Date: Sun, 16 Nov 2003 22:40:15 +0100
To: Alban Browaeys <albanbrowaeys@oreka.com>, 216616-done@bugs.debian.org
Subject: Re: Bug#216616: gcc-3.2: floating point problem with athlon thunderbird
In-Reply-To: <20031019235119.GA7753@argos.server>
References: <20031019235119.GA7753@argos.server>
X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Delivered-To: 216616-done@bugs.debian.org
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: LANG=3Dfr_FR@euro, LC_CTYPE=3Dfr_FR@euro
>=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;
> }



Reply to: