RE: SH4 floating point optimization bug

["Naveen Sharma, Noida" <naveens at noida dot hcltech dot com>]

Hi,
 
> 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.

Naveen.

>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;
> 
>  bar(&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.