This is the mail archive of the
mailing list for the GCC project.
RE: SH4 floating point optimization bug
- From: "Naveen Sharma, Noida" <naveens at noida dot hcltech dot com>
- To: Kris Warkentin <kewarken at qnx dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 16 May 2002 12:12:36 +0530
- Subject: RE: SH4 floating point optimization bug
> I'm chasing an optimization bug with the following code.
> It's manifested in
> gcc 2.95.3 and I was wondering if anyone recognized it. I
> thought that it
> might have been squashed in a later release
I am getting correct results with cross compiler built
from mainline.Seems to be fixed.
>but our toolchain
> hasn't been
> brought forward yet so I thought I'd ask first.
> void bar(float *val)
> int main()
> float x = 100.123;
> float y = 3.14159;
> y += x / y;
> printf("y=%f\n", y);
> return 1;
> The act of doing a single precision floating point
> calculation (y+=x/y)
> followed by calling a function that takes the address of one
> of the floats
> gives incorrect results when compiled with optimization.
> From the assembly
> output we were able to determine that there was some
> incorrect setting of
> the fpscr register. That is to say, there were a lot of
> redundant loads to
> fpscr which were getting the state (precision mode PR and
> possible transfer
> size mode SZ) scrambled. We were able to make the resulting
> assembly work
> properly by taking out many of the 'lds.l @rX+,fpscr'
> statements out. Does
> this ring a bell to anyone? I think my next step will be to
> compile a cvs
> head branch cross compiler and see what the code output is like.