| ID |
Summary |
State |
Reported In Release |
Target Release |
Workaround |
Release Notes |
| CODEGEN-4721 |
Linker crashes with INTERNAL ERROR: lnk2000 experienced a segmentation fault |
Fixed |
C2000_18.1.0.LTS |
C2000_18.1.3.LTS |
None. |
In the right (or wrong) circumstances, the linker may crash or print an error message and exit. The immediate reason is memory corruption caused by an errant data structure, which means that it's very hard to specify exactly how to reproduce or avoid it. There is no known workaround. |
| CODEGEN-4678 |
Incorrect error due to typedef of very large object |
Fixed |
C2000_18.1.0.LTS |
C2000_18.1.3.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_18.1.0.LTS, C2000_18.12.0.LTS |
C2000_18.1.3.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-4622 |
Builtin test __has_builtin incorrectly claims to support many __builtin functions |
Fixed |
C2000_18.1.0.LTS |
C2000_18.1.2.LTS |
Do not use __has_builtin until it is fixed. |
MCU release 18.1.x.LTS added the __has_builtin feature to detect whether or not a particular builtin function was supported. However, this feature test mistakenly returned true for a great number of builtins that the TI compiler does not support. |
| CODEGEN-4605 |
Incompatible redeclaration error with -o4 when using anonymous unions |
Fixed |
C2000_18.1.0.LTS |
C2000_18.1.2.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_18.1.0.LTS |
C2000_18.1.3.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-4576 |
hex --ascii option truncates address to 16 bits |
Fixed |
C2000_18.1.0.LTS |
C2000_18.1.2.LTS |
Use the hex converter from an earlier release |
When generating an "ASCII" format hex file, the hex converter would mistakenly truncate addresses to the lower 16 bits. |
| CODEGEN-4518 |
Code mapped to __fmin intrinsic drops conditional operand |
Fixed |
C2000_18.1.0.LTS |
C2000_18.1.2.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-4496 |
CLA compiler passes function arguments incorrectly and issues linker error |
Fixed |
C2000_18.1.0.LTS |
C2000_18.1.2.LTS |
None |
The CLA linker issues an undefined symbol error for a CLA math library function's scratchpad (__cla_CLAsincos_sp).
The fundamental bug is that the CLA code generator is erroneously passing a function argument on the function's scratchpad even though it should be passed in a register, and then zeroing out the register. Additionally, the function is a CLA math library function which has defined an incorrect scratchpad name, so once the function's scratchpad is referenced, the linker issues an undefined symbol error because there is no definition for the legitimate function scratchpad name. However, the function's scratchpad should not be referenced to begin with.
The bug was introduced in C2000 CGT v17.3.0.STS. |
| CODEGEN-4464 |
Compiler mistakenly drops EALLOW or EDIS after call to function |
Fixed |
C2000_18.1.0.LTS |
C2000_18.1.2.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_18.1.0.LTS |
C2000_18.1.2.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_18.1.0.LTS |
C2000_18.1.2.LTS |
Remove unnecessary const from helper in s__algo.c |
|
| CODEGEN-4339 |
div() and ldiv() return incorrect result when built with -o4 option |
Fixed |
C2000_18.1.0.LTS |
C2000_18.1.0.LTS |
|
|
| CODEGEN-4182 |
Should ignore option --pending_instantiations when compiling C files |
Fixed |
C2000_18.1.0.LTS |
C2000_18.1.2.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_18.1.0.LTS |
C2000_18.1.2.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_18.1.0.LTS |
C2000_18.1.2.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_18.1.0.LTS |
C2000_18.1.2.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_18.1.0.LTS |
C2000_18.1.1.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_18.1.0.LTS |
C2000_18.1.3.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_18.1.0.LTS |
C2000_18.1.0.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_18.1.0.LTS |
C2000_18.1.1.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-3858 |
OFD gets DIE attribute offset wrong when using --dwarf_display=none,dinfo |
Fixed |
|
C2000_18.1.0.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_18.1.0.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_18.1.0.LTS |
C2000_18.1.0.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_18.1.0.LTS |
C2000_18.1.2.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_18.1.0.LTS |
C2000_18.1.3.LTS |
No practical workaround. The impractical workaround:
Look for every 32-bit integer comparison in the program. For each signed comparison, if it is anything but a comparison to zero or the inputs will always be of the same sign, you will need to rewrite it to check the relative magnitude of the inputs. You may want to write a function or macro to do this. One way to do this is by using a floating-point comparison:
if (x < y)
becomes:
if (((float)x < (float)y) || (float)x == (float)y && (x < y)))
If x and y were of different signs, the first floating-point comparison would handle the comparison correctly. If they are not of different signs, the integer comparison instruction will work properly. Unfortunately, the floating-point comparison instruction doesn't have enough bits of precision to compare every set of inputs.
Another way to do it:
int xhi = x >> 16;
int xlo = y >> 16;
if ((xhi < xlo) || ((xhi == xlo) && (x < y)))
again, if x and y were of different signs, the first comparison would handle the comparison correctly. If they are not of different signs, the integer comparison instruction will work properly.
The workaround for the unsigned cases would look the same, but using "unsigned" instead of "int." |
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. |
| CODEGEN-3655 |
Incorrect code generated for multiplication |
Fixed |
|
C2000_18.1.0.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-3619 |
pragma triggers false MISRA-C:2004 19.1/A warning |
Fixed |
|
C2000_18.1.0.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-3595 |
Stack usage under reports stack amount used because it fails to handle function aliases |
Fixed |
C2000_18.1.0.LTS |
C2000_18.1.2.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-2373 |
Internal linker error triggered by function alias |
Fixed |
|
C2000_18.1.0.LTS |
|
Linker sometimes generates "Assertion failed" message and aborts. |
| CODEGEN-1979 |
Statements before declarations with no white space (aggravated by macros) may cause incorrect parser error |
Fixed |
|
C2000_18.1.0.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. |
| SDSCM00051734 |
Accepts invalid CLA instruction "MMOV32 MRx, MSTF" |
Fixed |
|
C2000_18.1.0.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. |
| SDSCM00050540 |
Accepts invalid CLA instruction "MMOV32 mem, MRn, COND" |
Fixed |
|
C2000_18.1.0.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 of size 512MB or larger truncated |
Fixed |
|
C2000_18.1.0.LTS |
N/A |
Due to an internal limitation, the code generation tools cannot presently allocate objects of size 512 MB or larger. When such objects are declared in the code, they were silently truncated and compilation continued without any diagnostics. |
