ID Summary State Reported In Release Target Release Workaround Release Notes
CODEGEN-6276 Using --opt_level=4 causes compiler to fail with INTERNAL ERROR: no match for UMULT Planned C2000_19.6.0.STS
CODEGEN-6070 Erroneous "redeclared with incompatible type" involving two tagless structs with same form Planned C2000_19.6.0.STS For this specific case, which involved the BLE stack: Edit file blestack/inc/att.h Find the typedef for attReadByTypeReq_t. Give the struct a tag (name). Any name will do as long as it is unique. Do the same for attReadByGrpTypeReq_t. Recompile all C files. -or- make sure all files are compiled as C or all files are compiled as C++. User-defined types defined in separate translation units are technically different types in C, but the C compiler merges them when it can determine that they are the same type, such as when there is a declaration in each translation unit for a symbol with external linkage. This bug was caused by type merging being a bit too aggressive in merging two structs that had exactly the same form, with identical members, but distinct struct tags. Type merging mistakenly thought it could merge these because it saw a function prototype that involved not exactly the same type, but a compatible type without a tag, and this function was later defined using both fully-defined types, this time with the struct tags. This particular bug cannot happen as long as you always use a tag (name) when declaring a struct or union. This is the name that appears after the keyword "struct" or "union" but before the opening curly brace.
CODEGEN-5231 Object file display (OFD) utility displays wrong offset for DW_AT_type entries Accepted C2000_19.6.0.STS
CODEGEN-4960 Using --gen_profile_info with code with CLA source fails to build Accepted C2000_19.6.0.STS N/A. As the title says, when using the --gen_profile_info option with a project that contains CLA code, it fails with an invalid filename as shown in the error message below: >> Compilation failure subdir_rules.mk:58: recipe for target 'matrix_mpy.obj' failed fatal error: Error opening icode file "C:\\Users\\user\\AppData\\Local Temp {B38860D0-28F1-4B19-9A99-2F0EA95 A0EA8} ": >> Abort - Cannot open input icode file C:\\Users\\user\\AppData\\Local\\Temp\\\\ {B38860D0-28F1-4B19-9A99-2F0EA95A0EA8} p: No such file or directory This does not happen with F28x projects that are free of CLA code. This was reproduced in CCSv8.1.0 with the default C2000 compiler version 18.1.2
CODEGEN-4895 For enum type variables incorrectly issue diagnostic: comparison between signed and unsigned operands Accepted C2000_19.6.0.STS The user can work around this by introducing a dummy enumeration constant with a negative value, as below. This causes the enum to have signed underlying type, which will get rid of the warning: enum E { zero = 0, one = 1, dummy = -1 }; Given this code: enum E { zero = 0, one = 1 }; int f(__typeof__(one) a, enum E b) { return a > b; } You will get this remark: remark: comparison between signed and unsigned operands This is technically not a bug. When you declare an enum, the underlying type might be signed or unsigned, but the standard explicitly says that "An identifier declared as an enumeration constant has type int" (C99 6.4.4.3). Thus, __typeof__(one) is "int", despite the fact that E has an unsigned underlying type.
CODEGEN-4712 No MISRA 10.1 and 10.6 diagnostics issued on initializations Planned C2000_19.6.0.STS
CODEGEN-4617 Compiler incorrectly issues MISRA 12.6 diagnostic: Expressions that are effectively Boolean should not be used Accepted C2000_19.6.0.STS
CODEGEN-4342 cerr.tie() returns the wrong value Open C2000_19.6.0.STS
SDSCM00051392 C2000 float software multiply doesn't handle -1*INF properly Accepted C2000_19.6.0.STS
SDSCM00051384 C2000 can't print 0 with %a format Accepted C2000_19.6.0.STS
SDSCM00049280 Ill advised enum scalar usage gets MISRA diagnostic, but similar usage of enum array does not Open C2000_19.6.0.STS
SDSCM00049278 Array that is correctly initialized erroneously gets a MISRA diagnostic about size not being specified Open C2000_19.6.0.STS
SDSCM00046113 C2000 RTS float arithmetic functions do not round correctly Open C2000_19.6.0.STS
SDSCM00040934 Structure is not initialized correctly when using -o2 or -o3 optimization Accepted C2000_19.6.0.STS The initialization will have to be done at run-time, through a __sti initialization routine. You can see this routine when compiling without optimization. To workaround the compiler removing this initialization routine, initialize the object at the beginning of main: Info2.mSize = ((unsigned)_end_isr_stack - (unsigned)_start_isr_stack);
SDSCM00018691 Linker gives misleading warning when dot expressions used in SECTION directive for .stack section Accepted C2000_19.6.0.STS
SDSCM00016646 strcmp doesn't correctly handle values with uppermost bit set Accepted C2000_19.6.0.STS
SDSCM00008928 Extern inline functions are not supported in the C/C++ Compiler with COFF ABI Accepted C2000_19.6.0.STS This bug only affects COFF ABI. If a function is declared as inline and there are no references to it in the same file, the function is eliminated and can't be called from another file.
SDSCM00008685 DWARF does not correctly represent variables stored in register pairs Planned C2000_19.6.0.STS Although 'var1' and 'var2' are shown to be in single registers, a debugger could determine that they are actually stored in register pairs by looking at the type of the variables: [00000113] DW_TAG_base_type DW_AT_name long long DW_AT_encoding 0x5 DW_AT_byte_size 0x8 The base type indicates that the size of the variables is 0x8 bytes. Since a single register can only store 0x4 bytes of information, it would take two registers to hold this values. On TI architectures, values stored in multiple registers are always stored in consecutive registers. Thus, the debugger would know that if the entire value could not fit in A4, the rest of the value must be in A5. A5 would contain the upper 32 bits of the value.
SDSCM00008652 pow(2,x) has fairly significant rounding error Accepted C2000_19.6.0.STS Please describe the workaround for this problem.
SDSCM00008630 printf gives wrong value for pointer when its value is incremented Open C2000_19.6.0.STS To get rid of the warning message modify the printf statement as follows: printf('0x%lx\n', 0x10000 + (t=(long int)&global_var)); This modified code executes correctly too.
SDSCM00008543 Forward reference in .space generates an internal error Accepted C2000_19.6.0.STS none
SDSCM00008248 Compilers on PC will not work without TMP set Accepted C2000_19.6.0.STS Set the TMP environment variable, even if just set to . (current directory)

Generated on Wed Jun 19 22:58:49 2019