C2000 C/C++ CODE GENERATION TOOLS 16.9.0.LTS September 2016 Defect History ------------------------------------------------------------------------------- Table of Contents ------------------------------------------------------------------------------- 1. Defects fixed in C2000 Code Generation Tools release 16.9.0.LTS 2. Current Known Issues =============================================================================== 1. Defects fixed in C2000 Code Generation Tools release 16.9.0.LTS =============================================================================== The following 2 defects were fixed in C2000 Code Generation Tools release 16.9.0.LTS, released September 2016. ------------------------------------------------------------------------------- FIXED CODEGEN-1285 ------------------------------------------------------------------------------- Summary : Remove -olength option from hex utility's help summary and Users Guides Fixed in : 16.9.0.LTS Affected Component : Hex Converter (hex) Release Notes: The help summary and Assembly Language Tools Users Guides mention the -olength option for the hex utility. However this option is not functional. The Users Guide lists this option in the summary but there is no detail on it. This option has been deprecated. ------------------------------------------------------------------------------- FIXED CODEGEN-1333 ------------------------------------------------------------------------------- Summary : Structure assignment causes compiler to fail with INTERNAL ERROR: Decomposition error. Fixed in : 16.9.0.LTS Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Structure assignment causes compiler to fail with INTERNAL ERROR: Decomposition error. Workaround: Replace struct assignments involving packed structures with a memcpy() call to copy the contents of the RHS of the struct assign to the LHS. =============================================================================== 2. Current Known Issues =============================================================================== The following 28 known issues exist for C2000 Code Generation Tools release 16.9.0.LTS as of September 2016. ------------------------------------------------------------------------------- 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 SDSCM00008630 ------------------------------------------------------------------------------- Summary : printf gives wrong value for pointer when its value is incremented Affected Component : C/C++ Compiler (cl) Description: The following code does not execute correctly. On Compiling the code (v 3.83) the following warning occurs 'warning: pointer points outside of underlying object'. Code is: int global_var = 5; int main() { long int t; printf('0x%lx\n', 0x10000 + ((long int)&global_var)); } Workaround: 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. ------------------------------------------------------------------------------- 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 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 SDSCM00046113 ------------------------------------------------------------------------------- Summary : C2000 RTS float arithmetic functions do not round correctly Affected Component : Runtime Support Libraries (RTS) Description: The expression 1+DBL_EPSILON/2 should be rounded DOWN to 1.0 for only mode the TI compiler supports: "round to even" ------------------------------------------------------------------------------- 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 SDSCM00049278 ------------------------------------------------------------------------------- Summary : Array that is correctly initialized erroneously gets a MISRA diagnostic about size not being specified Affected Component : Parser 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 SDSCM00049280 ------------------------------------------------------------------------------- Summary : Ill advised enum scalar usage gets MISRA diagnostic, but similar usage of enum array does not Affected Component : Parser Description: The test case given assigned a integer to an enum scalar variable. MISRA checking correctly flags this with a diagnostic. The test case goes on to do the same thing with an enum array expression. It should get the same MISRA diagnostic, but does not. ------------------------------------------------------------------------------- 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 SDSCM00051384 ------------------------------------------------------------------------------- Summary : C2000 can't print 0 with %a format Affected Component : Runtime Support Libraries (RTS) Description: When you try to print the value 0.0 with the newly-supported C99 format %a, you'll get an infinite loop. This is because the hand-coded assembly routine which tries to perform 0.0-0.0 returns -0.0, and then doesn't understand that 0.0==-0.0 ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051392 ------------------------------------------------------------------------------- Summary : C2000 float software multiply doesn't handle -1*INF properly Affected Component : Runtime Support Libraries (RTS) Description: Float emulation for multiplication does not correctly compute (-1*INFINITY) ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051510 ------------------------------------------------------------------------------- Summary : macro CLOCKS_PER_SEC should be type clock_t Affected Component : Runtime Support Libraries (RTS) Description: The C99 standard requires that CLOCKS_PER_SEC must be type clock_t ------------------------------------------------------------------------------- KNOWN ISSUE CODEGEN-1329 ------------------------------------------------------------------------------- Summary : Lower diagnostic about redefined opcode to a warning, when a compiler intrinsic is redefined Affected Component : Assembler, C/C++ Compiler (cl) Description: Here is an easy way to see the problem ... % cat try1.asm .cdecls LIST % { #define eallow __eallow() %} nop % cl2000 -al try1.asm "/tmp/23315avwWvi", ERROR! at line 39: [E0004] Cannot redefine existing opcode 'eallow' with .define .define "__eallow()",eallow 1 Assembly Error, No Assembly Warnings Errors in Source - Assembler Aborted >> Compilation failure This is not how it typically appears. In practice, that #define is in a header file in the controlSUITE package. This header file is included in assembly code via .cdecls. Earlier versions of the compiler did not support the __eallow() intrinsic. When those compiler versions are used, this #define is written ... #define eallow __asm(" EALLOW") This form of preprocessor macro is more complicated, so the .cdecls handling ignores it, and no diagnostic is seen. (Though if you use the LIST option on .cdecls, you can see a diagnostic in the .lst file.) So, this is why this macro poses no problems with earlier versions of the compiler. ------------------------------------------------------------------------------- KNOWN ISSUE CODEGEN-1510 ------------------------------------------------------------------------------- Summary : Assembler incorrectly issues warning on large constant used with MOVI32 instruction Affected Component : Assembler Description: % type try1.asm .text MOVI32 R4H, 0x39800801 % cl2000 --float_support=fpu32 -al try1.asm "try1.asm", WARNING! at line 2: [W0001] Value out of range MOVI32 R4H, 0x39800801 No Assembly Errors, 1 Assembly Warning