Debian Bug report logs - #40189
[PR c/6889] gcc produces incorrect minimization code

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: <camm@enhanced.com>

To: submit@bugs.debian.org

Subject: egcc: egcc produces incorrect minimization code

Date: Fri, 25 Jun 1999 15:34:24 -0400

Package: egcc
Version: 2.91.60-5

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
-----------------




-- System Information
Debian Release: 2.1
Kernel Version: Linux intech19 2.2.7 #1 SMP Thu May 27 11:53:43 EDT 1999 i686 unknown

Versions of the packages egcc depends on:
ii  libc6           2.0.7.19981211 GNU C Library: shared libraries
ii  g++             2.91.60-5      The GNU (egcs) C++ compiler.
ii  g++             2.91.60-5      The GNU (egcs) C++ compiler.

Message #12 received at 40189@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@cs.tu-berlin.de>

To: gcc@gcc.gnu.org

Cc: 36876@bugs.debian.org, 40189@bugs.debian.org

Subject: floating point arithmetics on ix86

Date: Fri, 5 Nov 1999 15:54:58 +0100 (MET)

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);
        }
}

/*---------------------------------------------------------------------*/

Message #19 received at 40189@bugs.debian.org (full text, mbox, reply):

From: N8TM@aol.com

To: doko@cs.tu-berlin.de, gcc@gcc.gnu.org

Cc: 36876@bugs.debian.org, 40189@bugs.debian.org

Subject: Re: floating point arithmetics on ix86

Date: Fri, 5 Nov 1999 21:13:43 EST

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

Message #24 received at 40189@bugs.debian.org (full text, mbox, reply):

From: gcc-gnats@gcc.gnu.org

To: 40189@bugs.debian.org

Subject: Re: c/6898: gcc produces incorrect minimization code

Date: 1 Jun 2002 20:56:00 -0000

Thank you very much for your problem report.
It has the internal identification `c/6898'.
The individual assigned to look at your
report is: unassigned. 

>Category:       c
>Responsible:    unassigned
>Synopsis:       gcc produces incorrect minimization code
>Arrival-Date:   Sat Jun 01 13:56:00 PDT 2002

Message #33 received at 40189-quiet@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@klose.in-berlin.de>

To: control@bugs.debian.org

Cc: 40189-quiet@bugs.debian.org

Subject: gcc: submitted Debian report #40189 to gcc-gnats as PR c/6898

Date: Sat, 01 Jun 2002 22:55:27 +0200

# submitted Debian report #40189 to gcc-gnats as PR c/6898
# http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=c/6898&database=gcc

forwarded 40189 gcc-gnats@gcc.gnu.org
retitle 40189 [PR c/6889] gcc produces incorrect minimization code
thanks

Message #38 received at 40189@bugs.debian.org (full text, mbox, reply):

From: reichelt@igpm.rwth-aachen.de

To: 40189@bugs.debian.org, camm@enhanced.com, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org

Subject: Re: c/6898: gcc produces incorrect minimization code

Date: 22 Nov 2002 16:47:01 -0000

Synopsis: gcc produces incorrect minimization code

State-Changed-From-To: open->closed
State-Changed-By: reichelt
State-Changed-When: Fri Nov 22 08:47:00 2002
State-Changed-Why:
    Not a bug.
    
    Whether you get ir=0 or ir=3 is just a matter when rounding will take place.
    Since the code is rearranged in optimization steps, you'll get varying
    results with different architectures and optimization options. Similar
    but not identical code might also lead to different results.
    Welcome to the world of floating point arithmetic.
    
    BTW, declaring t and amin as "volatile double" leads to your "expected"
    result even for -O0.

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

Message #43 received at 40189-done@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@cs.tu-berlin.de>

To: 40189-done@bugs.debian.org

Subject: Re: Bug#40189: c/6898: gcc produces incorrect minimization code

Date: Fri, 27 Dec 2002 17:05:03 +0100

therefore closing ...

reichelt@igpm.rwth-aachen.de writes:
> Synopsis: gcc produces incorrect minimization code
> 
> State-Changed-From-To: open->closed
> State-Changed-By: reichelt
> State-Changed-When: Fri Nov 22 08:47:00 2002
> State-Changed-Why:
>     Not a bug.
>     
>     Whether you get ir=0 or ir=3 is just a matter when rounding will take place.
>     Since the code is rearranged in optimization steps, you'll get varying
>     results with different architectures and optimization options. Similar
>     but not identical code might also lead to different results.
>     Welcome to the world of floating point arithmetic.
>     
>     BTW, declaring t and amin as "volatile double" leads to your "expected"
>     result even for -O0.
> 
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6898

Send a report that this bug log contains spam.