• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 718 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Possible C2000 compiler optimization bug

Charles Stanhope
Prodigy 60 points


I have a possible code generation bug that I've reproduced on compilers 6.2.0, 6.2.6, and 6.2.9. I have a reproducible test case. It appears to only manifest itself with -O2. I'll try to summarize the bug the best I can. It's an odd one that had me chasing my tail for a few hours today, and it took me a little while to get to the test case.I hope my report will prove of some use.

I have some legacy code that uses an array of 16-bit words to store offsets into other arrays (realndx in the test case). This array is iterated through in a loop. The bug is that the compiler caches the pointer to realndx into an XAR register. The generated assembly uses two post-increment address modes against the XAR register which causes the next iteration of the loop to use an incorrect offset into the realndx array. In the case that caused us to notice the bug, the second array element of realndx is never modified.

Things I noticed while debugging and creating the test case:

  1. The bug occurs with the call to output_data(). Without the call, the generated code is fine.
  2. If the final term of the data array is even, the bug does not occur. When the final term is odd, the generated code is incorrect.
  3. The bug seems to manifest itself on -O2.

The compiler flags I have been using are included as a comment in the test case.

Best regards.

  • 0
    TI__Guru* 84285 points

    Yes, there is something fishy going on in the generated code, but I haven't quite got my finger on it yet.

    By the way, your array "data" is incredibly large for a C2000 device.  Are the values you're using for array dimensions the real values you use in production?

  • 0 in reply to Archaeologist
    Prodigy 60 points

    I hadn't noticed the values I chose since I was focusing on the test case, but they are a little large. We have 1MB external memory, but the actual array dimensions in the application would be something like: [50][256][33].

  • 0 in reply to Charles Stanhope
    TI__Guru* 84285 points

    This issue is now SDSCM00051126.  If there is a side effect in a function call with an expression with the result of a 32-bit multiply feeding into a 32-bit add, the compiler could mistakenly duplicate the side effect, which could create incorrect behavior.  The optimizer can create this scenario from user code that doesn't appear to have a side effect, such as an array index inside a loop.  A possible workaround is to put the value of the function call argument in a volatile local variable before passing it to the function.

    That's still an incredibly large array, but I don't think its large size contributes to the problem.

  • 0 in reply to Archaeologist
    Prodigy 60 points

    Great! Thank you for looking into this and supplying the issue number and the work around. I'm applying the work around for now with appropriate comments.