| ID |
Summary |
State |
Reported In Release |
Target Release |
Workaround |
Release Notes |
| CODEGEN-5943 |
Compiler may lose volatile qualifier in A->B->C when B and C are both volatile |
Fixed |
C6000_8.2.0 |
C6000_8.2.7 |
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-5914 |
Compiler fails with "Assertion failed" when allocating 0x80000000-bit object |
Fixed |
C6000_8.2.0 |
C6000_8.2.7 |
Reduce the size of the very large object to less than 0x80000000 bits. In this particular case, since the object is created by BIOS, it's possible to configure the project to allocate memory using special labels in the memory region instead of allocating an array. See the forum thread.
Or use 8.3.x or later. |
Allocating a very large object, one that exceeds 0x8000000 bits, can cause a compiler crash with an "assertion failed" message.
Of active branches in early 2019, the problem only exists on C6000 8.2.x. All other branches are newer, and contain revised very-large-object handling. The actual assertion failure only happens with 8.2.4 and 8.2.5; it's not completely clear if using 8.2.3 or earlier lets the project function correctly. |
| CODEGEN-5905 |
Linker command file option --define with pathname with many directory components leads to error: "source line too long" |
Fixed |
C6000_8.2.0 |
C6000_8.2.7 |
|
|
| CODEGEN-5777 |
Compiler schedules an M-unit instruction too soon after MPYSP2DP or MPYSPDP |
Fixed |
C6000_8.2.0 |
C6000_8.2.6 |
Avoid mixing single and double-precision when using float multiplication, or use compiler option --legacy |
The compiler may place an M-unit instruction too close after either a MPYSP2DP or MPYSPDP instruction. This corrupts the functioning of one of the M-unit instructions. |
| CODEGEN-5623 |
Makefile dependence generation (--preproc_dependency) should quote spaces in filenames |
Fixed |
C6000_8.2.0 |
C6000_8.2.6 |
Rename the files so that they don't have spaces in the names. |
The parser generates makefile dependencies with the --preproc_dependency option. However, if any filename has a space in its name, the makefile dependencies will not be formatted in a way that can be parsed by make. |
| CODEGEN-5574 |
Loop controlled by unsigned char counter iterates more than 255 times |
Fixed |
C6000_8.2.0 |
C6000_8.2.7 |
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-5569 |
C++ constructor which uses volatile causes compiler to crash |
Fixed |
C6000_8.2.0 |
C6000_8.2.6 |
Compile at -o1 or less, or avoid the volatile accesses. |
It's hard to characterise this problem precisely, but a class with a constructor containing a volatile read and write, and a conversion operator containing a volatile read, when used to create a class object converted to integer, can cause the compiler to crash.
The test case is unusual and cut down quite a bit from the original. |
| CODEGEN-5533 |
Loop with Cortex-R, -mf3, and DWARF debug leads to assembler error "defined differently in each pass" |
Fixed |
C6000_8.2.0 |
C6000_8.2.7 |
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-5527 |
Local structure initialization is incorrectly optimized away |
Fixed |
C6000_8.2.0 |
C6000_8.2.7 |
None better than the one given in the description. |
A program that saves the address of a variable in an initialised local struct, but does not use the variable directly, may lose the part of the struct that saves the address. |
| CODEGEN-5450 |
Compiler mistakenly parallelizes MPYSPDP with single-cycle write of its SP input |
Fixed |
C6000_8.2.0 |
C6000_8.2.6 |
Avoid mixing single and double-precision when using float multiplication, or use compiler option --legacy |
In rare cases, the compiler may place an MPYSPDP instruction in parallel with a single-cycle instruction which writes to a register used by the MPYSPDP as its single-precision input. In this case, the single-cycle instruction will write over the value of the register in E1, even though the MPYSPDP still needs to read the register in E1. This corrupts the output of the MPYSPDP instruction. |
| CODEGEN-5236 |
Register allocation failure |
Fixed |
C6000_8.2.0 |
C6000_8.2.5 |
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-5119 |
Using #pragma RETAIN does not keep a static file level variable |
Fixed |
C6000_8.2.0 |
C6000_8.2.7 |
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-5040 |
--c64p_dma_l1d_workaround is missing from 8.x compilers |
Fixed |
C6000_8.2.4 |
C6000_8.2.5 |
|
|
| CODEGEN-4931 |
Applying __attribute__((used)) to static variable does not work |
Fixed |
C6000_8.2.0 |
C6000_8.2.6 |
|
|
| CODEGEN-4885 |
See MISRA diagnostics when compiling stdio.h |
Fixed |
C6000_8.2.0 |
C6000_8.2.6 |
none |
A program that includes <stdio.h> and checks for MISRA warnings may see some from stdio.h itself, which should not happen. |
| CODEGEN-4869 |
C6000 performance degradations between 8.2.2 and 8.2.3 |
Fixed |
C6000_8.2.3 |
C6000_8.2.4 |
No practical workaround; upgrade to a fixed version |
A bug fix in C6000 compiler versions 8.1.6 and 8.2.3 inadvertently negatively impacted the performance of many software-pipelined loops. |
| CODEGEN-4791 |
Structure field reference directly from function call causes INTERNAL ERROR |
Fixed |
C6000_8.2.0 |
C6000_8.2.4 |
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 |
C6000_8.2.0 |
C6000_8.2.6 |
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 |
C6000_8.2.3 |
C6000_8.2.4 |
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 |
C6000_8.2.0 |
C6000_8.2.4 |
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-4638 |
When shift counts are higher than 32, compiler sometimes optimizes to an incorrect shift count |
Fixed |
C6000_8.2.0 |
C6000_8.2.4 |
Turn off optimization by using optimization level off.
Otherwise, avoid a left-shift by a constant as an operand of the listed operations. However, compiler optimizations could interfere with this. Try keeping the shift count in a global variable instead of as a literal, or computing the shift separately into a variable (a global or volatile local) and doing the |, +, etc, on the variable. |
Left shifts by 32 or more, as an operand of +, -, &, |, or ^, (eg, ((X<<56) | (Y<<48))) may produce incorrect results. |
| CODEGEN-4634 |
Use of stdarg.h va_start macro causes a write to the wrong local variable |
Fixed |
C6000_8.2.0 |
C6000_8.2.5 |
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 |
C6000_8.2.0 |
C6000_8.2.5 |
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 |
C6000_8.2.0 |
C6000_8.2.4 |
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 |
C6000_8.2.0 |
C6000_8.2.5 |
|
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-4525 |
Unreachable code in linear assembly may lead to crash |
Fixed |
C6000_8.2.0 |
C6000_8.2.4 |
Remove the unreachable code before compiling, or compile with -o1, -o0, or -ooff, or use --symdebug:none which happens to avoid the problem. |
The compiler may crash if given a linear assembly file containing some code that has a label but is not reachable. It's theoretically possible to create the same problem with C/C++ code, but we haven't been able to do it and the risk is quite small. |
| CODEGEN-4419 |
Compiler erroneously speculates indexed load from the stack |
Fixed |
C6000_8.2.0 |
C6000_8.2.3 |
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 |
C6000_8.2.0 |
C6000_8.2.3 |
Remove unnecessary const from helper in s__algo.c |
|
| CODEGEN-4182 |
Should ignore option --pending_instantiations when compiling C files |
Fixed |
C6000_8.2.0 |
C6000_8.2.3 |
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 |
C6000_8.2.0 |
C6000_8.2.3 |
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 |
C6000_8.2.0 |
C6000_8.2.3 |
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 |
C6000_8.2.0 |
C6000_8.2.3 |
None |
The compiler crashes while parsing a struct or class with zero-sized members in C++ mode. |
| CODEGEN-3923 |
DWARF CFI information lost due to microoptimizations |
Fixed |
C6000_8.2.0 |
C6000_8.2.4 |
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 |
C6000_8.2.0 |
C6000_8.2.3 |
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-3876 |
Code incorrectly removed from functions calling "naked" attribute functions |
Fixed |
C6000_8.2.0 |
C6000_8.2.3 |
|
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 |
C6000_8.2.0 |
C6000_8.2.3 |
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 |
C6000_8.2.0 |
C6000_8.2.3 |
|
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-3794 |
False warning for MISRA 10.1/10.2 when commutative binary operands swapped |
Fixed |
C6000_8.2.0 |
C6000_8.2.3 |
|
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-3719 |
Software pipelined loop doesn't match on Windows and Linux |
Fixed |
C6000_8.2.0 |
C6000_8.2.3 |
Use --disable:cca |
In some cases, a software-pipelined loop might get a slightly different schedule or recurrence bound on Windows than when compiling on Linux. Due to the complicated nature of software pipelining, this error could compound until the performance of the software-pipelined loop is significantly different. This problem can only happen when using C6000 version 7.4.x or lower, or when using C6000 version 8.x or higher and the --legacy command-line option. |
| CODEGEN-3650 |
Linker crashes when printing module list to map file |
Fixed |
C6000_8.2.0 |
C6000_8.2.2 |
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 |
C6000_8.2.0 |
C6000_8.2.3 |
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 |
C6000_8.2.0 |
C6000_8.2.2 |
Set the timezone to 0 (UTC) until the fix is in place |
|
| CODEGEN-3613 |
Some vector types computations are not carried out |
Fixed |
C6000_8.2.0 |
C6000_8.2.2 |
It's possible that compiling with --opt_level=1 or greater will avoid the problem. It does in our test cases, but there are reports of cases for which that doesn't help.
The problem occurs with "*pv++ = ..." where pv is a pointer to a vector. Using "pv[i] = ..." or "*pv = ...; ++pv;" seem to effectively avoid it. |
|
| CODEGEN-3597 |
ELF header field e_phoff should be 0 when no program header is present |
Fixed |
C6000_8.2.0 |
C6000_8.2.2 |
|
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 |
C6000_8.2.0 |
C6000_8.2.3 |
|
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-3571 |
Temp filename collisions on Windows in linear assembler |
Fixed |
C6000_8.2.0 |
C6000_8.2.2 |
Disable parallel builds of linear assembly source files. |
When compiling multiple linear assembly jobs in parallel, it is possible to get the error message:
Unable to open temp macro library : %TEMP%\tempTI<number> - Aborting
|
| CODEGEN-2373 |
Internal linker error triggered by function alias |
Fixed |
C6000_8.2.0 |
C6000_8.2.3 |
|
Linker sometimes generates "Assertion failed" message and aborts. |
| CODEGEN-2372 |
C2000 hex utility emits spurious warning about creating an extra output file |
Fixed |
C6000_8.2.0 |
C6000_8.2.2 |
Ignore the warning or suppress it with option --diag_suppress=21117. |
The Hex utility sometimes emits spurious warnings about writing data to auto-generated files. |
| CODEGEN-2286 |
palign(8) of .init_array messes up __TI_INITARRAY_Limit address |
Fixed |
C6000_8.2.0 |
C6000_8.2.1 |
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 |
C6000_8.2.0 |
C6000_8.2.2 |
|
|
| CODEGEN-2119 |
Stack usage assistant call graph misses callee relationship for some direct calls |
Fixed |
C6000_8.2.0 |
C6000_8.2.0 |
|
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 |
C6000_8.2.0 |
C6000_8.2.1 |
Use directory names without spaces for output files. |
The hex utility did not correctly handle spaces in output directory and file names. |
| CODEGEN-1979 |
Statements before declarations with no white space (aggravated by macros) may cause incorrect parser error |
Fixed |
C6000_8.2.0 |
C6000_8.2.2 |
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 |
|
C6000_8.2.0 |
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-1967 |
_swap2 documented as intrinsic in compiler manual but is a macro in c6x.h |
Fixed |
|
C6000_8.2.0 |
Include the c6x.h header to use the macro, or you can use the intrinsic it is defined to. |
This is a documentation error. _swap2 is a macro, not an intrinsic. It is defined in c6x.h, which is in the compiler include directory:
#define _swap2(src) _packlh2((src), (src)) |
| CODEGEN-1948 |
_cmplt2 documented as intrinsic in compiler manual but is a macro in c6x.h |
Fixed |
|
C6000_8.2.0 |
Include the c6x.h header to use the macro, or you can use the intrinsic it is defined to. |
This is a documentation error. _cmplt2 is a macro, not an intrinsic. It is defined in c6x.h, which is in the compiler include directory:
#define _cmplt2(src1, src2) _cmpgt2((src2), (src1)) |
| CODEGEN-1658 |
SPLOOP Missed Stall Exception with Debugger |
Fixed |
|
C6000_8.2.0 |
None. |
A hardware bug on C6000 prevents the debugger from working correctly within certain instruction sequences in an SPLOOP. |
| CODEGEN-1656 |
Using --gen_profile_info does not work with -o4 |
Fixed |
C6000_8.2.0 |
C6000_8.2.1 |
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-1639 |
MISRA-C:2004 17.6/R false positive when assigning local struct member to static struct member |
Fixed |
C6000_8.2.0 |
C6000_8.2.1 |
|
|
| SDSCM00051180 |
Special sections .ovly, .binit, and .TI.crctab missing from EABI spec |
Fixed |
|
C6000_8.2.0 |
|
|
| SDSCM00046819 |
Intrinsic to instruction mapping has typos |
Fixed |
|
C6000_8.2.0 |
|
|
| CODEGEN-1517 |
#pragma FUNCTION_OPTIONS meaningless unless at least -o0 is used |
Fixed |
|
C6000_8.2.0 |
|
|
| SDSCM00052878 |
Documentation error: #pragma pack should be lower case |
Fixed |
|
C6000_8.2.0 |
|
|
| CODEGEN-1441 |
Compiler generates software pipelined loop that has multiple assignment code, and is not interrupt safe |
Fixed |
C6000_8.2.0 |
C6000_8.2.0 |
If the specific code sequence causing the issue can be located in the assembly source, then a user may insert a DINT instruction in front of the multi-cycle instruction and a RINT instruction after the last delay slot of the multi-cycle instruction. |
The compiler will mistakenly define and use a register that is defined
by a preceeding multi-cycle instruction while the definition of the value
created by the multi-cycle instruction is still in the process of being
written to that register. If an interrupt occurs between the delay slot
definition of that register and the delay slot use of that register, then
an incorrect value will arrive in the register for the delay slot use of
the register.
For example,
MPYLI .M1X A4,B6,A5:A4
MVK .S1 2380,A3
|| ADD .L1X A3,B8,A5
ADD .L1 A3,A5,A9
LDHU .D1T1 *A9,A5
NOP 1
...
In the above code, if an interrupt occurs in the delay slots of the
MPYLI instruction, between the definition of A5 and the subsequent use
of A5, then the value in A5 used by the second ADD instruction will be
the value that was written to A5 by the MPYLI instruction instead of the
first ADD instruction. |
| CODEGEN-1333 |
Structure assignment causes compiler to fail with INTERNAL ERROR: Decomposition error |
Fixed |
C6000_8.2.0 |
C6000_8.2.0 |
Replace struct assignments involving packed structures with a memcpy() call to copy the contents of the RHS of the struct assign to the LHS. |
|
| SDSCM00052721 |
lnk6x automatic RTS selection does not work when thread-safe version of RTS is needed |
Fixed |
C6000_8.2.0 |
C6000_8.2.0 |
Explicitly specify the thread-safe version of the RTS library that is to be included in the link instead of using libc.a on the link command line or in the linker command file. |
|
| SDSCM00052006 |
ltoa definition conflicts with quasi-standard ltoa |
Fixed |
C6000_8.2.0 |
C6000_8.2.6 |
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. |
| SDSCM00050131 |
Local struct with non-constant initializer treated as static scope variable |
Fixed |
C6000_8.2.0 |
C6000_8.2.6 |
Completely specify every aggregate member in the initializer, or do not provide an initializer at all and instead populate each field with a statement. |
Function local non-static aggregate (array or struct) variables which are initialized to zero, or with an initializer that incompletely specifies all of the aggregate members, will be converted to static scope (global) objects. This is wrong; each time the function is entered, there should be a fresh copy of the variable. |
| SDSCM00043877 |
Emit error message when objects too large for infrastructure (roughly 512MiB, or 256MiWords) are truncated |
Fixed |
C6000_8.2.0 |
C6000_8.2.3 |
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. |
| SDSCM00008465 |
INTERNAL ERROR for user code with void pointer dereference |
Fixed |
|
C6000_8.2.2 |
Don't dereference pointers to type void |
In relaxed mode, it is possible to write an expression that dereferences a void *. This doesn't mean anything, but if the user's code dereferences a volatile void *, the compiler could crash with an internal error. |
