C2000 C/C++ CODE GENERATION TOOLS 6.1.8 May 2014 Defect History ------------------------------------------------------------------------------- Table of Contents ------------------------------------------------------------------------------- 1. Defects fixed in C2000 Code Generation Tools release 6.1.8 2. Defects fixed in C2000 Code Generation Tools release 6.1.7 3. Defects fixed in C2000 Code Generation Tools release 6.1.6 4. Defects fixed in C2000 Code Generation Tools release 6.1.5 5. Defects fixed in C2000 Code Generation Tools release 6.1.4 6. Defects fixed in C2000 Code Generation Tools release 6.1.3 7. Defects fixed in C2000 Code Generation Tools release 6.1.2 8. Defects fixed in C2000 Code Generation Tools release 6.1.1 9. Defects fixed in C2000 Code Generation Tools release 6.1.0 10. Defects fixed in C2000 Code Generation Tools release 6.1.0B1 11. Current Known Issues =============================================================================== 1. Defects fixed in C2000 Code Generation Tools release 6.1.8 =============================================================================== The following 7 defects were fixed in C2000 Code Generation Tools release 6.1.8, released May 2014. ------------------------------------------------------------------------------- FIXED SDSCM00049707 ------------------------------------------------------------------------------- Summary : SUBL + IMPYL incorrectly turned into IMPYSL Fixed in : 6.1.8 Severity : S2 - Major Affected Component : Code Generator Release Notes: The compiler is over-aggressive when trying to combine SUBL and IMPYL into IMPYSL. Depending on the registers used, it may not be legal to combine them. That is, the result may be different. Defect occurs in C2000 Compiler versions: 6.1.3 - 6.1.7 Workaround: Make one of the terms in the expression a volatile variable. ------------------------------------------------------------------------------- FIXED SDSCM00049775 ------------------------------------------------------------------------------- Summary : No longer expose the option --float_support=fpu64 Fixed in : 6.1.8 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 SDSCM00049942 ------------------------------------------------------------------------------- Summary : Combination of __byte and optimization cause compiler to emit internal error message Fixed in : 6.1.8 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.1.8 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.1.8 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.1.8 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 SDSCM00050202 ------------------------------------------------------------------------------- Summary : MISRA-C rule 19.11 false positive Fixed in : 6.1.8 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") =============================================================================== 2. Defects fixed in C2000 Code Generation Tools release 6.1.7 =============================================================================== The following 11 defects were fixed in C2000 Code Generation Tools release 6.1.7, released March 2014. ------------------------------------------------------------------------------- FIXED SDSCM00045417 ------------------------------------------------------------------------------- Summary : bool and _Bool are not defined correctly in strict ANSI C mode Fixed in : 6.1.7 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 SDSCM00047666 ------------------------------------------------------------------------------- Summary : Definition of SIZE_MAX is wrong Fixed in : 6.1.7 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 SDSCM00048440 ------------------------------------------------------------------------------- Summary : SIGSEGV when using MISRA checks on code with an anonymous struct Fixed in : 6.1.7 Severity : S2 - Major Affected Component : Parser 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 SDSCM00048498 ------------------------------------------------------------------------------- Summary : MISRA-C rule 12.8 incorrectly reported for an expression like ((uint32_t)2U << 8U); Fixed in : 6.1.7 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 SDSCM00048712 ------------------------------------------------------------------------------- Summary : ARM assembler seg faults on certain input Fixed in : 6.1.7 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 SDSCM00049149 ------------------------------------------------------------------------------- Summary : AND loc16, #16bitSigned instruction with incorrect constant 0 Fixed in : 6.1.7 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.1.7 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.1.7 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) 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 SDSCM00049407 ------------------------------------------------------------------------------- Summary : FAILURE in optimizer on local static variables with --opt_level=4 Fixed in : 6.1.7 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." ------------------------------------------------------------------------------- FIXED SDSCM00049509 ------------------------------------------------------------------------------- Summary : SET_DATA_SECTION does not work if issued from within a _Pragma operator Fixed in : 6.1.7 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The test case attached has these lines ... #define PRAGMA(x) _Pragma(#x) PRAGMA(SET_DATA_SECTION("dsname")) This code compiles fine with several other TI compilers. However, for the C6000 compiler, this results in ... "file.c", line 5: error: this pragma cannot be used in a _Pragma operator (a #pragma directive must be used) "file.c", line 5: error: expected a "(" "file.c", line 5: error: expected a ")" Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00049568 ------------------------------------------------------------------------------- Summary : CLA compiler incorrectly converts floating point expression to unsigned type, instead of a signed type Fixed in : 6.1.7 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 =============================================================================== 3. Defects fixed in C2000 Code Generation Tools release 6.1.6 =============================================================================== The following 11 defects were fixed in C2000 Code Generation Tools release 6.1.6, released December 2013. ------------------------------------------------------------------------------- FIXED SDSCM00037672 ------------------------------------------------------------------------------- Summary : GCC cast-to-union wrongly rejected in initialization constant Fixed in : 6.1.6 Severity : S2 - Major Affected Component : Parser Release Notes: union u { int i; int *p; }; struct s { int n; union u a; } v = {1, (union u) 2 }; Initialization will be flagged with "cast to type "union u" is not allowed". In GCC compatibility mode the cast should be allowed. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00043860 ------------------------------------------------------------------------------- Summary : Printf format %#06x prints zeros in the wrong place Fixed in : 6.1.6 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.1.6 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 SDSCM00046180 ------------------------------------------------------------------------------- Summary : MISRA check 14.1 should not treat while(0) as potential infinte loop Fixed in : 6.1.6 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 SDSCM00047220 ------------------------------------------------------------------------------- Summary : Unsigned 32-bit and 64-bit comparisons may be performed incorrectly Fixed in : 6.1.6 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 SDSCM00047510 ------------------------------------------------------------------------------- Summary : (short)labs(x) incorrectly transformed to abs((short)x) Fixed in : 6.1.6 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.1.6 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 SDSCM00047792 ------------------------------------------------------------------------------- Summary : Multiple .cdecls instances sharing header files cause assembler error "struct/union/enum tag can't be global" Fixed in : 6.1.6 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.1.6 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. ------------------------------------------------------------------------------- FIXED SDSCM00048289 ------------------------------------------------------------------------------- Summary : Errors of the linker due to the difference in version of CGT Fixed in : 6.1.6 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 SDSCM00048747 ------------------------------------------------------------------------------- Summary : Using END(sym_name) or SIZE(sym_name) on .cinit can cause link to fail Fixed in : 6.1.6 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. =============================================================================== 4. Defects fixed in C2000 Code Generation Tools release 6.1.5 =============================================================================== The following 5 defects were fixed in C2000 Code Generation Tools release 6.1.5, released August 2013. ------------------------------------------------------------------------------- FIXED SDSCM00013456 ------------------------------------------------------------------------------- Summary : fgets in _IONBF mode does not respect size limit Fixed in : 6.1.5 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 SDSCM00042344 ------------------------------------------------------------------------------- Summary : Compiler generates internal error: illegal initialization or segmentation fault Fixed in : 6.1.5 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Compiler sometimes generates internal error: illegal initialization or segmentation fault when using gcc extension nested designed initializers. Workaround: The seg fault can be worked around if the nested designated initializer is removed: static struct cfg config[] = { // the first definition makes the segmentation fault. Comment it and everything is fine. { .module_id = MODULE_1, .param_length = sizeof(struct module_1_params), .param = (struct module_1_params []){{1}} /* remove this designated initializer */ }, { .module_id = MODULE_2, .param_length = 5, .param = (int[]){0,1,2,3,4} }, { .module_id = MODULE_3, .param_length = 2, .param = (int[]){0,1} } }; ------------------------------------------------------------------------------- FIXED SDSCM00046991 ------------------------------------------------------------------------------- Summary : Stack local accessed through FP before frame allocated Fixed in : 6.1.5 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 SDSCM00047353 ------------------------------------------------------------------------------- Summary : C2000 Assembler emits erroneous error statement when CALL consumes required latency between ECN instruction sequence Fixed in : 6.1.5 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 SDSCM00047357 ------------------------------------------------------------------------------- Summary : C2000 potential error in MPYF32 ADDF32 sequence for compiler versions through 6.1.4 Fixed in : 6.1.5 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: When source code includes a floating point multiply accumulate (for example: for (i=0; i < N; i++) sum += a[i] * b[i]; where sum, a[i] and b[i] are floating point values) but the generated assembly does NOT contain a RPT MACF32, there can be a bug in the MPYF32 ADDF32 sequence of instructions. If the sum was allocated to the R2H or R3H register, one of the sources of the multiply might be loaded into the same register, stomping the accumulated value. This bug can only occur with compiler options --float_support=fpu32 and -mt. Workaround: The bug occurs because of the method that was used to generate RPT MACF32 instructions. Therefore, compiling with the --no_rpt flag if the problem is found to occur will prevent the bug. =============================================================================== 5. Defects fixed in C2000 Code Generation Tools release 6.1.4 =============================================================================== The following 11 defects were fixed in C2000 Code Generation Tools release 6.1.4, released May 2013. ------------------------------------------------------------------------------- FIXED SDSCM00042332 ------------------------------------------------------------------------------- Summary : Don't generate typeinfo when not used Fixed in : 6.1.4 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 SDSCM00045173 ------------------------------------------------------------------------------- Summary : Missing qsort and bsearch implementations for comparison functions with C++ linkage Fixed in : 6.1.4 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.1.4 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.1.4 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 SDSCM00046231 ------------------------------------------------------------------------------- Summary : DATA_ALIGN should not be able to reduce alignment below default array alignment Fixed in : 6.1.4 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 SDSCM00046812 ------------------------------------------------------------------------------- Summary : Instructions are placed in the wrong order Fixed in : 6.1.4 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.1.4 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.1.4 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.1.4 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 SDSCM00047070 ------------------------------------------------------------------------------- Summary : INTERNAL ERROR: Illegal use of intrinsic: __f32toi16r Fixed in : 6.1.4 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.1.4 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. =============================================================================== 6. Defects fixed in C2000 Code Generation Tools release 6.1.3 =============================================================================== The following 9 defects were fixed in C2000 Code Generation Tools release 6.1.3, released March 2013. ------------------------------------------------------------------------------- FIXED SDSCM00042444 ------------------------------------------------------------------------------- Summary : Expression that multiplies two constants incorrectly triggers MISRA rule 10.1 about implicit conversion Fixed in : 6.1.3 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.1.3 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 SDSCM00045211 ------------------------------------------------------------------------------- Summary : Linker GROUP directive fails to allow NOINIT output sections and regular output sections to be together in the group Fixed in : 6.1.3 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.1.3 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 SDSCM00045894 ------------------------------------------------------------------------------- Summary : Use of option -pdse195 causes an incorrect error to be generated Fixed in : 6.1.3 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: An issue where diagnostics resulting from the evaluation of unused preprocessor tokens has been fixed. This issue only arose when error #195 was escalated to warning or error. For example, when compiling the following code with the option -pdse195: #define MY_CONCAT_DEFINE 1 #define MY_CONCAT_MACRO(a, b) a##b #if (MY_CONCAT_MACRO(MY_,CONCAT_DEFINE) == 0) #error ("Define is zero") #endif int x; The compiler generates the following incorrect error message: "test.c", line 5: error: zero used for undefined preprocessing identifier #if (MY_CONCAT_MACRO(MY_,CONCAT_DEFINE) == 0) ^ "test.c", line 5: error: zero used for undefined preprocessing identifier #if (MY_CONCAT_MACRO(MY_,CONCAT_DEFINE) == 0) ^ 2 errors detected in the compilation of "test.c". >> Compilation failure 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.13, 6.0.0B1 - 6.0.5, 6.1.0B1 - 6.1.2 Workaround: Compiling without -pdse195 will remove the errors caused by this issue. Alternatively, consider -pdsw195 if the diagnostic should be seen but not bar the program from compiling. ------------------------------------------------------------------------------- FIXED SDSCM00046356 ------------------------------------------------------------------------------- Summary : C2000 RPT MAC/IMACL/QMACL failures in small memory model Fixed in : 6.1.3 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.1.3 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.1.3 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. ------------------------------------------------------------------------------- FIXED SDSCM00046696 ------------------------------------------------------------------------------- Summary : The Compiler does not reset the PM bits to the default value before leaving a function Fixed in : 6.1.3 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. =============================================================================== 7. Defects fixed in C2000 Code Generation Tools release 6.1.2 =============================================================================== The following 9 defects were fixed in C2000 Code Generation Tools release 6.1.2, released January 2013. ------------------------------------------------------------------------------- FIXED SDSCM00044240 ------------------------------------------------------------------------------- Summary : C2000 RPT||MAC instruction generation introduces erroneous SUBB instruction Fixed in : 6.1.2 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 SDSCM00044285 ------------------------------------------------------------------------------- Summary : scanf %[^ mistakenly writes EOF to output Fixed in : 6.1.2 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.1.2 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 SDSCM00045587 ------------------------------------------------------------------------------- Summary : FPU Pipeline Issue Fixed in : 6.1.2 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.1.2 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.1.2 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 SDSCM00046048 ------------------------------------------------------------------------------- Summary : Increment performed using XAR register yields incorrect results. Fixed in : 6.1.2 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: C or C++ code that uses an increment, such as astruct.afield[0]++, that generated code that was performed using the XAR register instead of the ACC register can lead to incorrect results. The increment to the ACC (not the XAR) register sets the status register. The main issue is that a 16-bit operation cannot be performed with a XAR register because the XAR register is modeled as a 32-bit register. There is no arithmetic operation available that allows the developer to only modify the lower 16-bits of an XAR register. As a result, the upper 16-bits of the XAR register will be zeroed out even when only the lower 16-bits are affected by the operation when the XAR register as the destination. This incorrectly models a truly 16-bit operation. Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00046239 ------------------------------------------------------------------------------- Summary : Linker mishandles blocking for sections placed with the HIGH directive Fixed in : 6.1.2 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.1.2 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. =============================================================================== 8. Defects fixed in C2000 Code Generation Tools release 6.1.1 =============================================================================== The following 24 defects were fixed in C2000 Code Generation Tools release 6.1.1, released September 2012. ------------------------------------------------------------------------------- FIXED SDSCM00034341 ------------------------------------------------------------------------------- Summary : __byte Intrinsic usage giving internal error Fixed in : 6.1.1 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 SDSCM00041434 ------------------------------------------------------------------------------- Summary : Compiler optimizes away certain calls to assert() Fixed in : 6.1.1 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 SDSCM00042948 ------------------------------------------------------------------------------- Summary : Writing to wrong memory location Fixed in : 6.1.1 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.1.1 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.1.1 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.1.1 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 SDSCM00043325 ------------------------------------------------------------------------------- Summary : Complier is incorrectly calculating RPTB block size and generating assembler error "Block size out of range" Fixed in : 6.1.1 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 SDSCM00043705 ------------------------------------------------------------------------------- Summary : Novel Test failure N1204B03.cpp, N1204B26.cpp Fixed in : 6.1.1 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.1.1 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.1.1 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.1.1 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.1.1 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.1.1 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.1.1 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.1.1 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 SDSCM00044468 ------------------------------------------------------------------------------- Summary : The __norm32 intrinsic does not generate CSB instruction resulting in incorrect result Fixed in : 6.1.1 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.1.1 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.1.1 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 SDSCM00044736 ------------------------------------------------------------------------------- Summary : Loop nest over two-dimensional array compiles wrong if inner loop has early exit Fixed in : 6.1.1 Severity : S2 - Major Affected Component : Optimizer Release Notes: A simple loop nest that iterates over a two-dimensional array, or at least a data structure with two indexed parts (eg, x[i].y[j]), may compile incorrectly if the inner loop has a conditional break. The compiler converts the indexing into increments, with a correction amount at the end of the inner loop, and the early exit causes the converted code to misbehave. The listed workaround avoids the transformation and thus avoids the bug. The solution in the compiler is to recognise the early break and skip the transformation. 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.12, 6.0.0B1 - 6.0.3, 6.1.0B1 - 6.1.0 Workaround: Changing "break" to "j = 8" -- exiting early by advancing the inner loop's variable rather than by nonlocal control flow -- will work around the problem. ------------------------------------------------------------------------------- FIXED SDSCM00044969 ------------------------------------------------------------------------------- Summary : CLA compiler does not allow initialization of constant variables Fixed in : 6.1.1 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.1.1 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.1.1 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.1.1 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.1.1 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. =============================================================================== 9. Defects fixed in C2000 Code Generation Tools release 6.1.0 =============================================================================== The following 9 defects were fixed in C2000 Code Generation Tools release 6.1.0, released March 2012. ------------------------------------------------------------------------------- FIXED SDSCM00008276 ------------------------------------------------------------------------------- Summary : Linker accepts illegal address ranges and truncates to a valid address Fixed in : 6.1.0 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 SDSCM00008691 ------------------------------------------------------------------------------- Summary : Compiler round floats different than runtime support library Fixed in : 6.1.0 Severity : S3 - Minor Affected Component : Parser Release Notes: If you look at float.h in C28x's RTS, you will see this line: #define FLT_ROUNDS 0 /* TRUNCATE TOWARDS ZERO */ This macro 'FLT_ROUNDS', when set to zero, means that the result of any floating point operation is rounded toward zero. However, the 'FPSIM' floating-point package that the parser, optimizer, and assembler use to do floating-point calculations rounds toward nearest. Thus, if the compiler performs any optimizations like constant-folding on floating point numbers, the user may get an unexpected result. Fixed started with C28x release 5.0.0. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00041971 ------------------------------------------------------------------------------- Summary : Spurious remark generated from __STDC_VERSION__ ref in stddef.h in C++ mode Fixed in : 6.1.0 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 SDSCM00042439 ------------------------------------------------------------------------------- Summary : INTERNAL ERROR: no match for ASG Fixed in : 6.1.0 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 SDSCM00042691 ------------------------------------------------------------------------------- Summary : __swapf() intrinsic failure for -o1 and higher Fixed in : 6.1.0 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.1.0 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.1.0 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 SDSCM00043223 ------------------------------------------------------------------------------- Summary : Compiler may miss alias given struct-of-array-of-structs Fixed in : 6.1.0 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 SDSCM00043326 ------------------------------------------------------------------------------- Summary : Extremely long (templated) type names may overflow buffer, causing crash Fixed in : 6.1.0 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. =============================================================================== 10. Defects fixed in C2000 Code Generation Tools release 6.1.0B1 =============================================================================== The following 56 defects were fixed in C2000 Code Generation Tools release 6.1.0B1, released January 2012. ------------------------------------------------------------------------------- FIXED SDSCM00031246 ------------------------------------------------------------------------------- Summary : Zero length Section allocation problem Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Linker Duplicate Defects : SDSCM00039877 Release Notes: A zero length output section in a linker command file that contains the dot expression . += 0x0 will cause a linker error: .trace: fill = 0x0 { _SYS_PUTCBEG = .; . += 0x0; _SYS_PUTCEND = . - 1; } > L1SARAM PAGE 1 placement fails for object ".trace", size 0x0 (page 1). Available ranges: L1SARAM size: 0x1000 unused: 0x22e max hole: 0x22c error: errors encountered during linking; Workaround: Comment out the . += 0x0 expression: .trace: fill = 0x0 { _SYS_PUTCBEG = .; /*. += 0x0;*/ _SYS_PUTCEND = . - 1; } > L1SARAM PAGE 1 ------------------------------------------------------------------------------- FIXED SDSCM00037170 ------------------------------------------------------------------------------- Summary : Embed does not handle cross-filesystem rename correctly Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : Embed Utility Release Notes: The embed utility needs to copy the file across file systems before renaming it. Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00037878 ------------------------------------------------------------------------------- Summary : Linker generates relocation errors for symbols already in bss Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Linker Release Notes: If a partially linked out file does not include any bss variables the linker will still create a "$bss" symbol with a value of 0. This ensures that if this code is linked with boot code the DP is set to some known value. However, if this partially llinked file is later linked with code that includes bss variables, the linker may set $bss to an incorrect value. This will lead to relocation errors during the final link. NOTE: Use of several .bss output sections is not support by the current linkers. The following will generate relocation errors: .bss:subsect1 { f1.out (.bss:subsect1) } .bss:subsect2 { f2.out (.bss:subsect2) } .bss { . += 0x2100; *(.bss) } The global symbol $bss needs to be defined to the start of the .bss section to perform the relocations. The above would have to be written as: bss { . += 0x2100; f1.out (.bss:subsect1) f2.out (.bss:subsect2) *(.bss) } Workaround: None available. ------------------------------------------------------------------------------- FIXED SDSCM00038766 ------------------------------------------------------------------------------- Summary : Optimizer loses side effect in "expr % 1" - (codegen contains same bug SDSCM00038778) Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: Any expression modulo 1 -- "expr % 1" -- will be replaced by 0, because that's what it evaluates to. However, it is incorrect to completely remove "expr" if it has a side effect, such as incrementing a variable; the correct simplification is to "(expr, 0)". A similar problem exists for "((long)expr) / k" where the types int and long are distinct and k > INT_MAX. Defect occurs in C2000 Compiler versions: 4.1.4, 4.3.0B1 - 4.3.0, 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.5, 5.2.0B1 - 5.2.9, 6.0.0B1 - 6.0.0B2 Workaround: Do the side effect before the modulo. ------------------------------------------------------------------------------- FIXED SDSCM00038778 ------------------------------------------------------------------------------- Summary : Codegen missing increment operation - (optimizer contains same bug SDSCM00038766) Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: For any value of x, the expression 'x % 1' results in 0. The compiler will perform this simplification but will incorrectly not evaluate x for side effects (eg. x++, x(), etc.). The compiler has been updated to evaluate x if there is a side effect. Defect occurs in C2000 Compiler versions: 4.1.2 - 4.1.4, 4.3.0B1 - 4.3.0, 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.5, 5.2.0B1 - 5.2.9, 6.0.0B1 - 6.0.0B2 Workaround: Other than replacing 'x % 1' with 'x,0' no available compiler workarounds. ------------------------------------------------------------------------------- FIXED SDSCM00038871 ------------------------------------------------------------------------------- Summary : bug when using -plink optimization option Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : Post-link Optimizer (plink) Release Notes: The -plink option incorrectly removed a load to the DP register that it thought was redundant but in fact was not. 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.2 - 5.1.5, 5.2.0B1 - 5.2.9, 6.0.0B1 Workaround: Use -ex followed by the filename at the end of the command line options to avoid post-link optimization on the file. ------------------------------------------------------------------------------- FIXED SDSCM00038953 ------------------------------------------------------------------------------- Summary : C28x optimizer generates incorrect compare when compiling for --float_support=fpu32 Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: For the comparison within this for-loop: int lauf = 0; int max = 0; int index = 0; for(lauf = 16; lauf >= 0; lauf--) { int array = *end--; if (max <= array) { max = array; index = lauf; } } The optimizer incorrectly reverses the condition of the IF. This idiom is computing both the maximum value in the array and the index of that value. The C2800 processors with FPA have some special intrinsics that can speed that operation, and the optimiser attempts to recognise the idiom and use it. The bug is that the optimiser inverts the condition in the course of the recognition process. The requirements are well-illustrated by the example above: - a "one-armed" IF -- it has a then-clause but no else-clause - the IF predicate is <, <=, >, or >= - two assignments within the then-clause - one of the assignments writes one of the IF-predicate operands to the other, which must be a simple variable - the other assignment involves two simple variables, both integer or both float For the bug to arise: - the IF predicate must have the assigned-to variable on the left side of the comparison and the assigned value on the right - compilation must use -v28 and --float_support Defect occurs in C2000 Compiler versions: 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.9, 6.0.0B1 Workaround: Compile without optimization, or declare one of the variables volatile, or swap the two assignments, or reverse the IF predicate, or compile without the --float_support option. ------------------------------------------------------------------------------- FIXED SDSCM00038954 ------------------------------------------------------------------------------- Summary : Long double (64-bit) float constant computed with only single-precision Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The bug is in the rts source file strtold.c. This source is available in the rtssrc.zip file that is included in the compiler installation, in the lib directory. The strtold uses a global const array that is initialized to powers of ten: static const _DATA_ACCESS long double powerof10[] = { 1.e1, 1.e2, 1.e4, 1.e8, 1.e16, 1.e32, 1.e64L, 2.e128L, 1.e256L}; This code is not initializing all the literals to long doubles as is necessary for C28x. Thus some of these literals are first converted to double, then long double, losing precision. The fix, see attached file, is to add the correct suffix for all the values in this list. As a workaround, you could include the correct source in your project, such that this file is used rather than the object file in the rts library. A compiler update with the bug fix would be available in the next patch 2.1.1. That is currently schedule for 1-28-2011. 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.9, 6.0.0B1 Workaround: See notes. ------------------------------------------------------------------------------- FIXED SDSCM00039013 ------------------------------------------------------------------------------- Summary : Optimizer incorrectly optimizes ((x< typedef unsigned char U8; typedef unsigned short U16; typedef unsigned int U32; U16 parameter_mask; U32 mask; U8 parameters[6] = { 1, 1, 1, 1, 2, 0 }; main() { parameter_mask = (parameters[5] | (parameters[4] << 8U)); mask = 0; mask |= ( 0x00000001U ); if ((parameter_mask & 0x0200) == 0x0200) { mask |= 4; } printf("simple mask = 0x%d (should be 0x5)\n", mask); } 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.10, 6.0.0B1 Workaround: Avoid constructing the (A|B)&C form when it fits the conditions. In this test case, controlling inlining (as with -o2) is enough. Using a global variable instead of a local variable for the OR subexpression also inhibits the necessary propagation. ------------------------------------------------------------------------------- FIXED SDSCM00039046 ------------------------------------------------------------------------------- Summary : Cannot disable MISRA checking for rule 1.1 from the command line Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The MISRA rule 1.1 warning is no longer issued when using the --check_misra=- 1.1 option to disable it. Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00039176 ------------------------------------------------------------------------------- Summary : Linking fails if extra space is added to linker options Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : ELF Linker Release Notes: Empty arguments that are processed as a result of adding extra space to linker options are now discarded. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00039244 ------------------------------------------------------------------------------- Summary : Compiler generates internal error "TP>> internal error: Bad kind: TYPE::type_pointed_to" Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: An expression like *(x ? (T*)0xc0000000 : (T*)0xc0404000) -- a dereference of a pointer that is selected by a quest/colon, for which one or both alternatives is a literal integer cast to a pointer type -- may cause the compiler to crash. During other manipulations of the expression, the compiler inadvertently discards the pointer casts and creates an invalid situation. The requirements are a pointer-cast of a literal integer and a quest/colon that is used as the pointer part of a memory reference. They don't need to be written directly that way: - The original test case used an if-then-else to choose between two pointer-cast integers; the compiler converted it to quest/colon. - The original test case used const variables that were initialised to the integers; the compiler propagated the constant values into the body of the function that used the variables. - The original test case used a combination of struct and array references -- p->x[i].f -- but it was reducible to a memory access based on p, which was the pointer quest/colon. Defect occurs in C2000 Compiler versions: 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.10, 6.0.0B1 Workaround: In this case, since the pointer-cast integers are defined as const global variables, the workaround is to remove the const qualifier. That will prevent the insertion of the integer values into the body of the function. (Since const globals cannot be modified, their values may be freely introduced in place of the variables.) In a case that does not depend on such insertion, create one or two globals to hold the integers, to break up the expression. ------------------------------------------------------------------------------- FIXED SDSCM00039271 ------------------------------------------------------------------------------- Summary : Compiler generates illegal assembly instruction with --float_support=32 and optimization Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Compiler sometimes generates illegal assembly instruction (MOV32 R7H,XAR1,EQ) when compiled with --float_support=32 and optimization. Defect occurs in C2000 Compiler versions: 5.0.0B1 - 5.0.2, 5.1.0B1 - 5.1.6, 5.2.7 - 5.2.10, 6.0.0B1 Workaround: None available. ------------------------------------------------------------------------------- FIXED SDSCM00039311 ------------------------------------------------------------------------------- Summary : Registers are not pushed and popped on stack in the same order Fixed in : 6.1.0B1 Severity : S1 - Critical / PS Affected Component : C/C++ Compiler (cl) Release Notes: Issue with registers being pushed onto the stack and popped off the stack in different orders with interrupts. This problem only occurs on C2000. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00039401 ------------------------------------------------------------------------------- Summary : Compiler generates B instead of LB in long memory ranges, so target address can never be reached Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : Assembler Release Notes: The long branch generated by the assembler now gets the correct 22-bit program address. The assembler must convert the B to a LB because the offset is greater than signed 16 bits. The linker command file for this example needs to be also modified. A .text section starting at 0x3ef000 will cause the simulator to succeed due to no addresses in the executable in the 0x400000 range. Workaround: Do not create large loops in the source file that will cause the assembler to generate a long branch instruction. ------------------------------------------------------------------------------- FIXED SDSCM00039478 ------------------------------------------------------------------------------- Summary : Compiler generates incorrect code when optimization is enabled Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: Compiler sometimes generates incorrect code when optimization is enabled Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00039569 ------------------------------------------------------------------------------- Summary : Optimizer removes compare in single iteration do-while loop Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: In the following code: var1 = 1; do { var1--; if (((var1 < 1U))==0) {(foo(((unsigned char) 0x02)));}; } while (var1 != 0); the optimizer removes the compare and unconditionally calls the routine "foo". The conditions for this bug to occur would be: 1. The loop must be a single iteration. 2. The loop induction variable must be initialized to 1. 3. The first reference to the induction variable must be an expression that decrements the loop counter to 0. 4. The loop is a single iteration loop because the loop must break when the induction variable is equal to 0. 5. The next reference to the loop counter must be in a compare expression that can be reduced at compile time to (1 == 0). Under these conditions the optimizer could remove the compare expression causing code within the if block to execute. Workaround: Possible workarounds: 1. Mark the induction variable volatile. 2. Change the loop induction range from 0 to 1 to any other integer range. 3. Change the compare expression to any other expression not equal to one. i.e. (1 == 2). ------------------------------------------------------------------------------- FIXED SDSCM00040101 ------------------------------------------------------------------------------- Summary : Compiler generates temporary files when compiling C++ files with templates and -pm that are not automatically deleted Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: When compiling C++ files which use templates with -pm option the compiler generates temporary files that are not automatically deleted. Defect occurs in C2000 Compiler versions: 4.1.3 - 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 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00040110 ------------------------------------------------------------------------------- Summary : sdata[i]++; causes segmentation fault Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: sdata[i]++ no longer causes a segmentation fault. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00040151 ------------------------------------------------------------------------------- Summary : Getting compile time generated symbol re-definition error during linking C674x ELF target Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The linker may generate "duplicate symbol" errors for symbols named like _TI_DW_.debug_info. when linking object files. Using ofd, it can be seen that these symbols are signatures for COMDAT groups. This is an error in COMDAT generation in the assembler and linker. 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.11, 6.0.0B1 - 6.0.1 Workaround: No workaround exists. ------------------------------------------------------------------------------- FIXED SDSCM00040264 ------------------------------------------------------------------------------- Summary : optimizer reduces WRITE to volatile in a loop to a single WRITE to volatile after the loop Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: A volatile access may not be properly handled if the volatile qualifier is only present on the field in the definition of a struct, as opposed to the struct type as a whole or the variable itself. 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.11, 6.0.0B1 - 6.0.1 Workaround: Compile at -o1 or -o0, or try moving the volatile qualifier to the type or variable, or perhaps cast to volatile at the access itself. ------------------------------------------------------------------------------- FIXED SDSCM00040365 ------------------------------------------------------------------------------- Summary : Mixing direct and indirect accesses to same variable may give wrong answer Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Fix is currently scheduled for 7.2.5 update planned 7/29/11 and 6.1.20 update planned for 8/5/11. Referring to the same variable both directly and indirectly -- eg, given p[0]=&a, using both *p[0] and a in the same function -- may produce the wrong answer when the alias between the two references is missed. 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.11, 6.0.0B1 - 6.0.1 Workaround: Compile at -o1 or -o0, or avoid referring to same variable both directly or indirectly. ------------------------------------------------------------------------------- FIXED SDSCM00040369 ------------------------------------------------------------------------------- Summary : Assignment to local struct variable with recurrence may assign some fields incorrectly Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Given a struct type that contains a pointer to the same type, as in struct st { struct st *next; int val; } and a local variable X of that type, and an assignment to that variable like X = *(X.next); some fields of X may not be written correctly. (Because X.next is written before the read of *(X.next) has completed.) Fix is currently scheduled for 7.2.5 update planned 7/29/11 and 6.1.20 update planned for 8/5/11. Workaround: Change the local variable to a global, or declare it volatile, or make sure the pointer field ("next" in this example) is the last one listed in the type definition. ------------------------------------------------------------------------------- FIXED SDSCM00040377 ------------------------------------------------------------------------------- Summary : Error with va_end() as left operand of void expression Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The macro va_end should be legal in a void expression context such as the left hand operand of the comma operator. This means the macro needs to expand to a void expression rather than be an empty macro. Defect occurs in C2000 Compiler versions: 4.1.2 - 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.1 Workaround: Rewrite the code so that calls to va_end are by themselves, not as part of a larger expression. ------------------------------------------------------------------------------- FIXED SDSCM00040496 ------------------------------------------------------------------------------- Summary : US: Users unable to understand linker placement error message when there's blocking or aligning Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : ELF Linker Release Notes: Updated error message for linker placement failure to be more clear and include info on whether alignment and/or blocking was involved. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00040623 ------------------------------------------------------------------------------- Summary : Mixing direct and indirect accesses to same variable may give wrong answer Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00040794 Release Notes: Referring to the same variable both directly and indirectly -- eg, given p=&a, using both *p and a in the same function -- may produce the wrong answer when the alias between the two references is missed. 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.11, 6.0.0B1 - 6.0.1 Workaround: Compile at -o1 or -o0, or avoid referring to same variable both directly or indirectly. ------------------------------------------------------------------------------- FIXED SDSCM00040650 ------------------------------------------------------------------------------- Summary : Error when specifying 400 or more to precision of output format specifier Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The minimum max conversion (precision) printf size to be C89 compliant is 509. The conversion size is now C89 compliant. Workaround: Specify a printf precision of less than 400 ------------------------------------------------------------------------------- FIXED SDSCM00040651 ------------------------------------------------------------------------------- Summary : Return statement with embedded assignment from a post-increment or -decrement may return wrong value Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: A statement like "return j = i++" may return the value of i after it has been incremented, when it should return the value before the increment. It's possible that other cases exist, but all will involve an assignment of a post-increment or post-decrement embedded in another statement. 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.11, 6.0.0B1 - 6.0.1 Workaround: Do the assignment outside the return, as in "j = i; return i++;" or "j = i++; return j;" ------------------------------------------------------------------------------- FIXED SDSCM00040658 ------------------------------------------------------------------------------- Summary : Taking the address of a static local variable may lead to a missed alias Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00040663 Release Notes: Accessing a static local variable both directly and indirectly, by taking its address, may miss an alias and produce incorrect behavior. 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 Workaround: Compiling at -o0 should work, and compiling at -o1 may work. If the variable whose address is taken is not static, there is no problem. Sometimes it helps if the variable *holding* the address is not static. ------------------------------------------------------------------------------- FIXED SDSCM00040659 ------------------------------------------------------------------------------- Summary : Mixing direct and indirect accesses to same variable may give wrong answer Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Referring to the same variable both directly and indirectly -- eg, given p=&a, using both *p and a in the same function -- may produce the wrong answer when the alias between the two references is missed. 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.11, 6.0.0B1 - 6.0.1 Workaround: Compile at -o1 or -o0, or avoid referring to same variable both directly or indirectly. ------------------------------------------------------------------------------- FIXED SDSCM00040665 ------------------------------------------------------------------------------- Summary : Anonymous function call that can resolve to direct pure call may cause compiler crash Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: If an anonymous function call -- a call using a pointer-to-function variable rather than a direct function name -- can be resolved to a direct call to a known function with no side effects, in some cases the compiler may crash. Defect occurs in C2000 Compiler versions: 5.1.0B1 - 5.1.6, 5.2.0B1 - 5.2.11, 6.0.0B1 - 6.0.1 Workaround: Compile at -o0 or -o1, or avoid anonymous function calls. ------------------------------------------------------------------------------- FIXED SDSCM00040908 ------------------------------------------------------------------------------- Summary : Hex converter crashes with segmentation fault Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : Hex Converter (hex) Release Notes: Hex converter crashes with segmentation fault if more than 15 --exclude options are used. 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.1 Workaround: Use arm version 4.9.0 or later. ------------------------------------------------------------------------------- FIXED SDSCM00041275 ------------------------------------------------------------------------------- Summary : Compiler sometimes calls epilog functions prior to resetting PM bits Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Compiler sometimes calls epilog functions prior to resetting PM bits, which in turn effects operation of certain instructions within the epilog function. The epilog_c28x_2 function has been tagged as a function that needs the PM bits reset prior to it being called. Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041308 ------------------------------------------------------------------------------- Summary : Demangler does not expose the --abi=eabi option through the help or compiler documentation Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Demangler (dem) Duplicate Defects : SDSCM00041780 Release Notes: The dem470 tool supports a --abi=eabi option that is needed to demangle C++ names when compiling for EABI. The option is not documented. Workaround: Use --abi=eabi when demangling name produced from and EABI project. ------------------------------------------------------------------------------- FIXED SDSCM00041395 ------------------------------------------------------------------------------- Summary : scanf %1f should stop after one character Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: The scanf format %1f should stop after one character of input, but it ignores the field width and keeps parsing as long as the input looks like a floating-point number. 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 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041396 ------------------------------------------------------------------------------- Summary : sscanf(" ", "%s", arg) should not modify arg Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: When the scanf format %s is used, if there are no non-whitespace characters in the input, the conversion should fail and should not modify the argument. 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.11, 6.0.0B1 - 6.0.1 Workaround: Use a temporary variable as the destination of the format conversion, and only assign it to the desired location if sscanf does not fail. ------------------------------------------------------------------------------- FIXED SDSCM00041397 ------------------------------------------------------------------------------- Summary : scanf %4[..] consumes 5 characters Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: With a format string containing a %[ conversion specifier with field width, and input containing a sequence of characters that matches the scanset and has more characters than the field width, a call to vfscanf shall assign the number of characters equal to the field width to the corresponding pointer to character array leaving characters after the input item unread. 7.19.6.9;2a (161) The bug here is that, while _scanfi assigns the correct number of characters, it fails to unget the following character, which belongs to the next conversion. 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 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041398 ------------------------------------------------------------------------------- Summary : scanf %[..] matching failure should return immediately Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: When a conversion fails, scanf should return immediately. In these test cases, scanf erroneously keeps going. scanf eventually reports a return value that is too large. 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 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041442 ------------------------------------------------------------------------------- Summary : printf("%#.4o",345) adds too many zeros Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: When using the # printf format flag, printf should only add an extra "0" at the beginning of the number if it isn't already "0". 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.11, 6.0.0B1 - 6.0.1 Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00041447 ------------------------------------------------------------------------------- Summary : printf("%#.0o",0) fails to write "0" Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: For *printf functions, the C standard requires that if the value is 0, the precision is 0, and the # flag is used, a single "0" will be printed. 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.11, 6.0.0B1 - 6.0.1 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041550 ------------------------------------------------------------------------------- Summary : sscanf %% failure not handled correctly Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: scanf fails in these ways when the %% conversion specifier fails: When any sort of error occurs with %%, scanf immediately returns EOF. It should instead return EOF only if there were 0 previous successful conversions and there was an input failure. If the failure was either a matching failure, or there were any previous successful conversions, it should return the number of previous successful conversions. When the failure is a matching failure, scanf should unget the character that didn't match. It fails to do so. 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 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041551 ------------------------------------------------------------------------------- Summary : scanf %d and %f should immediately return upon input failure, even if ordinary characters were matched Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: scanf should immediately return when an input failure occurs, even if ordinary characters in the format were already successfully matched. This bug affects all of the integer and float conversions. 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 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041552 ------------------------------------------------------------------------------- Summary : sscanf.c _chkmbc should return EOF on input failure Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: It should be possible for sscanf to return EOF on a string if an input error occurs (the end of the input string is reached before the format string is exhausted), but it does not return EOF as appropriate. 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 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041553 ------------------------------------------------------------------------------- Summary : scanf input failure when looking for ordinary characters always returns EOF Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: When matching ordinary characters in the format string, if there is an input failure, scanf should return EOF only if there were no previous successful conversions. If there were any, it should return the number of previous successful conversions. 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 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041554 ------------------------------------------------------------------------------- Summary : scanf %e and %[ should not return EOF on matching failure Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: When using %f (or other floating-point conversion specifier) or %[, if a matching failure occurs before even one character is matched, scanf will return EOF instead of 0 as the standard requires. 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 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041569 ------------------------------------------------------------------------------- Summary : Optimizer removes weak object pointer check Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Optimizer Release Notes: The optimiser believed that UAND-of-NAME was always non-NULL. That's not true for weak symbols. 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 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00041776 ------------------------------------------------------------------------------- Summary : Optimizer substitutes packed bitfield reference without masking value at -o1 Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: Under certain specific circumstances, the compiler may replace an assignment to a bitfield with a temporary variable whose value has not been properly truncated as the original assignment did. To cause the bug, several passes that do the right thing must be inhibited; one known way is to use -o1 and a packed struct. Workaround: Compile at -o0 or -o2, or avoid packed bitfields. ------------------------------------------------------------------------------- FIXED SDSCM00041909 ------------------------------------------------------------------------------- Summary : strtoimax definition does not match prototype Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: The definition of strtoimax in strtoimax.c, and strtoumax in strtoumax.c, lack the restrict qualifiers found in the prototypes in inttypes.h 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.11, 6.0.0B1 - 6.0.2 Workaround: no workaround ------------------------------------------------------------------------------- FIXED SDSCM00042053 ------------------------------------------------------------------------------- Summary : Near a software pipelined loop that comes from an include file, the .dwpsn directives have the wrong file name Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Fixed a bug where debug information near an inlined loop could contain the incorrect file name. 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 Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00042061 ------------------------------------------------------------------------------- Summary : Library building fails when TEMP is moderately long (50+ characters) Fixed in : 6.1.0B1 Severity : S1 - Critical / PS Affected Component : Runtime Support Libraries (RTS) Release Notes: The ar470 command line is over 32k characters, which runs afoul of the insurmountable upper limit of the Win32 API CreateProcess. When this happens, the user will see a mysterious error which looks something like this: process_begin: CreateProcess(c:\progra~1\texasi~1\tms470~2.1\bin\ar470.exe, c:/progra~1/texasi~1/tms470~2.1/bin/ar470 -qa d:/docume~1/user.name/locals~1/temp/ti5b2e~1/rtsv7a8_a_le_eabi.lib e:/docume~1/user.name/locals~1/temp/ti5b2e~1/obj/decode.obj f:/docume~1/user.name/locals~1/temp/ti5b2e~1/obj/xatexit.obj, ...) failed. make (e=87): The parameter is incorrect. Defect occurs in C2000 Compiler versions: 6.0.2 Workaround: 1) Set TEMP to a shorter path before running CCS, or 2) Run mklib manually from the command line ------------------------------------------------------------------------------- FIXED SDSCM00042103 ------------------------------------------------------------------------------- Summary : Dynamic linking options should be hidden for non-C6000 targets Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : Linker Release Notes: Dynamic linking is not supported for any target but C6000, but the dynamic linking options were exposed in the shell and linker option help summary output. Ignore them. Defect occurs in C2000 Compiler versions: 6.0.0B1 - 6.0.2 Workaround: Ignore the dynamic linking options ------------------------------------------------------------------------------- FIXED SDSCM00042146 ------------------------------------------------------------------------------- Summary : Quotes in PATH, TEMP, etc on Windows breaks mklib Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: If the PATH environment variable has quotes in it, mklib will crash with a mysterious error like "CreateProcess(NULL, cl470 atexit.c ...) failed. The system cannot find the file specified." It is not legal to have literal quotes in PATH, but as an enhancement, mklib will attempt to remove quotes from PATH and try again. Defect occurs in C2000 Compiler versions: 6.0.2 Workaround: Do not use literal quotes in PATH or TEMP ------------------------------------------------------------------------------- FIXED SDSCM00042340 ------------------------------------------------------------------------------- Summary : Compiler mistakenly issues diagnostic about destructor for base class is not virtual Fixed in : 6.1.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The no virtual base class destructor diagnostic will no longer be emitted when the base class has a virtual destructor. Workaround: Do not use the -pdr option. ------------------------------------------------------------------------------- FIXED SDSCM00042368 ------------------------------------------------------------------------------- Summary : Parser generates segmentation fault Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Parser generates segmentation fault when compiling the following source file: static const int a[1]; int main(void) { (void)a[0]; return 0; } static const int a[1] = { 0 }; Workaround: Move the second static const int declaration above the reference. ------------------------------------------------------------------------------- FIXED SDSCM00042400 ------------------------------------------------------------------------------- Summary : Loop with asm statements causes compiler crash Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00043653 Release Notes: asm statement no longer causes compiler to crash Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00042563 ------------------------------------------------------------------------------- Summary : Optimiser crashes on certain loop cases Fixed in : 6.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Certain loop structures, which we are not able to describe concisely, can cause the optimiser to crash when compiling at -o2 or higher. The one known example involves C++ code and a lot of inlining; adjusting the inlining avoids the problem. Workaround: Compile at -o1. In this particular example, removing an "inline" keyword from a function avoids the problem, because it changes the complexity of the function causing the crash. =============================================================================== 11. Current Known Issues =============================================================================== The following 29 known issues exist for C2000 Code Generation Tools release 6.1.8 as of May 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 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 SDSCM00044238 ------------------------------------------------------------------------------- Summary : Structure members with two underscores in their name are not displayed corectly in Expressions view Affected Component : Demangler (dem) Description: Structure members with two underscores in their name are not displayed corectly in Expressions view. Build and load the following code in CCS 5.2. Open expressions view and add global variable param1. Notice that members 3 and 4 are shows simply as "m" and point to the same address. typedef struct { int sha1; int sha2; short m__CPU2_00_VSM_ALT; short m__CPU2_01_VSM_DC; } t_sysparams; volatile t_sysparams param1; void main(void) { param1.sha1 = 1; param1.m__CPU2_00_VSM_ALT = 5; } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00044401 ------------------------------------------------------------------------------- Summary : Debug window shows "long double" arguments as pointers Affected Component : C/C++ Compiler (cl) Description: See also SDSCM00044398 I'm having some VERY weird behavior on the C28 core of my Concerto F28M35H52C1 everything declared as "long double" are actually being created as pointers to long double. for example: void pwm_set(unsigned char index, long double value); in the debug window shows pwm_set(unsigned char, long double *)() at pwm_handler.c and when I pause inside this code and stop the mouse cursor on top of 'value' it shows: => value | long double * | 0x00000AE *(value) | long double | 0.0 also on long double exPID(struct exPID_struct *me, struct analogue_struct *PV, long double period) I see on the debug window as long double * and in the Variables window shows the pointer to be in some register that get changed all the time and the values just jump up and down like crazy. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00044803 ------------------------------------------------------------------------------- Summary : Errors/warnings that span more than one line in the build console get cut off in the Problems view Affected Component : C/C++ Compiler (cl) Description: When the "verbose diagnostic" compiler option is enabled (-- verbose_diagnostics), the errors/warnings in the build console that span more than one line get cut off to just the first line in the Problems view. Attached a screenshot of an example. Also see http://e2e.ti.com/support/development_tools/compiler/f/343/t/203509.aspx ============= This bug is for all ISAs, not only c2000. When --verbose_diagnostics (aka -pdv) is used, --diag_wrap=off is ignored by CGT. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00045178 ------------------------------------------------------------------------------- Summary : The C2000 compiler, where char is 16-bits, does not document how extended ASCII chars are handled Affected Component : Documentation Description: The type char is 16-bits on C2000. How are extended ASCII chars, where the MSB is 1, handled? This detail is not covered in the documentation. In at least one case, the upper 8 bits of the extended ASCII char value are all 1, and not all 0. ------------------------------------------------------------------------------- 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 SDSCM00047274 ------------------------------------------------------------------------------- Summary : Compiler incorrectly issues MISRA diagnostic 10.1 no implicit conversion of int which loses bits Affected Component : C/C++ Compiler (cl) Description: In this expression all variables are type uint16_t. The first one incorrectly is issued MISRA diagnostic 10.1 ... 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 the expression is complex k = 1U + i; // gets 10.1 k = i + 1U; // no diagnostic ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00047849 ------------------------------------------------------------------------------- Summary : string.h does not have prototype for memcpy Affected Component : C/C++ Compiler (cl) Description: The string.h included with CGT does not have prototype for memcpy(). Other mem functions have prototypes but there isnt one for memcpy. https://e2e.ti.com/support/development_tools/compiler/int- compiler/f/85/t/279604.aspx