Issues with code when using "-O3" and "--symdebug:none" compiler options.

What version of the compiler are you using? (Note: the compiler version is not the same as the CCS version)

Hi,
I'm using compiler TI v7.4.1 and CCSv5.3

Most of the modules are compiled without optimization. Few are compiled with -O3 but don't show any issues (at least not obvious). Only one of them is causing problems.

This code was ported from CCSv2.21 and the same optimization options were retained. No issues were seen with -O3 option for the module that we're seeing the problems with right now.

Thanks

Using -g tends to limit opportunities for optimization and also tends to obscure bugs. It is probably not fruitful to consider compilations involving -g when analyzing this bug.

Rather than modifying the source code, use the compiler option -mu (--disable_software_pipeline) to disable software pipelining without affecting other optimizations.

Other than that, there is too little information here to analyze the issue. Higher levels of optimization have a higher tendency to expose bugs, whether those bugs are in the user's source code or the compiler. Check for compiler warnings. Look in the code for questionable casts. You may need to post a compilable test case demonstrating the problem.

Thanks for a quick response.
I was going to take -g option out. I was trying different combinations to see if it affects execution in any way.

I'll give it a try with -mu option. I'll try your other suggestions as well.

Is there a document that explains what -g option does and how the full symbolic debug data is used?

Thanks

DSP Engineer said:

Is there a document that explains what -g option does and how the full symbolic debug data is used?

Not really.  Besides, more recent releases change the way debug information works so that it is much less intrusive, and doesn't inhibit optimization, so the old behavior is deprecated.

Traditionally, debugging introduces barrier-like directives between instructions.  For easier-to-understand behavior during debugging, instructions are discouraged from crossing debugging directives, but instruction motion is important for a lot of optimizations.

Symbolic debug data is just what it sounds like.  CCS or other debuggers will read it to figure out where your source code symbols live, so it can display them in the watch window.  It also reads the debug information to figure out what function you are in and what line of code you are on.  But again, since the bug doesn't show up when you add -g, it's probably not worthwhile to try to analyze the bug from the perspective of -g.  You can try to use -g as a workaround, but there's no guarantee that -g will always work around the problem.  Perhaps it's still there, but harder to notice when using -g.

Hi,
Our current workaround is just to disable optimization. The cpu utilization does not increase by a lot so It works for us.
We're concerned that other modules that are compiled with -O3 might have some issues that we're not aware of. Unlike the other module, we don't see any issues.


Thanks

I too would be concerned about not knowing the cause, but we have nothing to go on towards analysis..

DSP Engineer said:

Is there a document that explains what -g option does and how the full symbolic debug data is used?

Please see the discussion in this wiki article about the trade-off between optimization and debug.  Since you use a compiler older than version 8.0.0, the last section, titled Older Compilers, is relevant to you.

Thanks and regards,

-George