C2000 C/C++ CODE GENERATION TOOLS 6.2.9 September 2014 Defect History ------------------------------------------------------------------------------- Table of Contents ------------------------------------------------------------------------------- 1. Defects fixed in C2000 Code Generation Tools release 6.2.9 2. Defects fixed in C2000 Code Generation Tools release 6.2.8 3. Defects fixed in C2000 Code Generation Tools release 6.2.7 4. Defects fixed in C2000 Code Generation Tools release 6.2.6 5. Defects fixed in C2000 Code Generation Tools release 6.2.5 6. Defects fixed in C2000 Code Generation Tools release 6.2.4 7. Defects fixed in C2000 Code Generation Tools release 6.2.3 8. Defects fixed in C2000 Code Generation Tools release 6.2.2 9. Defects fixed in C2000 Code Generation Tools release 6.2.1 10. Defects fixed in C2000 Code Generation Tools release 6.2.0 11. Defects fixed in C2000 Code Generation Tools release 6.2.0B1 12. Current Known Issues =============================================================================== 1. Defects fixed in C2000 Code Generation Tools release 6.2.9 =============================================================================== The following 2 defects were fixed in C2000 Code Generation Tools release 6.2.9, released September 2014. ------------------------------------------------------------------------------- FIXED SDSCM00050763 ------------------------------------------------------------------------------- Summary : Only the C6000 compiler accepts the GCC builtin function __builtin_constant_p Fixed in : 6.2.9 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Error emitted that GNU __builtin_constant_p function not supported. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00050811 ------------------------------------------------------------------------------- Summary : Linker fails with INTERNAL ERROR: lnk2000 experienced an unhandled exception Fixed in : 6.2.9 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00050799 Release Notes: This bug occurs in the C preprocessor used for reading linker command files, and results in an unhandled exception from the linker. If no C preprocessor directives are used, the bug should not occur. The --disable_pp option can be used to turn off the preprocessor if no directives are present. Defect occurs in C2000 Compiler versions: 6.2.8 Workaround: Remove C preprocessor directives from linker command files. =============================================================================== 2. Defects fixed in C2000 Code Generation Tools release 6.2.8 =============================================================================== The following 3 defects were fixed in C2000 Code Generation Tools release 6.2.8, released August 2014. ------------------------------------------------------------------------------- FIXED SDSCM00050243 ------------------------------------------------------------------------------- Summary : Scary but harmless warning: FAILURE in mark_use_of_function_local_static() Fixed in : 6.2.8 Severity : S2 - Major Affected Component : Optimizer Release Notes: Compiling for C++ and using -pm or -o4 may produce a warning like FAILURE in mark_use_of_function_local_static() fname1: __sti fname2: __sti_ symbol: _$P$T62$2$1 This warning, despite its dramatic wording, is harmless. The compiler will build the program just as it should, and the warning does not indicate any change in behavior. It's a debugging message that should not have been visible outside the development team. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.8, 6.2.0B1 - 6.2.7 Workaround: Avoid -pm or -o4. But the warning doesn't indicate any change of the compiler's behavior, so you might as well ignore it. ------------------------------------------------------------------------------- FIXED SDSCM00050302 ------------------------------------------------------------------------------- Summary : Assembler emits spurious ECN error Fixed in : 6.2.8 Severity : S2 - Major Affected Component : Assembler Release Notes: The compiler can emit code that triggers a spurious error for FPU MMWRITE ECN2 (see SDSCM0045587). In this case, the assembly code has a MOV32, followed by an unconditional branch to another location, followed by a F32TOUI32. The assembler incorrectly emits the ECN error because it does not realize that control flow cannot reach the F32TOUI32 from the MOV32. Defect occurs in C2000 Compiler versions: 6.0.5 - 6.0.6, 6.1.2 - 6.1.8, 6.2.0B1 - 6.2.7 Workaround: Adjust the optimization level, or place part of the expression in a volatile variable. ------------------------------------------------------------------------------- FIXED SDSCM00050512 ------------------------------------------------------------------------------- Summary : Compiler does not handle control-C signal as expected Fixed in : 6.2.8 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: Added signal catchers for SIGINT and SIGBREAK on non-Unix hosts, so the tool exits cleanly instead of falling into the segfault report mechanism. Workaround: Later compiler releases (7.6.x and above) do not suffer from this problem. =============================================================================== 3. Defects fixed in C2000 Code Generation Tools release 6.2.7 =============================================================================== The following 13 defects were fixed in C2000 Code Generation Tools release 6.2.7, released June 2014. ------------------------------------------------------------------------------- FIXED SDSCM00049775 ------------------------------------------------------------------------------- Summary : No longer expose the option --float_support=fpu64 Fixed in : 6.2.7 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: Since there is no HW support for 64-bit floating point operations, the option --float_support=fpu64 should not appear in documentation or in the command line help summary. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00049859 ------------------------------------------------------------------------------- Summary : Compiler fails with INTERNAL ERROR message Fixed in : 6.2.7 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The attached test case fails with this message ... INTERNAL ERROR: armacpia experienced a segmentation fault while processing function startExciteSequence file file.c line 441 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 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00049909 ------------------------------------------------------------------------------- Summary : CLA compiler generates an internal error when indexing into an array without optimization enabled Fixed in : 6.2.7 Severity : S2 - Major Affected Component : Code Generator Release Notes: This bug is much more likely to occur if optimization is turned off. In many cases, setting the optimization level to 0 will resolve the issue. Defect occurs in C2000 Compiler versions: 6.1.7 - 6.1.8, 6.2.6 Workaround: Try turning optimization on. ------------------------------------------------------------------------------- FIXED SDSCM00049942 ------------------------------------------------------------------------------- Summary : Combination of __byte and optimization cause compiler to emit internal error message Fixed in : 6.2.7 Severity : S3 - Minor Affected Component : Optimizer Release Notes: The attached test case includes these lines ... uint16 buff_ptr = 0; if (__byte((int *)(buff_ptr), 1) != 0) When built with optimization, this code causes the compiler to fail with a message similar to ... >> main.c, line 12: INTERNAL ERROR: Illegal use of intrinsic: __byte 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. Cannot continue compilation - ABORTING! >> Compilation failure Workaround: Change if (__byte((int *)(buff_ptr), 1) != 0) to if (__byte((int *)(&buff_ptr), 1) != 0) ------------------------------------------------------------------------------- FIXED SDSCM00049997 ------------------------------------------------------------------------------- Summary : Loop with volatile loop control expression removed Fixed in : 6.2.7 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: In some cases, the optimizer can remove apparently-empty loops that have a loop test which compares the loop control variable with a volatile value. This is not legal; the volatile value could change, so the loop must be left in the code. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.7, 6.2.0B1 - 6.2.6, 6.3.0B1 Workaround: Declare the loop counter variable as volatile ------------------------------------------------------------------------------- FIXED SDSCM00050014 ------------------------------------------------------------------------------- Summary : Missing copyright notice on mklib.c source Fixed in : 6.2.7 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: The source code for mklib (mklib.c) is part of the product but lacks a proper copyright statement. This file should have the same copyright as the other TI-generated source files in the RTS library source code. Defect occurs in C2000 Compiler versions: 6.1.0B1 - 6.1.7, 6.2.0B1 - 6.2.6 Workaround: Not applicable ------------------------------------------------------------------------------- FIXED SDSCM00050023 ------------------------------------------------------------------------------- Summary : SIGSEGV when using pragma on a template function Fixed in : 6.2.7 Severity : S2 - Major Affected Component : Parser Release Notes: The compiler may emit an internal error (SIGSEGV) when the user attempts to apply a pragma to a template class function. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.7, 6.2.0B1 - 6.2.6, 6.3.0B1 Workaround: Do not apply any pragma to a template function. Move the function outside the template class. ------------------------------------------------------------------------------- FIXED SDSCM00050120 ------------------------------------------------------------------------------- Summary : Saturating expression lost when using optimizer Fixed in : 6.2.7 Severity : S2 - Major Affected Component : Optimizer Release Notes: At -o2 and above, the optimizer loses the saturating if-tests. Workaround: Use optimization level 1 or lower. ------------------------------------------------------------------------------- FIXED SDSCM00050193 ------------------------------------------------------------------------------- Summary : Compiler issues INTERNAL ERROR: no match for ENDLOOP Fixed in : 6.2.7 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: For the attached test case the compiler issues ... >> logger.pp, line 15164: INTERNAL ERROR: no match for ENDLOOP 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. Cannot continue compilation - ABORTING! >> Compilation failure Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00050202 ------------------------------------------------------------------------------- Summary : MISRA-C rule 19.11 false positive Fixed in : 6.2.7 Severity : S3 - Minor Affected Component : Parser Release Notes: A violation of MISRA-C rule 19.11 may be falsely detected when a use of an undefined macro is guarded by a check to make sure that the macro is defined before use: #undef X #if defined(X) && X ... #endif Workaround: Disable MISRA-C rule checking for 19.11 around the affected lines: #pragma CHECK_MISRA("-19.11") ... #pragma RESET_MISRA("19.11") ------------------------------------------------------------------------------- FIXED SDSCM00050227 ------------------------------------------------------------------------------- Summary : Illegal use of control register when setting all bits in IFR Fixed in : 6.2.7 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Sometimes the compiler will turn IFR |= 0xffff into IFR = 0xffff and then declares that this is an illegal use of IFR. The compiler should match IFR = 0xffff with an OR, as it matches IFR = 0 with IFR &= 0. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.8, 6.2.0B1 - 6.2.6, 6.3.0B1 Workaround: Split the write to IFR into two parts that together contain all of the bits: IFR |= 0xff00; IFR |= 0x00ff; ------------------------------------------------------------------------------- FIXED SDSCM00050351 ------------------------------------------------------------------------------- Summary : --symdebug:none and --symdebug:dwarf_version conflict when using -o4 Fixed in : 6.2.7 Severity : S3 - Minor Affected Component : ILinker (File Merge) Duplicate Defects : SDSCM00048790 Release Notes: The --symdebug:none and --symdebug:dwarf_version conflict when combined during LTO. The --symdebug:none and --symdebug:dwarf options are fine together so -- symdebug:dwarf_version should not cause a problem. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00050352 ------------------------------------------------------------------------------- Summary : Combining -pm and -o4 on the command line causes an error during -o4. Fixed in : 6.2.7 Severity : S3 - Minor Affected Component : ILinker (File Merge) Release Notes: When combining the -pm and -o4 options, an error occurs during the LTO phase. These option should be allowed to work together. Workaround: None. =============================================================================== 4. Defects fixed in C2000 Code Generation Tools release 6.2.6 =============================================================================== The following 6 defects were fixed in C2000 Code Generation Tools release 6.2.6, released April 2014. ------------------------------------------------------------------------------- FIXED SDSCM00048498 ------------------------------------------------------------------------------- Summary : MISRA-C rule 12.8 incorrectly reported for an expression like ((uint32_t)2U << 8U); Fixed in : 6.2.6 Severity : S2 - Major Affected Component : Parser Release Notes: A violation warning for the MISRA 12.8 rule was reported for the expression: ((uint32_t)2U << 8U); The MISRA 12.8 rule states that "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". The underlying type is determined by section 6.10 of the MISRA Guidelines. For a literal it is defined as being the smallest type of the same sign that can represent the literal, so for 2U the type is unsigned char. In that case the diagnostic is correct. However, the cast to uint32_t should make the underlying type unsigned int, making the operation legal. Defect occurs in C2000 Compiler versions: 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.6, 6.2.0B1 - 6.2.5 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00049320 ------------------------------------------------------------------------------- Summary : Multiple assignments to different, overlapping, array members of a union may occur in the wrong order Fixed in : 6.2.6 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Given a union whose fields are arrays of different types, accesses to different, overlapping, fields may occur in the wrong order. This problem is specific to unions of arrays; unions of scalars are handled correctly. Strictly speaking, it is undefined behavior to access overlapping parts of a union through fields of different types, but the compiler is supposed to be lenient enough to allow it. Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.5 Workaround: Don't access the same space within a union using differently-typed fields. ------------------------------------------------------------------------------- FIXED SDSCM00049326 ------------------------------------------------------------------------------- Summary : RTTI is enabled by default with no way to disable it. For C++ code, this can cause data size to double. Fixed in : 6.2.6 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: For COFF executables, when --rtti is not used, the compiler will suppress RTTI information, leaving the executable file a bit smaller. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00049568 ------------------------------------------------------------------------------- Summary : CLA compiler incorrectly converts floating point expression to unsigned type, instead of a signed type Fixed in : 6.2.6 Severity : S2 - Major Affected Component : Code Generator Release Notes: For a test case where a pointer is indexed by a float cast to a signed integer type, the compiler was mistakenly changing the cast to be an unsigned type. This gives the wrong value if the float value is negative. The symptom is that the CLA compiler incorrectly issues a MF32TOUI32 (converts float to unsigned int) instruction instead of the expected MF32TOI32 (converts float to signed int). Defect occurs in C2000 Compiler versions: 6.1.0B1 - 6.1.6, 6.2.0B1 - 6.2.5 Workaround: No reliable workaround ------------------------------------------------------------------------------- FIXED SDSCM00049626 ------------------------------------------------------------------------------- Summary : Compiler generates internal error: no match for PLUS when file is compiled with -o2 and float_support options Fixed in : 6.2.6 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00050358 Release Notes: Compiler generates internal error: no match for PLUS for certain source files when compiled with -o2 and --float_support=fpu32options Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00049885 ------------------------------------------------------------------------------- Summary : Loop increment larger than INT_MAX truncated Fixed in : 6.2.6 Severity : S2 - Major Affected Component : Optimizer Release Notes: For a down-counting loop with an increment larger than INT_MAX or smaller than INT_MIN, the optimizer may truncate the value of the increment at optimization level 2 or higher. Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.5 Workaround: Reduce optimization level to -o1 or less =============================================================================== 5. Defects fixed in C2000 Code Generation Tools release 6.2.5 =============================================================================== The following 11 defects were fixed in C2000 Code Generation Tools release 6.2.5, released February 2014. ------------------------------------------------------------------------------- FIXED SDSCM00045417 ------------------------------------------------------------------------------- Summary : bool and _Bool are not defined correctly in strict ANSI C mode Fixed in : 6.2.5 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00048227, SDSCM00048226 Release Notes: The size and type of "bool" and "_Bool" must be the same in all modes so that declarations of the same object in different modules are compatible. However, in strict ANSI C89 mode, stdbool.h defines _Bool as "unsigned int," which means a C++ module using bool and a C module including stdbool.h and using bool are using incompatible types. _Bool and stdbool.h are C99 features, so a strictly-conforming C89 program does not use them, but the TI compiler provides them as an extension. This would cause a problem when attempting to mix C++ files and C files which both declare The ARM EABI Procedure Call Standard for the ARM Architecture (ARM IHI 0042D) section 7.1.1 ("Arithmetic Types") requires that both C++ bool and C99 _Bool be unsigned byte types. However, the TI toolset does not conform to that requirement. Defect occurs in C2000 Compiler versions: 5.0.0 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.6, 6.2.0B1 - 6.2.4 Workaround: The compiler and library now agree on a single definition of bool and _Bool in all modes; its format is equivalent to "unsigned char." Unfortunately, this represents a backward incompatibility with older object files which match all of these conditions: - C source code - includes stdbool.h - compiled in strict C89 mode (the default in older compilers) - module interface uses type _Bool or bool (i.e. a global variable, function argument, or function return value of type derived from bool, or struct containing a type derived from bool.) To work around the problem, either recompile with the latest version of the compiler, or ensure that you aren"t using any _Bool or bool objects in the module interface. ------------------------------------------------------------------------------- FIXED SDSCM00046180 ------------------------------------------------------------------------------- Summary : MISRA check 14.1 should not treat while(0) as potential infinte loop Fixed in : 6.2.5 Severity : S3 - Minor Affected Component : Parser Release Notes: Misra rule 14.1 no longer emits a false warning for do{} while(0). Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00047666 ------------------------------------------------------------------------------- Summary : Definition of SIZE_MAX is wrong Fixed in : 6.2.5 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The definition of SIZE_MAX was incorrectly specified as the largest signed integer value. It is now defined as the largest unsigned integer value. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.6, 6.2.0B1 - 6.2.4 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00048289 ------------------------------------------------------------------------------- Summary : Errors of the linker due to the difference in version of CGT Fixed in : 6.2.5 Severity : S2 - Major Affected Component : Linker Duplicate Defects : SDSCM00048621 Release Notes: The fix for SDSCM00044393 was intended to allow the following linker command file syntax: SECTIONS { OUTSECT_NAME MEMORY_RANGE_NAME } The Assembly Language Tools User Guide erroneously stated that this syntax was accepted. However, allowing the above syntax introduces ambiguity in the linker command file grammar, which caused previously accepted command files to produce errors, resulting in this bug (SDSCM00048289). This change removes the fix applied for SDSCM00044393. The above syntax will no longer be accepted. The linker will now issue a warning if an output section is specified but no placement information is found for it. The documentation will be updated to specify that load allocation may be specified with the syntax "load = allocation" or "> allocation". The above syntax will result in a warning that no placement was specified for OUTSECT_NAME and a default placement will be applied. Valid linker command files that were rejected due to the ambiguity will now be accepted. Workaround: The problem can be avoided by using memory range names that are different from section names. For example, this linker command file may cause the error because "RAM" is both a memory range name and a section name: MEMORY { RAM : } SECTIONS { RAM : > RAM } But this one would not cause the error: MEMORY { RAM_MEM : } SECTIONS { RAM : > RAM_MEM } Also okay: MEMORY { RAM : } SECTIONS { RAM_SECT : > RAM } ------------------------------------------------------------------------------- FIXED SDSCM00048440 ------------------------------------------------------------------------------- Summary : SIGSEGV when using MISRA checks on code with an anonymous struct Fixed in : 6.2.5 Severity : S2 - Major Affected Component : Parser Duplicate Defects : SDSCM00050700 Release Notes: When using MISRA checking on code that contains an anonymous struct, the parser will crash with a SIGSEGV. Note that anonymous structs are not legal in strict ANSI mode, and MISRA emits a warning if strict ANSI mode is not used. Defect occurs in C2000 Compiler versions: 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.6, 6.2.0B1 - 6.2.4 Workaround: Do not use anonymous structs or unions when using MISRA ------------------------------------------------------------------------------- FIXED SDSCM00048712 ------------------------------------------------------------------------------- Summary : ARM assembler seg faults on certain input Fixed in : 6.2.5 Severity : S3 - Minor Affected Component : Assembler Duplicate Defects : SDSCM00049517 Release Notes: The problem is that the assembly instruction LDR r0,0x40004000 is not legal. The assembler believes 0x40004000 is a symbol because the user did not put a '#' in front of it. Adding the '#' produces the correct error: "Invalid addressing mode". This is still a defect because the assembler sshould not seg fault on a bad instruction. Workaround: Add the '#' in front of the 0x40004000 to produce the correct "Invalid addressing mode" error. ------------------------------------------------------------------------------- FIXED SDSCM00048747 ------------------------------------------------------------------------------- Summary : Using END(sym_name) or SIZE(sym_name) on .cinit can cause link to fail Fixed in : 6.2.5 Severity : S2 - Major Affected Component : ELF Linker Release Notes: When the compression is performed, the size of the parent collection needs to be updated. Workaround: Avoid the use of the END() or SIZE() operators for .cinit or other compressed sections. ------------------------------------------------------------------------------- FIXED SDSCM00049149 ------------------------------------------------------------------------------- Summary : AND loc16, #16bitSigned instruction with incorrect constant 0 Fixed in : 6.2.5 Severity : S2 - Major Affected Component : Code Generator Release Notes: C2000 supports an instruction that does a bitwise-and of a 16-bit immediate value to a memory location. In certain cases, when generating this instruction, the compiler would mistakenly use the immediate value 0 instead of the correct value. This bug is most likely to occur when using a bitwise-and expression with an integer constant operand that is smaller than 0x100, but other optimizations could potentially create the situation for any bitwise-and with a constant operand. integer constant operand. Defect occurs in C2000 Compiler versions: 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.6, 6.2.0B1 - 6.2.4 Workaround: Put the constant value in a volatile local variable. ------------------------------------------------------------------------------- FIXED SDSCM00049206 ------------------------------------------------------------------------------- Summary : #pragma CLINK does not work on initialized data Fixed in : 6.2.5 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The CLINK pragma now works as expected for initialized data. Defect occurs in C2000 Compiler versions: 6.1.0B1 - 6.1.6, 6.2.0B1 - 6.2.4 Workaround: Only uninitialized data can be marked CLINK. To make data CLINK, make it unitialized and do the initialization at startup. ------------------------------------------------------------------------------- FIXED SDSCM00049271 ------------------------------------------------------------------------------- Summary : INTERNAL ERROR results when building code that uses features from C++ testing framework Fixed in : 6.2.5 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00050480 Release Notes: The compiler correctly handles const variables that are referenced in a program using templates. Workaround: declare VAR as "extern const int VAR = 1;" ------------------------------------------------------------------------------- FIXED SDSCM00049393 ------------------------------------------------------------------------------- Summary : Certain cases of loops involving pointer-to-volatile may cause compiler crash Fixed in : 6.2.5 Severity : S2 - Major Affected Component : Optimizer Release Notes: A loop that incremented a pointer-to-volatile until it reached another known pointer-to-volatile value caused the compiler to crash. It is known that the volatile qualifier is an essential part of the problem. It is likely that the problem is limited to loops and volatile loop indices, but not certain. Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.4 Workaround: Remove the volatile qualifier. =============================================================================== 6. Defects fixed in C2000 Code Generation Tools release 6.2.4 =============================================================================== The following 2 defects were fixed in C2000 Code Generation Tools release 6.2.4, released November 2013. ------------------------------------------------------------------------------- FIXED SDSCM00047220 ------------------------------------------------------------------------------- Summary : Unsigned 32-bit and 64-bit comparisons may be performed incorrectly Fixed in : 6.2.4 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The compiler was using the TEST instruction for 32-bit comparisons to zero, and CMP64 for 64-bit comparisons to zero, but because neither instruction sets the C bit, they cannot be used for unsigned relational comparisons (< > <= >=). The compiler also removes redundant comparisons to zero, but does not distinguish between instructions which set the C bit and instructions which do not set the C bit when determining whether a comparison instruction is redundant; this means it is not safe to ever remove the comparison if an unsigned relational condition is being used in a branch. Defect occurs in C2000 Compiler versions: 4.1.0B1 - 4.1.4, 4.3.0B1 - 4.3.0, 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.5, 6.2.0B1 - 6.2.3 Workaround: No practical workaround. ------------------------------------------------------------------------------- FIXED SDSCM00048534 ------------------------------------------------------------------------------- Summary : String constant with indexing operator causes compiler to emit panic error message and quit Fixed in : 6.2.4 Severity : S2 - Major Affected Component : Parser Release Notes: An indexed expression without a variable like the one below was parsed incorrectly when appearing on the right hand side of an assignment: long x = "abcd"[0]; Workaround: None. =============================================================================== 7. Defects fixed in C2000 Code Generation Tools release 6.2.3 =============================================================================== The following defect was fixed in C2000 Code Generation Tools release 6.2.3, released October 2013. ------------------------------------------------------------------------------- FIXED SDSCM00048500 ------------------------------------------------------------------------------- Summary : C2000 compiler _IQsat protoype argument Fixed in : 6.2.3 Severity : S1 - Critical / PS Affected Component : Optimizer Release Notes: The __IQsat intrinsic is erroneously treating the final argument, min, as an int instead of a long when Optimization is enabled. This might result in the wrong min value being used. Workaround: Use the -Ooff flag to turn off Optimization in order to prevent the problem if using the __IQsat intrinsic. =============================================================================== 8. Defects fixed in C2000 Code Generation Tools release 6.2.2 =============================================================================== The following defect was fixed in C2000 Code Generation Tools release 6.2.2, released October 2013. ------------------------------------------------------------------------------- FIXED SDSCM00048290 ------------------------------------------------------------------------------- Summary : Use of option --gcc on C2000 CLA results in internal error message Fixed in : 6.2.2 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: If attempting to use --gcc with CLA files, the compiler will emit an internal error, regardless of the input. It should instead ignore --gcc. Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.1 Workaround: CLA does not support --gcc; do not attempt to use --gcc for CLA files. If you need --gcc for C2000 files in the same project, you will need to set the --gcc option individually on every file that uses GCC extensions. =============================================================================== 9. Defects fixed in C2000 Code Generation Tools release 6.2.1 =============================================================================== The following 9 defects were fixed in C2000 Code Generation Tools release 6.2.1, released September 2013. ------------------------------------------------------------------------------- FIXED SDSCM00013456 ------------------------------------------------------------------------------- Summary : fgets in _IONBF mode does not respect size limit Fixed in : 6.2.1 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: The second argument to fgets() is the maximum number of chars to read. In _IONBF mode, fgets() reads until end-of-line, potentially overrunning the input buffer. For example: #include #include #include #include main() { FILE *f = fopen("tst.txt", "r"); char buffer[100]; int counter = 0; setvbuf(f, NULL, _IONBF, 0); while (fgets(buffer, 5, f) != NULL) { printf("[%s]\n", buffer); switch (counter++) { case 0: assert(!strcmp(buffer, "aaaa")); break; case 1: assert(!strcmp(buffer, "bbbb")); break; case 2: assert(!strcmp(buffer, "cccc")); break; } } assert(feof(f)); puts("PASS"); } With tst.txt having (with no trailing newline): aaaabbbbcccc Defect occurs in C2000 Compiler versions: 3.08 - 3.13, 4.1.0B1 - 4.1.4, 4.3.0B1 - 4.3.0, 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.4, 6.2.0B1 - 6.2.0 Workaround: Do not use _IONBF mode ------------------------------------------------------------------------------- FIXED SDSCM00043860 ------------------------------------------------------------------------------- Summary : Printf format %#06x prints zeros in the wrong place Fixed in : 6.2.1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00008251 Release Notes: When the # and 0 flags are both used with the x conversion specifier, any extra 0 characters added to fill up the precision should be added after the 0x prefix, but the TI library added them before the 0x prefix. Defect occurs in C2000 Compiler versions: 4.1.0B2 - 4.1.4, 4.3.0B1 - 4.3.0, 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.5, 6.2.0B1 - 6.2.0 Workaround: Avoid using both # and 0 flags when using the x conversion specifier. ------------------------------------------------------------------------------- FIXED SDSCM00045944 ------------------------------------------------------------------------------- Summary : stdbool.h should not include stdarg.h Fixed in : 6.2.1 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Duplicate Defects : SDSCM00047665 Release Notes: A file which includes stdbool.h (or one of several other files) will get the fatal error: "Header file not supported by CLA compiler." Even though CLA doesn't support stdarg.h, a user's code should be able to use stdbool.h, stddef.h and stdint.h, for example. Defect occurs in C2000 Compiler versions: 6.1.0B1 - 6.1.5, 6.2.0B1 - 6.2.0 Workaround: Edit yvals.h and wrap every reference to stdarg.h or va_list with #if !defined(__TMS320C28XX_CLA__) ------------------------------------------------------------------------------- FIXED SDSCM00047353 ------------------------------------------------------------------------------- Summary : C2000 Assembler emits erroneous error statement when CALL consumes required latency between ECN instruction sequence Fixed in : 6.2.1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Because of a hardware silicon exception, if one of the 3 instructions FRACF32, UI16TOF32, or F32TOUI32 follows a move from a CPU to FPU register, there must be 5 delay cycles in between them. If there is a CALL in between them, the required latency will be consumed by the call and return latencies, plus any latency of the function being called. There is a bug in the assembler causing an error to be emitted when there is only a CALL between these two types of instructions: MOV32 FPUREG, CPUREG CALL TRIGGER INSTRUCTION In this case the assembler is only counting the latency of the CALL instruction (4 cycles), not the total latency consumed by the CALL. Workaround: There is no workaround other than inserting one NOP or another instruction between the 2 instructions. ------------------------------------------------------------------------------- FIXED SDSCM00047510 ------------------------------------------------------------------------------- Summary : (short)labs(x) incorrectly transformed to abs((short)x) Fixed in : 6.2.1 Severity : S2 - Major Affected Component : Code Generator Release Notes: The compiler tries to change labs to the less-expensive abs when the result will be cast to the narrower type, anyway. However, this is not legal unless the input to labs can be represented exactly in type short, which is not always the case. For example, consider (unsigned short)labs(40000), which should have the value 40000. Defect occurs in C2000 Compiler versions: 4.3.0B1 - 4.3.0, 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.5, 6.2.0B1 - 6.2.0 Workaround: Assign the return value of labs to a volatile local variable before converting it to the narrower type. ------------------------------------------------------------------------------- FIXED SDSCM00047542 ------------------------------------------------------------------------------- Summary : Assembler silently converts relocatable symbol to absolute value when instruction requires absolute value Fixed in : 6.2.1 Severity : S2 - Major Affected Component : Assembler Release Notes: The MMOVI32 instruction requires a floating point immediate in hex format as the second operand. When it is given a relocatable symbol instead, it converts it to an absolute value. The assembler should issue an error instead. When the final value of the symbol is known, it will not be updated since the instruction required a known immediate and the assembler treated the symbol as one. Workaround: Do not use a symbol for the immediate operand in MMOVI32. ------------------------------------------------------------------------------- FIXED SDSCM00047741 ------------------------------------------------------------------------------- Summary : C2000 compiler erroneously generates MACF32 R7H,R3H,mem32,*XAR7 Fixed in : 6.2.1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00049836 Release Notes: The C2000 v.6.2.0 Compiler generates MACF32 R7H, R3H, mem32, *XAR7 but only *XAR7++ is allowed as the final argument. This causes an assembler error. Only v.6.2.0 is affected. Workaround: Compiling without unified memory (-mt) or at optimization levels less than -O2 will prevent the erroneous instruction from being generated. ------------------------------------------------------------------------------- FIXED SDSCM00047792 ------------------------------------------------------------------------------- Summary : Multiple .cdecls instances sharing header files cause assembler error "struct/union/enum tag can't be global" Fixed in : 6.2.1 Severity : S2 - Major Affected Component : Assembler Release Notes: When multiple .cdecls clauses in an assembly file include headers that share the same definitions, duplicate code will be generated causing an assembler error. The assembler error will state that structure or enumeration tags can't be "global". The Assembly Language Tools User's Guide states that multiple .cdelcs instances do not share the same C/C++ environment. Therefore, headers that share the same definitions must be included in the same .cdecls instance. Workaround: Include headers sharing definitions in either a single .cdecls clause: .cdecls C, LIST %{ #include "header1.h" #include "header2.h" %} OR inside a single header file: .cdecls C, LIST, "header.h" ------------------------------------------------------------------------------- FIXED SDSCM00047883 ------------------------------------------------------------------------------- Summary : bsearch failure when using -pr relaxed ANSI mode or --gcc mode from C++ Fixed in : 6.2.1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00047268 Release Notes: In relaxed mode calling bsearch from C++ results in an infinite loop. Workaround: A workaround is to use --strict_ansi. =============================================================================== 10. Defects fixed in C2000 Code Generation Tools release 6.2.0 =============================================================================== The following 15 defects were fixed in C2000 Code Generation Tools release 6.2.0, released June 2013. ------------------------------------------------------------------------------- FIXED SDSCM00041192 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning for violation of Misra 9.2 Fixed in : 6.2.0 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: Compiler misreports Misra 9.2 warning for zero initialization of single dimension float arrays, like the one below: float array[ 10 ] = {0.0f}; Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00045173 ------------------------------------------------------------------------------- Summary : Missing qsort and bsearch implementations for comparison functions with C++ linkage Fixed in : 6.2.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The C++ standard requires two distinct prototypes for qsort, one for comparison functions with C linkage, and one for comparison functions with C++ linkage. The C++ linkage implementation was missing, which would lead to an incompatible parameter error when trying to use qsort in C++ with a comparison function that has C++ linkage. Defect occurs in C2000 Compiler versions: 4.1.0B1 - 4.1.4, 4.3.0B1 - 4.3.0, 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.13, 6.0.0B1 - 6.0.5, 6.1.0B1 - 6.1.3, 6.2.0B1 Workaround: Declare the comparison function extern "C" ------------------------------------------------------------------------------- FIXED SDSCM00045373 ------------------------------------------------------------------------------- Summary : EXIDX section for alias function leads to INTERNAL ERROR unhandled exception Fixed in : 6.2.0 Severity : S2 - Major Affected Component : Linker Release Notes: If all of --exceptions, --unused_section_elimination=off, and --retain=.ARM.EXIDX are used, and the compiler turns a C++ function into an alias (this is a TI-specific optimization), it is possible for the linker to retain the EXIDX section for the alias function but not the alias function itself, which leads to an internal error. Defect occurs in C2000 Compiler versions: 6.1.0B1 - 6.1.3, 6.2.0B1 Workaround: Do not use either --unused_section_elimination=off or --retain=.ARM.EXIDX. Neither one should be necessary in a properly-functioning linker, and both make the target footprint larger. ------------------------------------------------------------------------------- FIXED SDSCM00046072 ------------------------------------------------------------------------------- Summary : 16-bit unsigned int not correctly updated in union Fixed in : 6.2.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: This bug involves undefined behavior with code that writes to one member of a union and read from a different member (with some exceptions, none of which apply here). This code is therefore not portable. However, as an extension, the TI compiler does support this use and the bug is being analyzed. The auxiliary registers are not able to support unions where one field is 32-bits and the other field is a 2 element array field with 16-bit elements. Auxiliary registers model either a 32-bit value or a 16-bit value. They do not support accessing the lower 16 bits of a 32-bit value. As a result, to prevent incorrect results, place unions with 32 bit fields on the stack and not in a register. Workaround: Use unions in a C language defined manner. ------------------------------------------------------------------------------- FIXED SDSCM00046204 ------------------------------------------------------------------------------- Summary : C2000 RTS library lacks isnan and isinf Fixed in : 6.2.0 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Duplicate Defects : SDSCM00046219 Release Notes: The C2000 compiler now supports INFINITY, but printf would fall into an infinite loop while attempting to print an infinite value. This was due to the lack of the isinf macro. Defect occurs in C2000 Compiler versions: 6.2.0B1 Workaround: Check whether x==INFINITY or x==-INFINITY before attempting to print x ------------------------------------------------------------------------------- FIXED SDSCM00046231 ------------------------------------------------------------------------------- Summary : DATA_ALIGN should not be able to reduce alignment below default array alignment Fixed in : 6.2.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: With the following program: #pragma DATA_SECTION(array, 4) int array[100]; Observe that the alignment of array is 32, should be 64. The DATA_ALIGN pragma should not cause an array to have an alignment that is less than the default array alignment. The DATA_ALIGN pragma is ignored if it attempts to do so. Workaround: Use the DATA_ALIGN pragma with an array alignment value of at least 8 for C64x+ ------------------------------------------------------------------------------- FIXED SDSCM00046696 ------------------------------------------------------------------------------- Summary : The Compiler does not reset the PM bits to the default value before leaving a function Fixed in : 6.2.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: In rare cases, the compiler may not set the PM bits correctly. The compiler attempts to minimize the number of SPM instructions inserted in the code. For example, if there are multiple instructions that perform ">> 2" in a function, and no other SPM values, the compiler will attempt to insert a single SPM #-2 instruction in the function such that it must be executed prior to all instructions that use ">>2". The cases identified in which the error occurs involve a loop containing: - an instruction that sets the PM bits - a conditional block that contains an instruction that sets the PM bits. The error in the compiler may cause the PM value to be incorrect at the exit of the loop. Workaround: None identified. ------------------------------------------------------------------------------- FIXED SDSCM00046812 ------------------------------------------------------------------------------- Summary : Instructions are placed in the wrong order Fixed in : 6.2.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: In rare cases, incorrect analysis by the compiler may indicate that two memory or stack accesses are unrelated when they actually refer to the same object. If this occurs, the compiler may schedule an access incorrectly. Defect occurs in C2000 Compiler versions: 5.2.5 - 5.2.14, 6.0.0B1 - 6.0.5, 6.1.0B1 - 6.1.3, 6.2.0B1 Workaround: No definite workaround exists. However, changing the optimization level may avoid the problem by changing the stack or memory layout. ------------------------------------------------------------------------------- FIXED SDSCM00046816 ------------------------------------------------------------------------------- Summary : Excessive compile time - Optimizer hangs Fixed in : 6.2.0 Severity : S2 - Major Classification : Performance Affected Component : Optimizer Release Notes: A program containing large structs containing many fields, especially if those fields are of type char, may require excessive time to compile. The compiler must check all those fields for potential aliases, and does so inefficiently. Defect occurs in C2000 Compiler versions: 3.08 - 3.13, 4.1.0B1 - 4.1.4, 4.3.0B1 - 4.3.0, 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.14, 6.0.0B1 - 6.0.5, 6.1.0B1 - 6.1.3, 6.2.0B1 Workaround: None known. ------------------------------------------------------------------------------- FIXED SDSCM00046849 ------------------------------------------------------------------------------- Summary : stdin stdout stderr macros need to be usable without using namespace std for _ftable Fixed in : 6.2.0 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Duplicate Defects : SDSCM00045792, SDSCM00043348 Release Notes: stdin, stdout, and stderr are macros involving the identifier std::_ftable. As a macro, the namespace is not specified as you would for a type or variable (std::size_t). When cstdio is included, these macros are defined and should be usable without a using declaration putting std::_ftable in the global namespace. Defect occurs in C2000 Compiler versions: 4.1.0B1 - 4.1.4, 4.3.0B1 - 4.3.0, 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.14, 6.0.0B1 - 6.0.5, 6.1.0B1 - 6.1.3, 6.2.0B1 Workaround: Include stdio.h instead of cstdio ------------------------------------------------------------------------------- FIXED SDSCM00046910 ------------------------------------------------------------------------------- Summary : Using an invalid option with valid hex command file causes SIGSEGV Fixed in : 6.2.0 Severity : S2 - Major Affected Component : Hex Converter (hex) Release Notes: Using an invalid option with valid hex command file causes a segmentation fault. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.14, 6.0.0B1 - 6.0.5, 6.1.0B1 - 6.1.3, 6.2.0B1 Workaround: Fix or eliminate the invalid option. ------------------------------------------------------------------------------- FIXED SDSCM00046991 ------------------------------------------------------------------------------- Summary : Stack local accessed through FP before frame allocated Fixed in : 6.2.0 Severity : S2 - Major Affected Component : Code Generator Release Notes: The frame pointer is no longer accessed before the stack frame is allocated. Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00047070 ------------------------------------------------------------------------------- Summary : INTERNAL ERROR: Illegal use of intrinsic: __f32toi16r Fixed in : 6.2.0 Severity : S2 - Major Affected Component : Code Generator Release Notes: Compiler generates: "INTERNAL ERROR: Illegal use of intrinsic: __f32toi16r" Compiler will now accept the __f32toi16r intrinsic in a return statement. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00047076 ------------------------------------------------------------------------------- Summary : Complicated expressions involving __tbit intrinsic may be computed incorrectly Fixed in : 6.2.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The __tbit intrinsic is very limited in the context in which it can appear in source code. The __tbit intrinsic can only appear in the condition of an if (see spru514d.pdf). This compiler no longer produces incorrect code while attempting to maintain this requirement. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00049407 ------------------------------------------------------------------------------- Summary : FAILURE in optimizer on local static variables with --opt_level=4 Fixed in : 6.2.0 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00049409 Release Notes: In rare cases, the optimizer may emit a spurious diagnostic message which says "FAILURE in mark_use_of_function_local_static." This message includes some symbol names, the first of which will be partially garbled. This message does not affect the generated code, so it may be ignored. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.6, 6.2.0B1 - 6.2.0B1 Workaround: Ignore the message "FAILURE in mark_use_of_function_local_static." =============================================================================== 11. Defects fixed in C2000 Code Generation Tools release 6.2.0B1 =============================================================================== The following 50 defects were fixed in C2000 Code Generation Tools release 6.2.0B1, released April 2013. ------------------------------------------------------------------------------- FIXED SDSCM00008276 ------------------------------------------------------------------------------- Summary : Linker accepts illegal address ranges and truncates to a valid address Fixed in : 6.2.0B1 Severity : S3 - Minor Affected Component : Linker Release Notes: The linker will now generate an out of range error: "./test.cmd", line 4: error: integer constant does not fit within 32-bits: "0x123456789" error: errors encountered during linking; "test.out" not built Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00034341 ------------------------------------------------------------------------------- Summary : __byte Intrinsic usage giving internal error Fixed in : 6.2.0B1 Severity : S3 - Minor Affected Component : Code Generator Release Notes: Assigning the result of the __byte intrinsic to a local variable: i2 = __byte((int *)&i1,0); where 'i2' is a local, can cause a codegen crash. This can occur if there is no subsequent use or access of the result ('i2' in the example). Workaround: Create an access if the result of the byte intrinsic: int a_global_var; ... i2 = __byte((int *)&i1,0); a_global_var = i2; or make i2 volatile: volatile int i2; i2 = __byte((int *)&i1,0); ------------------------------------------------------------------------------- FIXED SDSCM00040282 ------------------------------------------------------------------------------- Summary : Triangular loop nest may cause optimizer crash Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: A loop nest like for (i = 0; i < 7; i++) for (j = 0; j <= i; j++) x += k; where the inner loop's trip count depends on the outer loop's iteration (this is called a triangular loop nest) and the inner loop's body contains an increment of a variable that isn't a loop index, may cause the compiler to crash. Workaround: Compile at -o1 or -o0, or add "#pragma UNROLL(1)" to the outer loop. Other unroll factors may also avoid the problem. ------------------------------------------------------------------------------- FIXED SDSCM00041434 ------------------------------------------------------------------------------- Summary : Compiler optimizes away certain calls to assert() Fixed in : 6.2.0B1 Severity : S3 - Minor Affected Component : Absolute Lister Release Notes: Certain assert() statements, most notably "assert(x&1)" and the equivalent "assert(x%2==0)", may be removed by the compiler and thus will not do the run-time condition check that is desired. Defect occurs in C2000 Compiler versions: 4.1.0B1 - 4.1.4, 4.3.0B1 - 4.3.0, 5.2.0B1 - 5.2.12, 6.0.0B1 - 6.0.3, 6.1.0B1 - 6.1.0 Workaround: Instead of "assert(p)", use "if (!p) assert(0)", which will still abort at the same place under the same conditions, but will have a different error message. More elaborately, implement a function equivalent to assert() but with a different name, that the compiler will not recognise as a system function. ------------------------------------------------------------------------------- FIXED SDSCM00041971 ------------------------------------------------------------------------------- Summary : Spurious remark generated from __STDC_VERSION__ ref in stddef.h in C++ mode Fixed in : 6.2.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: #include int main(void) { return 2; } Then compile with the following flags: cl6x a.cpp -pdv -pdr include/stddef.h", line 87: remark #195-D: zero used for undefined preprocessing identifier (__STDC_VERSION__ >= 199901L || !__TI_STRICT_ANSI_MODE__) This happens because __STDC_VERSION__ is not defined in C++ mode Workaround: Use the -pds=195 switch to avoid the remark. ------------------------------------------------------------------------------- FIXED SDSCM00042332 ------------------------------------------------------------------------------- Summary : Don't generate typeinfo when not used Fixed in : 6.2.0B1 Severity : S3 - Minor Affected Component : Code Generator Release Notes: The C++ type info is generated under EABI whenever the virtual function table is created as per the IA64 C++ ABI requirement. However, the typeinfo is not used if RTTI or C++ exceptions are not used. Hence it is a good candidate to place in slow external memory. However, they are presently generated under .const section and hence it is difficult to selectively group and place them. The proposal is to place the typeinfo under the .const:.typeinfo subsection to enable easier placement. For all targets except C2000's large data mode, typeinfo will now be placed in .const:.typeinfo, whereas C2000's large data mode will place it into .econst:.typeinfo. This behavior will be default in all future releases, but branch patches must provide the --typeinfo_subsections option in the shell to activate this placement change. This is because cache behavior could potentially be affected by changing the placement of the type information. To take advantage of this feature, the linker command file must detail the placement for the typeinfo subsection, most often times placing it into slow external memory to make room for more important data in faster memory. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00042439 ------------------------------------------------------------------------------- Summary : INTERNAL ERROR: no match for ASG Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: A __byte() intrinsic returning a long long caused the INTERNAL ERROR. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00042444 ------------------------------------------------------------------------------- Summary : Expression that multiplies two constants incorrectly triggers MISRA rule 10.1 about implicit conversion Fixed in : 6.2.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The expression ... var_int16 = 4 * 256; contains no implicit conversions. However, MISRA rule 10.1 about no implicit conversions is still emitted for that expression. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00042600 ------------------------------------------------------------------------------- Summary : Ill advised enum scalar usage gets MISRA diagnostic, but similar usage of enum array does not Fixed in : 6.2.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: 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. For example: typedef unsigned int uint16_t; uint16_t Func(void); typedef enum Error { OK, NO_DATA, BUFFER_FULL } Error_t; const Error_t errors[2] = {OK, OK}; uint16_t Func(void) { uint16_t myError; myError = OK; /* correctly flags as error (MISRA 10.1) */ myError = errors[0]; /* does not find error */ return myError; } Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00042691 ------------------------------------------------------------------------------- Summary : __swapf() intrinsic failure for -o1 and higher Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The __swapf intrinsic, and possibly other intrinsics that both read and write their arguments, will compile incorrectly with optimization if a memory reference (ie, not a simple variable) is used as argument. Defect occurs in C2000 Compiler versions: 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.11, 6.0.0B1 - 6.0.2, 6.1.0B1 Workaround: Don't use optimization. Possibly use scalar temps as arguments to __swapf ------------------------------------------------------------------------------- FIXED SDSCM00042811 ------------------------------------------------------------------------------- Summary : printf("%d") with negative values incorrect for printf_support=minimal Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: printf("%d") is treated as printf("%u") for --printf_support=minimal, which means negative values will be printed incorrectly. Defect occurs in C2000 Compiler versions: 6.1.0B1 Workaround: Use printf_support=nofloat ------------------------------------------------------------------------------- FIXED SDSCM00042837 ------------------------------------------------------------------------------- Summary : Some FPU instructions are not disassembled correctly Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Disassembler (dis) Release Notes: Fixed an error where the instructions A_F32TOI32 and I32TOF32 were incorrectly marked as being compatible with --float_support=fpu64 and not both fpu64 and fpu32. Defect occurs in C2000 Compiler versions: 5.0.0 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.11, 6.0.2, 6.1.0B2 - 6.1.0B1 Workaround: The instructions are not correctly marked as being valid for fpu32 mode, so the only way to access them is to use fpu64 mode. ------------------------------------------------------------------------------- FIXED SDSCM00042948 ------------------------------------------------------------------------------- Summary : Writing to wrong memory location Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: XAR5 does not get initialized before use. Value written to wrong memory location. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00043062 ------------------------------------------------------------------------------- Summary : Structure in .cdecls which contains bit fields does not match layout of C compiler Fixed in : 6.2.0B1 Severity : S3 - Minor Affected Component : Assembler Release Notes: Extra padding was incorrectly generated due to not keeping track of the bit offset properly for bitfields Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00043174 ------------------------------------------------------------------------------- Summary : Linker fails to honor specific placement for function from RTS library Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : COFF Linker Release Notes: Linker now honors section placement specification. Workaround: Do not include libc.a option. ------------------------------------------------------------------------------- FIXED SDSCM00043197 ------------------------------------------------------------------------------- Summary : Compiler may not issue DP loads in some cases when compiling using -o4 Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: When compiling at -o4 the compiler does not set the blocking flag when defining C/C++ data. As a result, the compiler may not issue the required DP loads if the data for a particular file is allocated across a page boundary. The conditions where this can happen are: 1. Compiling using the -o4 option 2. All the data variables defined in a C/C++ file are 16-bit scalars. If any data defined in the file is larger than 16-bits or is an aggregate type (struct/class, union, or array) then no issue. 3. The data for that file is allocated across a page boundary 4. Data accesses from the code in that file references data on both sides of the page boundary in a sequence. Defect occurs in C2000 Compiler versions: 6.1.0B1 - 6.1.0 Workaround: Avoid the triggering conditions (see release notes) ------------------------------------------------------------------------------- FIXED SDSCM00043223 ------------------------------------------------------------------------------- Summary : Compiler may miss alias given struct-of-array-of-structs Fixed in : 6.2.0B1 Severity : S1 - Critical / PS Affected Component : C/C++ Compiler (cl) Release Notes: In a particular situation involving a struct containing an array of structs, the compiler may miss an alias between a read and write of a scalar field in the nested struct. Defect occurs in C2000 Compiler versions: 6.0.0B1 - 6.0.2, 6.1.0B1 Workaround: In this case, save pointer-written-to-struct in a temp and dereference from the temp instead of re-reading from struct. In general, compile at -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00043325 ------------------------------------------------------------------------------- Summary : Complier is incorrectly calculating RPTB block size and generating assembler error "Block size out of range" Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Compiler incorrectly calculates RPTB block size and generates assembler error "Block size out of range". When building with: cl2000 -mn -o3 -v28 -ml --float_support=fpu32, the following error is generated: [E0200] Block size out of range RPTB $C$L2,#2 1 Assembly Error, No Assembly Warnings Workaround: Use -o2 instead of -o3 or add the --disable:opt_banz_to_rptb option along with -o3 ------------------------------------------------------------------------------- FIXED SDSCM00043326 ------------------------------------------------------------------------------- Summary : Extremely long (templated) type names may overflow buffer, causing crash Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: The optimizer may crash when it encounters an extremely long type name -- for example, a deep nested templated C++ class name -- while creating a printed representation. The crash is most likely, and perhaps only occurs, with -o2 or -o3. Defect occurs in C2000 Compiler versions: 3.08 - 3.13, 4.1.0B1 - 4.1.4, 4.3.0B1 - 4.3.0, 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.11, 6.0.0B1 - 6.0.2, 6.1.0B1 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00043705 ------------------------------------------------------------------------------- Summary : Novel Test failure N1204B03.cpp, N1204B26.cpp Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: If a function is called twice, and in one call an argument is a constant (integer literal, for example) and in another call the same argument is a static local variable, the compiler may erroneously arrange to pass the constant on both calls, ignoring the actual value of the variable. Defect occurs in C2000 Compiler versions: 5.1.6, 5.2.5 - 5.2.12, 6.0.0B1 - 6.0.3, 6.1.0B1 - 6.1.0 Workaround: Don't use static-local variables in arguments to function calls. ------------------------------------------------------------------------------- FIXED SDSCM00043713 ------------------------------------------------------------------------------- Summary : Linker fails with internal error Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Linker Duplicate Defects : SDSCM00043752 Release Notes: Linker sometimes fails with internal error: lnk.exe experienced an unhandled exception The linker no longer makes the assumption that the decompression routine's section can be automatically removed when the linker determines the decompression routine is not needed. Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00043807 ------------------------------------------------------------------------------- Summary : Register initialization lost during instruction predication Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: When converting control flow to predicated instructions, in rare cases the compiler could mistakenly discard some instructions which were unpredicatable or were already predicated. This will cause the generated code to work incorrectly in unpredictable ways. Defect occurs in C2000 Compiler versions: 6.1.0B1 - 6.1.0 Workaround: No practical workaround ------------------------------------------------------------------------------- FIXED SDSCM00043868 ------------------------------------------------------------------------------- Summary : Linker cannot find include file specified with relative path Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Linker Release Notes: The linker properly resets the source path after processing an #include. Workaround: This bug occurs because the linker does not properly reset the source path after processing an #include, causing a second #include to be relative to the wrong path. Any intervening token between the two #include directive will overcome this, as will any macro expansion (even if empty). For example: #define SPACE #include "../first.cmd" SPACE #include "../second.cmd" ------------------------------------------------------------------------------- FIXED SDSCM00043996 ------------------------------------------------------------------------------- Summary : Linker changes EALLOW instruction to ITRAP 0 instruction, which encodes as all 0's Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Assembler Release Notes: The assembler was not emitting a correct relocation entry for a 22-bit complex relocation expression. If the instruction containing the relocation entry was at the end of the section the linker will either generate read errors or overwrite the next instruction word that followed in the allocation. This issue will occur for any instruction that can take a 22-bit relocatable expression (such as FFC, LB,LC, LCR, MOVL XARx) and is at the end of an input section, and the operand is a complex relocatable expression (an expression that references multiple relocatable symbols) Defect occurs in C2000 Compiler versions: 6.0.0B1 - 6.0.3, 6.1.0B1 - 6.1.0 Workaround: The assembler is not correctly emitting the relocation entry for a 22-bit complex relocation expression if it appears in the last instruction in an input section. In this example it is not correctly handing the complex relocation expression used in the instruction: 'LB #STACK_START + _FlashBoot_SetTiming - FlashBootFunc_LoadStart' which is found in the testcase in FlashBoot.asm (the last instruction of the assembly function Copy_Configure_Flash). At linktime the first instruction in the next allocated function (ExecTime_Init in the test case) gets corrupted. In this case the EALLOW instruction is zeroed out resulting in an ITRAP. One workaround would be to add a nop after the 'BL' instruction in the assembly file so that the it is not the last instruction in the section. Another alternative is to define a linker symbol in one of the linker command files (such as FlashBoot_Memory.cmd) using that expression. Then replace the expression in the .asm file with the symbol. For example: In Flashboot_Memory.cmd add the line: FlashBoot_Offset = STACK_START + _FlashBoot_SetTiming - FlashBootFunc_LoadStart; Then use this symbol FlashBoot_Offset in the LB instruction in FlashBoot.asm: LB #FlashBoot_Offset There will be a linker warning: "FlashBoot_Memory.cmd", line 18: warning: section relative symbols from different output sections cannot be mixed; "FlashBootFunc_LoadStart" is in section ".FlashBoot_C_Function", "STACK_START" is in section ".stack" "FlashBoot_Memory.cmd", line 18: warning: section relative symbols from different output sections cannot be mixed; "_FlashBoot_SetTiming" is in section ".FlashBoot_C_Function", "STACK_START" is in section ".stack" that can be suppressed with --diag_suppress=10272 if desired. This issue will occur for any instruction that can take a 22-bit relocatable expression (such as FFC, LB,LC, LCR, MOVL XARx) and is at the end of an input section, and the operand is a complex relocatable expression (an expression that references multiple relocatable symbols). ------------------------------------------------------------------------------- FIXED SDSCM00044048 ------------------------------------------------------------------------------- Summary : Enabling vectorization produces incorrect code Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00045426 Release Notes: In certain cases, enabling vectorization could result in incorrect code being generated. Defect occurs in C2000 Compiler versions: 6.0.0B1 - 6.0.3, 6.1.0B1 - 6.1.0 Workaround: Disable vectorization or optimization. ------------------------------------------------------------------------------- FIXED SDSCM00044066 ------------------------------------------------------------------------------- Summary : opt470 experienced a segmentation fault Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: Corrected false assumption made while performing an optimization. Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00044216 ------------------------------------------------------------------------------- Summary : Link time optimization produces error about option --optimize_with_debug missing its argument Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: An optional parameter of on/off was added to the --optimize_with_debug option. During link time optimization (-o4), an internal tool incorrectly requires the option have a parameter, which it won't if the object file was built with an older tool chain. The bug has been fixed and the tool will accept the option with no parameter, which will be interpreted as --optimize_with_debug=on Defect occurs in C2000 Compiler versions: 6.1.0 Workaround: Recompile older object files with the newer compiler, or switch back to using the older compiler for all stages of the build. ------------------------------------------------------------------------------- FIXED SDSCM00044240 ------------------------------------------------------------------------------- Summary : C2000 RPT||MAC instruction generation introduces erroneous SUBB instruction Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The C2000 compiler may emit an erroneous SUBB instruction when RPT||MAC instructions (and variants) are generated for some codes. This might happen if one of the source operands is used again by another instruction. Workaround: If you see the incorrect instruction in the assembly/disassembly file, disable generation of RPT instructions with the -mi compiler flag. ------------------------------------------------------------------------------- FIXED SDSCM00044264 ------------------------------------------------------------------------------- Summary : Internal error on 0/(-DBL_MIN/2) Fixed in : 6.2.0B1 Severity : S3 - Minor Affected Component : Code Generator Release Notes: A constant expression of the form "0 / (-DBL_MIN / 2)" will cause the compiler to terminate with an internal error. In floating-point arithmetic, this is a well-formed expression. If denormal numbers are supported, the correct result is -0.0. Otherwise, the result is NaN, and the "invalid" floating point exception may be raised. Defect occurs in C2000 Compiler versions: 4.1.0B2 - 4.1.4, 4.3.0B1 - 4.3.0, 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.12, 6.0.0B1 - 6.0.3, 6.1.0B1 - 6.1.0 Workaround: Move at least one of the operands into a variable. ------------------------------------------------------------------------------- FIXED SDSCM00044285 ------------------------------------------------------------------------------- Summary : scanf %[^ mistakenly writes EOF to output Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: When using ^ to negate the scan set [ sscanf(in, "%[^abc]", out) ], scanf would incorrectly copy EOF to the output string. It should instead stop reading input and return as normal. Workaround: Negate the scan set manually; don't use the negation operator. ------------------------------------------------------------------------------- FIXED SDSCM00044393 ------------------------------------------------------------------------------- Summary : Linker silently ignores an output section placement spec with missing ">" in the SECTIONS directive Fixed in : 6.2.0B1 Severity : S3 - Minor Affected Component : Linker Release Notes: When previously parsing linker command files, the linker required the ">" to specify memory addresses for sections (i.e. sec1 > MEM1). The ">" operator is now optional as the documentation states it should be. Workaround: Don't omit the ">" in the linker command file. ------------------------------------------------------------------------------- FIXED SDSCM00044468 ------------------------------------------------------------------------------- Summary : The __norm32 intrinsic does not generate CSB instruction resulting in incorrect result Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The __norm32 intrinsic does not generate CSB instruction resulting in incorrect result. This issue also affects the __norm64() intrinsic. Issue was introduced in 6.1.0 release. Defect occurs in C2000 Compiler versions: 6.1.0 Workaround: Other than rewriting source to implement __norm32/64 functionality no available workarounds. ------------------------------------------------------------------------------- FIXED SDSCM00044472 ------------------------------------------------------------------------------- Summary : c2xlp_src_compatible causes error: label defined differently in each pass Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Assembler Release Notes: No Information Available; please see defect details. Workaround: To emulate the 'CC' instruction in C2xlp source compatible mode, the assembler will expand multiple conditions using SB and XCALL instructions. For the given example, 'CC dst,EQ,TC,NC' the assembler will assemble as: SB 4, NEQ SB 3, NTC XCALL dst,LO There is an assembler issue where the program counter bookkeeping does not calculate the expansion size correctly resulting in any label definition following the CC instruction to have different values as the assembler makes the 2nd pass during processing. A workaround would be to do the CC emulation by hand as shown above. This issue will be addressed in the next update for all active C2000 release branches. ------------------------------------------------------------------------------- FIXED SDSCM00044559 ------------------------------------------------------------------------------- Summary : Compiler incorrectly places MOV between MAX and MAXCUL which causes incorrect result Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: A MOV to the ACC register can no longer appear in between the MAXL and MAXCUL assembly instructions. The same holds true for the MINL and MINCUL assembly instructions. Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00044969 ------------------------------------------------------------------------------- Summary : CLA compiler does not allow initialization of constant variables Fixed in : 6.2.0B1 Severity : S3 - Minor Affected Component : Parser Release Notes: Updated the CLA compiler to allow initialized const data variables. Defect occurs in C2000 Compiler versions: 6.1.0 Workaround: Define the any const data from C28x code as is required for non-const data. ------------------------------------------------------------------------------- FIXED SDSCM00045105 ------------------------------------------------------------------------------- Summary : Empty struct as field of parent struct may cause optimizer abort Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: If a struct contains another struct, and the inner struct has no fields, and the parent struct is copied whole through an assignment of struct-type variables, the optimizer may abort. Defect occurs in C2000 Compiler versions: 5.2.12, 6.0.2 - 6.0.3, 6.1.0B1 - 6.1.0 Workaround: Add a dummy field to the empty struct. ------------------------------------------------------------------------------- FIXED SDSCM00045141 ------------------------------------------------------------------------------- Summary : C2000 generates incorrect code for __norm64() when compiling with optimization Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: When compiling with optimization the compiler will not return the correct shift value for the __norm() 64 intrinsic. It will return the correct normalized value however. Defect occurs in C2000 Compiler versions: 6.0.0B1 - 6.0.3, 6.1.0B1 - 6.1.0 Workaround: When compiling with optimization the compiler will not return the correct shift value for the __norm() 64 intrinsic. It will return the correct normalized value. No available workarounds. ------------------------------------------------------------------------------- FIXED SDSCM00045170 ------------------------------------------------------------------------------- Summary : C2000 disassembler does not decode XCALL instruction when file is compiled with --c2xlp_src_compatible Fixed in : 6.2.0B1 Severity : S3 - Minor Affected Component : Disassembler (dis) Release Notes: For object files compiled with --c2xlp_src_compatible and NOT compiled for FPU support, the disassembler doesn't decode C28x-only instructions (such as XCALL). Defect occurs in C2000 Compiler versions: 6.0.0B1 - 6.0.3, 6.1.0B1 - 6.1.0 Workaround: No available workaround other than compiling with FPU support turned on ------------------------------------------------------------------------------- FIXED SDSCM00045200 ------------------------------------------------------------------------------- Summary : C2000 register allocation failure with unsigned int array index variable also used as multiply operand. Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: The following code fails register allocation with options "-v28 -ml" and either -o0 or -o1 options. It fails when the index variable is an unsigned int. input and r may be signed or unsigned. int * input; int r; unsigned int i; for (i=0; i < n; i++) r = input[i] * i; Defect occurs in C2000 Compiler versions: 6.1.0 Workaround: Compile with -o2 or above, or optimizer off. ------------------------------------------------------------------------------- FIXED SDSCM00045211 ------------------------------------------------------------------------------- Summary : Linker GROUP directive fails to allow NOINIT output sections and regular output sections to be together in the group Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Linker Release Notes: An output section that includes NOINIT sections and regular sections is not allowed. The code to detect this error did not properly account for GROUPS, which can contain a mix of section types. However, this bug would only occur if a GROUP was declared to be type NOINIT in the linker command file. The type keyword should not be applied to GROUPs, as documented in SDSCM00032000, and this syntax will be disallowed when SDSCM00032000 is fixed. Defect occurs in C2000 Compiler versions: 6.1.0B1 - 6.1.2 Workaround: None. However, the type keyword should not be applied to GROUPs. ------------------------------------------------------------------------------- FIXED SDSCM00045302 ------------------------------------------------------------------------------- Summary : Result of integer division incorrect in some cases Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: The result of integer division is incorrect in some cases. The exact cases are not known at this time, but the bug can happen without optimization turned on. Here is a cutdown which more clearly shows the invalid operation, without optimization. /* cl2000 -v28 cutdown.c -z -l lnk.cmd && load2000 -q a.out */ #include short func(register long num, register long den) { den = (unsigned long)num / (unsigned long)den; return den; } int main (void) { short result = func(303996000, 11778); printf ("Correct answer is 25810, got %d\n", result); } Workaround: No guaranteed workaround at this time. However, it is likely that the following steps will avoid the problem: 1. Use a dedicated local integer variable for the result of the division. This step alone is likely sufficient. 2. Remove any use of the register keyword associated with the integer division operands. 3. Compile the code without optimization. This bug appears in all available versions of the C2000 compiler. ------------------------------------------------------------------------------- FIXED SDSCM00045587 ------------------------------------------------------------------------------- Summary : FPU Pipeline Issue Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Scenario 1 - Treat some 2p FPU instructions as 3p if followed by memory mapped read Updated the compiler to add a cycle latency between ADDF32/SUBF32/MPYF32/MACF32 instructions and a CPU memory mapped FPU read if the destination FPU register is the one being read by the memory mapped read (eg. MOV32 ACC,R4H - where R4h is read using it's memory mapped address). All active versions of the compiler have been updated. Updated the 6.2.0 assembler to detect this condition and report an error. The 6.0.x and 6.1.x branches of the assembler were not updated to detect this issue as it requires large infrastructure changes that are not typically put on release branches. ---------------------- Scenario 2 - The memory mapped write to an FPU register should be treated as a 6p instruction if followed by any of the FPU instructions: FRACF32, UI16TOF32, F32TOUI32. Does not require dependency between between the 2 instructions (ie different FPU registers involved). The compiler was already instrumented to avoid this scenario so no changes were required. All active releases of the assembler were updated to detect this problem sequence and report an error. Defect occurs in C2000 Compiler versions: 6.0.0 - 6.0.4, 6.1.0B1 - 6.1.1 Workaround: None available since tools need to be updated to handle these exceptions. ------------------------------------------------------------------------------- FIXED SDSCM00045911 ------------------------------------------------------------------------------- Summary : Assertion failure on BF that branches too far should be error message Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Assembler Release Notes: Fast branches with offsets greater than 16 bits are now converted to long branches. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00045920 ------------------------------------------------------------------------------- Summary : C2000 compiler generated code giving RPTB size error from assembler Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Compiler generated code is causing a "Block size out of range" assembler error for RPTB instruction. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00046092 ------------------------------------------------------------------------------- Summary : Constant expressions not rounded correctly for some values Fixed in : 6.2.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The TI compiler supports only IEEE "round to even" mode. The compiler folds constant expressions using the FPSIM package. When rounding "exactly halfway" values, the constant folder rounded toward infinity rather than "round to even". This means that for some values, the value should be rounded *down* to the nearest even number, not up to an odd one. This is very unlikely to cause a problem for most programs; the symptom would be that the very last bit would be incorrect, which is a very, very small error. Defect occurs in C2000 Compiler versions: 4.1.0B2 - 4.1.4, 4.3.0B1 - 4.3.0, 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.12, 6.0.0B1 - 6.0.4, 6.1.0B1 - 6.1.1 Workaround: If maximum precision is required, avoid the use of constant float expressions; place each operand in a variable. The problem can also occur if the optimizer can determine the exact value of the operands. If using the optimizer, put at least one operand in a volatile variable. ------------------------------------------------------------------------------- FIXED SDSCM00046239 ------------------------------------------------------------------------------- Summary : Linker mishandles blocking for sections placed with the HIGH directive Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Linker Release Notes: The linker did not correctly block a particular section which has the HIGH directive in the linker command file. This led to a global object straddling a page boundary, which violates an assumption used by the compiler to achieve DP optimization. Defect occurs in C2000 Compiler versions: 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.13, 6.0.0B1 - 6.0.4, 6.1.0B1 - 6.1.1 Workaround: 1) Don't use the HIGH directive, or 2) align all sections with the HIGH directive to the blocking factor (64) ------------------------------------------------------------------------------- FIXED SDSCM00046265 ------------------------------------------------------------------------------- Summary : No match for ICALL with intrinsic __mf32toi16r Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: The __mf32toi16r() and __mf32toui16r intrinsics were incorrectly implemented resulting in internal errors when used. The intrinsic implementations were corrected and coverage tests added. Defect occurs in C2000 Compiler versions: 6.1.1 Workaround: No available workaround. ------------------------------------------------------------------------------- FIXED SDSCM00046356 ------------------------------------------------------------------------------- Summary : C2000 RPT MAC/IMACL/QMACL failures in small memory model Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: There is a bug in the compilation process that generates RPT || MAC, RPT ||IMACL, and RPT || QMACL for small memory model. The correct assembly sequence is not generated, leaving an intermediary instruction in the assembly file that then causes an assembler error. This error does not occur in large memory model (-ml). Workaround: Download a patched release or use the --no_rpt/-mi compiler option to prevent repeat instructions. ------------------------------------------------------------------------------- FIXED SDSCM00046400 ------------------------------------------------------------------------------- Summary : op-assign of float expression to bit-field results in corrupted code Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: A bit-field may be assigned to with an op-assign (e.g. +=) operator. If the left hand side of the operator is a bit-field and right hand side is an expression with floating-point type, the compiler will in some cases write a corrupted value to the bit-field. Defect occurs in C2000 Compiler versions: 4.1.0B1 - 4.1.4, 4.3.0B1 - 4.3.0, 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.13, 6.0.0B1 - 6.0.5, 6.1.0B1 - 6.1.2 Workaround: Assign the value of the floating-point expression into a local integer variable and assign the local variable to the bit-field. ------------------------------------------------------------------------------- FIXED SDSCM00046689 ------------------------------------------------------------------------------- Summary : cg2000 segmentation fault when using -s Fixed in : 6.2.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: In rare and not easily predictable cases, the compiler will confuse a long embedded comment as a real instruction and attempt to process it, resulting in a segmentation fault. The trigger is the exact number of characters in the comment; a comment of a length exactly equal to one of a small set of lengths between approximately 100 and approximately 1000 will trigger the bug. In this case, the compiler is crashing on an optimizer interlisting comment with length 698. The optimizer can create very long comments in some cases, due to extensive optimization. Workaround: Remove the option -s to disable interlisting and avoid using asm() statements. =============================================================================== 12. Current Known Issues =============================================================================== The following 29 known issues exist for C2000 Code Generation Tools release 6.2.9 as of September 2014. ------------------------------------------------------------------------------- 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 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 SDSCM00012183 ------------------------------------------------------------------------------- Summary : Integer to pointer conversion doesn't truncate values Affected Component : Code Generator Description: I expect an expression involving a cast from integer to pointer type, where it is a narrowing conversion, to truncate the value of the integer to fit the pointer type. However, this doesn't seem to be happening for C28x in word mode. Conversion from integer to pointer is implementation-defined, but it works as I expect on the other targets. Possibly related is that fact that trg_alloc_offset() returns 0, but it should return 10 (bits) for C28x large model pointers. ------------------------------------------------------------------------------- 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 SDSCM00042600 ------------------------------------------------------------------------------- Summary : Ill advised enum scalar usage gets MISRA diagnostic, but similar usage of enum array does not Affected Component : C/C++ Compiler (cl) 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 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 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 SDSCM00050582 ------------------------------------------------------------------------------- Summary : Determine the best way to share data between C28x .c files and .cla files Affected Component : C/C++ Compiler (cl) Description: When data is defined in a .cla file, blocking is not used. If that data is referenced in a .c file by the C28x, the compiler issues instructions which presume the data is blocked. Since the data is not blocked, this can result in accessing incorrect memory locations. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050807 ------------------------------------------------------------------------------- Summary : Constant expression which fits in 32-bits still gets compiler diagnostic about "does not fit" Affected Component : C/C++ Compiler (cl) Description: The source line ... long val = (long)((8192.0*262144)-1); gets the diagnostic ... "file.c", line 1: error: floating-point value does not fit in required integral type However that value is 0x7fffffff, which fits in a 32-bit signed type. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050815 ------------------------------------------------------------------------------- Summary : MISRA rule 10.3, about casting the result of a integer expression, is inconsistently applied Affected Component : Parser Description: This code contains two nearly identical integer expressions. ================================= #include void Test1(const int16_t *test_in, int16_t *test_out, int16_t another_in) { *test_out = (int16_t)(((int32_t)(*test_in) * (int32_t)another_in) / (int32_t)32768L); // 10.3 diagnostic } void Test2(int16_t test_in, int16_t *test_out, int16_t another_in) { *test_out = (int16_t)(((int32_t)(test_in) * (int32_t)another_in) / (int32_t)32768L); // no diagnostic } =================================== One expression gets a MISRA diagnostic for rule 10.3, and other does not. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050821 ------------------------------------------------------------------------------- Summary : Compiler falsely reports MISRA error 17.6 Affected Component : C/C++ Compiler (cl) Description: For this code ... void Test1(const int16_t *input) { global_var = *input; // Sees misra 17.6 violation } The compiler generates the incorrect MISRA diagnostic ... "file.c", line 7: warning: (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 ("input") However, no addresses are being assigned.