Closed Defects in Release

ID Summary State Reported In Release Target Release Workaround Release Notes
CODEGEN-5236 Register allocation failure Fixed C6000_8.3.0 C6000_8.3.1 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-5040 --c64p_dma_l1d_workaround is missing from 8.x compilers Fixed C6000_8.3.1
CODEGEN-5033 Functions in <string> incorrectly return NULL Fixed C6000_8.3.0 C6000_8.3.1 Ignore or suppress the warning. char_traits<char>::find() and char_traits<wchar_t>::find() return char* and wchar_t*, respectively. In our __string file (included by <string>), they are written to return NULL, which is (void*)0 and not the same type as the declaration, thus producing a warning. We have updated the file to make them return 0, which fixes the warnings.
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-4634 Use of stdarg.h va_start macro causes a write to the wrong local variable Fixed C6000_8.3.0 C6000_8.3.1 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-4621 Remove COFF global linker symbols from documentation for ELF-only targets Fixed C6000_8.3.0
CODEGEN-4600 Warning when using pragma RETAIN with attribute((noinit)) Fixed C6000_8.3.0 C6000_8.3.1 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-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 Fixed 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

Generated on Thu Sep 27 11:19:49 2018