There appears to be a bug in the compiler optimization when processing an array of long doubles. For example, try the following code:
long double z[10] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
void foo(){
int i;
float f=0.5;
for(i=0;i<10;i++){
z[i] *= f;
}
}
After running foo(), I would expect z to contain the values {0.5, 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5}. This works properly at optimization levels up to -o1, but not at -o2 or -o3. At -o2 or -o3, the final values in z are {1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5, ???}. Note that z[9] contains 0.5 times the value in the next memory location, which could be anything depending on whether that location has been used yet. Basically, it appears that the optimizer output is incrementing to the next element of the array at the wrong time, resulting in z[i] = z[i+1] *f.
It does work at the higher optimization levels if i is declared "volatile", but this should not be necessary, because there is no external process that could modify i.
I simplified the above code to highlight the optimizer error. The problem originally occurred for me in the open-source "remez" FIR filter algorithm, available online.
I am using CCS 3.3 with Code Generation Tools 5.2.8, and my device is a TMS320F28335.
Could someone try this, and let me know if you get the same error? I would like to make sure I don't have some incorrect setting that could be causing this. Thanks.
