C2000 C/C++ CODE GENERATION TOOLS 6.4.9 November 2015 Defect History ------------------------------------------------------------------------------- Table of Contents ------------------------------------------------------------------------------- 1. Defects fixed in C2000 Code Generation Tools release 6.4.9 2. Current Known Issues =============================================================================== 1. Defects fixed in C2000 Code Generation Tools release 6.4.9 =============================================================================== The following 3 defects were fixed in C2000 Code Generation Tools release 6.4.9, released November 2015. ------------------------------------------------------------------------------- FIXED SDSCM00052393 ------------------------------------------------------------------------------- Summary : Legal use of __byte intrinsic with --opt_level=2 leads to error message: Illegal use of intrinsic: __byte Fixed in : 6.4.9 Severity : S2 - Major Affected Component : Optimizer Release Notes: Certain uses of __byte in non-trivial expressions will cause the compilation to fail with an error message like "error: "try1.c", line 2041: Illegal use of intrinsic: __byte". Workaround: Compile with -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00052397 ------------------------------------------------------------------------------- Summary : Optimizer crashes on unreachable integer divide-by-zero Fixed in : 6.4.9 Severity : S2 - Major Affected Component : Optimizer Release Notes: The optimizer crashes on an unreachable integer divide-by-zero. INTERNAL ERROR: c:\drives\i\C2000\V64~1.6\compiler\cgtools\bin\opt2000.exe experienced a segmentation fault Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00052414 ------------------------------------------------------------------------------- Summary : C2000 compiler 6.4.7 components are incorrectly labeled as 6.4.8. Fixed in : 6.4.9 Severity : S3 - Minor Affected Component : Shell Release Notes: All the versions of the C2000 compiler release 6.4.7 are labeled as 6.4.8. C:\CCSv6_1_1\ccsv6\tools\compiler\ti-cgt-c2000_6.4.7\bin>cl2000.exe -version TMS320C2000 C/C++ Compiler v6.4.8 Build Number 1PKKL-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 C/C++ Parser v6.4.8 Build Number 1PKKL-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 C/C++ File Merge v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 C/C++ Optimizer v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 C/C++ Codegen v6.4.8 Build Number 1PKKM-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Assembler v6.4.8 Build Number 1PKKL-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Embed Utility v6.4.8 Build Number 1PKKM-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 C Source Interlister v6.4.8 Build Number 1PKKM-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Linker v6.4.8 Build Number 1PKKM-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Absolute Lister v6.4.8 Build Number 1PKKL-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Strip Utility v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 XREF Utility v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 C++ Demangler v6.4.8 Build Number 1PKKM-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Hex Converter v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Library Builder v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Name Utility v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Object File Display v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Archiver v6.4.8 Build Number 1PKKL-I3E%IMB0-RTARQ-RAQ-C08D Workaround: N/A. =============================================================================== 2. Current Known Issues =============================================================================== The following 30 known issues exist for C2000 Code Generation Tools release 6.4.9 as of November 2015. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008248 ------------------------------------------------------------------------------- Summary : Compilers on PC will not work without TMP set Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00034609 Description: When compiling on the PC, the code generator cannot find the icode file produced by the parser if the environment variable TMP is no set. If TMP is set, then all appears well. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008465 ------------------------------------------------------------------------------- Summary : Language Conformance: crash because of void pointer dereference Affected Component : Parser Description: Compiler generates multiple INTERNAL ERRORs when code like the following is compiled: void dr106_1(void *pv, int i) { *pv; i ? *pv : *pv; *pv, *pv; } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008534 ------------------------------------------------------------------------------- Summary : Linker -xml_link_info option doesn't work when in a command file Affected Component : Linker Description: The option --xml_link_info=file.xml does not work when it is placed inside a linker command file. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008537 ------------------------------------------------------------------------------- Summary : assembler expression ~(0x80000000) evaulates as 0x80000000 Affected Component : Assembler Description: The following expression is evaluating incorrectly in the assembler: .eval ~(0x80000000), mask mask ends up getting assigned 0x80000000, whereas I expect it to be 0x7FFFFFFF. It seems that any constant with bit 31 set will incorrectly return 0x80000000 ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008543 ------------------------------------------------------------------------------- Summary : Forward reference in .space generates an internal error Affected Component : Assembler Description: If you attempt to assemble: .space 0+a b a .set 1 the assembler will generate an internal error. This happens with v3.83 and v4.1.0B1 on Solaris. If you change the code to: .space a b b .set 1 the correct error message is generated, 'Absolute, well-defined integer value expected'. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008652 ------------------------------------------------------------------------------- Summary : pow(2,x) has fairly significant rounding error Affected Component : Runtime Support Libraries (RTS) Description: The algorithm used for pow [exp(log(x),y)] is correct but sometimes leads to a precision error for some inputs, due to rounding bugs in floating- point handling. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008685 ------------------------------------------------------------------------------- Summary : DWARF does not correctly represent variables stored in register pairs Affected Component : Code Generator Description: In the attached example, variables 'var1' and 'var2' are both long long types, and are stored in A7:A6 and B5:B4. However, the DWARF information shows var1 only to be in A6, and var2 only to be in B4: [000000e8] DW_TAG_variable DW_AT_name var1 DW_AT_symbol_name _var1 DW_AT_type [00000113] DW_AT_location { DW_OP_reg6 } [000000fa] DW_TAG_variable DW_AT_name var2 DW_AT_symbol_name _var2 DW_AT_type [00000113] DW_AT_location { DW_OP_reg20 } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008928 ------------------------------------------------------------------------------- Summary : Extern inline functions are not supported in the C/C++ Compiler Affected Component : Parser Duplicate Defects : SDSCM00018364 Description: Users cannot create global accessible code with INLINE functions. The V3.00 compiler/code generator does not create globally accessible code for functions which are declared inline. A simple example is: inline int x() { return 1; } int y() {return 2;} When compiled with 'cl6x -k -c test.c', a warning is produced: 'test.c', line 1: warning: function 'x' was declared but never referenced and the resulting assembler file (test.asm) does not contain any code for x(). The documentation states that code declared inline will be inlined in that module but global code will also be generated (section 2.10.3.2 in v3.00 C Compiler manual). The new compiler is overly aggressive in its optimizations. If y() is modified to call x() then code is generated for x() unless the optimizer is also invoked (by using -x2). ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00014430 ------------------------------------------------------------------------------- Summary : calloc doesn't check arguments to make sure the requested size is reasonable Affected Component : Runtime Support Libraries (RTS) Description: The function calloc() is required to return a pointer to memory representing "nelem" copies of "size" bytes, or NULL if the request cannot be satisfied. However, for some values of "nelem" and "size" (specifically when the result of nelem*size wraps around), calloc can return a pointer to an object that is not large enough, rather than NULL. For example, on a 32-bit target, if the user calls calloc(0x00010001, 0x00010001), even though each argument by itself is reasonable, the request cannot be satisfied because the product is 0x000100020001, which exceeds size_t. (Note that we cannot check for overflow by checking if the product is less than either argument, which is commonly done for unsigned addition.) Arguably, we can try to claim that it is undefined behavior to make a call to calloc where the product would exceed size_t, but there doesn't seem to be anything in the standard which says so. The problem is worse on 16-bit targets, where calloc(0x0101, 0x0101) is enough to overflow size_t. It may not be obvious to the user that this overflows. Another concern is that it is hard to figure out whether a multiplication will overflow without having a double-width multiply available. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00016638 ------------------------------------------------------------------------------- Summary : dis2000 does not handle disassembly of expanded BCND instruction properly Affected Component : Disassembler (dis) Description: When C2XLP-specific instruction BCND is specified with multiple condition operands, the disassembly output does not show the expanded instruction sequence properly. Source code is attached, assemble with "asm2000 -v28 -m20 bcnd.asm", then disassemble with "dis2000 bcnd.obj > bcnd.dis". Observe disassembly of sequence of instructions that BCND expands to and you'll notice that the disassembly of the XB instruction encoding is not handled properly. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00016646 ------------------------------------------------------------------------------- Summary : strcmp doesn't correctly handle values with uppermost bit set Affected Component : Runtime Support Libraries (RTS) Description: The standard says: "The sign of a nonzero value returned by the comparison functions memcmp, strcmp, and strncmp is determined by the sign of the difference between the values of the first pair of characters (both interpreted as unsigned char) that differ in the objects being compared." However, this is a problem for 16-bit targets where the size of char is the same as the size of int. In this case, it's easy to mistakenly use an unsigned subtract to do the comparison and return it directly; this value can overflow. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00018691 ------------------------------------------------------------------------------- Summary : Linker gives misleading warning when dot expressions used in SECTION directive for .stack section Affected Component : Linker Description: Linker gives the warning: warning: creating ".stack" section with default size of 0x800; use the -stack option to change the default size even when the application does not link in boot code from RTS lib. A linker command file is used that contains a specialized SECTION directive for the ".stack" section. Because of a series of ". += " assignments in the section spec, the linker is forced to increase the size of the .stack section to 0xc00. The linker is doing the correct thing by making a .stack section large enough to accommodate the dot expressions, but the diagnostic is misleading, as 0x800 isn't the final size of the .stack section. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00037411 ------------------------------------------------------------------------------- Summary : C2000 assembler segmentation fault on RPTB with syntax error Affected Component : Assembler Description: The C2000 assembler will issue a segmentation fault if given a RPTB instruction with faulty syntax. The syntax error is not issued. The attached file rptb_mov32_FAIL.asm illustrates the problem. cl2000 --float_support=fpu32 -v28 rptb_mov32_FAIL.asm INTERNAL ERROR: asm2000 experienced a segmentation fault while processing section .text file rptb_mov32_FAIL.asm line 23 This is a serious problem. Please contact Customer Support with this message and a copy of the input file and help us to continue to make the tools more robust. >> Compilation failure We should see a syntax error on the RPTB instruction on line 21 of the input file. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00037836 ------------------------------------------------------------------------------- Summary : boot-time copy table (BINIT) not implemented in C2000 RTS Affected Component : Runtime Support Libraries (RTS) Description: The BINIT feature to trigger a copy-in at boot time is not implemented in the RTS library. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00039054 ------------------------------------------------------------------------------- Summary : Compiler reports a violation of Misra rule 12.8 for a structure variable Affected Component : C/C++ Compiler (cl) Description: MISRA warning (MISRA-C:2004 12.8/R) The right-hand operand of a shift operator shall lie between zero and one less than the width in bits of the underlying type of the left-hand operand In the following code I get MISRA 12.8 warning on myVar = myStruct.aVar >> 16 shift. Note that shift of unstructured variable myVar = myVar >> 16 is okay. typedef struct { unsigned long aVar; } myStruct_T; myStruct_T myStruct = {0xFFFFFFFFUL}; unsigned long myVar; myVar = myStruct.aVar >> 16; myVar = myVar >> 16; ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00039236 ------------------------------------------------------------------------------- Summary : Sometimes MISRA rule 19.15 is incorrectly emitted. The rule is about failing to use an inclusion guard in a header file. Affected Component : Parser Description: In the attached test case rule 19.15 gets emitted even though the files mentioned do have proper inclusion guards. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00040934 ------------------------------------------------------------------------------- Summary : Structure is not initialized correctly when using -o2 or -o3 optimization Affected Component : Optimizer Description: There is a problem with the initialization of a structure using symbols generated in the linker command file. We use symbols generated in the linker cmd file using the dot operator. These symbols are used as an initial value for a class/struct with a constructor. In our case we want the difference of two addresses that the linker generates. When using optimization -o2 or -o3, the compiler generates .cinit entries instead of the constructor call. In those .init-entries it doesn't use the difference of the addresses; instead it uses the first symbol. When turning off optimization or using lower level of opt than -o2, the constructor calls are generated and the struct is initialized correctly. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00042434 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 6.4 for bitfield definitions Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00043122 Description: Compiler misreports Misra warning 6.4 for bitfield definitions. typedef unsigned int uint16_t; typedef unsigned int bool_t; #define FALSE ((bool_t)0U) #define TRUE ((bool_t)1U) typedef struct mystructtag { uint16_t u16_hw_rev1; bool_t bl_hardware_supported:1; /* this violates rule 6.4 */ } st_software_info_t ; This generates the warning: "misra_test.c", line 9: warning: (MISRA-C:2004 6.4/R) Bit fields shall only be defined to be of type unsigned int or signed int Related forum thread: http://e2e.ti.com/support/development_tools/compiler/f/343/t/147639.aspx According to Misra, this is not a Misra violation. http://www.misra- c.com/forum/viewtopic.php?f=62&t=1167&sid=6fd53ec7591d33a4fa1b38e975c580bc ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00042435 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 10.1 Affected Component : C/C++ Compiler (cl) Description: Compiler misreports Misra warning 10.1 with the following code: typedef unsigned int uint16_t; typedef unsigned int bool_t; #define FALSE ((bool_t)0U) #define TRUE ((bool_t)1U) typedef struct mystructtag { uint16_t u16_hw_rev1; bool_t bl_hardware_supported:1; /* this violates rule 6.4 */ } st_software_info_t ; void main(void) { uint16_t u16_rev1_min, u16_tmp; st_software_info_t sts_sw_info; u16_rev1_min = 900U; sts_sw_info.bl_hardware_supported = FALSE; if (sts_sw_info.bl_hardware_supported == FALSE) /* this violates rule 10.1 */ { /* do something... */ } if (sts_sw_info.u16_hw_rev1 >= u16_rev1_min) /* this violates rule 10.1 */ { /* do something... */ } u16_tmp = sts_sw_info.u16_hw_rev1; if (u16_tmp >= u16_rev1_min) /* this does not violates rule 10.1 */ { /* do something... */ } The warning is: "misra_test.c", line 22: warning: (MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if it is not a conversion to a wider integer type of the same signedness "misra_test.c", line 27: warning: (MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if it is not a conversion to a wider integer type of the same signedness Related forum thread:http://e2e.ti.com/support/development_tools/compiler/f/3- 43/t/147639.aspx Related Misra threads that say this is not a Misra violation: http://www.misra- c.com/forum/viewtopic.php?f=62&t=1167&sid=6fd53ec7591d33a4fa1b38e975c580bc http://www.misra- c.com/forum/viewtopic.php?f=66&t=1168&sid=6fd53ec7591d33a4fa1b38e975c580bc ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00043043 ------------------------------------------------------------------------------- Summary : Array that is correctly initialized erroneously gets a MISRA diagnostic about size not being specified Affected Component : C/C++ Compiler (cl) Description: For this input ... int16_t y[]={1,5,8}; The compiler incorrectly issues this diagnostic ... "try1.c", line 2: warning: (MISRA-C:2004 8.12/R) When an array is declared with external linkage, its size shall be stated explicitly or defined implicitly by initialisation ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00044056 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 10.1 Affected Component : C/C++ Compiler (cl) Description: Compiler misreports MISRA warning 10.1/R for the following code. typedef enum _MyEnum { One, Two } MyEnum; MyEnum MyVariable; int foo(void) { int result = 1; if (One == MyVariable) // fails here with MISRA-C:2004 10.1/R { result = 2; } return result; } Our coding style convention requires that the variable is at the right hand side. Therefore I don't want to swap One and MyVariable, although that makes the warning to disappear. Is that a bug in the MISRA checker? If not, why is the comparison of two terms not commutable? ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00045452 ------------------------------------------------------------------------------- Summary : Compiler misreports MISRA warning 17.6 Affected Component : C/C++ Compiler (cl) Description: Compiler misreports MISRA warning 17.6 with the attached code. (MISRA-C:2004 17.6/R) The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist In the following code, the assignment of &myLocalStruct->data to myDataPtr in myFunc has MISRA 17.6 reported. myDataPtr only persists for the duration of the function, and therefore does not persist longer than data passed into that function. typedef struct { uint8 data; } Struct_T; void myFunc(Struct_T *myLocalStruct); void main(void); void myFunc(Struct_T *myLocalStruct) { uint8 *myDataPtr; myDataPtr = &myLocalStruct->data; /* (MISRA-C:2004 17.6/R) reported here */ } void main(void) { Struct_T myStruct = { 0U }; myFunc(&myStruct); } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00045473 ------------------------------------------------------------------------------- Summary : Compiler misreports violation of Misra 9.2 for zero initialization of structures Affected Component : C/C++ Compiler (cl) Description: Compiler misreports violation of Misra 9.2 for zero initialization of structures. (MISRA-C:2004 9.2/R) Braces shall be used to indicate and match the structure in the non-zero initialisation of arrays and structures typedef struct { unsigned char nModuleId; unsigned char nInstanceId; unsigned char nApiId; unsigned char nErrorId; } DetLog_T; DetLog_T sctDetLog_M[0x100] = { 0U }; ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00048321 ------------------------------------------------------------------------------- Summary : C2000 binary file IO does not handle char data with more than 8-bits of data Affected Component : Runtime Support Libraries (RTS) Description: On C2000 a char is 16 bits, but the fread and fwrite functions will only read and write the lower 8 bits of every char. The problem looks to be in the __TI_writemsg/__TI_readmsg functions and the PACKCHAR macro. The macro only writes the lower 8 bits, but the function increments by 16 bits for every invocation of PACKCHAR. I'm not sure which piece is wrong. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049284 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 10.1 Affected Component : Parser Description: Compiler misreports MISRA warning 10.1/R for the following code. typedef enum _MyEnum { One, Two } MyEnum; MyEnum MyVariable; int foo(void) { int result = 1; if (One == MyVariable) // fails here with MISRA-C:2004 10.1/R { result = 2; } return result; } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050131 ------------------------------------------------------------------------------- Summary : Local struct with non-constant initializer treated as static scope variable Affected Component : Parser Description: We've discovered a problem where the C++ compiler places a local structure variable not on the stack but in the data segment, as if it was a static structure. The problem is especially insidious because the issue will only have an impact on re-entrance. The problem seems to occur only for C++ files, and only if the structure initializer list contains a variable. Constant initializer lists do not trigger the issue. The structure in the first function will be allocated on the stack, but the structure in the second will be compiled as if it was declared static. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050540 ------------------------------------------------------------------------------- Summary : CLA Assembler accepts invalid instruction MMOV32 mem, MRn, COND Affected Component : Assembler Description: The CLA assembler accepts and invalid instruction and encodes a different instruction, generating an object file. See the attached assembly and disassembly output. There is no conditional MMOV32 to a memory destination. The only valid conditional MMOV32 instructions have register (MRn) destinations. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051315 ------------------------------------------------------------------------------- Summary : The type _Bool is illegal by default only for CLA code Affected Component : C/C++ Compiler (cl) Description: Any use of the built-in type _Bool is not allowed in CLA code. But it is allowed in C code. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00052021 ------------------------------------------------------------------------------- Summary : Compiler incorrectly issues MISRA warnings 10.1 and 10.3 in some circumstances Affected Component : C/C++ Compiler (cl) Description: For this code ... typedef unsigned int ui; ui x; ui *px; void fxn(void); void fxn(void) { px = &x; /* 10.1 warning */ px = (ui *)&x; /* 10.3 warning */ } The compiler issues MISRA warnings 10.1 and 10.3. This appears to be an error in the compiler. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00052276 ------------------------------------------------------------------------------- Summary : hex2000, while using -b option, mistakenly states a section "falls in unconfigured memory" Affected Component : Hex Converter (hex) Description: Through the utility tiobj2bin.bat, the customer invokes the hex utility in this manner ... % hex2000 -q -b -image -o output.bin hhh.txt file.out Where hhh.txt contains ... ROMS { all_mem: o = 0x7c0000, l = 0x2fff0 } Because -b is used, -memwidth=8 is implied. With that option, all addresses (which count in terms of 16-bit words) must be doubled. The first initialized section preset is at address 0x3e0000. Double that to get 0x7c0000. Even so, when hex2000 runs, it issues the following ... warning: section file.out(preset) at 07c0000h falls in unconfigured memory (skipped)