This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug optimization/13285] -O2 optimization on MIPS causes strange problem with floating-point
- From: "cgd at broadcom dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 3 Dec 2003 20:04:40 -0000
- Subject: [Bug optimization/13285] -O2 optimization on MIPS causes strange problem with floating-point
- References: <20031203182253.13285.baitisj@evolution.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From cgd at broadcom dot com 2003-12-03 20:04 -------
Subject: Re: New: -O2 optimization on MIPS
causes strange problem with floating-point
At Wed, 3 Dec 2003 18:23:17 +0000 (UTC), "baitisj at evolution dot com" wrote:
> When I compile the following program without -O2 and run it on two of my
> R5K-mipsel platforms, I get the following (expected, seemingly
> correct) output:
Err, you've requested MIPS32 code generation. I'm not familiar with
either of the parts you mention, but MIPS32 is in general a superset
of "R5000", and generating MIPS32 code on a part capable of running
only MIPS IV ISA instructions will ... not produce the desired result.
Based on the execution time, it looks to me like using -mips32 is
generating code which causes a trap on your processor, and the FP
exception handler / emulator (which should know how to execute
instructions that the processor can't) is producing an... unexpected
result, possibly because it doesn't know how to handle those
instructions properly, either.
So, I guess the question I have is:
(1) are you really sure those parts can run MIPS32 code, and
(2) if not, why are you generating MIPS32 code to run on them?
(That Linux doesn't reject MIPS32 binaries if the processor/kernel
can't run them is another issue, but not one for GCC to be concerned
with.)
cgd
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13285