This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/OMAP-L137: Compiler 8.x no longer works when activating optimization

Part Number: OMAP-L137
Other Parts Discussed in Thread: MATHLIB

Tool/software: TI C/C++ Compiler

Hi everyone,

I have a rather complex signal processing project. So far, I worked with compiler version 7.4.x (latest was 7.4.23). I developed the code without compiler optimization to track down the functionality. Then, I activated compiler optimization and the same functionality worked with lower measured load - everything was fine.

Recently, I had to switch from compiler version 7 to version 8. Now, the code worked when optimization was not used. However, the code does no longer work as expected when switching on optimization (level o2 - global optimization). I have changed some code fragments and deactivated optimization for one specific file to have the code running propperly again but I do not think that this is really a preferable solution.

The code is a sequential flow of operations in an interrupt service routine- no dependency on multi-threading is involved. Also, no RESTRICT keyword is used. I use the TI mathlib and dsplib. Also, it makes a difference if using the 8.1.4 or 8.2.1 version of the compiler: the shown undesired behavior differs. I also tried activating various compiler options, e.g., the option to keep the order of floating point operations. Each of those did not really solve the problem.

Are these kinds of problems known from other users? What can I do to track down the reason for the malfunction? Maybe, the optimization done by compiler version 8 is broken?

Best regards

Hauke

  • While you don't specifically say, I can tell from the compiler version numbers that you have problems with the C6000 compiler, and not the ARM compiler.

    Unfortunately, there is not enough detail here that specific action is possible.  We need you to narrow down the problem even more.

    Please keep an open mind about the cause.  It might be an error in the compiler.  But I have also seen cases like this that ended up being user error.  Sometimes an error is present all the time, but is only exposed by different compiler versions or build options.

    user4306123 said:
    I have changed some code fragments and deactivated optimization for one specific file to have the code running propperly again

    That being the case, please focus on that one specific file.  Build everything with the usual optimization, including this file.  But disable optimization for just one function.  Do that with #pragma FUNCTION_OPTIONS(function_name, "--opt_level=off") .  Please read more about that pragma in the C6000 compiler manual.  Then test.  Hopefully, this is practical, and you will eventually find only one function that, when optimized, causes the problem.  Then, you can make a test case out of that file, with that function as the focus.  To do that, please follow the directions in the article How to Submit a Compiler Test Case.

    Thanks and regards,

    -George

  • Hi George,
    thank you for anwering my question. Yes, you are right, I talked about the C6000 compiler version 8. Sorry for the lack of clarity.

    I have found my workaround for the described issue. It seems that when the compiler optimizes across multiple for-loops, the problem arises, e.g.,

    void myFunction()
    {
    for(i=0; i < 512; i++)
    {
    // Do something
    }

    for(i = 0; i < 512; i++)
    {
    // Do something else
    }
    }

    I have seen output value deviations and nan outputs, and I have really tracked down correct code functionality in debug mode. But you are right, I can not guarantee that there is no undetected bug.

    The solution which worked for me was to put parts of the functionality into a dedicated function to break up optimization length. Is that optimization across loops a new feature of compiler 8 compared to compiler 7? I did not see these problems with compiler 7.

    Unfortunately, I do not have the opportunity to prepare a compiler test case since the code is highly confidential.

    Thank you and best regards

    Hauke
  • Unfortunately, this ...

    user4306123 said:
    void myFunction()
    {
    for(i=0; i < 512; i++)
    {
    // Do something
    }

    for(i = 0; i < 512; i++)
    {
    // Do something else
    }
    }

    ... is still too vague.  There is not enough detail there to act on.  

    user4306123 said:
    Unfortunately, I do not have the opportunity to prepare a compiler test case since the code is highly confidential.

    I understand.  However, a test case is the only way to advance this issue.  Keep in mind you don't have to send everything, just a preprocessed form of the one key file.  You don't have to post it on the forum.  You can send it just to me.

    Thanks and regards,

    -George