[Bug c/12331] New: Incorrect floating-point result due to loss of significance

[adam at irvine dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12331

           Summary: Incorrect floating-point result due to loss of
                    significance
           Product: gcc
           Version: 3.2.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: adam at irvine dot com
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux

The following program, when compiled by GCC 3.2.2, produces unexpected
results on a Pentium (running RedHat Linux 9):

    double func() 
    {
      return 100.001;
    }

    main ()
    {
      double result;
      double y;
      y = 1000.0004;
      result = (func() + y) - (func() + y);
      printf ("%g\n", result);
      printf ("%08X %08X\n", ((int *)&result)[0], ((int *)&result)[1]);
    }

The output of the first line is 8.52651e-14, not 0 as expected.  

The important instructions are:

0x0804832b <func+3>:    fldl   0x8048448

0x08048351 <main+30>:   call   0x8048328 <func>
0x08048356 <main+35>:   faddl  0xfffffff0(%ebp)
0x08048359 <main+38>:   fstpl  0xffffffe8(%ebp)
0x0804835c <main+41>:   call   0x8048328 <func>
0x08048361 <main+46>:   faddl  0xfffffff0(%ebp)
0x08048364 <main+49>:   fsubrl 0xffffffe8(%ebp)
0x08048367 <main+52>:   fstpl  0xfffffff8(%ebp)

The problem is that the first "fstpl" instruction stores an 80-bit FPU
register into a 64-bit temporary, causing some significance to be
lost; when the same value is later computed in the 80-bit FPU
register, and the 64-bit temporary is subtracted, that extra
significance that was lost is the result of the subtraction.  I don't
consider this an "inherent limitation of the floating point types" (as
discussed in the Non-bugs section of your web site), since this
problem is avoidable by generating code that does not lose
significance (e.g. by using 80-bit temporaries).  


gcc -v output:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

No special options were used when compiling:

   gcc test2.c -o test2