C2000 C/C++ CODE GENERATION TOOLS 15.9.0 October 2015 Defect History ------------------------------------------------------------------------------- Table of Contents ------------------------------------------------------------------------------- 1. Defects fixed in C2000 Code Generation Tools release 15.9.0 2. Current Known Issues =============================================================================== 1. Defects fixed in C2000 Code Generation Tools release 15.9.0 =============================================================================== The following 21 defects were fixed in C2000 Code Generation Tools release 15.9.0, released October 2015. ------------------------------------------------------------------------------- FIXED SDSCM00038327 ------------------------------------------------------------------------------- Summary : ARM RTS libraries expose enumerations across ABI boundaries, but are marked as having no visible enumerations Fixed in : 15.9.0 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: The compiler uses different strategies to pick the size of an enumerated type, controlled by the --enum_type option. The allowed strategies are int or packed in EABI. When linking, object files that access enumerations in other object files must match in their enumeration type strategy. If they do not match, the behavior is undefined and your program may compute incorrect results or crash. However, if an object file does not define or access any enumerated types, it may be linked with object files using either strategy. The compiler records this fact in the object file by setting a build attribute indicating it has no "visible" enumerations. The RTS library routines are marked as having no visible enumerations. This is true for the C routines in the library, but some C++ header files expose enumerations that are used in inline functions. This violates the previous assumption. An example of such a C++ header file is You can only be affected by this defect if you attempt to mix object files with different enum_type strategies and use certain C++ features, such as . This fix will cause a C++ ABI incompatibility for the C6000 8.0 series of compilers through version 8.0.1. Any C6000 C++ project upgrading from 8..0 or 8.0.1 will need to be cleaned and recompiled to avoid any unexpected behavior. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.11, 6.4.0B1 - 6.4.2 Workaround: When using C++ RTS functions, use --enum_type=packed, or rebuild the RTS library with the --enum_type=int option. ------------------------------------------------------------------------------- FIXED SDSCM00044254 ------------------------------------------------------------------------------- Summary : c2000 hextool maximum block size limitation Fixed in : 15.9.0 Severity : S2 - Major Affected Component : Hex Converter (hex) Release Notes: On some devices, Hextool may cause the bootloader to hang due to the creation of a maximum length boot block (0xFFFF). The maximum length will be lowered to 0xFFFE. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.9 - 6.2.10, 6.4.0B1 - 6.4.2 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00050103 ------------------------------------------------------------------------------- Summary : Buffer the output of warning and error messages to facilitate better error reporting during parallel compilation Fixed in : 15.9.0 Severity : S2 - Major Classification : Enhancement Affected Component : C/C++ Compiler (cl) Release Notes: The added --buffer_diagnostics option may be used to force compiler diagnostics to be printed by line instead of by character. This will reduce mangling of diagnostics when multiple instances of the compiler are ran in parallel. Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.11, 6.4.0B1 - 6.4.3 Workaround: Workaround is to manually buffer the compiler output using a script or with the --write_diagnostics_file option. ------------------------------------------------------------------------------- FIXED SDSCM00050959 ------------------------------------------------------------------------------- Summary : SIGSSEGV when using % in an option argument Fixed in : 15.9.0 Severity : S2 - Major Affected Component : Shell Release Notes: In some cases, the compiler passes user-created identifiers directly to a function which behaves like printf without using a format string. If the user's identifier contains any printf-special characters, the compiler may crash. Defect occurs in C2000 Compiler versions: 6.4.0B1 - 6.4.2 Workaround: Don't use any printf-special characters like % in a compiler argument ------------------------------------------------------------------------------- FIXED SDSCM00050992 ------------------------------------------------------------------------------- Summary : The optimizer should not make a symbol an alias if it has either the location or code_section pragmas applied. Fixed in : 15.9.0 Severity : S2 - Major Affected Component : Compiler Consultant (ci) Release Notes: For a reason external to the expression of the program, the user relies on function X being at a particular address A. The only method the user has to do this is to put the function in its own special subsection and place it at A in the linker command file. Workaround: Available workarounds are to: 1. Reduce the optimization level to -o2. 2. If using a COFF abi, you can move the functions into separate files. 3. Add an __asm("NOP") to the function which will prevent an alias from being created. ------------------------------------------------------------------------------- FIXED SDSCM00051050 ------------------------------------------------------------------------------- Summary : Optimization produces incorrect floating point result Fixed in : 15.9.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: When compiling code involving floating-point multiplication and addition with hardware floating-support enabled, the compiler could turn an instruction sequence "ADDF32 MPYF32" into "MACF32" when it is not legal to do so. This bug will only occur if it just so happens that the compiler used R7 as one of the operands of the ADDF32 instruction, which is not predictable by the user. The level of optimization as well as many other factors will affect whether or not the bug occurs, but it can't be predicted whether higher or lower levels will trigger the bug. Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.9, 6.4.0B1 Workaround: Add option --disable:ank_peep ------------------------------------------------------------------------------- FIXED SDSCM00051097 ------------------------------------------------------------------------------- Summary : Output section splitting creates a zero-length section Fixed in : 15.9.0 Severity : S2 - Major Affected Component : ELF Linker Release Notes: In certain rare cases, the linker might split an output section into several output sections such that one of them had zero length. The linker really ought not to create split zero-length sections, as it doesn't improve the linkability of the program. This can only happen if one of the input sections is of zero length. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.9, 6.4.0B1 Workaround: 1) Do not split the section in question. 2) Change the zero-length section so that it has at least one more byte. ------------------------------------------------------------------------------- FIXED SDSCM00051126 ------------------------------------------------------------------------------- Summary : Compiler mistakenly duplicates side-effect in function call argument Fixed in : 15.9.0 Severity : S2 - Major Affected Component : Code Generator Release Notes: If there is a side effect in a function call with an expression with the result of a 32-bit multiply feeding into a 32-bit add, the compiler could mistakenly duplicate the side effect, which could create incorrect behavior. The optimizer can create this scenario from user code that doesn't appear to have a side effect, such as an array index inside a loop. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0 - 6.2.10, 6.4.0B1 - 6.4.0 Workaround: Put the value of the function call argument in a volatile local register before passing it to the function. ------------------------------------------------------------------------------- FIXED SDSCM00051128 ------------------------------------------------------------------------------- Summary : Alias missed on address of local passed as function argument Fixed in : 15.9.0 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00047553 Release Notes: In certain cases, the compiler may produce incorrect code when a local variable whose address is passed to a function is then modified by the function, such as in the following example (where y is the affected local written by modf()): double f(double x) { double y = 0.; if(modf(x, &y) < 0.) return y - 1; else return y; } Workaround: Use the -ma (--aliased_variables) option. ------------------------------------------------------------------------------- FIXED SDSCM00051144 ------------------------------------------------------------------------------- Summary : CLA compiler issues warning about size_t when compiling stddef.h Fixed in : 15.9.0 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: When compiling for CLA, if stddef.h is included, the parser will warn: declaration of "size_t" does not match the expected type "unsigned int". Both types are 32 bits wide and compatible, so the warning may be safely ignored. Defect occurs in C2000 Compiler versions: 6.1.0B1 - 6.1.10, 6.2.9 - 6.2.10, 6.4.0B1 - 6.4.1 Workaround: To silence the warning, either 1) Disable the warning on the command line: cl2000 --cla_support -pds=921 2) Disable the warning in source before the inclusion: #pragma diag_suppress 921 ------------------------------------------------------------------------------- FIXED SDSCM00051212 ------------------------------------------------------------------------------- Summary : MSP 4.4.0 changes to _lock.h declaration of _nop(void) instead of _nop() breaking driverlib Fixed in : 15.9.0 Severity : S2 - Major Affected Component : Runtime Intrinsics Release Notes: MSP 4.4.0 RTS file _lock.h changed prototype for _nop() to _nop(void) which errors in parser for driverlib projects. Workaround: Update _lock.h in the rts source folder, rename the library you are using, and it will automatically be rebuilt during next compile. To find compiler install location, click on project properties and click on: Resource->Linked Resources The "Path Variable" will have an entry for: CG_TOOL_ROOT c:\install_location\ccsv6\tools\compiler\msp430_4.3.4 Within above folder look for: .\lib\src\_lock.h .\include\_lock.h Edit both of above files and change below line 47: _CODE_ACCESS void _nop(void); to remove void argument and instead be: _CODE_ACCESS void _nop(); Rename the library you are using with suffix .old: .\lib\rtsx_lc_sd_eabi.lib change to a temp name .\lib\rtsx_lc_sd_eabi.lib.old Rebuild your project and the rts should automatically rebuild. ------------------------------------------------------------------------------- FIXED SDSCM00051235 ------------------------------------------------------------------------------- Summary : C2000 CGT v6.4 CLA linker errors Fixed in : 15.9.0 Severity : S1 - Critical / PS Affected Component : Linker Release Notes: When compiling for CLA with the new C2000 CGT v6.4 compiler, the linker will generate errors if old linker command files are used. A patch will be released within the next couple of weeks to avoid this problem. Workaround: Make the following changes to the linker command file: 1) Remove the following: --undef_sym=__cla_scratchpad_end --undef_sym=__cla_scratchpad_start 2) Add the following: .scratchpad : > CLARAM1, PAGE = 1 ------------------------------------------------------------------------------- FIXED SDSCM00051241 ------------------------------------------------------------------------------- Summary : Output section splitting creates a zero-length section Fixed in : 15.9.0 Severity : S2 - Major Affected Component : ELF Linker Release Notes: In certain rare cases, the linker might split an output section into several output sections such that one of them had zero length. The linker really ought not to create split zero-length sections, as it doesn't improve the linkability of the program. This can only happen if one of the input sections is of zero length. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.10, 6.4.0B1 - 6.4.0 Workaround: 1) Do not split the section in question. 2) Change the zero-length section so that it has at least one more byte. ------------------------------------------------------------------------------- FIXED SDSCM00051261 ------------------------------------------------------------------------------- Summary : The exception handling (_eh) version of runtime library is not automatically built when --exceptions option is enabled Fixed in : 15.9.0 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: The exception handling (_eh) version of runtime library is not automatically built for projects that have --exceptions option enabled. This results in "undefined symbol" linker errors due to the incorrect rts library being linked in. This is caused by a missing build attribute in assembly files. This may be confirmed by examining the assembly for "Tag_Exceptions". Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.10, 6.4.0B1 - 6.4.1 Workaround: You can build the library manually. In a command terminal, browse to the lib dir of the code gen folder (ex. C:\ti\ccsv6\tools\compiler\c2000_6.2.7\lib) and run the following command: > set PATH=%PATH%;C:\ti\ccsv6\tools\compiler\c2000_6.2.7\bin > mklib --pattern=rts2800_eh.lib --index=libc.a -- > install_to=C:/ti/ccsv6/tools/compiler/c2000_6.2.7/lib Update the paths to the CGT folder to match your install. Change the library name that is passed to the --patter option to build the other libraries for floating point (rts2800_fpu32_eh.lib) or large memory model (rts2800_ml_eh.lib). ------------------------------------------------------------------------------- FIXED SDSCM00051267 ------------------------------------------------------------------------------- Summary : Corrupted .cinit records for large data structures Fixed in : 15.9.0 Severity : S2 - Major Affected Component : Code Generator Release Notes: A large statically initialized data structure may corrupt the initialization table. This may occur when: 1. The size of the structure is greater than the largest possible initialization record on the target. 2. The COFF ABI is being used. This will result in the creation of a zero length initialization record immediately following the record for the large structure which will end the initialization process. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.10, 6.4.0 - 6.4.1 Workaround: Data structures will need to be manually initialized. ------------------------------------------------------------------------------- FIXED SDSCM00051388 ------------------------------------------------------------------------------- Summary : Compiler emits illegal instruction for SP save Fixed in : 15.9.0 Severity : S2 - Major Affected Component : Code Generator Release Notes: On C2000, an illegal store of the stack pointer to memory may be generated. This bug has only been seen at optimization level 2 and above but could occur at a lower level. If affected assembly is generated, the assembler will error with "Illegal operand combination." Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.4 - 6.2.10, 6.4.0B1 - 6.4.2 Workaround: Changing the optimization level for an affected file will most likely avoid the error. ------------------------------------------------------------------------------- FIXED SDSCM00051389 ------------------------------------------------------------------------------- Summary : Compiler emits RPTB that is too large Fixed in : 15.9.0 Severity : S2 - Major Affected Component : Code Generator Release Notes: The compiler treated the instruction ADDUL P, loc32 as if it were 16 bits. However, it is actually 32 bits. If the compiler used this instruction in an RPTB, it would underestimate the size of the RPTB, and could potentially create an RPTB that was too large to be legal. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.10, 6.4.0B1 - 6.4.2 Workaround: No practical workaround ------------------------------------------------------------------------------- FIXED SDSCM00051394 ------------------------------------------------------------------------------- Summary : Loop containing floating-point min or max reduction may cause compiler crash Fixed in : 15.9.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: A loop containing a min or max reduction -- ie for ... a = (a > b) ? a : b; when all the expressions are floating-point and the code is compiled with --float_support=fpu32 or fpu64, may cause the compiler to crash. Defect occurs in C2000 Compiler versions: 6.4.0B1 - 6.4.2 Workaround: Compile with -o0 or -o1, or use -mf0, -mf1, or -mf2, or add "#pragma UNROLL(1)" to the offending loop. ------------------------------------------------------------------------------- FIXED SDSCM00051472 ------------------------------------------------------------------------------- Summary : Conditionals that use shift operator may be optimized out Fixed in : 15.9.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: Shift operations in conditional statements may be optimized out, treating the result as 0. This will result in the entire conditional block being removed. NOTE: Intrinsics that perform shifts may be affected. In the observed test case, a shift was not explicitly used -- the C6x intrinsic _extu, which performs two shifts, was affected. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.11, 6.4.0B1 - 6.4.2 Workaround: This behavior may be avoided by lowering the optimization level to -o1 or -o0. Moving the conditional check result to a variable so that the shift is not in the conditional may in some cases also avoid this behavior. ------------------------------------------------------------------------------- FIXED SDSCM00051506 ------------------------------------------------------------------------------- Summary : x -= y * z replaced with __parallel_mpy_add_f32 Fixed in : 15.9.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00051514 Release Notes: Floating point operations of the form x -= y * z may be computed as x += y * z on C2000. The issue is identifiable by the use of the MACF32 (floating point multiply accumulate) instruction in affected loops. Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.11, 6.4.2 Workaround: Lower the optimization level to -o0 or -o1. Alternatively, changing the statement "x -= y * z" to "volatile float t = y * z; x -= t" should also avoid this behavior. ------------------------------------------------------------------------------- FIXED SDSCM00051517 ------------------------------------------------------------------------------- Summary : Stack is corrupted when --opt_for_space is used Fixed in : 15.9.0 Severity : S2 - Major Affected Component : Code Generator Release Notes: When optimize for size is used on C2000 (-ms, --opt_for_space, -mf0), the prolog and/or epilog for a function may be replaced with library routines such as _prolog_c28x_2. If a prolog from the library is used, but an epilog from the library is not, this may result in not properly restoring all saved registers from the stack. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.11, 6.4.2 Workaround: Disable/lower optimization for size. Note: Normal optimization levels (-o[0-4]) do not affect this bug. Lowering or removing the use of -ms (--opt_for_space) and -mf to favor performance over size will alleviate this behavior. =============================================================================== 2. Current Known Issues =============================================================================== The following 32 known issues exist for C2000 Code Generation Tools release 15.9.0.STS as of October 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 SDSCM00008691 ------------------------------------------------------------------------------- Summary : Compiler round floats different than runtime support library Affected Component : Parser Description: If you look at float.h in C28x's RTS, you will see this line: #define FLT_ROUNDS 0 /* TRUNCATE TOWARDS ZERO */ This macro 'FLT_ROUNDS', when set to zero, means that the result of any floating point operation is rounded toward zero. However, the 'FPSIM' floating-point package that the parser, optimizer, and assembler use to do floating-point calculations rounds toward nearest. Thus, if the compiler performs any optimizations like constant-folding on floating point numbers, the user may get an unexpected result. ------------------------------------------------------------------------------- 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 SDSCM00042344 ------------------------------------------------------------------------------- Summary : Compiler generates internal error: illegal initialization or segmentation fault Affected Component : C/C++ Compiler (cl) Description: The attached test case generates a segmentation fault when compiled with CGT 6.1.x and 7.0.x. It generates the following error when compiled with 7.2.5 and 7.3.1 but does generate a .obj file. Build with: cl6x --gcc seg_fault.c >> INTERNAL ERROR: ILLEGAL INITIALIZATION This may be a serious problem. Please contact customer support with a description of this problem and a sample of the source files that caused this INTERNAL ERROR message to appear. Note: May lose variable initialization information ... continuing compilation ... User would like to know if there is a workaround. ------------------------------------------------------------------------------- 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 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