Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on intel

Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on intel

[Joseph S. Myers]

The following reply was made to PR c/8395; it has been noted by GNATS.

From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Marco Bernardo <bernardo@sti.uniurb.it>
Cc: Bruce Allen <ballen@gravity.phys.uwm.edu>, Bruce Allen <ballen@aei.mpg.de>, 
     <gcc-gnats@gcc.gnu.org>,  <gcc-bugs@gcc.gnu.org>,  <nobody@gcc.gnu.org>
Subject: Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on
 intel
Date: Mon, 4 Nov 2002 17:02:43 +0000 (GMT)

 On Mon, 4 Nov 2002, Marco Bernardo wrote:
 
 > However, for a person doing research on the formal semantics of programming
 > languages, it is difficult to accept that two differently compiled versions
 > of the same sequential program return two different values for the same input.
 > The compiler should not be free to alter the semantics of a sequential program,
 > i.e. the program output for a given input! Some consistency should be kept.
 
 You should read Norrish's thesis (link from the GCC readings page) which
 gives a (imperfect) formal model in HOL of the semantics of a subset of
 C90.  There are many areas where the program output for a given input is
 only partially constrained.
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 

Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on intel

[Marco Bernardo]

The following reply was made to PR c/8395; it has been noted by GNATS.

From: Marco Bernardo <bernardo@sti.uniurb.it>
To: Bruce Allen <ballen@gravity.phys.uwm.edu>
Cc: Bruce Allen <ballen@aei.mpg.de>, <gcc-gnats@gcc.gnu.org>,
	<gcc-prs@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <nobody@gcc.gnu.org>
Subject: Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on
 intel
