Part Number: AM62A7-Q1
When compiling with the TI C7000 compiler for the C7504 DSP core with exceptions enabled and a high optimization level, we have witnessed an issue that we believe is incorrect code generation or optimization. We have a minimum reproducible example in hopes of identifying the issue and arranging a fix or workaround with TI. We can send the example on request.
The example contains a small C++ object stored in a `std::unique_ptr`. The pointer is scoped to a function (`exception_mishandle_example`), which calls another function that optionally throws an exception (`eme_inner`). The generated/optimized code mishandles cleanup of the pointer and its allocated object when the exception is thrown.
We examined disassembly of the example and identified what we think is the problematic behavior. In the scenario we've created, the compiler appears to move the contents of the pointer/object from the stack to a register (if it's small enough). The compiler NEVER puts the object back onto the stack. If the object was originally on the stack, the program may clobber the contents of that memory, which is considered safe behavior since the data is safely saved in a register. If an exception is thrown, however, the preserved register is not correctly restored / referenced in the designated exception handler. Per the C++ exception handling ABI, the destructors for any object that goes out of scope while unwinding need to be called. We have witnessed the compiler generated exception handling code call these destructors incorrectly by either (1) assuming that the contents of the object are still valid on the stack, attempting to load the clobbered address, and failing, or (2) restoring the contents from an unrelated register and failing. If no exception is thrown, the destructors are called correctly using the context of the the preserved register.
The CCS project we can provide exhibits behavior (2). We were unable to reproduce behavior (1) in a small example, but we believe that the issues are related. The commonality between them seems to be moving the object data into a register and incorrectly referencing that data in the exception handler.
NOTE: We did not attach the .zip file directly since the forum doesn't allow it.
