Compiler bug(?) in TI's CCS 5.1 on MotionFit SDK 5.1

FYI, here's a (thinly disguised) snippet of code from the MF SDK (eMPL_outputs.c file, inv_get_sensor_type_heading function definition) that showed a nasty compiler bug (I'm presuming).

Here's the code, embedded in my posting on the TI CCS forum: (http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/242897/850289.aspx#850289)

This has been driving me nuts -- trying to chase down a numeric error in code that worked before. Environment is C code on the MSP430, using the latest, up-to-date CCS 5.1.x and C compiler. Was trying to convert a quaternion (check it out in Wikipedia :-) to a heading angle, which involved some bit-bashing of sensor data and and arctan function. Here's the relevant code:

int get_heading(long *data, int8_t *accuracy, time_t *timestamp)

{

long t1, t2, q00, q03, q12, q22;

float fdata;

float volatile x, y, z;  // ***ADDED FOR DEBUGGING***



q00 = q29_mult(out.quat[0], out.quat[0]);

q03 = q29_mult(out.quat[0], out.quat[3]);

q12 = q29_mult(out.quat[1], out.quat[2]);

q22 = q29_mult(out.quat[2], out.quat[2]);



/* X component of the Ybody axis in World frame */

t1 = q12 - q03;



/* Y component of the Ybody axis in World frame */

t2 = q22 + q00 - (1L << 30);



x = (float) t2;

y = (float) t1;

z = atan2f(y, x);

fdata = z * 57.295779;

…...

Those of you in the know will recognize the last line as a conversion from radians to degrees. The last four lines were originally just one, without the intermediate variables: x, y and z, which I added to localize the problem. Originally thought that atan2f was failing. Hey, what else could go wrong :-) The problem is actually with the multiplication (and/or assignment). The value of z is correct, say -0.03, but fdata is something outrageous like 60,000.

I tried changing the compiler optimization settings from the default to no avail (disabled, etc.).

Now here's the interesting part, if I change the declaration at the beginning of the function from "float fdata;" to "float volatile fdata;" the multiplication works correctly and fdata ends up with the right value (e.g., around -1.7).

What's wrong? Compiler bug? (Guess I should look at the assembly code :-) Anybody else seeing anything like this?

Mike