SH4 floating point optimization bug

["Kris Warkentin" <kewarken at qnx dot com>]

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

cheers,

Kris