[Bug c/15470] New: Incorrect floating-point generation on Pentium 4 with -mno-fp-ret-in-387

[Bug c/15470] New: Incorrect floating-point generation on Pentium 4 with -mno-fp-ret-in-387

[coyote at coyotegulch dot com]

The attached program incorrectly computes double values when compiled with the
GCC mainline (3.5 20040514) command:

    gcc -lrt -lm -std=gnu99 -DVERIFY -DACOVEA -O1 -o evo -mno-fp-ret-in-387
coybench_evo.c

The above produces incorrect output of:
    best = ( -0.495,  0.497)

Correct output is (approximately:
    best = ( -0.495,  0.497)

Since this is beign compiled on a machine with an integrated hardware math
coprocessor (a Pentium 4), this option probably wouldn't be used. I ran across
this while doing Acovea runs with the attached benchmark. This is not a priority
in and of itself, but it might indicate a more troublesome problem elsewhere in
the compiler.

I note that correct code is generated for the x86_64, probably because the
Opteron has 64-bit registers to hold 64-bit doubles. But that's just
speculation... if I get some time, I'll generate some assembler and see what's
going wrong on the P4.

-- 
           Summary: Incorrect floating-point generation on Pentium 4 with -
                    mno-fp-ret-in-387
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: coyote at coyotegulch dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux
  GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux


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

[Bug c/15470] Incorrect floating-point generation on Pentium 4 with -mno-fp-ret-in-387

[coyote at coyotegulch dot com]

------- Additional Comments From coyote at coyotegulch dot com  2004-05-15 21:34 -------
Created an attachment (id=6309)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6309&action=view)
Test case to demonstrate problem

Yes, I know it's a big fat test case. I'll try to shorten it a bit when I get
the chance.

-- 


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

[Bug c/15470] Incorrect floating-point generation on Pentium 4 with -mno-fp-ret-in-387

[coyote at coyotegulch dot com]

------- Additional Comments From coyote at coyotegulch dot com  2004-05-15 21:35 -------
(In reply to comment #0)

> Correct output is (approximately:
>     best = ( -0.495,  0.497)

The above should read:

Correct output is (approximately):
    best = ( -0.655,  0.500)


-- 


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

[Bug target/15470] Incorrect floating-point generation on Pentium 4 with -mno-fp-ret-in-387

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target
           Keywords|                            |wrong-code


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

[Bug target/15470] Incorrect floating-point generation on Pentium 4 with -mno-fp-ret-in-387

[belyshev at lubercy dot com]

------- Additional Comments From belyshev at lubercy dot com  2004-05-16 18:09 -------
Created an attachment (id=6312)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6312&action=view)
minimized testcase (124 bytes)

cat > bug.i << EOF
extern double cos (double);
extern int printf (const char *, ...);

int main ()
{
	printf ("%f\n", cos (0.5));
	return 0;
}
EOF
gcc bug.i -lm -mno-fp-ret-in-387
./a.out
0.000000


-- 


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

[Bug target/15470] Incorrect floating-point generation on Pentium 4 with -mno-fp-ret-in-387

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-16 18:13 -------
This is invalid as you are changing the ABI and since cos is not compiled with -mno-fp-ret-in-387, it is 
returned in the fp register.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug target/15470] Incorrect floating-point generation on Pentium 4 with -mno-fp-ret-in-387

[coyote at coyotegulch dot com]

------- Additional Comments From coyote at coyotegulch dot com  2004-05-16 20:00 -------
(In reply to comment #4)
> This is invalid as you are changing the ABI and since cos is not compiled with
-mno-fp-ret-in-387, it is 
> returned in the fp register.

I'm willing to accept you analysis, but one question does come to mind: Why does
the program work properly with -mno-fp-ret-in-387 on x86_64?

-- 


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

[Bug target/15470] Incorrect floating-point generation on Pentium 4 with -mno-fp-ret-in-387

[wilson at specifixinc dot com]

------- Additional Comments From wilson at specifixinc dot com  2004-05-17 00:14 -------
Subject: Re:  New: Incorrect floating-point generation on Pentium
 4 with -mno-fp-ret-in-387

coyote at coyotegulch dot com wrote:
> I note that correct code is generated for the x86_64, probably because the
> Opteron has 64-bit registers to hold 64-bit doubles.

Correct code is generated for x86_64 because it uses a different ABI by 
default that does not use the 387 FP register stack.  This means x86_64 
has none of the "excess precision" problems that plague the x86 
compiler.  Essentially, x86_64 code defaults to -mfpmath=sse.

Also, this means that the -mno-fp-ret-in-387 option has no effect on 
x86_64 code, because it wasn't using the 387 FP regs in the first place.


-- 


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

[Bug target/15470] Incorrect floating-point generation on Pentium 4 with -mno-fp-ret-in-387

[coyote at coyotegulch dot com]

------- Additional Comments From coyote at coyotegulch dot com  2004-05-17 01:23 -------
(In reply to comment #6)
Thanks for the explanation. I'm fairly new to x86_64 programming.

Somewhere in the GCC documents, issues such as this need to be clearly
documented -- i.e., how architecture selection affects the validity of various
options. I've run into this several times now, with different processors.

I may submit a documentation patch, if no one objects.

-- 


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