Date: Mon, 4 Nov 2002 17:56:51 +0100 (CET)

 Dear Bruce, Tim and Toone,
 
 Thanks for your messages and for the useful information
 you provided me with.
 
 >> 2. I hope we all agree on the fact that the output produced by
 >>    a (sequential) C program is the same for a given input,
 >>    regardless of the compilation options that are used.
 >
 >Absolutely false!
 >
 >C does not specify the order in which mathematical expressions are
 >evaluated, unless the programmer makes these completely explicity.
 >
 >And indeed compiling with optimizations turned on can eliminate many
 >subexpressions, cause compile-time evaluatiosn, register sorage etc, which
 >can also change results.
 
 I understand that:
 - C does not specify the order in which mathematical expressions are evaluated
   (up to operators precedence and associativity, I guess)
 - this order is important at run time (as you pointed out to me)
 - the compiler can change the order in which mathematical expressions
   are evaluated, especially for optimization purposes
 
 However, for a person doing research on the formal semantics of programming
 languages, it is difficult to accept that two differently compiled versions
 of the same sequential program return two different values for the same input.
 The compiler should not be free to alter the semantics of a sequential program,
 i.e. the program output for a given input! Some consistency should be kept.
 
 Anyway, thanks again for your messages.
 
 Best regards,
 		Marco
 
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 Prof. Marco Bernardo
 
 Universita` di Urbino
 Centro per l'Applicazione delle Scienze e Tecnologie dell'Informazione
 Piazza della Repubblica 13, 61029 Urbino, Italy
 
 Phone: +39-0722-4475    -  E-mail: bernardo@sti.uniurb.it
 Fax:   +39-0722-4475    -  WWW:    http://www.sti.uniurb.it/bernardo/
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 

Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on intel

[Bruce Allen]

The following reply was made to PR c/8395; it has been noted by GNATS.

From: Bruce Allen <ballen@gravity.phys.uwm.edu>
To: Marco Bernardo <bernardo@sti.uniurb.it>
Cc: Bruce Allen <ballen@aei.mpg.de>, gcc-gnats@gcc.gnu.org,
       gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Subject: Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on
 intel
Date: Mon, 4 Nov 2002 04:58:02 -0600 (CST)

 > 2. I hope we all agree on the fact that the output produced by
 >    a (sequential) C program is the same for a given input,
 >    regardless of the compilation options that are used.
 
 Absolutely false!
 
 C does not specify the order in which mathematical expressions are
 evaluated, unless the programmer makes these completely explicity.
 
 And indeed compiling with optimizations turned on can eliminate many
 subexpressions, cause compile-time evaluatiosn, register sorage etc, which
 can also change results.
 
 Bruce Allen
 

Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on intel

[Bruce Allen]

The following reply was made to PR c/8395; it has been noted by GNATS.

From: Bruce Allen <ballen@gravity.phys.uwm.edu>
To: Marco Bernardo <bernardo@sti.uniurb.it>
Cc: Toon Moene <toon@moene.indiv.nluug.nl>, Bruce Allen <ballen@aei.mpg.de>,
       gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
       nobody@gcc.gnu.org
Subject: Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on
 intel
Date: Sun, 3 Nov 2002 00:18:59 -0600 (CST)

 Marco, Toon is completely correct.  
 
 If you read the materials that we keep asking you to study, you will learn
 that there is a discrete set of "IEEE754 floating point numbers".  
 Somewhat less than 2^32 of them for single precision, somewhat less than
 2^64 of them for double precision.
 
 As a consequence, since this is a finite set, and the real numbers are not
 even a countable set, most real numbers are not IEEE754 floats.  Only a
 finite subset are.  Examples:
  Pi      ==> not an IEEE754 float
  1.2     ==> not an IEEE754 float
  6       ==> IS an IEEE754 float
  1.25    ==> IS an IEEE754 float
  1+2^-20 ==> IS an IEEE754 float
 Also, a mathematical operation between two IEEE754 floats may or may not
 yield another IEEE754 float.  For example 1.25*1.25 does yield another
 IEEE754 float, but (1+2^-20)*(1+2^-20) does yield an IEEE754 float if
 working in double precision, but not in single precision.
 
 When the result of a mathematical operation (say, assigning 1.2 to an
 IEEE754 variable) does not yield an IEEE754 float, the standard specifies
 a couple of different possible user-selectable ways to round the number
 (assign it an IEEE754 value).  There is round-to-nearest (pick closest
 IEEE754 float) and round-to-zero.
 
 Also, languages like C do not specify an order for operations to take
 place  in expressions.  So two identical lines of C might yield different
 results with different compilers.
 
 Like you, I am a University Professor (Physics).  I teach IEEE754 in my
 course on mathematical methods where we spend a few weeks on numerical
 methods.  Here are a few exercises for you to do:
 
 -- what is the largest integer that is an IEEE754 single float?  double
    float? Write this as a sum of powers of 2.
 -- what is the largest integer N such that both N and N+1 are IEEE754
    single floats?
 -- what is the smallest positive number that is still a normalized IEEE754
    single float.  smallest positive number that is an IEEE754 single float
    but is not normalized?
 Please read some of the literature (it is not a complicated subject) and
 do the exercises.
 
 Bruce Allen
 
 On Sat, 2 Nov 2002, Toon Moene wrote:
 
 > Marco Bernardo wrote:
 > 
 > > 1. Some colleagues of mine tried to compile and run the same program
 > >    on other platforms, in particular on a sparc machine, and the output
 > >    turned out to be
 > >        -6 -1.2 5 0 -6 0
 > >    Why is that? Isn't the IEEE 754 standard adopted on sparc machines?
 > 
 > Yes.  For further explanations, see the "Further Readings" item on our 
 > home page:
 > 
 > http://gcc.gnu.org -> "Further Readings" (left column) ->
 > 
 > 	Differences among IEEE 754 implementations (by Doug Priest)
 > 
 > -- 
 > Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
 > Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
 > Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
 > Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)
 > 
 > 
 

Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on intel

[Bruce Allen]

The following reply was made to PR c/8395; it has been noted by GNATS.

From: Bruce Allen <ballen@gravity.phys.uwm.edu>
To: Marco Bernardo <bernardo@sti.uniurb.it>
Cc: Tim Prince <tprince@computer.org>, Bruce Allen <ballen@aei.mpg.de>,
       gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
       nobody@gcc.gnu.org
Subject: Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on
 intel
Date: Sun, 3 Nov 2002 00:19:45 -0600 (CST)

 Marco, Tim is also completely correct.
 
 Bruce
 
 On Sat, 2 Nov 2002, Tim Prince wrote:
 
 > On Saturday 02 November 2002 07:42, Marco Bernardo wrote:
 > 
 > > Let me conclude by saying that my intention is not to be polemic.
 > > My point of view is that of a university professor who wants to teach
 > > to his students that there is a great alternative to Microsoft,
 > > which is Linux and the free software world.
 > > You would then understand that it is very difficult for me to support gcc
 > > and to teach my students how to use gcc in the presence of such a strange
 > > behavior, which is not justifiable at all on a scientific basis.
 > >
 > >
 > From a professorial point of view, you should be encouraging your students to 
 > consult expert references on floating point numerics, even if you don't care 
 > to do so yourself.  Before you start arguing about IEEE standards and 
 > scientific bases, you should be reading up on them, and the technical reasons 
 > for including the extended precision option.
 > If you are teaching at this level of detail, you could show your students how 
 > to set 53-bit rounding mode in order to duplicate the fpu settings of 
 > Microsoft compilers, how to use fpu mode settings to test code reliability, 
 > and how to break the Microsoft compiler by putting the fpu in standard 
 > default mode.  As standard C does not define a function for this purpose, the 
 > C committee must not have considered it to be as large an issue as you.
 > -- 
 > Tim Prince
 > 
 

Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on intel

[Tim Prince]

The following reply was made to PR c/8395; it has been noted by GNATS.

From: Tim Prince <tprince@computer.org>
To: Marco Bernardo <bernardo@sti.uniurb.it>,
	Bruce Allen <ballen@gravity.phys.uwm.edu>
Cc: Bruce Allen <ballen@aei.mpg.de>, <gcc-gnats@gcc.gnu.org>,
	<gcc-prs@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <nobody@gcc.gnu.org>
Subject: Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on intel
Date: Sat, 2 Nov 2002 08:15:47 -0800

 On Saturday 02 November 2002 07:42, Marco Bernardo wrote:
 
 > Let me conclude by saying that my intention is not to be polemic.
 > My point of view is that of a university professor who wants to teach
 > to his students that there is a great alternative to Microsoft,
 > which is Linux and the free software world.
 > You would then understand that it is very difficult for me to support gcc
 > and to teach my students how to use gcc in the presence of such a strange
 > behavior, which is not justifiable at all on a scientific basis.
 >
 >
 From a professorial point of view, you should be encouraging your students to 
 consult expert references on floating point numerics, even if you don't care 
 to do so yourself.  Before you start arguing about IEEE standards and 
 scientific bases, you should be reading up on them, and the technical reasons 
 for including the extended precision option.
 If you are teaching at this level of detail, you could show your students how 
 to set 53-bit rounding mode in order to duplicate the fpu settings of 
 Microsoft compilers, how to use fpu mode settings to test code reliability, 
 and how to break the Microsoft compiler by putting the fpu in standard 
 default mode.  As standard C does not define a function for this purpose, the 
 C committee must not have considered it to be as large an issue as you.
 -- 
 Tim Prince

Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on intel

[Toon Moene]

The following reply was made to PR c/8395; it has been noted by GNATS.

From: Toon Moene <toon@moene.indiv.nluug.nl>
To: Marco Bernardo <bernardo@sti.uniurb.it>
Cc: Bruce Allen <ballen@gravity.phys.uwm.edu>, Bruce Allen
 <ballen@aei.mpg.de>,  gcc-gnats@gcc.gnu.org,  gcc-prs@gcc.gnu.org, 
 gcc-bugs@gcc.gnu.org,  nobody@gcc.gnu.org
Subject: Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on
 intel
Date: Sat, 02 Nov 2002 16:56:04 +0100

 Marco Bernardo wrote:
 
 > 1. Some colleagues of mine tried to compile and run the same program
 >    on other platforms, in particular on a sparc machine, and the output
 >    turned out to be
 >        -6 -1.2 5 0 -6 0
 >    Why is that? Isn't the IEEE 754 standard adopted on sparc machines?
 
 Yes.  For further explanations, see the "Further Readings" item on our 
 home page:
 
 http://gcc.gnu.org -> "Further Readings" (left column) ->
 
 	Differences among IEEE 754 implementations (by Doug Priest)
 
 -- 
 Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
 Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
 Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
 Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)
 

Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on intel

[Marco Bernardo]

The following reply was made to PR c/8395; it has been noted by GNATS.

From: Marco Bernardo <bernardo@sti.uniurb.it>
To: Bruce Allen <ballen@gravity.phys.uwm.edu>
Cc: Bruce Allen <ballen@aei.mpg.de>, <gcc-gnats@gcc.gnu.org>,
	<gcc-prs@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <nobody@gcc.gnu.org>
Subject: Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on
 intel
Date: Sat, 2 Nov 2002 16:42:46 +0100 (CET)

 On Thu, 31 Oct 2002, Bruce Allen wrote:
 
 >It's not an argument, it's simply the facts. Please read the materials
 >that I refered you to.
 
 Ok, let us suppose that for the following program prova.c
       #include <stdio.h>
       int main(void)
       {
 	      double x, y, z, y_times_z;
 
 	      x = -6.0;
 	      y = -1.2;
 	      z = 5;
 	      y_times_z = y * z;
 	      printf("%g %g %g %g %g %g\n",
 	             x,
 	             y,
 	             z,
 	             x - y * z,
 	             y_times_z,
 	             x - y_times_z);
 	      return(0);
       }
 compiled with
     gcc -ansi -Wall prova.c -o prova
 on an intel machine, the following output
     -6 -1.2 5 -2.22045e-16 -6 0
               ^^^^^^^^^^^^
 is not a bug, but simply a consequence of the adoption of
 the IEEE 754 standard for floating point numbers.
 
 Now, I see two problems:
 
 1. Some colleagues of mine tried to compile and run the same program
    on other platforms, in particular on a sparc machine, and the output
    turned out to be
        -6 -1.2 5 0 -6 0
    Why is that? Isn't the IEEE 754 standard adopted on sparc machines?
 
 2. I hope we all agree on the fact that the output produced by
    a (sequential) C program is the same for a given input,
    regardless of the compilation options that are used.
    (If not, the compiler would not be compliant with the semantics).
    Now, try to compile the program above with
        gcc -ansi -Wall -O prova.c -o prova
    on an intel machine, i.e. try to set the code optimization option.
    In such a case the output turns out to be
        -6 -1.2 5 0 -6 0
    i.e. the right value 0 is obtained instead of the wrong -2.22045e-16.
 
 This is a clear evidence that gcc contains a serious bug that should be
 fixed asap (in the right way, i.e. according to the output obtained by
 setting option -O).
 
 Let me conclude by saying that my intention is not to be polemic.
 My point of view is that of a university professor who wants to teach
 to his students that there is a great alternative to Microsoft,
 which is Linux and the free software world.
 You would then understand that it is very difficult for me to support gcc
 and to teach my students how to use gcc in the presence of such a strange
 behavior, which is not justifiable at all on a scientific basis.
 
 Best regards,
 		Marco
 
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 Prof. Marco Bernardo
 
 Universita` di Urbino
 Centro per l'Applicazione delle Scienze e Tecnologie dell'Informazione
 Piazza della Repubblica 13, 61029 Urbino, Italy
 
 Phone: +39-0722-4475    -  E-mail: bernardo@sti.uniurb.it
 Fax:   +39-0722-4475    -  WWW:    http://www.sti.uniurb.it/bernardo/
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 

Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on intel

