ID Summary State Reported In Release Target Release Workaround Release Notes
CODEGEN-6270 Compiler manual incorrectly lists callgraph as option for --analyze Fixed C2000_19.6.0.STS
CODEGEN-6131 C28 fast int div: FPU load scheduling issue Fixed C2000_19.6.0.STS Either disable fast integer division --idiv_support=none, or if using fast integer division, --idiv_support=idiv0, avoid using the specific case for the I64/UI64 fast integer division. For the C2000 fast integer division feature, --idiv_support=idiv0, FPU register loads could incorrectly move ahead of the ABSxxDIVxx instruction in a fast integer division sequence. This could only happen for the I64/UI64 fast integer division case.
CODEGEN-6020 C28 fast int div: reduce unnecessary CPU to FPU MOVs Fixed C2000_19.6.0.STS Higher optimization levels, --opt_level=2 or greater, helped to offset this issue. For fast integer division feature, --idiv_support=idiv0, cases involving I64, UI64, I16 and UI16 were loading integer values to FPU registers by first loading to CPU registers, followed by the CPU-to-FPU register moves which add extra delay slots.
CODEGEN-5960 Dynamic libraries are not supported on targets other than C6000 Fixed C2000_19.6.0.STS C2000_19.6.0.STS
CODEGEN-5943 Compiler may lose volatile qualifier in A->B->C when B and C are both volatile Fixed C2000_19.6.0.STS C2000_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-5862 C2000 intrinsic __rpt_mov_imm fails to compile with negative source literal Fixed C2000_19.6.0.STS C2000_19.6.0.STS N/A When the C2000 intrinsic __rpt_mov_imm is used with a negative source operand, the compiler fails with a match error. This is because it was erroneously modeled as having an unsigned source operand.
CODEGEN-5791 C++ enum class with explicit type has some problems Fixed C2000_19.6.0.STS C2000_19.6.0.STS Avoid specifying an explicit base type for an enum. Values of a C++ enum class type with an explicit base type may not be cast properly to and from integral types. The exact conditions depend on undefined behavior, and thus are not 100% predictable; the known cases happen only on Windows, though the compiler uses the same codebase on all platforms.
CODEGEN-5773 --emit_references:file causes an internal error on Mac Fixed C2000_19.6.0.STS C2000_19.6.0.STS
CODEGEN-5739 C28x compiler manual incorrectly implies fields in a struct of type long, long long, double, long double, are only aligned o Fixed C2000_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 C2000_19.6.0.STS C2000_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 C2000_19.6.0.STS C2000_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 C2000_19.6.0.STS C2000_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-5119 Using #pragma RETAIN does not keep a static file level variable Fixed C2000_19.6.0.STS C2000_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 C2000_19.6.0.STS
SDSCM00052006 ltoa definition conflicts with quasi-standard ltoa Fixed C2000_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:54:08 2019