| ID |
Summary |
State |
Reported In Release |
Target Release |
Workaround |
Release Notes |
| CODEGEN-5387 |
Loop with early exit may peel incorrectly when unrolling (as with -mf3 or above) |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.10.LTS |
Add "#pragma UNROLL(1)" to the affected loop to inhibit unrolling, or compile with --opt_for_speed=2 or lower which inhibits unrolling of all loops. |
The compiler may unroll loops to speed them up. If it doesn't know the exact trip count, it needs to "peel" some iterations to make sure it does the extras if they don't fit exactly into the unrolled loop.
If the loop has an early exit -- in this case, it looks roughly like
while (flen-- && isdigit(*s)) ...
-- then there's a problem, because when the unrolled loop finishes, it could be because it's done, or it could be because isdigit(*s) returned false. If the unrolled part is done, we need to do the peeled part, but if isdigit() returned false, we don't, and the logic isn't ready for that conundrum and does the wrong thing. |
| CODEGEN-5317 |
Ternary (?:) expression with 0/1 result uses type of predicate, not result, when optimised |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.10.LTS |
Compile with -Ooff. |
An expression like "(p ? 1 : 0)" can be converted by the compiler into "(p != 0)". If the types of 1 and 0 are wider than int, and the expression is shifted left, as in "(p ? 1UL : 0UL) << 16", then the value shifted will be int instead of the wider type, and the overall value will be incorrect. |
| CODEGEN-5236 |
Register allocation failure |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.9.LTS |
No practical workaround |
The compiler may, in rare cases, allocate registers incorrectly. The most common symptom would be an internal error indicating that register allocation has failed. This problem has only been observed on C28x compiler version 8.1.3.LTS, but could occur for other ISAs. |
| CODEGEN-5174 |
Error in workaround for CODEGEN-3721 |
Fixed |
|
C2000_16.9.9.LTS |
Rewrite the code to avoid "<=" or ">=" integer comparisons. This may not always be possible, because the optimizer may rearrange other integer comparisons to create "<=" or ">=" comparisons. |
Integer <= and >= comparisons may falsely return "true" for some inputs. This will only happen for inputs that have more than 24 significant binary digits but vary in the lowest bits. The more significant binary digits the values have, the more bits may vary in the lowest end of the values and still falsely compare equal. |
| CODEGEN-5032 |
Loop over array, preceded by shuffle of the array using scalar temp repeatedly, may produce incorrect results |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.10.LTS |
The test case uses the same temp, nTemp, repeatedly in the shuffle function. Using different temps for each assignment will avoid the problem. Using "#pragma UNROLL(1)" to inhibit unrolling of the affected loops may also avoid the problem. |
The problem case looks something like
x = a[0]
a[1] = x
x = a[2]
a[3] = x
for (i = 0; i < N; i++) {
a[i] = ...
... a[i] ...
}
It shuffles data in an array a[] using the scalar x, then loops over array a[]. This particular arrangement, with the right optimisations, will do the wrong thing with the shuffle code. The wrong thing is part of optimising the loop, so both parts are required for there to be a problem. A workaround is to use a separate scalar variable for each assignment in the shuffle, ie, "x1 = a[0]; a[1] = x1" and "x2 = a[2]; a[3] = x2". |
| CODEGEN-4885 |
See MISRA diagnostics when compiling stdio.h |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.10.LTS |
none |
A program that includes <stdio.h> and checks for MISRA warnings may see some from stdio.h itself, which should not happen. |
| CODEGEN-4791 |
Structure field reference directly from function call causes INTERNAL ERROR |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.9.LTS |
Compile with any value of --opt_level except "off".
Or, given the expression f().x, change it to "t=f(); t.x"; in other word, capture the struct returned from the function call in a variable, and make the field reference from that variable instead of directly from the function call. |
Compiling an expression like f().x -- a function call immediately used to make a structure field reference -- can cause the compiler to abort with INTERNAL ERROR. Any use of the optimiser, or a simple code rearrangement, avoids the problem. |
| CODEGEN-4700 |
Incorrect diagnostic when using macro that comes from macro library |
Fixed |
|
C2000_16.9.10.LTS |
Unpack all of the macro libraries and re-pack them into a single unified library, or rename all macros to names with less than 15 characters |
If you are using assembler macro libraries, and you have more than one library, and two or more of those libraries have macros with names that are longer than 15 characters, you may get an incorrect error message from the assembler saying "Bad archive entry" |
| CODEGEN-4678 |
Incorrect error due to typedef of very large object |
Fixed |
C2000_16.9.7.LTS |
C2000_16.9.8.LTS |
As a workaround, remove the typedef. Where the typedef was used, instead use the type the typedef refers to. |
The TI compiler infrastructure is incapable of handling user-declared objects above a certain size, because it mistakenly truncates the size of very large objects. Formerly, this resulted in quiet corruption, which was defect CODEGEN-449. Now that CODEGEN-449 is fixed, the compiler will emit an error if the user attempts to create a type larger than the tool can handle. However, this error check is not quite right for typedefs. A typedef for a very large object that is still within the compiler's limit may cause the parser to mistakenly emit an error that the object is greater than the maximum supported size. |
| CODEGEN-4668 |
Macro with temp label causes assembler to crash |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.9.LTS |
The problem will not occur without macro labels. If labels are required, no workaround is known. |
The assembler may crash or report a memory misuse when using an assembly macro containing a label, if the label appears in an instruction in a position that requires extra lookahead to parse.
The original example is a register name followed by a comma and a label use; for that assembler, the thing following the comma might be a shift specifier, so it requires expanding the macro label. That extra step frees some memory that it shouldn't, causing the problem. |
| CODEGEN-4634 |
Use of stdarg.h va_start macro causes a write to the wrong local variable |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.9.LTS |
The test case for codegen-4634 has both a va_list declaration and a use of va_start. If the two are placed together, by moving the va_list declaration into the scope with the va_start, the problem does not occur.
The general workaround is to ensure an expression appears before the first nested scope. Exactly how to do that will depend on the situation. |
A function with a nested scope that declares local variables and appears before any expressions in the function, and also declares top-level locals after that, may mishandle the local variables in a way that acts as though some share a location though they're supposed to be distinct. I.e.,
int test(int arg, ...)
{
{ int a = 0; }
int b;
may mishandle a, b, arg, or any extra arguments.
Known cases all involve the ellipsis (...) parameter, but it is not known if that is also a necessary prerequisite. |
| CODEGEN-4623 |
Compiler incorrectly optimizes away member functions which arise from explicit template instantiation |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.10.LTS |
Compiling at -o2 helps, but sacrifices some optimisation. Adding a FUNC_CANNOT_INLINE pragma may also help, if it isn't an automatically-defined function. |
Compiling at -o3 may not retain external symbols for functions that are completely inlined within the file but which are declared extern, when using versions of the compiler from before 2017 -- ie, C6000 8.2.x, C2000/MSP430/TMS470 16.9.x. |
| CODEGEN-4605 |
Incompatible redeclaration error with -o4 when using anonymous unions |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.8.LTS |
Do not use anonymous structs or unions; give all struct members a name, even if it is never used. |
Anonymous structs and unions are a GCC extension. They are members of a parent structure and have no names. You access the elements inside them as if they were direct members of the parent class. If you have an anonymous struct or union inside a union and you use -O4 optimization, you may get the mistaken error "symbol so-and-so redeclared with incompatible type" at link time. This bug can only happen in COFF mode.
Essentially the same bug was previously fixed for EABI and was known as CODEGEN-1191. |
| CODEGEN-4600 |
Warning when using pragma RETAIN with attribute((noinit)) |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.9.LTS |
|
When using pragma RETAIN with attribute((noinit)) on the same symbol for an EABI target, a .clink directive is erroneously emitted in the assembly file, leading to a warning that the .CLINK directive is being ignored because the symbol already has .RETAIN specified. |
| CODEGEN-4518 |
Code mapped to __fmin intrinsic drops conditional operand |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.8.LTS |
No workaround except restructuring the code to avoid this shape. |
A statement like
if (A >= 0) A = 0;
is a candidate to be replaced by the __fmin intrinsic, if other details fit. However, the compiler will also accept
if (A >= 0) B = 0;
and that is not correct.
The problem is limited to C2000 with --float_support=fpu32 and when A and B are both floating-point expressions, and applies to both min and max idioms. The incorrect transformation can happen when "A" is an expression as well as when it is just a variable, and the constant value can be any number, not just 0. |
| CODEGEN-4464 |
Compiler mistakenly drops EALLOW or EDIS after call to function |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.8.LTS |
Put the definitions of F and G in separate files. |
If you have two functions in a file, F and G, where both F and G use either EDIS or EALLOW, and F comes before G in the file (or optimization is turned on), and G calls F, you may encounter a bug where the compiler improperly deletes one or more EDIS or EALLOW instructions.
If there are any EDIS or EALLOW instructions in G after the call to F, the compiler must leave at least one, because calling F puts the EALLOW bit into an unknown state. However, if there are any EDIS or EALLOW instructions before the call to F, the compiler will mistakenly think that the call to F did not modify the EALLOW bit, and will consider all EDIS and EALLOW instructions immediately following the call to F to be unnecessary, and will delete them. |
| CODEGEN-4419 |
Compiler erroneously speculates indexed load from the stack |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.8.LTS |
Modify the source code of the offending function to make local variables "volatile." There's no obvious way to pre-determine that a function will suffer from this bug; you just have to wait for the bug to happen, look at the line number of the offending instruction (which will always be a load with indexed addressing with base register SP), and go to the function at that line number. Make every local variable in that function "volatile." If it's a C++ function, you may need to make the function "volatile." |
The compiler moves instructions from one block to another to increase parallelism. Usually this is done by predicating (adding a condition to) every instruction that is moved above a branch. However, in some cases, the compiler will "speculate" the instruction, which means removing the condition entirely. This is done when the instruction's side-effects are judged to be safe, such as load of a local variable. In the case that the instruction's condition would have been false, this load will be useless, but at least it will be safe, because the stack pointer (SP) is at a legal location, and there won't be a memory fault. However, when a local variable's value is read with an indexed expression, the index register is not necessarily speculated exactly when the load is, so the index register may have a garbage value. In this test case, the load was speculated, but the index register definition wasn't, so in the false branch, the computed address was garbage, and we would read a random memory address, causing a memory fault. (Even though SP was perfectly valid, the index register was garbage, so SP+index might point anywhere in memory.) |
| CODEGEN-4407 |
Not using const causes unexpected build error when calling std::sort |
Fixed |
|
C2000_16.9.8.LTS |
Remove unnecessary const from helper in s__algo.c |
|
| CODEGEN-4311 |
Linker issues diagnostic: Invalid CIE reference 0xff000000 for the FDE at offset 0x00001745 in the .debug_frame section() |
Fixed |
C2000_16.9.4.LTS |
C2000_16.9.6.LTS |
Upgrade to 16.9.6.LTS or higher. |
The problem here is that the user is feeding at least one object file compiled with C2000 16.9.6.LTS into the 16.9.4.LTS linker, which is not a supported use case. Part of the fix for CODEGEN-2399 was to fix the alignment and size of CIE and FDE entries in .debug_frame. This change is forward-compatible, but not backward-compatible. Thus, because one of the object files was compiled with 16.9.6.LTS, linker version 16.9.6.LTS or higher must be used. |
| CODEGEN-4182 |
Should ignore option --pending_instantiations when compiling C files |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.8.LTS |
If the user wishes to use the option --pending_instantiations, they must add this option individually to each C++ file. |
The compiler option --pending_instantiations only makes any sense when used with C++ code. It cannot have any effect on C code. Indeed, when passed as an option to a compilation of C code, the compiler will stop and emit an error, "pending instantiations option can be used only when compiling C++"
This is troublesome when trying to compile a mixture of C and C++ files in CCS. If the user wishes to use the option --pending_instantiations, they cannot just add this option to the global compiler options list; they must add this option individually to each C++ file. |
| CODEGEN-4113 |
Assembler computes wrong result for expression 0x232800 % 0x10000 |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.7.LTS |
In some instances, as in the original test case, the AND operator can be used instead, but that is not a general workaround. |
The modulo operator in the TI assembler, for releases made in mid-to-late 2016 and all of 2017, is unreliable. In some cases it will produce an incorrect answer. |
| CODEGEN-4078 |
LInker takes over 5 minutes to finish |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.7.LTS |
None. If the linker command file wants to be that specific about memory ranges, then the work has to be done, and the option to disable the work has its own bug. |
Linking may take excessively long when the linker command file specifically places a lot of variables at specific addresses, especially for C2000. The original report was placing more than 300 variables. The --no_placement_optimization option is not a workaround because it causes a linker crash. Both problems are fixed together. |
| CODEGEN-3931 |
Compiler crashes while handling 0 length array in zero sized struct |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.8.LTS |
None |
The compiler crashes while parsing a struct or class with zero-sized members in C++ mode. |
| CODEGEN-3927 |
Compiler generates too-small RPTB loop with MOV AH, #0 |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.7.LTS |
Manually insert a NOP instruction in the repeat block (RPTB) in the generated assembly file, and compile the assembly file. Alternately, insert a NOP intrinsic in the source code loop for which the repeat block is generated. |
The compiler generates a repeat block (RPTB) that turns out to be too small when run through the assembler. This is because the compiler miscalculates the size of an instruction from not taking into account that the value loaded into a register is zero. |
| CODEGEN-3923 |
DWARF CFI information lost due to microoptimizations |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.8.LTS |
No practical workaround. |
Some optimizations in the compiler would change instructions but fail to retain debugging directives attached to those instructions. This could impact the accuracy of the DWARF debugging information in various ways. |
| CODEGEN-3918 |
Writing multiple input sections in one line unexpectedly changes how input sections are combined into output sections |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.7.LTS |
Stick with separate lines, if there are subsection cases like this one that should be comprehended. |
In a linker command file, using a line like "hello.obj (.const, .far)" may link differently than two lines with one section each. The problem is that the single line is interpreted as the OR of the two sections, and the linker does not understand that the OR also encompasses any of their subsections. Two separate lines are analysed separately and completely. |
| CODEGEN-3878 |
C2000 latency violation on back edge of RPTB |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.7.LTS |
The only workaround is to insert a NOP intrinsic at the end or the beginning of the repeat block. However, one would have to first identify the latency violation. |
In the case of a special instruction sequence requiring an additional latency-- a 2-cycle floating point instruction followed by a trigonometric math instruction, the additional required cycle was not generated when the instructions appeared in a repeat block and the result of the floating point instruction was used in the next iteration of the repeat block. |
| CODEGEN-3876 |
Code incorrectly removed from functions calling "naked" attribute functions |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.7.LTS |
|
The compiler supports the GCC attribute "naked," which means that a function shall not have prolog or epilog code. The idea is that this makes a blank function that the user may fill with assembly code.
The compiler also keeps track of the register usage behavior of previous functions in the same module, so that it can do some small optimizations like allocate caller-saved registers or eliminate unused code.
In this case, the compiler mistakenly assumed that a naked function did not use its input. The truth is that naked functions are essentially hand-coded assembly functions; while the compiler can assume they obey the C calling convention, the compiler can't know register behavior because it cannot parse the assembly instructions. |
| CODEGEN-3858 |
OFD gets DIE attribute offset wrong when using --dwarf_display=none,dinfo |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.7.LTS |
If you use --dwarf_display=none,dinfo, use --dwarf_display=none,dinfo,types instead |
You can use OFD to display the DWARF debugging information in your object files by using the option '--dwarf' (or -g). You can narrow the categories of DWARF information displayed by using the '--dwarf_display' option. If you use the option --dwarf_display=none,dinfo you will see the DWARF DIE objects in the .dwarf_info section, but you will not see any DW_AT_type attributes unless you also use the "types" flag. This is not a bug. However, when OFD skips a DW_AT_type attribute, it displays the offset of the skipped DW_AT_type for the next attribute instead of the next attribute's correct offset. |
| CODEGEN-3801 |
Linker crashes with INTERNAL ERROR (unhandled exception) |
Fixed |
C2000_16.9.4.LTS |
C2000_16.9.6.LTS |
|
The linker experiences a segmentation fault when there is a reference from a debug section to a symbol without a section (for example, an absolute symbol). |
| CODEGEN-3795 |
C2000 compiler fails to emit load DP instruction |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.6.LTS |
Use compiler option --disable_dp_load_opt to disable DP load optimization. |
The compiler fails to update the DP register before certain variable accesses. The issue is likely to occur when accessing variables that belong to sections that contain a combination of blocked and unblocked variables. |
| CODEGEN-3794 |
False warning for MISRA 10.1/10.2 when commutative binary operands swapped |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.7.LTS |
|
In certain cases, the compiler could emit an unwarranted MISRA diagnostic about type conversion. This would occur when using a commutative binary arithmetic operator with mixed operand types. The compiler mistakenly compared one operand's type to the other type. It should have compared each type to the promoted type of the operation. |
| CODEGEN-3721 |
Incorrect handling of comparisons on CLA hardware |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.8.LTS |
No practical workaround. Update compiler to 18.1.3.LTS or better. |
Unsigned comparison utilizes the CLA signed integer comparison instruction MCMP32. Due to a problem with this instruction, 32-bit signed comparisons between numbers of different signs and with a delta larger in magnitude than INT32_MAX will overflow, and the status bits will not be set correctly. For this reason, a certain subset of unsigned comparisons will also not be performed correctly. The compiler will add the command-line option "--cla_signed_compare_workaround". Setting this option to "on" will instruct the compiler to insert workaround code for every integer comparison (including unsigned comparisons). The added code can substantially add to the code size, so the compiler will not perform this workaround by default. |
| CODEGEN-3676 |
CLA store-load cycles for read-before-write pipeline hazard |
Fixed |
|
C2000_16.9.6.LTS |
No work around other than upgrade to a fixed version. |
For CLA instruction scheduling of stores followed by loads, only 2 cycles (instead of 3 cycles) were placed between the store/load. Fixed this to be the 3 cycles required by CLA pipeline to avoid read-before-write issue. To offset code size impact (increased NOPs), enabled better memory disambiguation checking to additionally eliminate unnecessary NOPs if a store/load pair were to different memory locations. |
| CODEGEN-3655 |
Incorrect code generated for multiplication |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.6.LTS |
|
Under a set of special circumstances too detailed for this release note to describe, it is possible for the compiler to drop certain multiply instructions, yielding incorrect code. The circumstances are somewhat rare. This will probably only happen with multiplications near an access of a 32-bit variable that is cast to 16 bits. |
| CODEGEN-3650 |
Linker crashes when printing module list to map file |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.6.LTS |
Add linker option --mapfile_contents=all,nomodules |
When creating a linker map file, and a summary of modules is written to the linker map file, and the entry point is undefined, the linker may crash. |
| CODEGEN-3619 |
pragma triggers false MISRA-C:2004 19.1/A warning |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.7.LTS |
N/A |
Certain pragmas appearing prior to #include statements, such as #pragma RESET_MISRA, would cause MISRA warning 19.1/A to be issued:
MISRA-C:2004 19.1/A: #include statements in a file should only be preceded by other preprocessor directives or comments |
| CODEGEN-3617 |
gmtime incorrect when invoked in timezones east of GMT |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.6.LTS |
Set the timezone to 0 (UTC) until the fix is in place |
|
| CODEGEN-3597 |
ELF header field e_phoff should be 0 when no program header is present |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.6.LTS |
|
ELF header field e_phoff should be 0 when no program header is present, and ELF header field e_shoff should be 0 when no section headers are present. |
| CODEGEN-3595 |
Stack usage under reports stack amount used because it fails to handle function aliases |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.8.LTS |
|
CCS Stack Assistant did not accurately track aliased functions-- functions whose definitions are represented by a different symbol name. Now, the alias function will be used to determine stack size correctly, and the aliased function call name will be replaced with its alias. Currently, the Stack Assistant GUI is not capable of showing both the aliased and alias function names for calls to aliased functions-- this will require a future update. |
| CODEGEN-3591 |
When using fill value, linker may crash or hang |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.5.LTS |
Upgrade to 17.6.0.STS or higher |
When using a fill value on a memory range, the linker may get into a corrupted state and either crash or enter an infinite loop. |
| CODEGEN-3580 |
C2000 float to int intrinsics matching error |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.6.LTS |
Assign the result to the same signedness as the conversion and subsequently cast it to the other:
unsigned int x = __f32toui16r(f);
int y = x;
int y = __f32toi16r(f);
unsigned int x = y; |
The following intrinsics fail to match depending on whether the result is assigned to a signed or unsigned int.
Conversion to unsigned int fails to match when assigned to signed int:
int x = __f32toui16r(f);
Conversion to signed int fails to match when assigned to unsigned int:
unsigned y = __f32toi16r(f); |
| CODEGEN-2373 |
Internal linker error triggered by function alias |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.6.LTS |
|
Linker sometimes generates "Assertion failed" message and aborts. |
| CODEGEN-2343 |
C2000 indexed addressing performance degradation |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.5.LTS |
|
For array indexing expressions of the form P[N] or P->f, whether written by the user or generated by an optimization, where N is a constant larger than 255 (after scaling by the size of the type), the compiler may generate inefficient code. We want this:
MOV AR0, #N
MOVL ... *AR1[AR0]
However, the compiler was actually doing this:
MOV ACC, AR1
ADD ACC, #(N/2) << 1
MOV AR2, ACC
MOVL ..., *AR2[0]
This is much more costly |
| CODEGEN-2286 |
palign(8) of .init_array messes up __TI_INITARRAY_Limit address |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.4.LTS |
In the linker command file, replace
.init_array > FLASH, palign(8), fill = 0xffffffff
with the following GROUP statement:
GROUP
{
.init_array
} > FLASH, palign(8)
The palign(8) on GROUP will ensure that any required padding is added after .init_array. However, both the size of .init_array and the value of __TI_INITARRAY_Limit remain unchanged. |
Applying palign(8) to .init_array caused __TI_INIT_ARRAY_Limit to be set to the end of .init_array including the padding. This broke RTS startup code responsible for calling constructors because the table of constructors now includes invalid data. This bug has been fixed and __TI_INIT_ARRAY_Limit is no longer affected by padding. |
| CODEGEN-2238 |
Compiler incorrectly emits MISRA 10.1 for function argument |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.6.LTS |
|
|
| CODEGEN-2182 |
INTERNAL ERROR: opt2000 experienced a segmentation fault |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.0.LTS |
The problem appears with a while-loop that places the increment or decrement ahead of the MAC. Work around it by using a for-loop, or by moving the increment/decrement to the end of the loop body (instead of in the while-loop predicate, for instance). |
A while-loop like
while (n--) sum += *x++ * *y++;
may cause the compiler to crash. Use a for-loop instead. |
| CODEGEN-2179 |
I16TOF32 or UI16TOF32 lost or cannot be generated |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.3.LTS |
|
The compiler incorrectly modeled I16TOF32 and UI16TOF32. This had two detrimental effects:
1. If the compiler created one of these instructions with a memory operand and gave it post-increment addressing, it could be dropped as dead code, leading to incorrect results.
2. Some loops that should have used one of these instructions would instead sign extend the 16-bit integer and used I32TOF32 or UI32TOF32 instead. |
| CODEGEN-2176 |
RPTB block containing RPT is too small |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.3.LTS |
|
This bug can occur when there is a small loop containing a smaller loop, where the smaller loop behaves like memset(foo, 0, n). Only the fill value zero will trigger this bug. The generated RPTB may be one byte too small to be legal, and the assembler will reject the RPTB. |
| CODEGEN-2171 |
C2000 compiler disables if conversion on mac |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.3.LTS |
|
|
| CODEGEN-2168 |
Incorrect use of MPYA overwrites T register, resulting in wrong computation |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.4.LTS |
|
The kill of register T was not being captured in the MPYA P,loc16,#16bit instruction causing a prior load to the T register to be erroneously overwritten by a subsequent MPYA P,loc16,#16bit instruction. |
| CODEGEN-2166 |
INTERNAL ERROR: lnk2000 failed to allocate memory |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.3.LTS |
Compile with --disable:cla_scratchpad_overlay, or
do not allow CLA functions to call any function in any section that may contain its own ancestor. |
CLA modules should have each function in its own text section, and CLA functions should absolutely not be recursive or mutually recursive in any way. For this test case, hand-coded CLA functions had two functions (A and C) in the same text section. A has a call to B, which is in a different text section. B has a call to C. This forms a cycle in the call graph, because the linker can only see sections and doesn't realize A and C are different functions. Due to a bug in the CLA scratchpad overlay optimization, this cycle would cause the linker to go into an infinite loop. |
| CODEGEN-2143 |
Anonymous struct in union causes type merging failure at -O4 |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.4.LTS |
Do not use anonymous structs or unions; give all struct members a name, even if it is never used. |
Anonymous structs and unions are a GCC extension. They are members of a parent structure and have no names. You access the elements inside them as if they were direct members of the parent class. If you have an anonymous struct or union inside a union and you use -O4 optimization, you may get the mistaken error "symbol so-and-so redeclared with incompatible type" at link time. |
| CODEGEN-2119 |
Stack usage assistant call graph misses callee relationship for some direct calls |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.3.LTS |
|
The Object File Display utility failed to detect function callees when generating call graph information for functions that contain nested blocks. |
| CODEGEN-2113 |
Hex utility mishandles space in directory name of output file |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.4.LTS |
Use directory names without spaces for output files. |
The hex utility did not correctly handle spaces in output directory and file names. |
| CODEGEN-2098 |
Temp filename collisions on Windows with many parallel invocations |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.3.LTS |
|
In some cases with a large number of compilations in parallel on Windows, the compiler could create temporary files with colliding names, resulting in strange compilation failures. |
| CODEGEN-2060 |
Even though option --buffer_diagnostics is not used, compiler issues diagnostic that says it is deprecated |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.3.LTS |
None |
The --buffer_diagnostics compiler option was deprecated as of MCU compilers v16.6.0.STS because this setting became the default behavior for the compiler. However, the option was passed to the linker and the linker issued a remark stating the option was deprecated. |
| CODEGEN-2053 |
Compiler incorrectly reorders struct assign for small, volatile structs with bit-fields |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.2.LTS |
Use optimization level 0 or off (option --opt_level) |
For a very specific optimization, the optimizer may drop a volatile qualifier from a struct assignment. In some cases, the compiler may later perform an incorrect optimization, most commonly incorrectly reordering volatile assignments.
This bug can only happen in a function compiled with optimization level 1 or higher which contains both of the following: 1) A struct assign where the destination is volatile, and the source is a known constant, and the struct contains a bit-field, and the struct is of size "int" or smaller. 2) Any bit-field access (read or write) other than as part of a struct assign or initialization expression. That is, the name of the bit-field is present in the access expression. Note that the optimizer can create this situation by inlining functions, so 1 and 2 might be in different functions in the source code.
Consider a tree x = y where x and y are of type struct S. If the value of y is known at compile time (e.g. a const value), the optimizer will try to turn the struct constant into an integer constant (possibly combining bit-fields) and rewrite the tree to look like this: "(unsigned *)x = 32;" However, if y is volatile, that should be "*(volatile unsigned *)x = 32;" Because the access is not volatile, instruction scheduling could cause this instruction to drift past nearby volatile accesses. |
| CODEGEN-2050 |
Use of -o4 causes linker XML map file to have missing input_file entries |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.2.LTS |
|
|
| CODEGEN-2025 |
Linker crash message incorrectly suggests submitting a preprocessed file |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.3.LTS |
|
|
| CODEGEN-1979 |
Statements before declarations with no white space (aggravated by macros) may cause incorrect parser error |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.6.LTS |
Do not start any statement in the left-most column
Rearrange your code so that there are no statements before declarations. |
C99 and C++ allow statements before declarations in functions. This is not allowed by the C89 language, but as an extension, the TI compiler allows such statements in relaxed mode. However, in certain circumstances, the compiler may emit the 'error: expected "}"' for otherwise legal code which has statements before declarations.
This problem can only occur in relaxed C89 mode (which is the default mode), and 1) you have a function with statements that start in the left-most column, or 2) you use macros where the macro body contains C code with statements before declarations. |
| CODEGEN-1976 |
Value of __cplusplus is wrong |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.2.LTS |
If possible, use the -ps or --strict_ansi options. This mode will use the strict definition of __cplusplus, which is 199711L. |
Our parser mimicked G++ behavior for the value of this macro in relaxed ANSI mode. This reproduced a bug in G++ versions v.4.7 and v.4.3 that has since been fixed. |
| CODEGEN-1932 |
Update compiler roadmaps on routine basis |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.1.LTS |
|
|
| CODEGEN-1927 |
Float variables allocated to FPU register such as R4H are displayed as "unknown register R4HL" in Variables view |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.2.LTS |
Lowering the level of optimization in the project such that the variable is not allocated to a register will allow its value to be displayed correctly in the Variables view. |
Fixed an issue where FPU32 registers were sometimes incorrectly named and not available during debug. |
| CODEGEN-1710 |
Illegal instruction selection for __byte_peripheral_32 on FPU32 |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.2.LTS |
Try a lower level of optimization. For our test case, optimization levels lower than 3 did not expose the bug. However, this workaround may not help for all test cases. |
Although byte peripheral types are integral, when FPU32 device support is enabled, the compiler might store 32-bit integral values in floating point registers when CPU registers are unavailable. The compiler erroneously generates a MOVL instruction instead of a MOV32 instruction for moving 32-bit byte peripheral data between floating point registers and byte peripheral memory, if this data gets assigned to a floating point register. |
| CODEGEN-1709 |
Using #pragma INTERRUPT(HPI) crashes the compiler |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.2.LTS |
Besides not using #pragma INTERRUPT(HPI), there is no workaround. The compiler requires an update. |
Fixed a crash that occurs when using #pragma INTERRUPT(HPI) |
| CODEGEN-1703 |
Designated initializer plus struct hack hangs compiler |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.1.LTS |
Avoiding using string constants to initialize objects with flexible array members. Instead, use a brace-initialized array. For example:
struct { int a; char b[]; } mystruct = {0, {'h', 'e', 'l', 'l', 'o'} }; |
Fixed a compiler hang caused by initializing flexible array members with string constants.
struct {int a; char b[]; } mystruct = {0, "hello"} /* Would cause the compiler to hang and/or crash */ |
| CODEGEN-1687 |
Assembler issues confusing diagnostic: Size is > 64 words, allocation will span page boundary |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.1.LTS |
Compile source files without the --issue_remarks option. |
Blocking related diagnostics are no longer issued by the assembler when compiling C/C++ source files. However, these diagnostics will continue to be issued when compiling hand-coded assembly files. The diagnostics may be disabled by excluding --issue_remarks in the compiler options. |
| CODEGEN-1671 |
Arrays of Byte Peripherals or types aligned larger than their size should generate error |
Fixed |
|
C2000_16.9.1.LTS |
Do not attempt to create an array of byte peripheral objects. |
The C language guarantees that the size of an array is equal to the size of each element times the number of elements. Because we double the alignment of byte peripheral data types but do not change the size, this does not hold true. There would be padding in the array, which is not allowed by the standard.
Underneath the hood, we use the aligned GCC attribute to change the alignment for byte peripherals. On GCC, if you try to make an array of elements whose alignment is larger than its size (see example code below), you get the following error:
"9:1: error: alignment of array elements is greater than element size"
However, our parser doesn’t generate an error. Instead, it just reduces the alignment of the element size silently and makes an array.
We need to generate an error and document that this is not allowed, both for byte peripherals and the aligned GCC attribute. |
| CODEGEN-1667 |
Assignment to 32-bit byte peripheral from 64-bit cast to 32-bit value causes internal error |
Fixed |
|
C2000_16.9.0.LTS |
Saving the cast value to a 32-bit temp and then assigning to the 32-bit byte peripheral will work at optimization settings of 0 and off. |
If a 64-bit value is cast to a 32-bit value and then assigned to a 32-bit byte peripheral type, an internal error occurs. |
| CODEGEN-1662 |
Optimizer incorrectly detects __fmin and __fmax idioms |
Fixed |
|
C2000_16.9.1.LTS |
If you want floating-point absolute value, use fabs. However, there are other ways this bug could be triggered that have no practical workaround other than to use -Ooff |
|
| CODEGEN-1656 |
Using --gen_profile_info does not work with -o4 |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.4.LTS |
Lower the optimization level to -o3. |
Previously, link time optimization failed when profiling options --gen_profile_info and use_profile_info were specified in combination with the --opt_level=4 option. The errors were because profiling options were not supported when used in combination with --opt_level=4.
Application profiling during whole program optimization is now supported. Profiling options --gen_profile_info and --use_profile_info may now be combined with --opt_level=4. |
| CODEGEN-1640 |
MISRA 19.1 misreported: #include statements should only be preceded by other preprocessor directives |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.1.LTS |
No practical workaround |
|
| CODEGEN-1639 |
MISRA-C:2004 17.6/R false positive when assigning local struct member to static struct member |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.4.LTS |
|
|
| CODEGEN-1634 |
MISRA 7.1 misreported: octal tokens in token paste |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.1.LTS |
No practical workaround |
|
| CODEGEN-1632 |
MISRA 15.2 misreported: switch clause unconditional break |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.1.LTS |
Put an explicit break at the end of the compound statement |
|
| CODEGEN-1517 |
#pragma FUNCTION_OPTIONS meaningless unless at least -o0 is used |
Fixed |
|
C2000_16.9.0.LTS |
|
|
| CODEGEN-1510 |
Assembler incorrectly issues warning on large constant used with MOVI32 instruction |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.0.LTS |
|
|
| CODEGEN-1420 |
Compiler mistakenly overwrites upper 32-bits to 0 by using MOVZ instruction to compute var32 |= 0x20 |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.1.LTS |
|
Fixed an issue where the compiler would issue a MOVZ instruction that zeroes the upper bits of an XAR register when those upper bits are needed for a future instruction. |
| CODEGEN-1333 |
Structure assignment causes compiler to fail with INTERNAL ERROR: Decomposition error |
Fixed |
|
C2000_16.9.0.LTS |
Replace struct assignments involving packed structures with a memcpy() call to copy the contents of the RHS of the struct assign to the LHS. |
|
| CODEGEN-1329 |
Lower diagnostic about redefined opcode to a warning, when a compiler intrinsic is redefined |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.3.LTS |
Remove the #define or do not include the header file in assembly files. |
When a header file attempting to redefine an opcode name is included in assembly files, the assembler issues an error because it is not legal to redefine an opcode name. While this behavior is correct, it causes programs to fail to compile when some C2000 header files are included in assembly files due to the "#define eallow ..." in the header files. |
| SDSCM00040386 |
Remove -olength option from hex utility's help summary and Users Guides |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.0.LTS |
|
|
| SDSCM00051734 |
Accepts invalid CLA instruction "MMOV32 MRx, MSTF" |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.6.LTS |
|
When coding in assembly for the CLA, the assembler accepts an instruction of the form MMOV32 MRx, MSTF. This is not a valid instruction. |
| SDSCM00051510 |
macro CLOCKS_PER_SEC should be type clock_t |
Fixed |
|
C2000_16.9.0.LTS |
|
|
| SDSCM00050540 |
Accepts invalid CLA instruction "MMOV32 mem, MRn, COND" |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.6.LTS |
Care should be taken when writing hand-coded assembly to only write valid instructions as they are documented. |
The CLA assembler accepts an instruction of the form "MMOV32 mem, MRn, COND", which is not legal. There is no conditional MMOV32 to a memory destination. The only valid conditional MMOV32 instructions have register (MRn) destinations. |
| SDSCM00043877 |
Emit error message when objects too large for infrastructure (roughly 512MiB, or 256MiWords) are truncated |
Fixed |
C2000_16.9.0.LTS |
C2000_16.9.7.LTS |
N/A |
Due to an internal limitation, the code generation tools cannot presently allocate objects larger than roughly 512MiB (roughly 256MiWords). Data objects larger than this are silently truncated to a much smaller size. When such objects are declared in the code, they are silently truncated and compilation continues without any diagnostics. |