[Bruce Allen]

The following reply was made to PR c/8395; it has been noted by GNATS.

From: Bruce Allen <ballen@gravity.phys.uwm.edu>
To: Marco Bernardo <bernardo@sti.uniurb.it>
Cc: Bruce Allen <ballen@aei.mpg.de>, gcc-gnats@gcc.gnu.org,
       gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Subject: Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on
 intel
Date: Thu, 31 Oct 2002 02:46:13 -0600 (CST)

 Hi Marco,
 
 > I can understand that the problem is related to the IEEE 754
 > representation.
 > 
 > However, let me point out some weaknesses in your argument:
 
 It's not an argument, it's simply the facts. Please read the materials
 that I refered you to.
 
 Bruce Alen
 

Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on intel

[Marco Bernardo]

The following reply was made to PR c/8395; it has been noted by GNATS.

From: Marco Bernardo <bernardo@sti.uniurb.it>
To: Bruce Allen <ballen@aei.mpg.de>
Cc: gcc-gnats@gcc.gnu.org, <gcc-prs@gcc.gnu.org>,
	<gcc-bugs@gcc.gnu.org>, <nobody@gcc.gnu.org>
Subject: Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on
 intel
Date: Thu, 31 Oct 2002 09:39:56 +0100 (CET)

 Dear Bruce,
 
 Thanks for your message.
 
 >There's nothing wrong here.  It's very reasonable for this code to
 >produce ~10^-16 for double.
 >The reason is tha the number 1.2 can not be exactly represented as an
 >IEEE754 floating point number.
 >The numbers 5 and -6 CAN be exactly represented.
 
 I can understand that the problem is related to the IEEE 754
 representation.
 
 However, let me point out some weaknesses in your argument:
 
 1. If -1.2 does not have an exact representation,
    why is the value of variable y (i.e. -1.2)
    correctly displayed through printf?
 
 2. Let us consider the following variant of the program
    I attached to my report:
       #include <stdio.h>
       int main(void)
       {
 	      double x, y, z, y_times_z;
 
 	      x = -6.0;
 	      y = -1.2;
 	      z = 5;
 	      y_times_z = y * z;
 	      printf("%g %g %g %g %g %g\n",
 	             x,
 	             y,
 	             z,
 	             x - y * z,
 	             y_times_z,
 	             x - y_times_z);
 	      return(0);
       }
    With respect to the previous version, I added
    variable y_times_z together with the visualization
    of y_times_z as well as x - y_times_z.
    Surprisingly enough, the output is
       -6 -1.2 5 -2.22045e-16 -6 0
    i.e. the correct values are somehow restored.
    Now, passing through an additional variable
    like y_times_z is how the target code produced
    by gcc should be organized, isn't it?
    If so, then both x - y * z and x - y_times_z
    should evaluate to 0.
    Since this is not the case, gcc contains a bug
    in the way it translates the arithmetical expressions
    when doubles are involved.
 
 In conclusion, I still believe that gcc contains a serious bug
 on the intel platform, which should hopefully be fixed asap.
 
 If the bug is fixed, or you or someone else reading this message
 is able to point out some flaw in my argument, then my colleagues,
 my students, and I will be glad to keep using gcc.
 
 Best regards,
 		Marco
 
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 Prof. Marco Bernardo
 
 Universita` di Urbino
 Centro per l'Applicazione delle Scienze e Tecnologie dell'Informazione
 Piazza della Repubblica 13, 61029 Urbino, Italy
 
 Phone: +39-0722-4475    -  E-mail: bernardo@sti.uniurb.it
 Fax:   +39-0722-4475    -  WWW:    http://www.sti.uniurb.it/bernardo/
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 

Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on intel

[bangerth]

Synopsis: gcc 2.95.4 and 3.2 generate wrong code for double on intel

State-Changed-From-To: open->closed
State-Changed-By: bangerth
State-Changed-When: Wed Oct 30 12:57:03 2002
State-Changed-Why:
    Given the explanation of Bruce Allen, this is not a bug.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8395

Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on intel

[Bruce Allen]

The following reply was made to PR c/8395; it has been noted by GNATS.

From: Bruce Allen <ballen@aei.mpg.de>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, bernardo@sti.uniurb.it,
   gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on
 intel
Date: Wed, 30 Oct 2002 18:25:15 +0100

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8395
 
 There's nothing wrong here.  It's very reasonable for this code to 
 produce ~10^-16 for double.
 The reason is tha the number 1.2 can not be exactly represented as an 
 IEEE754 floating point number.
 The numbers 5 and -6 CAN be exactly represented.
 
 I suggest that you read the first 15 or so pages of "Numerical Recipes 
 in C" by Press, Teukolsky (and two others).
 They discuss this question.  Then look at 
 http://www.etsimo.uniovi.es/~antonio/uned/ieee754/IEEE-754.html
 
 The closest IEEE754 double to 1.2 is (in binary)
 1.0011001100110011001100110011001100110011001100110011
 =
 1.1999999999999999555910790149937383830547332763671875......
 in decimal.
 
 If we multiply this by 5 (which is exactly represented by an IEEE754 
 double) one gets
 5.9999999999999997779553950749686919152736663818359375
 
 which is not 6.  The difference is what you are seeing.
 
 #include <stdio.h>
 int main(void)
 {
     double x, y, z;
     long double lx, ly, lz;
 
     x = -6.0;
     y = -1.2;
     z = 5;
     printf("%g %g %g %g\n",
            x,
            y,
            z,
            x - y * z);
     lx = -6.0L;
     ly = -1.2L;
     lz = 5L;
     printf("%Lg %Lg %Lg %Lg\n",
            lx,
            ly,
            lz,
            lx - ly * lz);
     return(0);
 }
 
 

c/8395: gcc 2.95.4 and 3.2 generate wrong code for double on intel

[bernardo]

>Number:         8395
>Category:       c
>Synopsis:       gcc 2.95.4 and 3.2 generate wrong code for double on intel
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Wed Oct 30 00:26:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Marco Bernardo
>Release:        gcc 2.95.4 and 3.2
>Organization:
>Environment:
intel processor (pentium 4), Linux Debian 2.4.16
>Description:
Expressions containing occurrences of double variables
are wrongly translated, especially when negative values
are involved.
The problem disappears when using long double instead
of double.
In the attached program, the value of the expression
should be 0. This is the case with long double, whereas
its value is -2.22045e-16 with double.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/x-csrc; name="prova.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="prova.c"

I2luY2x1ZGUgPHN0ZGlvLmg+CmludCBtYWluKHZvaWQpCnsKCWRvdWJsZSB4LCB5LCB6OwoJbG9u
ZyBkb3VibGUgbHgsIGx5LCBsejsKCgl4ID0gLTYuMDsKCXkgPSAtMS4yOwoJeiA9IDU7Cglwcmlu
dGYoIiVnICVnICVnICVnXG4iLAoJICAgICAgIHgsCgkgICAgICAgeSwKCSAgICAgICB6LAoJICAg
ICAgIHggLSB5ICogeik7CglseCA9IC02LjBMOwoJbHkgPSAtMS4yTDsKCWx6ID0gNUw7Cglwcmlu
dGYoIiVMZyAlTGcgJUxnICVMZ1xuIiwKCSAgICAgICBseCwKCSAgICAgICBseSwKCSAgICAgICBs
eiwKCSAgICAgICBseCAtIGx5ICogbHopOwoJcmV0dXJuKDApOwp9Cg==