| CODEGEN-4668 |
Macro with temp label causes assembler to crash |
Fixed |
C6000_8.3.0 |
C6000_8.3.0 |
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-4621 |
Remove COFF global linker symbols from documentation for ELF-only targets |
Planned |
|
C6000_8.3.0 |
|
|
| CODEGEN-4548 |
Compiler manual incorrectly spells option --disable_software_pipelining. It is spelled --disable_software_pipeline. |
Fixed |
|
C6000_8.3.0 |
|
|
| CODEGEN-4525 |
Unreachable code in linear assembly may lead to crash |
Fixed |
C6000_8.3.0 |
C6000_8.3.0 |
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-4113 |
Assembler computes wrong result for expression 0x232800 % 0x10000 |
Fixed |
C6000_8.3.0 |
C6000_8.3.0 |
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.3.0 |
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.3.0 |
C6000_8.3.0 |
None |
The compiler crashes while parsing a struct or class with zero-sized members in C++ mode. |
| CODEGEN-3918 |
Writing multiple input sections in one line unexpectedly changes how input sections are combined into output sections |
Fixed |
C6000_8.3.0 |
C6000_8.3.0 |
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-3797 |
Documentation should state that users must use far keyword when declaring C/C++ data symbols defined by the linker |
Planned |
|
C6000_8.3.0 |
|
|
| CODEGEN-3613 |
Some vector types computations are not carried out |
Fixed |
C6000_8.3.0 |
C6000_8.3.0 |
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-2346 |
Compiler produces incorrect code at -o2 optimization |
Fixed |
C6000_8.3.0 |
C6000_8.3.0 |
None known. |
Compiler may produce incorrect code at -o2 or greater optimization when given irregular loops. |
| CODEGEN-2286 |
palign(8) of .init_array messes up __TI_INITARRAY_Limit address |
Fixed |
C6000_8.3.0 |
C6000_8.3.0 |
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-2113 |
Hex utility mishandles space in directory name of output file |
Fixed |
C6000_8.3.0 |
C6000_8.3.0 |
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.3.0 |
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. |
| SDSCM00037671 |
XML output needs encoding specification |
Fixed |
|
C6000_8.3.0 |
|
|
