ID Summary State Reported In Release Target Release Workaround Release Notes
CODEGEN-6270 Compiler manual incorrectly lists callgraph as option for --analyze Fixed MSP430_19.6.0.STS
CODEGEN-6135 Using --opt_level=4 with inconsistent --near_data can cause relocation overflow error Fixed MSP430_19.6.0.STS MSP430_19.6.0.STS Make sure that all files are compiled with --near_data=none when making a global variable that must use large data pointers, or else use -O3 instead of -O4. This test case has a large global array, which requires --near_data=none, and indeed the files that reference it have that option. However, another file (mpu_init.c) was compiled with --near_data=globals. Due to a bug in the compiler, all the --near_data options are merged at -O4 into a single --near_data that applies to all the recompiled files, and the merged value is "globals." With --near_data=globals, short pointers are used for the large global array, which can't work and causes a relocation-overflow error. The solution to the compiler bug is to stick with the original --near_data for each file. The workaround for this case is to make sure all files are compiled with --near_data=none, or else to use -O3 instead of -O4.
CODEGEN-5986 Compiler may crash when auto as return type of uninstantiated member function in template class resolves to template paramet Fixed MSP430_19.6.0.STS MSP430_19.6.0.STS Avoid "auto" as the return type of a member function if its immediate resolution is a template parameter. Or explicitly instantiate the class or function. In the given test case, there's a variable defined with type EventSubscriberTable<int>. To avoid the problem, then, include either template class EventSubscriberTable<int>; or template auto EventSubscriberTable<int>::getBroadcastList(void); in the source file. Given a class definition like template <typename T> class Table { public : auto getList(void) { return m_Callbacks; } private : T m_Callbacks; }; where the member function getList() returns "auto" and that "auto" can be seen to be "T", and this program: int main(int argc, char* argv[]) { Table<int> m_Table; return 0; } in which the Table class is instantiated but the function getList() is never used, the compiler may crash. The problem requires the combination of auto, template parameter, and uninstantiated function. Changing any of those details will avoid it.
CODEGEN-5943 Compiler may lose volatile qualifier in A->B->C when B and C are both volatile Fixed MSP430_19.6.0.STS MSP430_19.6.0.STS The expression has to contain both dereferences, eg, a->b->c, for the problem to appear. If they're separated by using a temp, as in T * volatile p; p = a->b; ... p->c ... then the problem should be avoided. Making the temp "p" volatile is also important, to prevent the compiler from recombining the two dereferences. Or compile with -o1, -o0, or -ooff. In an expression like A->B->C, when B and C are both volatile structure fields, we'd expect to see two distinct memory accesses every time. There is a bug in the compiler specifically with having two dereferences in a single expression, ie, A->B->C, in which it may lose the volatile qualifier from B. That may lead it to save A->B in a temporary variable and reuse that value instead of re-reading it as is supposed to happen.
CODEGEN-5809 MSP430 compiler may intermittently crash when using hardware multiply Fixed MSP430_19.6.0.STS Don't use the hardware multiply, ie, --use_hw_mpy=none. The MSP430 compiler may crash when using the hardware multiply, eg, --use_hw_mpy=F5. There is not a simple code sequence that triggers the problem; the right combination of instructions and codegen passes may access outside the bounds of an internal compiler structure, and that may trigger a crash.
CODEGEN-5773 --emit_references:file causes an internal error on Mac Fixed MSP430_19.6.0.STS MSP430_19.6.0.STS
CODEGEN-5674 Under -o4, compiler may assume a global variable is constant, if it's only set in files containing inline asm() Fixed MSP430_19.6.0.STS MSP430_19.6.0.STS First, compiling with -o3 (or less) instead of -o4 will avoid the problem. Second, making g_sys_opmode volatile does indeed work around the problem. Since the "volatile" qualifier tells the compiler that something is modifying the variable outside the compiler's view, that's exactly what is needed to keep it from being assumed constant. Third, removing the asm() from main.c will work around the problem, by including main.c in the recompilation. I modified EINT/DINT and EALLOW/EDIS macros in F2806x_Device.h and two cpu.h files, making them use the intrinsics __enable_interrupts, __disable_interrupts, __eallow, and __edis. As it happens, __enable_interrupts and __disable_interrupts control both INTM and DBGM, while the macros control them individually, so this may not be a completely satisfactory solution. The immediate trigger for the bug is that main.c contains asm() statements. That's the only file that sets g_sys_opmode; other files only read it. The presence of asm() keeps the file out of the recompilation that -O4 does. The compiler, however, still thinks it has the whole program (or at least the important parts); since it doesn't see main.c, it doesn't see the writes, and concludes that g_sys_opmode is a constant 0.
CODEGEN-5574 Loop controlled by unsigned char counter iterates more than 255 times Fixed MSP430_19.6.0.STS MSP430_19.6.0.STS Compile at -o1 or less, or restructure the loop to make it not need the 8-bit wraparound. A do-while loop with an unsigned loop variable narrower than int can miss one of its wraparound cases, for instance if the loop counts down and the counter starts at zero. The compiler may promote the variable to int, making it wider than the original and thus it will experience a much larger count when it wraps.
CODEGEN-5533 Loop with Cortex-R, -mf3, and DWARF debug leads to assembler error "defined differently in each pass" Fixed MSP430_19.6.0.STS MSP430_19.6.0.STS Several pieces have to come together for this problem to happen. --opt_for_speed needs to be 3 or greater; thus a workaround is to reduce optimization to --opt_for_speed=1. The source code has to have one or more IFs, followed by a nested scope that isn't part of a compound statement and defines local variables, followed by a loop. Another workaround is thus to move the local variable definitions to the enclosing scope. (Another that works for the given test case but isn't necessarily general is to initialise all those local variables, where they're defined in the nested scope.) Normal debug info must be present; a final workaround is therefore to use --symdebug:none to suppress debug info. Of course, that makes debugging difficult. The assembler will become confused when presented with the sequence of a .align, an instruction that is smaller than the specified alignment, a label, and the DWARF DW_AT_low_pc directive. Because of the way it processes alignments and labels in different passes, it will conclude that the label was defined with two different values, and report an error. This sequence is not something a human asm programmer would write. It arises from compiling a particular shape of statements in a loop, with a particular set of compilation options, to position the label and the .align and the directive. See the Workaround, which also indicates how to modify the code or compiler options to avoid this bug.
CODEGEN-5486 Global constexpr class errors out when assigning to member data Fixed MSP430_19.6.0.STS MSP430_19.6.0.STS The error can be avoided If the constexpr class definition is wrapped in a function which simply returns the instance of the class. For example: constexpr MyClass getA() { MyClass A("This is a constant literal"); return A;} Using 'getA()' instead of 'A' will work as expected. Constexpr class definitions may generate spurious parser errors, including one about "accessing expired storage."
CODEGEN-5119 Using #pragma RETAIN does not keep a static file level variable Fixed MSP430_19.6.0.STS MSP430_19.6.0.STS Use both "#pragma RETAIN" and "__attribute__((used))" at the same time. The RETAIN pragma may not keep an unused variable like it's supposed to.
CODEGEN-4931 Applying __attribute__((used)) to static variable does not work Fixed MSP430_19.6.0.STS
SDSCM00052006 ltoa definition conflicts with quasi-standard ltoa Fixed MSP430_19.6.0.STS Don't use ltoa; instead use sprintf. For a long time, the TI RTS has defined a function named ltoa used in printf. However, quasi-standard function ltoa with a different prototype has been floating around the net for even longer. The presence of TI's definition causes problems for applications which attempt to use ltoa. It's difficult for the user to override the definition in their program to use the quasi-standard version, because TI has a prototype for the bogus version in stdlib.h This defect has been resolved by renaming TI's ltoa to something in the implementation namespace. Additionally, we've added a definition of ltoa conforming to the quasi-standard version.

Generated on Wed Jun 19 22:55:06 2019