Optimization 'changes' via #pragma

If you are building C code, then try 

#pragma FUNCTION_OPTIONS(name_of_function, "--opt_level=off")

If you are building C++ code, then write this just before the function

#pragma FUNCTION_OPTIONS("--opt_level=off")

Thanks and regards,

-George

This implies the optimizer operates at  a minimum of a function level.

Thanks but the results connote something I'm either missing or ... what I'm not sure.  I've applied the aforementioned pragma on the function but it appears that it is still optimizing out "unused code" in the function.

What I'm trying to do is set a break point for when an integer iterator is at a certain value for example:

if(sensor_index == sl_sensor_4)
{
	compensation_value = temperature.current.value;
}
// compensate the sensor
// get the temperature first
compensation_value = temperature.current.value;

The break point is the line inside the conditional so as I can inspect what is going on at that point. However the line inside it is automatically optimized out despite the use of

#pragma FUNCTION_OPTIONS(temp_compensate, "--opt_level=off")
void	temp_compensate(void)

Being applied to the function, shouldn't it NOT touch the code and generate EXACTLY what I have (and thus the break point should be able to be set at that point). The list file shows that it completely ignores the lines where the break point needs to occur despite turning off optimization on the function.

Trying to debug a specific instance of a loop over a set of values is difficult if you have to do it for every value (when I only need to look at one value heh).

I suspect I may have to unroll the loop to find out what is going on at the specific instance (sigh) a lot of work I guess. :D

Stephen

Hi,

You can try with a volatile, non static, maybe also extern variable (or call a dummy function defined in another compilation unit). I don't know if it work also when program level optimizaiton are turned on.

volatile int watchpoint;

....

if (cond) { watchpoint =temperature.current.value; }

Thanks both of you, I hadn't considered using the volatile keyword to 'fix' some of the issue.

I also hadn't realized that complete control of compiler behavior wasn't available. It would explain a few things anyhow.

This definitively answered my question.

Thanks!

Stephen