TMS470 C/C++ CODE GENERATION TOOLS 5.1.14 December 2015 Defect History ------------------------------------------------------------------------------- Table of Contents ------------------------------------------------------------------------------- 1. Defects fixed in TMS470 Code Generation Tools release 5.1.14 2. Defects fixed in TMS470 Code Generation Tools release 5.1.13 3. Defects fixed in TMS470 Code Generation Tools release 5.1.12 4. Defects fixed in TMS470 Code Generation Tools release 5.1.11 5. Defects fixed in TMS470 Code Generation Tools release 5.1.10 6. Defects fixed in TMS470 Code Generation Tools release 5.1.9 7. Defects fixed in TMS470 Code Generation Tools release 5.1.8 8. Defects fixed in TMS470 Code Generation Tools release 5.1.7 9. Defects fixed in TMS470 Code Generation Tools release 5.1.6 10. Defects fixed in TMS470 Code Generation Tools release 5.1.5 11. Defects fixed in TMS470 Code Generation Tools release 5.1.4 12. Defects fixed in TMS470 Code Generation Tools release 5.1.3 13. Defects fixed in TMS470 Code Generation Tools release 5.1.2 14. Defects fixed in TMS470 Code Generation Tools release 5.1.1 15. Defects fixed in TMS470 Code Generation Tools release 5.1.0 16. Defects fixed in TMS470 Code Generation Tools release 5.1.0B1 17. Current Known Issues =============================================================================== 1. Defects fixed in TMS470 Code Generation Tools release 5.1.14 =============================================================================== The following 2 defects were fixed in TMS470 Code Generation Tools release 5.1.14, released December 2015. ------------------------------------------------------------------------------- FIXED SDSCM00052339 ------------------------------------------------------------------------------- Summary : demangler --output option does not work at all Fixed in : 5.1.14 Severity : S2 - Major Affected Component : Demangler (dem) Release Notes: The --output option of armdem does not work at all. You will always get the error message ">> Cannot open output file '(null)'" Workaround: armdem file.asm > file.dis ------------------------------------------------------------------------------- FIXED SDSCM00052529 ------------------------------------------------------------------------------- Summary : Optimizer assumes enum variable can only have value of enumeration constants Fixed in : 5.1.14 Severity : S2 - Major Affected Component : Optimizer Release Notes: If an enumerated type is defined to have only two constants that evaluate to 0 and 1, then the compiler will assume that only those two values are possible. However, the C++ and C standards allow variables of enumerated types to hold other values as well; if other values are used, the compiler may produce incorrect code. Workaround: Don't make enumerated types with constants only for 0 and 1 if other values may be used. Either add a third value, or use values different than 0 and 1, or avoid using values that aren't the enumeration constants. =============================================================================== 2. Defects fixed in TMS470 Code Generation Tools release 5.1.13 =============================================================================== The following 10 defects were fixed in TMS470 Code Generation Tools release 5.1.13, released September 2015. ------------------------------------------------------------------------------- FIXED SDSCM00051870 ------------------------------------------------------------------------------- Summary : Underflow on conversion from double to float gives Inf instead of 0.0 Fixed in : 5.1.13 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: When converting a double to a float, if the double is smaller than the smallest float value, it should underflow to 0.0 or -0.0. Instead, it underflows to Inf or -Inf. This bug only occurs in 32-bit mode and Thumb 2 mode floating-point emulation. The 16-bit Thumb mode does not have this problem, nor does the hardware. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.122, 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.12, 5.0.4.102 - 5.0.4.103, 5.2.0B1 - 5.2.4, 15.3.0 Workaround: Avoid conversions from double to float, or use the 16-bit mode library. The 16-bit mode library is not available on Thumb 2 only devices such as Cortex-M3. ------------------------------------------------------------------------------- FIXED SDSCM00051958 ------------------------------------------------------------------------------- Summary : Linker incorrectly splits text section. Section .text.1 is too long. It overwrites the trampoline at the start of .text.2 Fixed in : 5.1.13 Severity : S2 - Major Affected Component : Linker Release Notes: In rare cases, the linker may duplicate a trampoline. This may lead to the trampoline being placed twice. If this occurs, the .text section may be split near the position of the trampoline to create two sections that overlap each other and both contain the trampoline. This may be observed in the linker map file. If NOP padding is added at the end of the first overlapping section, other code may be overwritten. This may be observed in disassembly. This can only occur when split placement is used in the linker command file; e.g. ".text >> foo" instead of ".text > foo". Workaround: Disabling split placement of the section will avoid this issue. Otherwise -- disable_early_consolidation will also avoid this behavior. ------------------------------------------------------------------------------- FIXED SDSCM00052014 ------------------------------------------------------------------------------- Summary : Cannot read files with inode > 4B Fixed in : 5.1.13 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Large file support (LFS) was not previously provided. The would result in messages such as "could not open source file" on some files on some file systems when one of the file attributes, such as the inode, cannot be represented in 32 bits. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00052040 ------------------------------------------------------------------------------- Summary : Use of noinit attribute causes compiler to crash Fixed in : 5.1.13 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The noinit and persistent pragmas are not supported for the ARM 5.1.x releases. Workaround: Move to a ARM 5.2.x release. ------------------------------------------------------------------------------- FIXED SDSCM00052083 ------------------------------------------------------------------------------- Summary : Error correcting codes may not be generated for sections beyond the first in a memory region Fixed in : 5.1.13 Severity : S2 - Major Affected Component : Linker Release Notes: Error correcting codes may not be generated for sections beyond the first in a memory region. For example, if .text is placed in PMEM and .const is also placed in PMEM, .const will not have ECC generated for it. Workaround: Place each section that needs ECC in a separate memory region. ------------------------------------------------------------------------------- FIXED SDSCM00052114 ------------------------------------------------------------------------------- Summary : Windows Stack Size for Parser Should be Raised Fixed in : 5.1.13 Severity : S2 - Major Affected Component : Parser Release Notes: By default, the parser only allows 64 pending template instantiations. By using the --pending_instantiations option, more may be allowed. While it is very unlikely to overflow the stack when parsing with the default maximum of 64 levels of recursion in a template instantiation, raising the limit may lead to a stack overflow. This will occur at lower values for -- pending_instantiations on Windows since the default stack size is 1MB. On Linux, this behavior may still occur but only at higher values since the most common default stack size for user applications on Linux is 8MB. Workaround: There are at least two options: 1. On Windows, if you have Visual Studio available, the stack for an executable may be raised with editbin. For example, to raise the stack to 8MB for the acpia6x parser, you would use: editbin /stack:8388608 acpia6x.exe 2. Use the linux toolchain. The default stack is much higher. Even if that limit is reached, the soft limit for the stack size of user applications may be raised with ulimit. For example, to raise the stack to 16MB, you would use: ulimit -S -s 16384 (This could be placed in the startup script, such as .bashrc) ------------------------------------------------------------------------------- FIXED SDSCM00052140 ------------------------------------------------------------------------------- Summary : math.h should not have a using statement for abs Fixed in : 5.1.13 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: Inclusion of the math.h header under C++ may generate an error at "using std::abs". Workaround: Include cmath instead of math.h. ------------------------------------------------------------------------------- FIXED SDSCM00052144 ------------------------------------------------------------------------------- Summary : RTS libraries do not get automatically built if the library is missing (Mac OS X) Fixed in : 5.1.13 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: On Mac OS X, the RTS lib does not get auto generated if it is missing like it does on Windows/Linux. mklib, which is responsible for building the libraries, is not currently supported on Mac OS X. Workaround: Copy the libraries from a Windows/Linux machine. ------------------------------------------------------------------------------- FIXED SDSCM00052185 ------------------------------------------------------------------------------- Summary : In certain cases at opt_level=2 or higher, compiler gets load and store instructions in the wrong order Fixed in : 5.1.13 Severity : S2 - Major Affected Component : Optimizer Release Notes: The test case in CQ52185 is, strictly speaking, undefined behavior: it refers to a volatile variable both directly and via cast-to-char*, and the cast form casts away the volatile. Alias analysis assumes that a volatile reference cannot alias a non-volatile reference. Workaround: Retain "volatile" in the cast, or remove it from the definition. ------------------------------------------------------------------------------- FIXED SDSCM00052216 ------------------------------------------------------------------------------- Summary : M0 little-endian double multiply incorrectly gives +Inf Fixed in : 5.1.13 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: In little-endian mode for Cortex-M0, double float multiply will give incorrect results for most inputs. At one point, the registers representing the exponent and the most significant bits of the mantissa are swapped. For most inputs, this would lead to a return value of +Inf. Workaround: modify fd_mul16.as as follows and add it to your project: .if .TMS470_BIG_DOUBLE POP {res1, op1e} ; Grab that stuff we stored off .else POP {res1} ; Grab that stuff we stored off POP {op1e} ; Grab that stuff we stored off .endif =============================================================================== 3. Defects fixed in TMS470 Code Generation Tools release 5.1.12 =============================================================================== The following 7 defects were fixed in TMS470 Code Generation Tools release 5.1.12, released May 2015. ------------------------------------------------------------------------------- FIXED SDSCM00051112 ------------------------------------------------------------------------------- Summary : Missing __aeabi_localeconv Fixed in : 5.1.12 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: Function __aeabi_localeconv is required for ARM EABI compatibility, but TI's compiler RTS didn't provide it. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.122, 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.11, 5.0.4.102 - 5.0.4.103, 5.2.0B1 - 5.2.4, 15.3.0 Workaround: Link with another vendor's toolset ------------------------------------------------------------------------------- FIXED SDSCM00051636 ------------------------------------------------------------------------------- Summary : The --rom option should not be exposed for any target except C6000 Fixed in : 5.1.12 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The --rom option is not implemented for any compiler targets other than C6000. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00051708 ------------------------------------------------------------------------------- Summary : Loop downcounter may be mistakenly typed too small Fixed in : 5.1.12 Severity : S2 - Major Affected Component : Optimizer Release Notes: When optimized, a loop may be restructured to use a downcounter, essentially of the form "while (--i)". However, in some cases, the downcounter may receive a type that is too small. In particular, if the loop may run for more iterations than MAX_INT, all iterations may not execute. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.122, 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.11, 5.0.4.102 - 5.0.4.103, 5.2.0B1 - 5.2.3, 15.3.0 Workaround: Lower the level of optimization. ------------------------------------------------------------------------------- FIXED SDSCM00051709 ------------------------------------------------------------------------------- Summary : incompatible wchar_t types diagnostic gives wrong type for one file Fixed in : 5.1.12 Severity : S3 - Minor Affected Component : ELF Linker Duplicate Defects : SDSCM00051644, SDSCM00046111 Release Notes: When linking object files with incompatible settings for the size of wchar_t, the linker will incorrectly describe the settings for the two files. Defect occurs in TMS470 Compiler versions: 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.11, 5.0.4.102 - 5.0.4.103, 5.2.0B1 - 5.2.3, 15.3.0 Workaround: Ignore the settings reported for the size of wchar_t ------------------------------------------------------------------------------- FIXED SDSCM00051740 ------------------------------------------------------------------------------- Summary : AP modified before V4 saved, potentially corrupting the stack pointer Fixed in : 5.1.12 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: When compiling a function with a large frame for Thumb2 mode, the compiler can generate a frame allocation sequence that uses AP as a temporary register, corrupting the frame pointer (V4). Defect occurs in TMS470 Compiler versions: 5.1.0B1 - 5.1.11, 5.2.0B1 - 5.2.4, 15.3.0 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00051762 ------------------------------------------------------------------------------- Summary : Dot expression adding align(64) computes hugely incorrect size Fixed in : 5.1.12 Severity : S2 - Major Affected Component : ELF Linker Release Notes: When computing the size to be added for a dot expression (e.g. ". += align(64)"), the linker may mistakenly compute a large value and fail to place the section: "lnk.cmd", line 56: error: program will not fit into available memory. placement with alignment fails for section ".foo" size 0x0 . Available memory ranges: BMEM size: 0x2000000 unused: 0x1ff8ff0 max hole: 0x1ff8ff0 Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.122, 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.11, 5.0.4.102 - 5.0.4.103, 5.2.0B1 - 5.2.4, 15.3.0 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00051809 ------------------------------------------------------------------------------- Summary : "if (P) X=A; else X=B;" may compile incorrectly when A and B are 0/1 and P is 0/1 with a side effect Fixed in : 5.1.12 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: "if (P) X=A; else X=B;" may compile incorrectly when A and B are either 0 or 1, P is known to return only 0 and 1, and P has side effect (eg, it is a function that modifies a global variable and then returns 0 or 1). The compiler tries to reduce the IF to a simpler form like "X=P", but it does so via an intermediate form that uses P twice, which is incorrect when P has side effects. Defect occurs in TMS470 Compiler versions: 5.1.0B1 - 5.1.11, 5.2.0B1 - 5.2.4, 15.3.0 Workaround: Typically such an IF is equivalent to "X=P" or "X=!P"; write it that way to avoid the problem. Adding statements to either arm of the IF can also help. =============================================================================== 4. Defects fixed in TMS470 Code Generation Tools release 5.1.11 =============================================================================== The following 8 defects were fixed in TMS470 Code Generation Tools release 5.1.11, released March 2015. ------------------------------------------------------------------------------- FIXED SDSCM00050103 ------------------------------------------------------------------------------- Summary : Buffer the output of warning and error messages to facilitate better error reporting during parallel compilation Fixed in : 5.1.11 Severity : S2 - Major Classification : Enhancement Affected Component : C/C++ Compiler (cl) Release Notes: The added --buffer_diagnostics option may be used to force compiler diagnostics to be printed by line instead of by character. This will reduce mangling of diagnostics when multiple instances of the compiler are ran in parallel. Defect occurs in TMS470 Compiler versions: 5.1.0B1 - 5.1.10, 5.2.0B1 - 5.2.2 Workaround: Workaround is to manually buffer the compiler output using a script or with the --write_diagnostics_file option. ------------------------------------------------------------------------------- FIXED SDSCM00051110 ------------------------------------------------------------------------------- Summary : __aeabi_{i,l}div0 should be extern, not static Fixed in : 5.1.11 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: The TI ARM RTS library failed to make the functions __aeabi_{i,l}div0 external. These functions are really only meant for the compiler and library vendor to use, but they are still required. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.122, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.10, 5.0.4.102 - 5.0.4.103, 5.2.0B1 - 5.2.2 Workaround: Use a different vendor's RTS library. ------------------------------------------------------------------------------- FIXED SDSCM00051412 ------------------------------------------------------------------------------- Summary : Compiler generates illegal assembly code Fixed in : 5.1.11 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: If source is affected by the bug, the assembler will emit "Offset out of range." This is caused by the use of the constant 2147483648 (0x80000000). In the observed test case, 0x80000001 will not cause the failure. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.122, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.10, 5.0.4.100 - 5.0.4.103, 5.2.0 - 5.2.2 Workaround: The use of the constant 0x80000000 may cause the bug. Exchanging the constant with a smaller value will avoid the issue. If not possible, raising the optimization level may avoid the issue. ------------------------------------------------------------------------------- FIXED SDSCM00051444 ------------------------------------------------------------------------------- Summary : Advanced use of SFINAE idiom fails to compile Fixed in : 5.1.11 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: SFINAE stands for substitution failure is not an error. It is idiomatic way of using C++ templates. The attached test case compiles clean with several C++ compilers in the field, including 4.9.x versions of GCC. But it sees this error with the TI compiler ... "file.cpp", line 18: error: no instance of constructor "sf::sf" matches the argument list argument types are: (int (A::*)()) 1 error detected in the compilation of "file.cpp". >> Compilation failure Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00051463 ------------------------------------------------------------------------------- Summary : Automatic library resolution fails when a a load image file is included in the link Fixed in : 5.1.11 Severity : S2 - Major Affected Component : Linker Release Notes: Using automatic library selection (linking against libc.a) may result in failures such as undefined symbols if one of the object files in the link does not have build attributes. This is due to automatic library selection silently failing. Defect occurs in TMS470 Compiler versions: 4.9.1 - 4.9.9, 5.0.0B1 - 5.0.11, 5.1.9 - 5.1.10, 5.0.4.102 - 5.0.4.103, 5.2.0B1 - 5.2.2 Workaround: Specify the specific library to link against instead of using libc.a. ------------------------------------------------------------------------------- FIXED SDSCM00051472 ------------------------------------------------------------------------------- Summary : Conditionals that use shift operator may be optimized out Fixed in : 5.1.11 Severity : S2 - Major Affected Component : Optimizer Release Notes: Shift operations in conditional statements may be optimized out, treating the result as 0. This will result in the entire conditional block being removed. NOTE: Intrinsics that perform shifts may be affected. In the observed test case, a shift was not explicitly used -- the C6x intrinsic _extu, which performs two shifts, was affected. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.122, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.10, 5.0.4.102 - 5.0.4.103, 5.2.0B1 - 5.2.2 Workaround: This behavior may be avoided by lowering the optimization level to -o1 or -o0. Moving the conditional check result to a variable so that the shift is not in the conditional may in some cases also avoid this behavior. ------------------------------------------------------------------------------- FIXED SDSCM00051621 ------------------------------------------------------------------------------- Summary : Redeclaring extern "C" function as static causes parser to hang Fixed in : 5.1.11 Severity : S2 - Major Affected Component : Parser Release Notes: Redeclaring an extern "C" function function as static may cause the parser to hang. For example: extern "C" namespace N { extern void foo(); void bar(); static inline void foo() {} } will result in the parser hanging due to the redeclaration of foo(). Defect occurs in TMS470 Compiler versions: 5.1.8 - 5.1.10, 5.2.0B1 - 5.2.3, 15.3.0B1 Workaround: Use consistent function declarations. ------------------------------------------------------------------------------- FIXED SDSCM00051629 ------------------------------------------------------------------------------- Summary : Compiler seg faults in C++ copy constructor call Fixed in : 5.1.11 Severity : S2 - Major Affected Component : Parser Release Notes: This segmentation fault may occur in calls to copy constructors. For example: new CLASS( myCLASS ); Defect occurs in TMS470 Compiler versions: 5.1.0B1 - 5.1.10, 5.2.0B1 - 5.2.3, 15.3.0B1 Workaround: In some cases, using a different ABI option may avoid this error. However, the most safe option is to avoid the use of a copy constructor. =============================================================================== 5. Defects fixed in TMS470 Code Generation Tools release 5.1.10 =============================================================================== The following 4 defects were fixed in TMS470 Code Generation Tools release 5.1.10, released January 2015. ------------------------------------------------------------------------------- FIXED SDSCM00050764 ------------------------------------------------------------------------------- Summary : Bound function has incorrect address in DWARF debug info Fixed in : 5.1.10 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00049433 Release Notes: The TI compiler allows a function to be bound to a specific address, usually with "#pragma location". There was a bug in the way the TI assembler recorded the DWARF debugging information for a bound function that corrupted the DWARF debugging information. This would cause CCS to report "no source available" when stepping attempting to step into such a function. Defect occurs in TMS470 Compiler versions: 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.9, 5.0.4.102, 5.2.0B1 - 5.2.0 Workaround: Set a breakpoint at the bound function and run to it, rather than attempting to step into it. ------------------------------------------------------------------------------- FIXED SDSCM00050992 ------------------------------------------------------------------------------- Summary : The optimizer should not make a symbol an alias if it has either the location or code_section pragmas applied. Fixed in : 5.1.10 Severity : S2 - Major Affected Component : Compiler Consultant (ci) Release Notes: For a reason external to the expression of the program, the user relies on function X being at a particular address A. The only method the user has to do this is to put the function in its own special subsection and place it at A in the linker command file. Workaround: Available workarounds are to: 1. Reduce the optimization level to -o2. 2. If using a COFF abi, you can move the functions into separate files. 3. Add an __asm("NOP") to the function which will prevent an alias from being created. ------------------------------------------------------------------------------- FIXED SDSCM00051238 ------------------------------------------------------------------------------- Summary : The Cortex-R4 silicon defect for VMRSEQ APSR_nzcv, FPSCR is incorrectly warned about if the destination is an ARM register Fixed in : 5.1.10 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The warning incorrectly triggers for cases where the destination register for the VMRS instruction is not APSR_nzcv. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00051241 ------------------------------------------------------------------------------- Summary : Output section splitting creates a zero-length section Fixed in : 5.1.10 Severity : S2 - Major Affected Component : ELF Linker Release Notes: In certain rare cases, the linker might split an output section into several output sections such that one of them had zero length. The linker really ought not to create split zero-length sections, as it doesn't improve the linkability of the program. This can only happen if one of the input sections is of zero length. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.9, 5.0.4.102, 5.2.0B1 - 5.2.1 Workaround: 1) Do not split the section in question. 2) Change the zero-length section so that it has at least one more byte. =============================================================================== 6. Defects fixed in TMS470 Code Generation Tools release 5.1.9 =============================================================================== The following 9 defects were fixed in TMS470 Code Generation Tools release 5.1.9, released November 2014. ------------------------------------------------------------------------------- FIXED SDSCM00049110 ------------------------------------------------------------------------------- Summary : IT instruction doesn't accept lowercase conditions Fixed in : 5.1.9 Severity : S3 - Minor Affected Component : Assembler Release Notes: The IT instruction should accept both uppercase and lowercase condition codes, but it rejects lowercase condition codes. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.10, 5.1.0B1 - 5.1.8, 5.0.4.102 Workaround: Use uppercase condition codes ------------------------------------------------------------------------------- FIXED SDSCM00050051 ------------------------------------------------------------------------------- Summary : Table driven exception handling code does not check for malloc returning NULL Fixed in : 5.1.9 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: In programs with extremely small .sysmem, one helper function for C++ exception handling would incorrectly handle a failure to allocate the global state for C++ exception handling. Later, if a C++ exception was thrown, the program would write to memory locations near 0 and potentially crash in a confusing manner. The program ought to have aborted when the global state could not be allocated. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.8, 5.0.4.100 - 5.0.4.102 Workaround: Allocate more space to .sysmem ------------------------------------------------------------------------------- FIXED SDSCM00050505 ------------------------------------------------------------------------------- Summary : TDEH emergency buffer should be allocated on stack Fixed in : 5.1.9 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: The TI RTS has an "emergency buffer" functionality for C++ exception handling. The emergency buffer pre-allocates enough space for one std::bad_alloc object, so that if an allocation failure occurs in a low-memory situation, we can at least handle the bad_alloc exception gracefully. However, the C++ exception handling code tries to malloc a buffer to hold the register context for phase 1 of the stack unwinding pass. This means that in the very situation where we need the emergency buffer, we couldn't possibly malloc the register context. Thus, despite having been careful to create the emergency buffer, it can't work, because we'll invariably run out of memory trying to use it. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.8, 5.0.4.102 Workaround: Allocate more space to .sysmem ------------------------------------------------------------------------------- FIXED SDSCM00050742 ------------------------------------------------------------------------------- Summary : Should allow "ADD R0, R1" for v6m0 Fixed in : 5.1.9 Severity : S2 - Major Affected Component : Assembler Release Notes: In UAL notation, the instruction "ADD Rn, Rm" does not set the status. Thumb 2 adds a 16-bit encoding for this instruction when where Rn and Rm are low registers. The assembler allowed this instruction for v7 or above. However, while Cortex-M0 is considered v6, it is actually a Thumb 2, so the test should be against T2, not v7. Defect occurs in TMS470 Compiler versions: 5.0.0B1 - 5.0.10, 5.1.0B1 - 5.1.7, 5.0.4.102 TMS470 Compiler versions: 5.0.0B1 - 5.0.10, 5.1.0B1 - 5.1.8, 5.0.4.102 Workaround: No practical workaround ------------------------------------------------------------------------------- FIXED SDSCM00050860 ------------------------------------------------------------------------------- Summary : In pre-UAL syntax Cortex, "ADD R2, R0" should set sign Fixed in : 5.1.9 Severity : S3 - Minor Affected Component : Assembler Release Notes: In pre-UAL syntax Cortex, "ADD R2, R0" should set sign Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.10, 5.1.0B1 - 5.1.8, 5.0.4.102 Workaround: No practical workaround ------------------------------------------------------------------------------- FIXED SDSCM00050973 ------------------------------------------------------------------------------- Summary : The function __aeabi_uidiv is missing in the RTS Fixed in : 5.1.9 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Duplicate Defects : SDSCM00045035 Release Notes: The function __aeabi_uidiv is required by ARM EABI, but missing from TI's library. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.8, 5.0.4.102, 5.2.0B1 Workaround: Link with another vendor's linker, or add a function named __aeabi_uidiv which takes two unsigned int arguments and calls __aeabi_uidivmod ------------------------------------------------------------------------------- FIXED SDSCM00051039 ------------------------------------------------------------------------------- Summary : 64-bit divide routine does not return results as documented Fixed in : 5.1.9 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: The ARM EABI run-time ABI requires that __aeabi_ldivmod return one of a specific set of values when the divisor is zero. __aeabi_ldivmod is to return the value of calling __aeabi_ldiv0 with an argument of LLONG_MIN, LLONG_MAX, or 0, when the dividend is negative, positive, or zero, respectively. However, for some negative values, the function would instead return the dividend. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.8, 5.0.4.102, 5.2.0B1 Workaround: Don't rely on integer division by zero to return any reasonable value. ------------------------------------------------------------------------------- FIXED SDSCM00051097 ------------------------------------------------------------------------------- Summary : Output section splitting creates a zero-length section Fixed in : 5.1.9 Severity : S2 - Major Affected Component : ELF Linker Release Notes: In certain rare cases, the linker might split an output section into several output sections such that one of them had zero length. The linker really ought not to create split zero-length sections, as it doesn't improve the linkability of the program. This can only happen if one of the input sections is of zero length. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.11, 5.1.0B1 - 5.1.8, 5.0.4.102, 5.2.0B1 Workaround: 1) Do not split the section in question. 2) Change the zero-length section so that it has at least one more byte. ------------------------------------------------------------------------------- FIXED SDSCM00051155 ------------------------------------------------------------------------------- Summary : Compiler does not define __TI_GNU_ATTRIBUTE_SUPPORT__ as the documentation describes Fixed in : 5.1.9 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: There is no method by which a customer can implement a compile time check on whether GCC extensions are supported. Workaround: None. =============================================================================== 7. Defects fixed in TMS470 Code Generation Tools release 5.1.8 =============================================================================== The following 10 defects were fixed in TMS470 Code Generation Tools release 5.1.8, released September 2014. ------------------------------------------------------------------------------- FIXED SDSCM00046351 ------------------------------------------------------------------------------- Summary : Assembler mishandles certain combinations of S and condition codes Fixed in : 5.1.8 Severity : S2 - Major Affected Component : Assembler Release Notes: When using the UAL syntax for an instruction which both sets the status register and is conditional, the assembler would get confused when trying to distinguish S used as "sets status" versus S used as "signed" in SB and SH. It would also get confused when using HS with MOV or LD. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.9, 5.1.0B1 - 5.1.7, 5.0.4.102 Workaround: Use the pre-UAL syntax ------------------------------------------------------------------------------- FIXED SDSCM00048891 ------------------------------------------------------------------------------- Summary : Should reject MUL instruction with constant operand in T2 mode Fixed in : 5.1.8 Severity : S3 - Minor Affected Component : Assembler Release Notes: For Thumb 2, the instructions MUL, MLA, and MLS may not accept a constant (immediate) value as an operand; the operands must be registers. However, the linker fails to emit an error for the source registers; instead, it silently encodes an incorrect register. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.9, 5.1.0B1 - 5.1.7, 5.0.4.102 Workaround: Don't use the illegal instruction "MUL R4, R4, #5". Thumb 2 doesn't have a MUL which accepts a constant argument. ------------------------------------------------------------------------------- FIXED SDSCM00050243 ------------------------------------------------------------------------------- Summary : Scary but harmless warning: FAILURE in mark_use_of_function_local_static() Fixed in : 5.1.8 Severity : S2 - Major Affected Component : Optimizer Release Notes: Compiling for C++ and using -pm or -o4 may produce a warning like FAILURE in mark_use_of_function_local_static() fname1: __sti fname2: __sti_ symbol: _$P$T62$2$1 This warning, despite its dramatic wording, is harmless. The compiler will build the program just as it should, and the warning does not indicate any change in behavior. It's a debugging message that should not have been visible outside the development team. Defect occurs in TMS470 Compiler versions: 2.54.02 - 2.54.209, 2.54.03 - 2.54.129, 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.9, 5.1.0B1 - 5.1.7, 5.0.4.100 - 5.0.4.102 Workaround: Avoid -pm or -o4. But the warning doesn't indicate any change of the compiler's behavior, so you might as well ignore it. ------------------------------------------------------------------------------- FIXED SDSCM00050512 ------------------------------------------------------------------------------- Summary : Compiler does not handle control-C signal as expected Fixed in : 5.1.8 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: Added signal catchers for SIGINT and SIGBREAK on non-Unix hosts, so the tool exits cleanly instead of falling into the segfault report mechanism. Workaround: Later compiler releases (7.6.x and above) do not suffer from this problem. ------------------------------------------------------------------------------- FIXED SDSCM00050677 ------------------------------------------------------------------------------- Summary : Using --opt_level=1 or higher causes compiler to fail with INTERNAL ERROR: >>>Register allocation failed Fixed in : 5.1.8 Severity : S2 - Major Affected Component : Code Generator Release Notes: Floating point registers are causing INTERNAL ERROR: register allocation failure. Workaround: Use _itof and _ftoi intrinsics ------------------------------------------------------------------------------- FIXED SDSCM00050689 ------------------------------------------------------------------------------- Summary : Non-status setting MOV Rd, Rs should be allowed for Cortex-M0 Fixed in : 5.1.8 Severity : S2 - Major Affected Component : Assembler Release Notes: In UAL mode for ARM v6 and above, the syntax "MOV Rd, Rs" should be allowed for any registers, and should not set status. However, the assembler rejected it with an error. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.10, 5.1.0B1 - 5.1.7, 5.0.4.102 Workaround: Use the CPY Rd, Rs syntax ------------------------------------------------------------------------------- FIXED SDSCM00050721 ------------------------------------------------------------------------------- Summary : Compiler truncates 64-bit case labels Fixed in : 5.1.8 Severity : S2 - Major Affected Component : Code Generator Release Notes: In some cases, the compiler optimizes switch case label comparisons by computing the difference between two adjacent case labels. The bug is that the compiler may truncate this difference to a 32-bit value. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.10, 5.1.0B1 - 5.1.7, 5.0.4.102 Workaround: Do not use a switch involving case labels with value larger than 32 bits; use nested if/else statements instead. ------------------------------------------------------------------------------- FIXED SDSCM00050732 ------------------------------------------------------------------------------- Summary : unsigned comparison to zero evaluated incorrectly Fixed in : 5.1.8 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The compiler can generate incorrect code for an unsigned comparison to a register which is zero, where the register is negated before comparison. When the bug occurs, the compiler will generate a CMN instruction where src2 is a register with value exactly zero, with a following unsigned condition (CS/HS, CC/LO, HI, LS) depending on the value of SR set by CMN. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.10, 5.1.0B1 - 5.1.7, 5.0.4.102 Workaround: No practical workaround ------------------------------------------------------------------------------- FIXED SDSCM00050763 ------------------------------------------------------------------------------- Summary : Only the C6000 compiler accepts the GCC builtin function __builtin_constant_p Fixed in : 5.1.8 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Error emitted that GNU __builtin_constant_p function not supported. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00050825 ------------------------------------------------------------------------------- Summary : Should not require explicit S bit on CMN, TST instructions in UAL mode Fixed in : 5.1.8 Severity : S2 - Major Affected Component : Assembler Release Notes: Although CMP, CMN, and TST do set the status bits, the UAL syntax does not require an explicit S bit suffix when these instructions are used. The TI compiler should accept them without an S suffix, but it does not accept CMN or TST without the S suffix. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.10, 5.1.0B1 - 5.1.7, 5.0.4.102 Workaround: Add the S suffix when using TI compilers in UAL mode =============================================================================== 8. Defects fixed in TMS470 Code Generation Tools release 5.1.7 =============================================================================== The following 7 defects were fixed in TMS470 Code Generation Tools release 5.1.7, released July 2014. ------------------------------------------------------------------------------- FIXED SDSCM00049328 ------------------------------------------------------------------------------- Summary : Linker fails to link object that relies on section level attributes for compatibility Fixed in : 5.1.7 Severity : S2 - Major Affected Component : Linker Release Notes: The symptom of this bug is interlinking with a file generated by the ARM Ltd. (Keil) compiler. The error message is: error: file "cpu.o" does not preserve 8-byte alignment of 8-byte data, but other input files require this; incompatible files The ARM Ltd. compiler is using section level build attributes in the file. Section level and symbol level attributes are deprecated according to ARM document IHI 0045D from late 2012. The TI compiler will now issue a warning if these deprecated attributes are found, and bypass file compatibility checking. The link will continue. The user must insure that the files are compatible. Workaround: If you believe that the error message is erroneous, it can be suppressed using --diag_suppress=16012. ------------------------------------------------------------------------------- FIXED SDSCM00049997 ------------------------------------------------------------------------------- Summary : Loop with volatile loop control expression removed Fixed in : 5.1.7 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: In some cases, the optimizer can remove apparently-empty loops that have a loop test which compares the loop control variable with a volatile value. This is not legal; the volatile value could change, so the loop must be left in the code. Defect occurs in TMS470 Compiler versions: 2.54.02 - 2.54.209, 2.54.03 - 2.54.129, 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.9, 5.1.0B1 - 5.1.6 Workaround: Declare the loop counter variable as volatile ------------------------------------------------------------------------------- FIXED SDSCM00050202 ------------------------------------------------------------------------------- Summary : MISRA-C rule 19.11 false positive Fixed in : 5.1.7 Severity : S3 - Minor Affected Component : Parser Release Notes: A violation of MISRA-C rule 19.11 may be falsely detected when a use of an undefined macro is guarded by a check to make sure that the macro is defined before use: #undef X #if defined(X) && X ... #endif Workaround: Disable MISRA-C rule checking for 19.11 around the affected lines: #pragma CHECK_MISRA("-19.11") ... #pragma RESET_MISRA("19.11") ------------------------------------------------------------------------------- FIXED SDSCM00050350 ------------------------------------------------------------------------------- Summary : ARM _enable_interrupts() _disable_interrupts() had wrong implementation for 6M0 Fixed in : 5.1.7 Severity : S3 - Minor Affected Component : Code Generator Release Notes: For Cortex-M0, intrinsics _enable_interrupts(), _disable_interrupts() and _restore_interrupts() incorrectly used the FAULTMASK instead of PRIMASK. Workaround: Use inline assembly with "CPSID i" or "CPSIE i" or "MSR PRIMASK, setting" ------------------------------------------------------------------------------- FIXED SDSCM00050351 ------------------------------------------------------------------------------- Summary : --symdebug:none and --symdebug:dwarf_version conflict when using -o4 Fixed in : 5.1.7 Severity : S3 - Minor Affected Component : ILinker (File Merge) Duplicate Defects : SDSCM00048790 Release Notes: The --symdebug:none and --symdebug:dwarf_version conflict when combined during LTO. The --symdebug:none and --symdebug:dwarf options are fine together so -- symdebug:dwarf_version should not cause a problem. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00050352 ------------------------------------------------------------------------------- Summary : Combining -pm and -o4 on the command line causes an error during -o4. Fixed in : 5.1.7 Severity : S3 - Minor Affected Component : ILinker (File Merge) Release Notes: When combining the -pm and -o4 options, an error occurs during the LTO phase. These option should be allowed to work together. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00050520 ------------------------------------------------------------------------------- Summary : strip crashes on files with more than 64k sections Fixed in : 5.1.7 Severity : S2 - Major Affected Component : Strip Utility Release Notes: The strip utility will abnormally terminate if its input is an ELF file with more than 64k sections (actually exactly 0xff00), and its output would be less than 64k sections. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.9, 5.1.0B1 - 5.1.6, 5.0.4.102 Workaround: Don't strip the file =============================================================================== 9. Defects fixed in TMS470 Code Generation Tools release 5.1.6 =============================================================================== The following 9 defects were fixed in TMS470 Code Generation Tools release 5.1.6, released May 2014. ------------------------------------------------------------------------------- FIXED SDSCM00049229 ------------------------------------------------------------------------------- Summary : Symbols are missing in .debug_pubnames part of the Dwarf information Fixed in : 5.1.6 Severity : S1 - Critical / PS Affected Component : C/C++ Compiler (cl) Release Notes: This bug happens all the time. It causes the missing of .debug_pubnames section. If the users rely on the .debug_pubnames to search the global variable or function's debug information entry, he will see this bug and will have no .debug_pubnames sections. This bug should only affect debug capability. Not the execution results. Workaround: There is no work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00049326 ------------------------------------------------------------------------------- Summary : RTTI is enabled by default with no way to disable it. For C++ code, this can cause data size to double. Fixed in : 5.1.6 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: For COFF executables, when --rtti is not used, the compiler will suppress RTTI information, leaving the executable file a bit smaller. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00049421 ------------------------------------------------------------------------------- Summary : Auto-generated stress test terminate abnormally in optimizer Fixed in : 5.1.6 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: This test is a very large sequence of recurrent assignments. The compiler combines all of them into one very large statement, and crashes or aborts depending on the release and platform. The reported crash with release C6000 5.1.0 is a stack overflow that happens only on Windows. It is probably due to an inefficiency in the Windows C++ compiler that was used to build the release, but we can't reproduce the problem when we use our current Windows compiler. (C6000 5.1.0 was built in 2004.) The aborts seen in releases C6000 6.1.x through 7.x are due to an overly conservative sanity check, triggered by the very large statement. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.8, 5.1.0B1 - 5.1.5 Workaround: Compile at -o0; since the test case involves no loops or control flow, that's no less efficient than higher optimisation levels. Or reduce the size of the test case, as mentioned in the original report. Or use two or more accumulators, combined at the end, instead of one single accumulator; that reduces the maximum statement size. ------------------------------------------------------------------------------- FIXED SDSCM00049603 ------------------------------------------------------------------------------- Summary : C Initialization records are created for NOLOAD sections Fixed in : 5.1.6 Severity : S3 - Minor Affected Component : ELF Linker Release Notes: A NOLOAD output section is not allocated in the executable file created by the linker. If RAM model is used as the initialization method, the section will not be initialized by the loader since it is not allocated in memory. If ROM model is used it will be initialized because the linker creates initialization records in the .cinit section even if the section is marked NOLOAD This is a bug. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.8, 5.1.4 - 5.1.5 Workaround: Specify the type as NOINIT in addition to NOLOAD ------------------------------------------------------------------------------- FIXED SDSCM00049859 ------------------------------------------------------------------------------- Summary : Compiler fails with INTERNAL ERROR message Fixed in : 5.1.6 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The attached test case fails with this message ... INTERNAL ERROR: armacpia experienced a segmentation fault while processing function startExciteSequence file file.c line 441 This is a serious problem. Please contact Customer Support with this message and a copy of the input file and help us to continue to make the tools more robust. >> Compilation failure Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00049897 ------------------------------------------------------------------------------- Summary : Compiler tools are getting installed into tms470_xxx directory instead of arm_xxx Fixed in : 5.1.6 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: Compiler tools are getting installed into tms470_xxx directory instead of arm_xxx Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00049921 ------------------------------------------------------------------------------- Summary : Compiler generates CBZ to a label that is too far away Fixed in : 5.1.6 Severity : S2 - Major Affected Component : Code Generator Release Notes: On Cortex devices, the compiler may generate a CBZ instruction with a destination branch that is too far away. This bug can only appear when --unaligned_access=on, which is the default for Cortex devices. Defect occurs in TMS470 Compiler versions: 5.1.0B1 - 5.1.5 Workaround: Use the option --unaligned_access=off ------------------------------------------------------------------------------- FIXED SDSCM00050014 ------------------------------------------------------------------------------- Summary : Missing copyright notice on mklib.c source Fixed in : 5.1.6 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 TMS470 Compiler versions: 5.0.0B1 - 5.0.8, 5.1.0B1 - 5.1.5 Workaround: Not applicable ------------------------------------------------------------------------------- FIXED SDSCM00050023 ------------------------------------------------------------------------------- Summary : SIGSEGV when using pragma on a template function Fixed in : 5.1.6 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 TMS470 Compiler versions: 2.54.02 - 2.54.209, 2.54.03 - 2.54.129, 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.8, 5.1.0B1 - 5.1.5 Workaround: Do not apply any pragma to a template function. Move the function outside the template class. =============================================================================== 10. Defects fixed in TMS470 Code Generation Tools release 5.1.5 =============================================================================== The following 2 defects were fixed in TMS470 Code Generation Tools release 5.1.5, released February 2014. ------------------------------------------------------------------------------- FIXED SDSCM00048498 ------------------------------------------------------------------------------- Summary : MISRA-C rule 12.8 incorrectly reported for an expression like ((uint32_t)2U << 8U); Fixed in : 5.1.5 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 TMS470 Compiler versions: 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.8, 5.1.0B1 - 5.1.4 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00049443 ------------------------------------------------------------------------------- Summary : Use of .align directive with large value (>8K) may cause internal assembler error Fixed in : 5.1.5 Severity : S2 - Major Affected Component : Assembler Release Notes: This bug will occur when the assembler must generate 64K or more bits of fill to achieve the requested alignment for a symbol. One workaround is to place the symbol in a separate section. The alignment is then handled at link time by placing the section at a properly aligned location. Defect occurs in TMS470 Compiler versions: 5.1.0B1 - 5.1.4 Workaround: Place the symbol into a separate section. The alignment will apply to the section; the linker will place the section at the requested alignment. For example, the .align for func1 below may cause the bug, but the .align for func2 will work as expected. .text ... .align 32768 ; May trigger the bug func1: ... .sect ".text:func2" .align 32768 ; applied to section; assembler bug will not occur func2: ... .text ; switch back to .text section =============================================================================== 11. Defects fixed in TMS470 Code Generation Tools release 5.1.4 =============================================================================== The following 8 defects were fixed in TMS470 Code Generation Tools release 5.1.4, released February 2014. ------------------------------------------------------------------------------- FIXED SDSCM00045417 ------------------------------------------------------------------------------- Summary : bool and _Bool are not defined correctly in strict ANSI C mode Fixed in : 5.1.4 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 TMS470 Compiler versions: 4.4.0 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.9, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.8, 5.1.0B1 - 5.1.3 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 : 5.1.4 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 TMS470 Compiler versions: 4.6.0B1 - 4.6.6, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.7, 5.1.0B1 - 5.1.3 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00049165 ------------------------------------------------------------------------------- Summary : Crash on object file with very long names, such as mangled C++ templates Fixed in : 5.1.4 Severity : S2 - Major Affected Component : Disassembler (dis) Release Notes: The disassembler prints symbols as labels when disassembling an object file. If any of those labels was longer than 256 characters, the label would overflow a buffer and cause memory corruption, possibly crashing the disassembler. Labels of that length are fairly common in C++ programs using templates. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.7, 5.1.0B1 - 5.1.3 Workaround: Use "armstrip" or "armstrip -p" to remove symbols from the file. ------------------------------------------------------------------------------- FIXED SDSCM00049206 ------------------------------------------------------------------------------- Summary : #pragma CLINK does not work on initialized data Fixed in : 5.1.4 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The CLINK pragma now works as expected for initialized data. Defect occurs in TMS470 Compiler versions: 5.0.0B1 - 5.0.7, 5.1.0B1 - 5.1.3 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 : 5.1.4 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00050480 Release Notes: The compiler correctly handles const variables that are referenced in a program using templates. Workaround: declare VAR as "extern const int VAR = 1;" ------------------------------------------------------------------------------- FIXED SDSCM00049355 ------------------------------------------------------------------------------- Summary : The linker generates a relocation overflow for R_ARM_THM_ALU_PREL_11_0 when linking with IAR object files. Fixed in : 5.1.4 Severity : S2 - Major Affected Component : ELF Linker Release Notes: The current TI ARM tools do not use this relocation type. This bug occurs when interlinking with other ARM compilers; the IAR tools have been specifically found to use this relocation type. The error in the TI tools while handling this relocation type is now fixed. Defect occurs in TMS470 Compiler versions: 4.9.0 - 4.9.9, 5.0.0B1 - 5.0.8, 5.1.0B1 - 5.1.3 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00049420 ------------------------------------------------------------------------------- Summary : Trampolines generated for symbols defined in the linker command file cause a warning and are incorrect Fixed in : 5.1.4 Severity : S1 - Critical / PS Affected Component : Linker Release Notes: When a called function beyond the reach of the call instruction, the linker uses trampolines to bounce control flow to the called function. In ELF, if the called function is an absolute symbol defined in the linker command file, the linker would create a trampoline that mistakenly bounced control flow to address 0 rather than the proper address of the called function. Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.8, 5.1.0B1 - 5.1.3 Workaround: Disable trampolines with --trampolines=off or adjust the linker command file so that all calls to the function defined with an absolute symbol are in-range of the call instruction. ------------------------------------------------------------------------------- FIXED SDSCM00049448 ------------------------------------------------------------------------------- Summary : Erroneous warning about DW_CFA_def_cfa_sf being DWARF 3 specific Fixed in : 5.1.4 Severity : S2 - Major Affected Component : ELF Linker Release Notes: The linker is incorrectly identifying the CIE version as 2 when it is really 3. The linker will now correctly identify the CIE version number. Defect occurs in TMS470 Compiler versions: 4.6.0B1 - 4.6.6, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.8, 5.1.0B1 - 5.1.3 Workaround: It should be safe to ignore the warning =============================================================================== 12. Defects fixed in TMS470 Code Generation Tools release 5.1.3 =============================================================================== The following 13 defects were fixed in TMS470 Code Generation Tools release 5.1.3, released December 2013. ------------------------------------------------------------------------------- FIXED SDSCM00044118 ------------------------------------------------------------------------------- Summary : Inline jump table mistakenly gets .clink attached Fixed in : 5.1.3 Severity : S2 - Major Affected Component : Code Generator Release Notes: The compiler sometimes generates jump tables to implement switches. Usually, these jump tables are in a different section, and each section needs to be handled with the appropriate choice of .retain, .clink, or neither. In this case, as a special optimization, the jump table is actually part of the function text, and is not in its own distinct section. In this case, the compiler should not emit any .retain or .clink, but it emits .clink. The assembler detects this and (depending on the ABI) emits a warning that the .clink is ignored. Defect occurs in TMS470 Compiler versions: 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.9, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.6, 5.1.0B1 - 5.1.2 Workaround: You can ignore this warning. ------------------------------------------------------------------------------- FIXED SDSCM00046180 ------------------------------------------------------------------------------- Summary : MISRA check 14.1 should not treat while(0) as potential infinte loop Fixed in : 5.1.3 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 SDSCM00047963 ------------------------------------------------------------------------------- Summary : Incorrect float compare when one value is equal to the other but with all zero low word Fixed in : 5.1.3 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: The problem here is that the __aeabi_cdcmple function has a bug when comparing two float values that have identical upper 32 bits, but differ in the lower 32 bits, and one of them has all 0's in the lower 32 bits. The last thing that happens in __aeabi_cdcmple is a comparison of the lower bits to 0, which sets the Z bit, which is incorrect - we want C=1 Z=0 Workaround: Use 32-bit float, or link against the RTS from another vendor's EABI toolchain. ------------------------------------------------------------------------------- FIXED SDSCM00048289 ------------------------------------------------------------------------------- Summary : Errors of the linker due to the difference in version of CGT Fixed in : 5.1.3 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 SDSCM00048419 ------------------------------------------------------------------------------- Summary : ARM compiler should set the Tag_PCS_config build attribute to 1, meaning bare metal PCS. Fixed in : 5.1.3 Severity : S2 - Major Affected Component : Assembler Release Notes: The TI compiler will now set the PCS_config build attribute to value "1" aka "bare platform". It will accept tag values 0 (undefined) and 1 and mix them without a diagnostic message to ensure older object files can still be linked with newer files since this is a summary attribute and the critical checks occur on the attributes following it. Workaround: Use --diag_warning=16004 to downgrade the diagnostic to a warning if one is encountered. ------------------------------------------------------------------------------- FIXED SDSCM00048440 ------------------------------------------------------------------------------- Summary : SIGSEGV when using MISRA checks on code with an anonymous struct Fixed in : 5.1.3 Severity : S2 - Major Affected Component : Parser Duplicate Defects : SDSCM00050700 Release Notes: When using MISRA checking on code that contains an anonymous struct, the parser will crash with a SIGSEGV. Note that anonymous structs are not legal in strict ANSI mode, and MISRA emits a warning if strict ANSI mode is not used. Defect occurs in TMS470 Compiler versions: 4.8.0B1, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.7, 5.1.0B1 - 5.1.2 Workaround: Do not use anonymous structs or unions when using MISRA ------------------------------------------------------------------------------- FIXED SDSCM00048448 ------------------------------------------------------------------------------- Summary : CRC algorithm is not correct for little endian parts Fixed in : 5.1.3 Severity : S2 - Major Affected Component : Linker Release Notes: When using CRC algorithm TMS570_CRC64_ISO For little endian parts, each 64-bit chunk of data needs to be byte swapped before calculating the CRC. The linker was not correctly computing the CRC. Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.7, 5.1.0B1 - 5.1.2 Workaround: No practical workaround ------------------------------------------------------------------------------- FIXED SDSCM00048513 ------------------------------------------------------------------------------- Summary : ARM linker generates an overflow error for R_ARM_THM_PC8 relocation Fixed in : 5.1.3 Severity : S3 - Minor Affected Component : Linker Release Notes: The IAR ARM compiler produces the R_ARM_THM_PC8 relocation for 16-bit literal load instructions. The TI compiler does not produce this relocation type. It should be safe to ignore the overflow diagnostic in this case. Defect occurs in TMS470 Compiler versions: 2.41.beta - 2.71, 4.1.0 - 4.1.7, 2.54.205 - 2.54.209, 2.54.110 - 2.54.129, 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.9, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.7, 5.1.0 - 5.1.2 Workaround: There is no workaround. You should be able to ignore the error. ------------------------------------------------------------------------------- FIXED SDSCM00048534 ------------------------------------------------------------------------------- Summary : String constant with indexing operator causes compiler to emit panic error message and quit Fixed in : 5.1.3 Severity : S2 - Major Affected Component : Parser Release Notes: An indexed expression without a variable like the one below was parsed incorrectly when appearing on the right hand side of an assignment: long x = "abcd"[0]; Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00048712 ------------------------------------------------------------------------------- Summary : ARM assembler seg faults on certain input Fixed in : 5.1.3 Severity : S3 - Minor Affected Component : Assembler Duplicate Defects : SDSCM00049517 Release Notes: The problem is that the assembly instruction LDR r0,0x40004000 is not legal. The assembler believes 0x40004000 is a symbol because the user did not put a '#' in front of it. Adding the '#' produces the correct error: "Invalid addressing mode". This is still a defect because the assembler sshould not seg fault on a bad instruction. Workaround: Add the '#' in front of the 0x40004000 to produce the correct "Invalid addressing mode" error. ------------------------------------------------------------------------------- FIXED SDSCM00048747 ------------------------------------------------------------------------------- Summary : Using END(sym_name) or SIZE(sym_name) on .cinit can cause link to fail Fixed in : 5.1.3 Severity : S2 - Major Affected Component : ELF Linker Release Notes: When the compression is performed, the size of the parent collection needs to be updated. Workaround: Avoid the use of the END() or SIZE() operators for .cinit or other compressed sections. ------------------------------------------------------------------------------- FIXED SDSCM00048936 ------------------------------------------------------------------------------- Summary : Linker generated ECC is not correct for F035 devices Fixed in : 5.1.3 Severity : S2 - Major Affected Component : Linker Release Notes: When the input required padding due to the mirroring scheme, the algorithm failed to take the length of padding into account when computing the ECC values, leading to incorrect ECC data. This manifested in the F035 mirroring scheme. Defect occurs in TMS470 Compiler versions: 5.0.0B1 - 5.0.7, 5.1.0B1 - 5.1.3 Workaround: Use the NowECC tool to generate ECC for F035 ------------------------------------------------------------------------------- FIXED SDSCM00049035 ------------------------------------------------------------------------------- Summary : Value of "weak" global incorrectly propagated into function Fixed in : 5.1.3 Severity : S2 - Major Affected Component : Optimizer Release Notes: When using a weak symbol def with an initializer, the weak symbol could be pre-empted with a strong symbol from another compilation unit. The optimizer is not entitled to assume that weak definition is actually used, and thus cannot assume its initializer is the actual value it has at runtime. However, the optimizer mistakenly copied the value of the initializer into the function where the variable was used, which led to an error when the symbol was pre-empted by a strong symbol with a different value. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.121, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.9.0B1 - 4.9.9, 5.0.0B1 - 5.0.7, 5.1.0B1 - 5.1.2 Workaround: Do not use an explicit initializer with weak symbol definitions, or use optimization level -o2 or lower. =============================================================================== 13. Defects fixed in TMS470 Code Generation Tools release 5.1.2 =============================================================================== The following 8 defects were fixed in TMS470 Code Generation Tools release 5.1.2, released September 2013. ------------------------------------------------------------------------------- FIXED SDSCM00013456 ------------------------------------------------------------------------------- Summary : fgets in _IONBF mode does not respect size limit Fixed in : 5.1.2 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 TMS470 Compiler versions: 2.40 - 2.71, 4.1.0B1 - 4.1.7, 2.54.203 - 2.54.209, 2.54.03 - 2.54.129, 4.3.0B1, 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.120, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.201 - 4.7.1.202, 4.10.0B1, 5.0.0B1 - 5.0.6, 5.1.0B1 - 5.1.1 Workaround: Do not use _IONBF mode ------------------------------------------------------------------------------- FIXED SDSCM00029483 ------------------------------------------------------------------------------- Summary : asm470 crash on bad asm instruction Fixed in : 5.1.2 Severity : S2 - Major Affected Component : Assembler Release Notes: The instruction in this test case (" MOV R0 #0") is missing a comma; the assembler discarded the #0 part as extra garbage, so the instruction looks like only one operand is provided. A function in the assembler which is checking whether the instruction can be a THUMB2 instruction, but doesn't check that the operand is non-NULL, leading to a NULL pointer dereference, which will crash the assembler. Defect occurs in TMS470 Compiler versions: 4.4.0 - 4.4.18, 4.5.0 - 4.5.2, 4.4.10.100 - 4.4.10.120, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.200 - 4.7.1.202, 4.10.0B1, 5.0.0B1 - 5.0.6, 5.1.0B1 - 5.1.1 Workaround: Provide the correct number of operands to this kind of instruction, separated by commas where required. You can quickly find most of the errors in the instructions at issue by assembling in ARM mode, where the appropriate error messages will appear without the crash. ------------------------------------------------------------------------------- FIXED SDSCM00043860 ------------------------------------------------------------------------------- Summary : Printf format %#06x prints zeros in the wrong place Fixed in : 5.1.2 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 TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.120, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.6, 5.1.0B1 - 5.1.1 Workaround: Avoid using both # and 0 flags when using the x conversion specifier. ------------------------------------------------------------------------------- FIXED SDSCM00047502 ------------------------------------------------------------------------------- Summary : linker fails with internal error if .cinit and .data are in the same GROUP Fixed in : 5.1.2 Severity : S2 - Major Affected Component : Linker Release Notes: The internal error was caused by attempting to place .cinit in a GROUP with .data in an ELF file. This is not a recommended practice. The fix will allow .cinit and .data in a GROUP only if .data preceeds .cinit. In that case, compression of cinit records can not be performed. If .cinit is placed before .data in a GROUP, a user level error is reported. Defect occurs in TMS470 Compiler versions: 4.9.0 - 4.9.8, 5.0.0B1 - 5.0.6, 5.1.0B1 - 5.1.1 Workaround: Move .cinit so that it is not in any GROUP ------------------------------------------------------------------------------- FIXED SDSCM00047774 ------------------------------------------------------------------------------- Summary : In some cases, compiler fails to use unaligned load when reading members of a packed structure Fixed in : 5.1.2 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The compiler issues an unaligned load instruction LDNW when reading a member of a structure. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00047883 ------------------------------------------------------------------------------- Summary : bsearch failure when using -pr relaxed ANSI mode or --gcc mode from C++ Fixed in : 5.1.2 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 SDSCM00048263 ------------------------------------------------------------------------------- Summary : _sxtb16(x, 0) in Thumb-2 mode gives INTERNAL ERROR: no match Fixed in : 5.1.2 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: When using the intrinsic _sxtb16 with 0 as the second argument in Thumb-2 mode (Cortex-M4 or Cortex-A8/R4 in thumb mode), the compiler will abort with an internal error message. Defect occurs in TMS470 Compiler versions: 5.1.0B1 - 5.1.1 Workaround: For Cortex-A8/R4, compile the function in ARM mode. No practical workaround for Cortex-M4. ------------------------------------------------------------------------------- FIXED SDSCM00048272 ------------------------------------------------------------------------------- Summary : Compiler uses non-UAL syntax for SWI in UAL mode Fixed in : 5.1.2 Severity : S3 - Minor Affected Component : Code Generator Release Notes: When compiling for a pre ARMv7 (Cortex) architecture in Thumb mode, the compiler will emit an SWI for the _call_swi intrinsic, and the assembler will emit a warning that SWI is not UAL form. Defect occurs in TMS470 Compiler versions: 5.1.0B1 - 5.1.1 Workaround: Ignore the warning =============================================================================== 14. Defects fixed in TMS470 Code Generation Tools release 5.1.1 =============================================================================== The following 0 defects were fixed in TMS470 Code Generation Tools release 5.1.1, released October 2013. =============================================================================== 15. Defects fixed in TMS470 Code Generation Tools release 5.1.0 =============================================================================== The following 89 defects were fixed in TMS470 Code Generation Tools release 5.1.0, released July 2013. ------------------------------------------------------------------------------- FIXED SDSCM00037422 ------------------------------------------------------------------------------- Summary : Incorrect layout in .cdecls struct Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Assembler Release Notes: The attached test case defines a structure which contains a union. The last field in the structure is assigned the offset 9 by the compiler. The assembler, via .cdecls, assigns that same field the offset 10. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00041192 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning for violation of Misra 9.2 Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: Compiler misreports Misra 9.2 warning for zero initialization of single dimension float arrays, like the one below: float array[ 10 ] = {0.0f}; Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00041434 ------------------------------------------------------------------------------- Summary : Compiler optimizes away certain calls to assert() Fixed in : 5.1.0 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 TMS470 Compiler versions: 2.41.beta - 2.50.beta, 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.116, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.209, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.5, 4.7.1.201 - 4.7.1.202, 5.0.0B1 Workaround: Instead of "assert(p)", use "if (!p) assert(0)", which will still abort at the same place under the same conditions, but will have a different error message. More elaborately, implement a function equivalent to assert() but with a different name, that the compiler will not recognise as a system function. ------------------------------------------------------------------------------- FIXED SDSCM00041971 ------------------------------------------------------------------------------- Summary : Spurious remark generated from __STDC_VERSION__ ref in stddef.h in C++ mode Fixed in : 5.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 SDSCM00042194 ------------------------------------------------------------------------------- Summary : Partial link drops weak function symbol Fixed in : 5.1.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The linker now copies the weak symbol into the output file Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00042292 ------------------------------------------------------------------------------- Summary : In EABI mode string literals used in member functions result in static members of the class and not placed in .const:.string Fixed in : 5.1.0 Severity : S2 - Major Classification : Performance Affected Component : Parser Release Notes: In EABI mode, the compiler was incorrectly creating static class member char arrays for string literals used in member functions instead of putting them in .const:.string. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00042332 ------------------------------------------------------------------------------- Summary : Don't generate typeinfo when not used Fixed in : 5.1.0 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 SDSCM00042417 ------------------------------------------------------------------------------- Summary : #pragma WEAK; 'if (f)' gets eliminated even if 'f' is a weak function Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00044527 Release Notes: EABI mode allows weak symbol references. If the symbol is weak and not defined, its address is zero. The compiler incorrectly assumes that the address of a weak symbol is non-zero and simplfies comparisons of &symbol to true, but it should not. In other words, if the user writes "if (&symbol) symbol_is_defined();", symbol_is_defined will be called even if symbol is weak and not defined. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.118, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.3 Workaround: Create a volatile pointer to hold the weak pointer value before using it in any comparisons, including the test in an if statement. ------------------------------------------------------------------------------- FIXED SDSCM00042444 ------------------------------------------------------------------------------- Summary : Expression that multiplies two constants incorrectly triggers MISRA rule 10.1 about implicit conversion Fixed in : 5.1.0 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 SDSCM00042581 ------------------------------------------------------------------------------- Summary : Linker fails with internal error: lnk6x failed to allocate memory Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Linker Release Notes: The linker could report an internal error due to a memory allocation failure in certain cases. This bug involves the linker options --make_static, --localize, or --hide. If any of these options is used in a partial link, then the final link may produce the internal error. The linker was localizing comdat symbols during the partial link, which is incorrect behavior. The result was that the comdat symbols could not be resolved in the final link, but this was not detected properly, causing the memory allocation failure. One example of a comdat symbol is a static data member of a template class. The static data member must be resolved to a single instance, so it can not be localized during the partial link. This bug fix ensures that --make_static, --localize, and --hide do not affect comdat symbols during the partial link, and lists these symbols in the mapfile if requested. Also, if a similar symbol resolution error is encounted due to some other cause, the linker will now detect and report the error instead of encountering a memory allocation error later in the linking process. Defect occurs in TMS470 Compiler versions: 4.4.0 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.2 Workaround: This bug can only be triggered if a partial link is performed using the --make_static, --localize or --hide option (the memory allocation failure will occur during the final link, however). Removing that option is one way to avoid this bug. Alternatively, the partial link step may be removed from the build process, if possible. ------------------------------------------------------------------------------- FIXED SDSCM00042595 ------------------------------------------------------------------------------- Summary : Compiler generates an internal error "no match for COMPARE" for the attached testcase Fixed in : 5.1.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Use of unsigned long long types in a comparison causes a codegen crash. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00042600 ------------------------------------------------------------------------------- Summary : Ill advised enum scalar usage gets MISRA diagnostic, but similar usage of enum array does not Fixed in : 5.1.0 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 SDSCM00042811 ------------------------------------------------------------------------------- Summary : printf("%d") with negative values incorrect for printf_support=minimal Fixed in : 5.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 TMS470 Compiler versions: 5.0.0B1 Workaround: Use printf_support=nofloat ------------------------------------------------------------------------------- FIXED SDSCM00042914 ------------------------------------------------------------------------------- Summary : Linker segfault using partial link output file of C++ source with ELF and exceptions enabled Fixed in : 5.1.0 Severity : S2 - Major Affected Component : ELF Linker Release Notes: The linker fails with a segmentation fault when using a file created by partial linking C++ code with exceptions enabled and using the ELF file format. While the first (partial) link appears to succeed, a second link using the (corrupted) output file from the partial link causes the linker to segfault and stop. Workaround: Re-link partial linked output file with a fixed linker, then perform final link again with the now correct partial link output file. ------------------------------------------------------------------------------- FIXED SDSCM00043036 ------------------------------------------------------------------------------- Summary : Assembler generates segmentation fault Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Assembler Release Notes: Assembler generates segmentation fault when compiling certain files Workaround: Remove or modify the asm statement that attempts to access a C function parameter. ------------------------------------------------------------------------------- FIXED SDSCM00043069 ------------------------------------------------------------------------------- Summary : CDP instruction not accepted for v4 versions Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Assembler Release Notes: The CDP instruction generates an assembler error for version v4 in arm-mode. Workaround: Assemble at version v5e or higher. ------------------------------------------------------------------------------- FIXED SDSCM00043143 ------------------------------------------------------------------------------- Summary : Compiler incorrectly rewrites expression as rotate operation Fixed in : 5.1.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The problem could occur when an expression matches one of: x << a | y >> b if a + b = vsz x >> a | y << b if a + b = vsz x << z | y >> (vsz - z) x << (vsz - z) | y >> z Where: a and b are constant integers vsz is the size of x and y in bits When all of: x and y are expressions involving . or -> operators with the same left-hand sides x and y are of exactly the same type x and y are of unsigned type Effect of optimization: When compiler optimizer is enabled at -O1 or higher, the optimizer may transform equivalent code sequences into an expression which causes the problem to occur. For example, the sequence { int x = s.a, y = s.b; return x << 16 | y >> 16; } could still cause the problem despite the shift/or expression not directly including a . or -> operator. This includes sequences which may be generated as a result of function inlining. Workaround: Workaround 1: Make sure x and y can't include structure references, for example by using a function such as the following to compute the expression: #pragma FUNC_CANNOT_INLINE(f); /* omit "(f)" in C++ */ unsigned f(unsigned x, unsigned a, unsigned y, unsigned b) { return x << a | y >> b; } Workaround 2: Use volatile temporaries for x and y, for example: volatile int x = s.a; volatile int y = s.b; return x << 16 | y >> 16; ------------------------------------------------------------------------------- FIXED SDSCM00043152 ------------------------------------------------------------------------------- Summary : Optimizer issues information advice using optimizer's temporary symbols instead of using symbols from user code Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Optimizer Release Notes: The optimiser may issue alias advice that refers to the optimiser's temporary symbols, whose declarations the user cannot control. This advice does not affect the code's behavior, though it leaves some suggested improvements inaccessible. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.114, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.209, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.3, 4.7.1.201 - 4.7.1.202 Workaround: None. Ignore the bad advice, or try to ascertain which user variable the temp refers to by studying the optimiser comments in the .asm file. ------------------------------------------------------------------------------- FIXED SDSCM00043174 ------------------------------------------------------------------------------- Summary : Linker fails to honor specific placement for function from RTS library Fixed in : 5.1.0 Severity : S2 - Major Affected Component : COFF Linker Release Notes: Linker now honors section placement specification. Workaround: Do not include libc.a option. ------------------------------------------------------------------------------- FIXED SDSCM00043223 ------------------------------------------------------------------------------- Summary : Compiler may miss alias given struct-of-array-of-structs Fixed in : 5.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 TMS470 Compiler versions: 4.8.0B1, 4.9.0B1 - 4.9.3, 5.0.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 SDSCM00043229 ------------------------------------------------------------------------------- Summary : Instruction reordering alters logic Fixed in : 5.1.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: A sequence of code that initialises a struct by assignments to its fields, then copies the whole struct to another struct, then reads the fields individually, may sometimes read before the struct copy has happened. This situation has been observed when the initialisation is in an inlined function (and thus the struct-to-struct copy mimics the return from the callee), the struct read is defined within a scope that is not at top level, and another non-top-level scope defines a local array. Workaround: No general workaround is known, aside from compiling with -o0 or -o1.. This specific case can be worked around by removing the extra braces around the bulk of the body of main(), or by inhibiting the inlining of GetPrms(). ------------------------------------------------------------------------------- FIXED SDSCM00043326 ------------------------------------------------------------------------------- Summary : Extremely long (templated) type names may overflow buffer, causing crash Fixed in : 5.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 TMS470 Compiler versions: 2.166e - 2.178e, 2.209e, 2.40.beta - 2.71, 4.1.0B1 - 4.1.7, 2.54.02 - 2.54.209, 2.54.03 - 2.54.129, 2.202.03e - 2.202.15e, 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.114, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.209, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.3, 4.7.1.201 - 4.7.1.202, 5.0.0B1 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00043468 ------------------------------------------------------------------------------- Summary : Compiler update for Silicon Erratum Cortex-R4#57 for TMS570LS3xxx Fixed in : 5.1.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Please reference errata SPNZ181, Cortex-R4#57 http://www.ti.com/lit/er/spnz181a/spnz181a.pdf The --arm_vmrs_si_workaround=on|off option was added to prevent a conditional VMRS instruction from being generated by the compiler. By default, the option is enabled (on). A warning will be emitted if a developer attempts to add a conditional VMRS instruction to the assembly file when the option is enabled. The developer can turn the option off using --arm_vmrs_si_workaround=off. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00043538 ------------------------------------------------------------------------------- Summary : The --unaligned_access=on option is not valid for v4 and v5e architectures Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Shell Release Notes: The ARM9 and ARM7 cores do not support unaligned accesses in the hardware. The compiler --unaligned_access=on option should not be used when generating code for these cores. For ARM11 and up, the hardware can be configured to support unaligned accesses. If the hardware support is enabled, the user can use the --unaligned_access=on option to enable the compiler to generate these accesses. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00043642 ------------------------------------------------------------------------------- Summary : Compiler incorrectly simplifies "(x >> k1) < k2" when k2 is constant smaller than int Fixed in : 5.1.0 Severity : S1 - Critical / PS Affected Component : C/C++ Compiler (cl) Release Notes: Given an IF with a predicate like "(x >> k1) < k2", the compiler will attempt to convert it to "x < (k2<.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 : 5.1.0 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 TMS470 Compiler versions: 5.0.0B1 Workaround: No practical workaround ------------------------------------------------------------------------------- FIXED SDSCM00043868 ------------------------------------------------------------------------------- Summary : Linker cannot find include file specified with relative path Fixed in : 5.1.0 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 SDSCM00043948 ------------------------------------------------------------------------------- Summary : IF predicate with negative integer factor simplifies incorrectly Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: An IF predicate with a negative integer factor -- eg, "if (x*(-3) == -9)" -- may be simplified incorrectly, for instance to "if (x == -3)" instead of the correct "if (x == 3)". Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.116, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.209, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.5, 4.7.1.201 - 4.7.1.202, 5.0.0B1 Workaround: None. Avoid the situation. ------------------------------------------------------------------------------- FIXED SDSCM00043966 ------------------------------------------------------------------------------- Summary : Second instance of three-operand associative op may miscompile Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: If two three-operand expressions using the same associative operator and two of the same operands occur in the same function -- for example, x*x*x and 30*x*x -- the second expression may miscompile and be treated as identical to the first. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.116, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.209, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.5, 4.7.1.201 - 4.7.1.202, 5.0.0B1 Workaround: Compile at -o1 or -o0, or avoid the situation. ------------------------------------------------------------------------------- FIXED SDSCM00044012 ------------------------------------------------------------------------------- Summary : Optimizer crash Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: Certain intrinsic operations are commutative -- their operands can occur in either order. Many of these are parallel versions of common commutative operations, like _add2, or specialised versions, like _smpy. Minimum and maximum operations also have commutative intrinsics, _min2 and _maxu4 for example. When one of these commutative intrinsics appears in a reduction -- an expression like x = _op(x, k); -- inside nested loops, the optimiser may crash. It is looking for similar kinds of expressions, but isn't handling intrinsics correctly. The compiler will either produce correct code here, or crash; it will not silently produce incorrect code. Some of these intrinsics can be introduced by the compiler itself, based on the original source code. The motivating case for this bug report looks like for (i = a; i < b; i++) for (j = c; j < d; j++) { t = ...; if (t < min) min = t; } and the compiler transformed the IF into _min2. For the problem to occur, the required ingredients are a commutative intrinsic or expressions that can be transformed into one, inside a nest of two loops that are simple enough that the outer loop may be unrolled. The workaround is to add "#pragma UNROLL(1)" to the outer loop, or to compile at -o1 or -o0, to prevent the transformation where the crash occurs. Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.5, 4.10.0B1, 5.0.0B1 Workaround: Try "#pragma UNROLL(1)" ahead of the outermost for-loop, or compile with -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00044048 ------------------------------------------------------------------------------- Summary : Enabling vectorization produces incorrect code Fixed in : 5.1.0 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 TMS470 Compiler versions: 4.4.10.100 - 4.4.10.116, 4.9.0B1 - 4.9.6, 5.0.0B1 - 5.0.0 Workaround: Disable vectorization or optimization. ------------------------------------------------------------------------------- FIXED SDSCM00044066 ------------------------------------------------------------------------------- Summary : opt470 experienced a segmentation fault Fixed in : 5.1.0 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 : 5.1.0 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 TMS470 Compiler versions: 5.0.0B1 Workaround: Recompile older object files with the newer compiler, or switch back to using the older compiler for all stages of the build. ------------------------------------------------------------------------------- FIXED SDSCM00044227 ------------------------------------------------------------------------------- Summary : Compiler may not ensure uniqueness of static variables in C++ templates Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Parser Duplicate Defects : SDSCM00043437 Release Notes: In EABI mode, static variables in template functions and static data members of template classes may not be properly allocated and/or initialized. Templates are typically defined in header files, resulting in separate instances in each translation unit (source file). The tools must merge these multiple instances into unique instances, and ensure that static objects are allocated and initialized only once. There are three specific cases in which these mechanisms may fail, resulting in incorrect behavior of the program. They are: 1. A static variable in a template function, or a static variable in a member function of a template class, may not be allocated as a single unique object. This error occurs only when all of the following conditions occur: - the function is not declared inline, AND - the function is not implicity inline by virtue of having its body defined within the template class, AND - the function body is compiled in multiple translation units (i.e. the definition is in a header file). For example: template void f() { static int var; // ... } If this function definition is compiled into multiple translation units, the compiler may incorrectly create multiple instances of 'var'. Additionally, the compiler may incorrectly allocate 'var' into a section with other variables. This may cause unexpected behavior during linking, such as incorporating of unreferenced sections into the link, or changing the contents of the data section from link to link (depending on which copy of 'f()' arbitrarily gets linked in). A workaround for this defect is to declare the function f() as inline. 2. Under the same conditions described in case 1, if the static variable is initialized with a constructor, the constructor may incorrectly be called multiple times. For example: template void f() { static T var; // ... } The constructor T::T() may be called multiple times to initialize 'var'. Declaring f() as inline also works around this problem. 3. Similarly, if a static data member of a template class is initialized with a constructor, the constructor may incorrectly be called multiple times. This occurs only when all of the following conditions occur: - the definition (not the declaration) of the data member appears in multiple translation units, AND - the member is referenced in multiple translation units in which the definition occurs. For example: template class MyClass { static T var; // declaration }; // definition template T MyClass::var; // may call T::T() multiple times A workaround for case 3 is to move the definition from a header file to a .cpp file, so that it only occurs once. Workaround: 1. If a template function, or member function of a template class, has a static varaible, declare the function 'inline'. 2. If a template class has a static data member with initialization by constructor, put the definition of the data member in a .cpp file rather than a .h file. ------------------------------------------------------------------------------- FIXED SDSCM00044242 ------------------------------------------------------------------------------- Summary : FPEXC register not properly restored before existing assembly function Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Code Generator Release Notes: In VFPv2, the FPEXC register will be updated for any unsupported VFP instruction. The FPEXC register is now properly saved and restored when the FPEXC register might be modified inside an interrupt function when VFP is enabled for either VFPv2,3,4. Workaround: Disable VFP support. ------------------------------------------------------------------------------- FIXED SDSCM00044264 ------------------------------------------------------------------------------- Summary : Internal error on 0/(-DBL_MIN/2) Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Code Generator Release Notes: A constant expression of the form "0 / (-DBL_MIN / 2)" will cause the compiler to terminate with an internal error. In floating-point arithmetic, this is a well-formed expression. If denormal numbers are supported, the correct result is -0.0. Otherwise, the result is NaN, and the "invalid" floating point exception may be raised. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.6, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.1 Workaround: Move at least one of the operands into a variable. ------------------------------------------------------------------------------- FIXED SDSCM00044285 ------------------------------------------------------------------------------- Summary : scanf %[^ mistakenly writes EOF to output Fixed in : 5.1.0 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 SDSCM00044363 ------------------------------------------------------------------------------- Summary : LDM instruction generates internal error: unexpected operand in LDM/STM conversion Fixed in : 5.1.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: LDM instruction "LDM sp!, {lr}" generates internal error: unexpected operand in LDM/STM conversion The compiler now accepts LDM instructions with only one register in the register list operand. Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00044393 ------------------------------------------------------------------------------- Summary : Linker silently ignores an output section placement spec with missing ">" in the SECTIONS directive Fixed in : 5.1.0 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 SDSCM00044450 ------------------------------------------------------------------------------- Summary : Parser allows virtual base classes that are too large Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Parser Release Notes: In EABI, due to the RTTI implementation, the compiler can only handle virtual base classes of a certain size. The parser incorrectly computed this size and did not emit a warning for very large virtual base classes that were too large. This would lead to data corruption. Defect occurs in TMS470 Compiler versions: 4.1.0B1 - 4.1.7, 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.6, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.0 Workaround: Do not allow any object to inherit from virtual base classes with total size larger than approximately 0x7ffff0 ------------------------------------------------------------------------------- FIXED SDSCM00044474 ------------------------------------------------------------------------------- Summary : Compiler generates Internal error: Constant table error Fixed in : 5.1.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00044071 Release Notes: Compiler generates Internal error: Constant table error Workaround: There is an issue with the compiler pass that embeds constant definitions so that the references to these constants efficiently reach the definitions. The issue manifests when encountering large string constants that are placed close together in straight line code. A possible workaround is to try assigning pointers to the large string constants and use the pointers. For example: Instead of func(parm1,parm2, "A very long string constant ....") try: const char *sptr = "A very long string constant ..."; : func(parm1,parm2,sptr); ------------------------------------------------------------------------------- FIXED SDSCM00044536 ------------------------------------------------------------------------------- Summary : Fix to CQ44227 causes incompatible object code resulting in link failure Fixed in : 5.1.0 Severity : S2 - Major Affected Component : ELF Linker Release Notes: The fix to CQ44227 creates an object code incompatibility with object code from previous toolsets, which can cause a C++ program consisting of code from both to fail to link. CQ44227 was an issue with static data members of template classes and functions, which require an initialization guard variable to insure one-time initialization. The guard variable was introduced into the same COMDAT section as the static data member. The issue is that if code from an older toolset (which does not contain the guard) is linked with code from a newer toolset (which does), the linker may choose the COMDAT group without the guard, thus leaving no definition for the guard. This can trigger an undefined symbol error, or, if the object code is in a library, cause the linker to hang. This problem occurs only under the following conditions: - a static variable in a template function or static data member requires initialization by constructor (as described in CQ44227) - For C6x, the program includes object code compiled by version 7.3.6 of the C6x compiler, as well as object code compiled by an eariler version. - For ARM, the program includes object code compiled by version 4.9.6 or 5.0.0, as well as object code compiled by an earlier version. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00044719 ------------------------------------------------------------------------------- Summary : Linker fails with unhandled exception Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Linker Release Notes: Linker fails with unhandled exception All version 5.0.0 object file manipulation tools crash when attempting to read a pre-5.0.0 EABI object file with build attribute OFBA_ARM_Tag_compatibility set. This build attribute is not usually set. This means that 5.0.0 cannot be used when OFBA_ARM_Tag_compatibility is written to the object file. Defect occurs in TMS470 Compiler versions: 5.0.0 Workaround: There is no workaround. ------------------------------------------------------------------------------- FIXED SDSCM00044735 ------------------------------------------------------------------------------- Summary : EXIDX_CANTUNWIND yields invalid memory read Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: If an exception is thrown that tries to propagate up through any C-compiled function, the RTS must call std::terminate(). The linker is responsible for fabricating CANTUNWIND entries in the EXIDX table for C functions so that the unwinder knows it has unwound to a C function. If the C function happens to be placed after the last C++ text section, the linker doesn't create such an EXIDX entry. This is a bug in the RTS. The EXIDX lookup does check whether it is running off the end of the EXIDX table, but when it does, it mistakenly attempts to read a value from just beyond the end of the table. This problem only occurs in EABI. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.6, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.0 Workaround: This bug can only occur when the program is terminating due to a problem with an uncaught exception. To work around the issue, ensure that C++ functions which might be called from a C function catch all exceptions. ------------------------------------------------------------------------------- FIXED SDSCM00044736 ------------------------------------------------------------------------------- Summary : Loop nest over two-dimensional array compiles wrong if inner loop has early exit Fixed in : 5.1.0 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 TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.6, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.1 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 SDSCM00044738 ------------------------------------------------------------------------------- Summary : EABI partial linking omits referenced library functions which refer to unresolved symbols Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Linker Release Notes: The bug could happen when partial link is used. Also one or more files partially linked are compailed with optimization. The optimizer recognized some function as alias function. The paritial does not handle alias function correctly. Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.8, 5.1.0B1 Workaround: There is no work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00044775 ------------------------------------------------------------------------------- Summary : Missed dependence between x[i+4] and x[i] when i unsigned Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00045067 Release Notes: A loop with a write to x[i+k1] and a read from x[i+k2], where i is an unsigned integral type and k1 and k2 are constants, may produce incorrect answers, because the compiler will not recognise the dependence between the two accesses. Whether or not the result is correct is due to variations in the scheduling of instructions in the compiler output. The compiler misses the dependences because it doesn't properly sign-extend the unsigned difference computation and ends up with a large positive number instead of the correct small negative one. Defect occurs in TMS470 Compiler versions: 4.8.0B1, 4.9.0B1 - 4.9.6, 5.0.0B1 - 5.0.1 Workaround: Change "i" from unsigned to signed, from UINT32 to INT32. ------------------------------------------------------------------------------- FIXED SDSCM00044817 ------------------------------------------------------------------------------- Summary : Assembler reports "Illegal mnemonic" for RFEFD when compiled for Thumb2 Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Assembler Release Notes: Assembler reports "Illegal mnemonic" for RFEFD instruction when compiled for Thumb2 Assembler now accepts REFEA , REFFD , SRSFD, SRSEA pseudo instructions while in thumb mode. Workaround: Change RFEFD assembly instruction to RFEIA. ------------------------------------------------------------------------------- FIXED SDSCM00045105 ------------------------------------------------------------------------------- Summary : Empty struct as field of parent struct may cause optimizer abort Fixed in : 5.1.0 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 TMS470 Compiler versions: 4.9.1 - 4.9.6, 5.0.0B1 - 5.0.1 Workaround: Add a dummy field to the empty struct. ------------------------------------------------------------------------------- FIXED SDSCM00045173 ------------------------------------------------------------------------------- Summary : Missing qsort and bsearch implementations for comparison functions with C++ linkage Fixed in : 5.1.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The C++ standard requires two distinct prototypes for qsort, one for comparison functions with C linkage, and one for comparison functions with C++ linkage. The C++ linkage implementation was missing, which would lead to an incompatible parameter error when trying to use qsort in C++ with a comparison function that has C++ linkage. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.119, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.4, 5.1.0B1 Workaround: Declare the comparison function extern "C" ------------------------------------------------------------------------------- FIXED SDSCM00045211 ------------------------------------------------------------------------------- Summary : Linker GROUP directive fails to allow NOINIT output sections and regular output sections to be together in the group Fixed in : 5.1.0 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 TMS470 Compiler versions: 5.0.0B1 - 5.0.3 Workaround: None. However, the type keyword should not be applied to GROUPs. ------------------------------------------------------------------------------- FIXED SDSCM00045232 ------------------------------------------------------------------------------- Summary : Incorrect linker symbol value after multiple partial links Fixed in : 5.1.0 Severity : S2 - Major Affected Component : ELF Linker Release Notes: Linker symbols whose values depend on section placement were getting assigned absolute values instead of section relative values in partial links. These are symbols that are defined using the '.' operator, and/or those defined using the linker command file keywords such as START, END, LOAD_START etc. As a result, the final link would assign incorrect values to these symbols. Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.6, 5.0.0B1 - 5.0.1 Workaround: Create a large memory region in the linker command files for use during each partial link that defines memory starting at address zero. ------------------------------------------------------------------------------- FIXED SDSCM00045246 ------------------------------------------------------------------------------- Summary : Workaround for Stellaris ARM cache silicon errata Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Code Generator Release Notes: Added a workaround for the silicon errata as described in the document "Stellaris LM4FS1AH5BB Rev A1/A2". This workaround is enabled through the --stellaris_cache_si_workaround compiler switch. If a word-aligned value is loaded from an SRAM location into a core register, then altered by storing a byte or halfword at an unaligned offset, the altered word-aligned value is not correctly indicated when loaded into a core register. The loaded value from the SRAM location into a core register will reflect the original value, not the modified value. The following assembly sequence causes the altered value loaded into a core register to not load the correct value, even though the correct value is visible in the SRAM memory location: LDR R0, [SP, #+0]; STRB R0, [SP, #+1]; (STRH can cause silicon exception as well) LDR R0, [SP, #+0]; This assembly sequence causes erroneous values only if these three instructions are executed in this order. However, the three instructions do not have to be consecutive, which means that other instructions can be placed in between the first and the second instructions or the second and the third instructions and the false value will still occur. The solution is to insert after the STR: STR V1, [SP, #-4]; LDR V1, [SP, #-4]; This forces the cached value to be reloaded from memory The compiler switch will add the necessary extra STR, LDR instruction to and from the stack. The --unaligned_access=on option cannot be used with the --stellaris_cache_si_workaround switch. If a user tries to do so, a warning will be emitted and unaligned accesses will be disabled. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00045357 ------------------------------------------------------------------------------- Summary : Linker generates unhandled exception when generating dynamic library Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Linker Release Notes: Linker sometimes generates unhandled exception when generating dynamic library The ELF executable was statically linked because it could not be dynamically linked. The executable should not have been statically linked. The linker now emits an error when an executable cannot be statically or dynamically linked. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00045373 ------------------------------------------------------------------------------- Summary : EXIDX section for alias function leads to INTERNAL ERROR unhandled exception Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Linker Release Notes: If all of --exceptions, --unused_section_elimination=off, and --retain=.ARM.EXIDX are used, and the compiler turns a C++ function into an alias (this is a TI-specific optimization), it is possible for the linker to retain the EXIDX section for the alias function but not the alias function itself, which leads to an internal error. Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.7, 5.0.0B1 - 5.0.4, 5.1.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 SDSCM00045381 ------------------------------------------------------------------------------- Summary : Read of array element, before memcpy() overwrites it, may be out of order Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: The two statements a = x[0]; memcpy(&x[0], &x[1], K); may not occur in the correct order under certain conditions at -o2 and above. The memcpy() may overwrite the first element before it is saved in the variable. The problem is specific to memcpy(). Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.3 Workaround: The test case is using memcpy() to implement a shift register in an array. More efficient, and also avoiding the problem, is to use a circular-queue arrangement: instead of having the head of the queue always be x[0] and implementing a pop by shifting the whole array, have the head be x[head] and implement the pop as head=(head+1)%arraysize. Or use -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00045550 ------------------------------------------------------------------------------- Summary : Truncated pointer created by cast from integer constant Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: For an expression of the form ((t *)c1+c2), where t is an arbitrary type and c1 and c2 are integer constants small enough to fit in a type smaller than int, the optimizer could mistakenly truncate the sum of c1 and c2 to the smaller type. It is possible for other optimizations to create this expression through simplification of other expressions. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.3 Workaround: Don't use the optimizer at all for source files which contain pointer math of the form shown in the release notes. ------------------------------------------------------------------------------- FIXED SDSCM00045562 ------------------------------------------------------------------------------- Summary : Multiplication by power-of-2 wider than int may use wrong type Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: When multiplying a variable of a type the same size as int, or smaller, by a constant power of two with a type wider than int, the compiler may convert the multiply into a shift-left, and use the wrong type, thus computing the wrong answer. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.2 Workaround: Make the variable the same wider-than-int type as the constant. Casting it may also work. Or compile at -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00045660 ------------------------------------------------------------------------------- Summary : Different code generated on Linux and PC under the same option for the same source code Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: In some cases, the same code compiled with the same version of the compiler may produce different asm on Windows than on Linux. The reason is some unstable sorting of equivalent internal rules and inlineable call sites. The two systems will sort differently in these cases and the resulting asm will vary; in some cases, performance will also be different. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.2 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00045724 ------------------------------------------------------------------------------- Summary : CCS disassembles FMRX and FMXR instructions incorrectly on CortexR4 Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Disassembler (dis) Release Notes: CCS disassembles FMRX instruction as FMXR and FMXR instruction as FMRX on CortexR4 The assembled FMRX instruction is incorrectly disassembled as a VMSR instead of a VMRS instruction due to a decoding error. The assembled FMXR instruction is also incorrectly disassembled as a VMRS instead of a VMSR instruction. Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00045742 ------------------------------------------------------------------------------- Summary : Add support for the --symbol_map option with link time optimization (-o4) is being performed Fixed in : 5.1.0 Severity : S3 - Minor Classification : Enhancement Affected Component : ILinker (File Merge) Release Notes: For program level compile with --opt_level=4, previously the --symbol_map option was not allowed. The icode linker has been updated to handle the symbol_map option and --opt_level=4 will now work with symbol mapping. Defect occurs in ALPHA tool releases only. Workaround: There is no workaround for this. ------------------------------------------------------------------------------- FIXED SDSCM00045882 ------------------------------------------------------------------------------- Summary : Template type not correctly resolved at parse time. Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Parser Release Notes: Template type correctly resolved at parse time. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00046000 ------------------------------------------------------------------------------- Summary : Fail to provide __aeabi_cdrcmple, etc in Thumb mode EABI libraries Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: The following helper functions are missing from all v4, v5e, and v6 (not including Cortex-M0) EABI Thumb mode libraries: __aeabi_cdrcmple __aeabi_cfrcmple __aeabi_dcmpeq __aeabi_dcmpge __aeabi_dcmpgt __aeabi_dcmple __aeabi_dcmplt __aeabi_dcmpun __aeabi_dneg __aeabi_drsub __aeabi_fcmpeq __aeabi_fcmpge __aeabi_fcmpgt __aeabi_fcmple __aeabi_fcmplt __aeabi_fcmpun __aeabi_fneg __aeabi_frsub The following are missing from Cortex-M0 EABI libraries: __aeabi_cdcmpeq __aeabi_cfcmpeq Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 4.10.0B1, 5.0.0B1 - 5.0.3 Workaround: If using the TI compiler, the TI compiler presently doesn't call any of these functions, so no workaround should be necessary. If using any other vendor's compiler and linking with the TI toolchain, for v4, v5e, and v6, use the ARM mode library; for Cortex-M0, link with the other vendor's toolchain. ------------------------------------------------------------------------------- FIXED SDSCM00046015 ------------------------------------------------------------------------------- Summary : Recurrence with unsigned subscript can lead to wrong answer Fixed in : 5.1.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: A loop with a recurrence like "x[i] = ... x[i-1] ..." or "x[i+1] = ... x[i] ..." may produce the wrong answers when i (or any other part of a complex subscript) is of an unsigned type. Defect occurs in TMS470 Compiler versions: 4.8.0B1, 4.9.0B1 - 4.9.7, 5.0.0B1 - 5.0.3 Workaround: Use only signed variables for subscripts and loop index variables, or compile at -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00046016 ------------------------------------------------------------------------------- Summary : Internal error for STMFD Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Assembler Release Notes: When assembling for Cortex-M0, the assembler emits an internal error for the following instruction. It should instead emit an error message. STMFD sp!, {lr} Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00046018 ------------------------------------------------------------------------------- Summary : MSR ASPR encoded incorrectly when ASPR is lowercase with flags specified Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Assembler Release Notes: The assembler will mis-encode MSR when the destination is lowercase apsr and flags are specified. This is true for both ARM and Thumb 2 modes, and for both the register and immediate versions. Examples: MSR apsr_nzcvq, r0 MSR apsr_g, r0 MSR apsr_nzcvqg, r0 are encoded as: MSR CPSR_cxsf, R0 ; wrong flags MSR CPSR_, R0 ; invalid instruction MSR CPSR_cxsf, R0 ; wrong flags Defect occurs in TMS470 Compiler versions: 5.0.0B1 - 5.0.2 Workaround: Always specify ASPR in uppercase ------------------------------------------------------------------------------- FIXED SDSCM00046025 ------------------------------------------------------------------------------- Summary : Incorrect save/restore code for Cortex-M0 __aeabi_drsub and _dcmpun Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: The compiler calls helper functions in the library to handle basic tasks such as floating-point comparisons. TI's Cortex-M0 implementation of two of these functions, __aeabi_drsub and __aeabi_dcmpun, did not properly save and restore registers, and so calling these functions could corrupt the calling function's state, leading to unpredictable results. Workaround: If using the TI compiler, the TI compiler presently doesn't call any of these functions, so no workaround should be necessary. If using any other vendor's compiler, link with the other vendor's toolchain. ------------------------------------------------------------------------------- FIXED SDSCM00046026 ------------------------------------------------------------------------------- Summary : Cortex-M0 __aeabi_ulcmp ignores lower 32 bits of 64-bit compare Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: The compiler calls helper functions in the library to handle basic tasks such as 64-bit comparisons. TI's Cortex-M0 implementation of __aeabi_ulcmp ignores the lower 32 bits of a 64-bit comparison. Workaround: If using the TI compiler, the TI compiler presently doesn't call any of these functions, so no workaround should be necessary. If using any other vendor's compiler, link with the other vendor's toolchain. ------------------------------------------------------------------------------- FIXED SDSCM00046029 ------------------------------------------------------------------------------- Summary : Cortex-M0 __aeabi_uldivmod fails to return ULLONG_MAX for 1/0 Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: ARM EABI requires that __aeabi_uldivmod return ULLONG_MAX when the divisor is zero and the dividend is non-zero. The TI implementation of this function for Cortex-M0 fails to do so. Workaround: For Cortex-M0, link with another vendor's linker and RTS. ------------------------------------------------------------------------------- FIXED SDSCM00046032 ------------------------------------------------------------------------------- Summary : EABI rcmple functions fail to preserve A1-A4 Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: The EABI states that all 6 "3-way, status-returning comparison functions preserve all core registers except ip, lr, and the CPSR." TI's implementation of __aeabi_cdrcmple and __aeabi_cfrcmple clobber A1-A4 and A1-A2 respectively. Workaround: If using the TI compiler, the TI compiler presently doesn't call either of the affected functions, so no workaround should be necessary. If using any other vendor's compiler, link with the other vendor's toolchain. ------------------------------------------------------------------------------- FIXED SDSCM00046084 ------------------------------------------------------------------------------- Summary : Hex utility incorrectly picks empty section over a non-empty section with duplicate name Fixed in : 5.1.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: There can be duplicate section names in an object file. When converting such a file, the hex converter will emit a warning and fail to convert the section. For this test case, it is sufficient to have the hex converter ignore zero-length sections. Handling duplicate section names, neither of which are empty, will require some redesign, and will be pursued as a separate effort. This defect report has been re-purposed as the more targeted fix of ignoring zero-length sections. See SDSCM00046936 for the ongoing work to handle duplicate section names for non-empty sections. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.119, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.4, 5.1.0B1 Workaround: Use a different output section for the duplicate .text section ------------------------------------------------------------------------------- FIXED SDSCM00046092 ------------------------------------------------------------------------------- Summary : Constant expressions not rounded correctly for some values Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The TI compiler supports only IEEE "round to even" mode. The compiler folds constant expressions using the FPSIM package. When rounding "exactly halfway" values, the constant folder rounded toward infinity rather than "round to even". This means that for some values, the value should be rounded *down* to the nearest even number, not up to an odd one. This is very unlikely to cause a problem for most programs; the symptom would be that the very last bit would be incorrect, which is a very, very small error. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.3 Workaround: If maximum precision is required, avoid the use of constant float expressions; place each operand in a variable. The problem can also occur if the optimizer can determine the exact value of the operands. If using the optimizer, put at least one operand in a volatile variable. ------------------------------------------------------------------------------- FIXED SDSCM00046175 ------------------------------------------------------------------------------- Summary : INTERNAL ERROR: cg6x experienced a segmentation fault while processing function Fixed in : 5.1.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: This bug could only happen in C++ code with exception turned ON. Another added condition is that in this C++ code, there are excpetions thrown either in destructor or throw expression. When this bug happens, you will see an error emitted from the compiler. Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.7, 5.1.0B1 Workaround: There is no work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00046177 ------------------------------------------------------------------------------- Summary : ELF section header table not guaranteed to be aligned Fixed in : 5.1.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: I conclude that the linker is generating something wrong when creating relocatable output that gets corrected when it later generates executable output. A further observation: after linking the relocatable linker output to form an executable, I note that the section headers are misaligned (at offset 0xaca from the start of the file). This appears to break the alignment rule from: http://www.sco.com/developers/gabi/2003-12-17/ch4.intro.html#file_format "All data structures that the object file format defines follow the ``natural'' size and alignment guidelines for the relevant class. If necessary, data structures contain explicit padding to ensure 8-byte alignment for 8-byte objects, 4-byte alignment for 4-byte objects, to force structure sizes to a multiple of 4 or 8, and so forth. Data also have suitable alignment from the beginning of the file. Thus, for example, a structure containing an Elf32_Addr member will be aligned on a 4-byte boundary within the file. " Section headers contain Elf32_Addr members, and so should be aligned on a 4-byte boundary (which 0xaca isn't). It appears that the compiler is failing to pad the size of the string table to ensure the alignment of the following areas. You can see that the alignment of the section headers depends on the size of the string table by changing the function name to 'main2'. This generates an output file where the section header offset is 534. The misaligned section headers lead to a CCS crash (SDSCM00046176). Defect occurs in TMS470 Compiler versions: 4.9.0 - 4.9.8, 5.0.0B1 - 5.0.4, 5.1.0B2 - 5.1.0B1 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00046190 ------------------------------------------------------------------------------- Summary : Compiler may mishandle C symbols that resemble C++ mangled names (esp long sequences of underscores) Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: The compiler may mishandle C code with variables whose names resemble C++ mangled names. The one known instances is variables with a sequence of four or more consecutive underscores (eg, "x_____y"). In this case, one pass in the compiler dropped enough of the names to mistakenly think two distinct variables were only one, leading to incorrect results. Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.7, 5.0.0B1 - 5.0.3 Workaround: Don't use variables or functions with long sequences of underscores in C code. ------------------------------------------------------------------------------- FIXED SDSCM00046231 ------------------------------------------------------------------------------- Summary : DATA_ALIGN should not be able to reduce alignment below default array alignment Fixed in : 5.1.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: With the following program: #pragma DATA_SECTION(array, 4) int array[100]; Observe that the alignment of array is 32, should be 64. The DATA_ALIGN pragma should not cause an array to have an alignment that is less than the default array alignment. The DATA_ALIGN pragma is ignored if it attempts to do so. Workaround: Use the DATA_ALIGN pragma with an array alignment value of at least 8 for C64x+ ------------------------------------------------------------------------------- FIXED SDSCM00046346 ------------------------------------------------------------------------------- Summary : Linker takes too long to link after upgrade to 7.3.X Fixed in : 5.1.0 Severity : S2 - Major Classification : Performance Affected Component : ELF Linker Release Notes: Long link times can be caused by the linker's type merging pass to reduce the debug section size. This problem is usually noticed in large projects that contain several hundred files or more. This problem has been addressed by an improved type merging algorithm that should reduce link times. Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.7, 5.1.0B1 Workaround: Use -b can always to wrok around this long type merging problem. But it is not needed with this fix. ------------------------------------------------------------------------------- FIXED SDSCM00046400 ------------------------------------------------------------------------------- Summary : op-assign of float expression to bit-field results in corrupted code Fixed in : 5.1.0 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 TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.118, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.3 Workaround: Assign the value of the floating-point expression into a local integer variable and assign the local variable to the bit-field. ------------------------------------------------------------------------------- FIXED SDSCM00046408 ------------------------------------------------------------------------------- Summary : The compiler should accept the _sxth, _sxtb, _uxth, and _uxtb intrinsics for Cortex-M3 Fixed in : 5.1.0 Severity : S3 - Minor Affected Component : Parser Release Notes: The _sxth, _sxtb, _uxth, _uxtb intrinsics are now supported for Cortex-M3. Workaround: The operations of these intrinsics can be expressed in C without intrinsics: int x; unsigned y; (short)x; // _sxth (signed char)x; // _sxtb (unsigned short)y; // _uxth (unsigned char) y; // _uxtb ------------------------------------------------------------------------------- FIXED SDSCM00046812 ------------------------------------------------------------------------------- Summary : Instructions are placed in the wrong order Fixed in : 5.1.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: In rare cases, incorrect analysis by the compiler may indicate that two memory or stack accesses are unrelated when they actually refer to the same object. If this occurs, the compiler may schedule an access incorrectly. Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.8, 5.0.0B1 - 5.0.4, 5.1.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 : 5.1.0 Severity : S2 - Major Classification : Performance Affected Component : Optimizer Release Notes: A program containing large structs containing many fields, especially if those fields are of type char, may require excessive time to compile. The compiler must check all those fields for potential aliases, and does so inefficiently. Defect occurs in TMS470 Compiler versions: 2.209e, 2.40.beta - 2.71, 4.1.0B1 - 4.1.7, 2.54.02 - 2.54.209, 2.54.03 - 2.54.129, 2.202.03e - 2.202.15e, 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.119, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.4, 5.1.0B1 Workaround: None known. ------------------------------------------------------------------------------- FIXED SDSCM00046848 ------------------------------------------------------------------------------- Summary : NOINIT keyword may be ignored Fixed in : 5.1.0 Severity : S2 - Major Affected Component : ELF Linker Duplicate Defects : SDSCM00047211 Release Notes: The linker command file keyword type(NOINIT) will be ignored in the ARM v5.0.4 and MSP430 v4.1.5 compilers. The changes made to fix SDSCM00045211 were incorrect, causing sections marked NOINIT in the linker command file to be initialized via the cinit mechanism for EABI. Defect occurs in TMS470 Compiler versions: 5.0.4, 5.1.0B1 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00046849 ------------------------------------------------------------------------------- Summary : stdin stdout stderr macros need to be usable without using namespace std for _ftable Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Duplicate Defects : SDSCM00045792, SDSCM00043348 Release Notes: stdin, stdout, and stderr are macros involving the identifier std::_ftable. As a macro, the namespace is not specified as you would for a type or variable (std::size_t). When cstdio is included, these macros are defined and should be usable without a using declaration putting std::_ftable in the global namespace. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.119, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.4, 5.1.0B1 Workaround: Include stdio.h instead of cstdio ------------------------------------------------------------------------------- FIXED SDSCM00046910 ------------------------------------------------------------------------------- Summary : Using an invalid option with valid hex command file causes SIGSEGV Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Hex Converter (hex) Release Notes: Using an invalid option with valid hex command file causes a segmentation fault. Defect occurs in TMS470 Compiler versions: 4.6.0B1 - 4.6.6, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.8, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.4, 5.1.0B1 Workaround: Fix or eliminate the invalid option. ------------------------------------------------------------------------------- FIXED SDSCM00047206 ------------------------------------------------------------------------------- Summary : Calls to isnan in C++ program lead to undefined symbol error Fixed in : 5.1.0 Severity : S1 - Critical / PS Affected Component : Runtime Support Libraries (RTS) Release Notes: The definition of isnan and isinf in the header file math.h eventually refers to library functions, and in C++ needs to refer to these functions in a namespace. The user should be able to use isnan and isinfo without refering to the std namespace. Defect occurs in TMS470 Compiler versions: 4.8.0B1, 4.9.0B1 - 4.9.8, 5.0.0B1 - 5.0.4, 5.1.0B1 Workaround: Add "using namespace std;" after including math.h ------------------------------------------------------------------------------- FIXED SDSCM00047263 ------------------------------------------------------------------------------- Summary : different binaries after compilation Fixed in : 5.1.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: When address-space layout randomisation is used by the OS, as is usually the case for modern Windows and Linux versions, compiler output may be different once in a while on the same input. It isn't predictable; in the given test case, usually only a handful of iterations are needed before a difference appears, but sometimes it takes a couple dozen. Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.8, 4.10.0B1, 5.0.0B1 - 5.0.5, 5.1.0B1 Workaround: "setarch -R" appears to work around the problem on Linux. There are apparently add-on tools for Windows that accomplish the same, or one can fiddle with the registry, but I don't have details. ------------------------------------------------------------------------------- FIXED SDSCM00049564 ------------------------------------------------------------------------------- Summary : Assembler check for CBNZ range is too lenient Fixed in : 5.1.0 Severity : S2 - Major Affected Component : Assembler Release Notes: The assembler should emit a diagnostic when a CBNZ to an out-of-range label is used, but it doesn't emit a diagnostic in every case that it should. It checks that the range is less than or equal to 128, but it should check that the range is less than or equal to 126. Code which uses a CBNZ (which could be generated by the compiler) to a label 128 bytes away will be silently accepted by the assembler, but will be broken. Workaround: None. =============================================================================== 16. Defects fixed in TMS470 Code Generation Tools release 5.1.0B1 =============================================================================== The following 72 defects were fixed in TMS470 Code Generation Tools release 5.1.0B1, released April 2013. ------------------------------------------------------------------------------- FIXED SDSCM00037422 ------------------------------------------------------------------------------- Summary : Incorrect layout in .cdecls struct Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Assembler Release Notes: The attached test case defines a structure which contains a union. The last field in the structure is assigned the offset 9 by the compiler. The assembler, via .cdecls, assigns that same field the offset 10. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00041434 ------------------------------------------------------------------------------- Summary : Compiler optimizes away certain calls to assert() Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Absolute Lister Release Notes: Certain assert() statements, most notably "assert(x&1)" and the equivalent "assert(x%2==0)", may be removed by the compiler and thus will not do the run-time condition check that is desired. Defect occurs in TMS470 Compiler versions: 2.41.beta - 2.50.beta, 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.116, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.209, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.5, 4.7.1.201 - 4.7.1.202, 5.0.0B1 Workaround: Instead of "assert(p)", use "if (!p) assert(0)", which will still abort at the same place under the same conditions, but will have a different error message. More elaborately, implement a function equivalent to assert() but with a different name, that the compiler will not recognise as a system function. ------------------------------------------------------------------------------- FIXED SDSCM00041971 ------------------------------------------------------------------------------- Summary : Spurious remark generated from __STDC_VERSION__ ref in stddef.h in C++ mode Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: #include int main(void) { return 2; } Then compile with the following flags: cl6x a.cpp -pdv -pdr include/stddef.h", line 87: remark #195-D: zero used for undefined preprocessing identifier (__STDC_VERSION__ >= 199901L || !__TI_STRICT_ANSI_MODE__) This happens because __STDC_VERSION__ is not defined in C++ mode Workaround: Use the -pds=195 switch to avoid the remark. ------------------------------------------------------------------------------- FIXED SDSCM00042194 ------------------------------------------------------------------------------- Summary : Partial link drops weak function symbol Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The linker now copies the weak symbol into the output file Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00042292 ------------------------------------------------------------------------------- Summary : In EABI mode string literals used in member functions result in static members of the class and not placed in .const:.string Fixed in : 5.1.0B1 Severity : S2 - Major Classification : Performance Affected Component : Parser Release Notes: In EABI mode, the compiler was incorrectly creating static class member char arrays for string literals used in member functions instead of putting them in .const:.string. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00042332 ------------------------------------------------------------------------------- Summary : Don't generate typeinfo when not used Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Code Generator Release Notes: The C++ type info is generated under EABI whenever the virtual function table is created as per the IA64 C++ ABI requirement. However, the typeinfo is not used if RTTI or C++ exceptions are not used. Hence it is a good candidate to place in slow external memory. However, they are presently generated under .const section and hence it is difficult to selectively group and place them. The proposal is to place the typeinfo under the .const:.typeinfo subsection to enable easier placement. For all targets except C2000's large data mode, typeinfo will now be placed in .const:.typeinfo, whereas C2000's large data mode will place it into .econst:.typeinfo. This behavior will be default in all future releases, but branch patches must provide the --typeinfo_subsections option in the shell to activate this placement change. This is because cache behavior could potentially be affected by changing the placement of the type information. To take advantage of this feature, the linker command file must detail the placement for the typeinfo subsection, most often times placing it into slow external memory to make room for more important data in faster memory. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00042417 ------------------------------------------------------------------------------- Summary : #pragma WEAK; 'if (f)' gets eliminated even if 'f' is a weak function Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00044527 Release Notes: EABI mode allows weak symbol references. If the symbol is weak and not defined, its address is zero. The compiler incorrectly assumes that the address of a weak symbol is non-zero and simplfies comparisons of &symbol to true, but it should not. In other words, if the user writes "if (&symbol) symbol_is_defined();", symbol_is_defined will be called even if symbol is weak and not defined. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.118, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.3 Workaround: Create a volatile pointer to hold the weak pointer value before using it in any comparisons, including the test in an if statement. ------------------------------------------------------------------------------- FIXED SDSCM00042444 ------------------------------------------------------------------------------- Summary : Expression that multiplies two constants incorrectly triggers MISRA rule 10.1 about implicit conversion Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The expression ... var_int16 = 4 * 256; contains no implicit conversions. However, MISRA rule 10.1 about no implicit conversions is still emitted for that expression. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00042581 ------------------------------------------------------------------------------- Summary : Linker fails with internal error: lnk6x failed to allocate memory Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Linker Release Notes: The linker could report an internal error due to a memory allocation failure in certain cases. This bug involves the linker options --make_static, --localize, or --hide. If any of these options is used in a partial link, then the final link may produce the internal error. The linker was localizing comdat symbols during the partial link, which is incorrect behavior. The result was that the comdat symbols could not be resolved in the final link, but this was not detected properly, causing the memory allocation failure. One example of a comdat symbol is a static data member of a template class. The static data member must be resolved to a single instance, so it can not be localized during the partial link. This bug fix ensures that --make_static, --localize, and --hide do not affect comdat symbols during the partial link, and lists these symbols in the mapfile if requested. Also, if a similar symbol resolution error is encounted due to some other cause, the linker will now detect and report the error instead of encountering a memory allocation error later in the linking process. Defect occurs in TMS470 Compiler versions: 4.4.0 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.2 Workaround: This bug can only be triggered if a partial link is performed using the --make_static, --localize or --hide option (the memory allocation failure will occur during the final link, however). Removing that option is one way to avoid this bug. Alternatively, the partial link step may be removed from the build process, if possible. ------------------------------------------------------------------------------- FIXED SDSCM00042595 ------------------------------------------------------------------------------- Summary : Compiler generates an internal error "no match for COMPARE" for the attached testcase Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Use of unsigned long long types in a comparison causes a codegen crash. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00042600 ------------------------------------------------------------------------------- Summary : Ill advised enum scalar usage gets MISRA diagnostic, but similar usage of enum array does not Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The test case given assigned a integer to an enum scalar variable. MISRA checking correctly flags this with a diagnostic. The test case goes on to do the same thing with an enum array expression. It should get the same MISRA diagnostic, but does not. For example: typedef unsigned int uint16_t; uint16_t Func(void); typedef enum Error { OK, NO_DATA, BUFFER_FULL } Error_t; const Error_t errors[2] = {OK, OK}; uint16_t Func(void) { uint16_t myError; myError = OK; /* correctly flags as error (MISRA 10.1) */ myError = errors[0]; /* does not find error */ return myError; } Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00042811 ------------------------------------------------------------------------------- Summary : printf("%d") with negative values incorrect for printf_support=minimal Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: printf("%d") is treated as printf("%u") for --printf_support=minimal, which means negative values will be printed incorrectly. Defect occurs in TMS470 Compiler versions: 5.0.0B1 Workaround: Use printf_support=nofloat ------------------------------------------------------------------------------- FIXED SDSCM00042914 ------------------------------------------------------------------------------- Summary : Linker segfault using partial link output file of C++ source with ELF and exceptions enabled Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : ELF Linker Release Notes: The linker fails with a segmentation fault when using a file created by partial linking C++ code with exceptions enabled and using the ELF file format. While the first (partial) link appears to succeed, a second link using the (corrupted) output file from the partial link causes the linker to segfault and stop. Workaround: Re-link partial linked output file with a fixed linker, then perform final link again with the now correct partial link output file. ------------------------------------------------------------------------------- FIXED SDSCM00043036 ------------------------------------------------------------------------------- Summary : Assembler generates segmentation fault Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Assembler Release Notes: Assembler generates segmentation fault when compiling certain files Workaround: Remove or modify the asm statement that attempts to access a C function parameter. ------------------------------------------------------------------------------- FIXED SDSCM00043069 ------------------------------------------------------------------------------- Summary : CDP instruction not accepted for v4 versions Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Assembler Release Notes: The CDP instruction generates an assembler error for version v4 in arm-mode. Workaround: Assemble at version v5e or higher. ------------------------------------------------------------------------------- FIXED SDSCM00043143 ------------------------------------------------------------------------------- Summary : Compiler incorrectly rewrites expression as rotate operation Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The problem could occur when an expression matches one of: x << a | y >> b if a + b = vsz x >> a | y << b if a + b = vsz x << z | y >> (vsz - z) x << (vsz - z) | y >> z Where: a and b are constant integers vsz is the size of x and y in bits When all of: x and y are expressions involving . or -> operators with the same left-hand sides x and y are of exactly the same type x and y are of unsigned type Effect of optimization: When compiler optimizer is enabled at -O1 or higher, the optimizer may transform equivalent code sequences into an expression which causes the problem to occur. For example, the sequence { int x = s.a, y = s.b; return x << 16 | y >> 16; } could still cause the problem despite the shift/or expression not directly including a . or -> operator. This includes sequences which may be generated as a result of function inlining. Workaround: Workaround 1: Make sure x and y can't include structure references, for example by using a function such as the following to compute the expression: #pragma FUNC_CANNOT_INLINE(f); /* omit "(f)" in C++ */ unsigned f(unsigned x, unsigned a, unsigned y, unsigned b) { return x << a | y >> b; } Workaround 2: Use volatile temporaries for x and y, for example: volatile int x = s.a; volatile int y = s.b; return x << 16 | y >> 16; ------------------------------------------------------------------------------- FIXED SDSCM00043152 ------------------------------------------------------------------------------- Summary : Optimizer issues information advice using optimizer's temporary symbols instead of using symbols from user code Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Optimizer Release Notes: The optimiser may issue alias advice that refers to the optimiser's temporary symbols, whose declarations the user cannot control. This advice does not affect the code's behavior, though it leaves some suggested improvements inaccessible. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.114, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.209, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.3, 4.7.1.201 - 4.7.1.202 Workaround: None. Ignore the bad advice, or try to ascertain which user variable the temp refers to by studying the optimiser comments in the .asm file. ------------------------------------------------------------------------------- FIXED SDSCM00043174 ------------------------------------------------------------------------------- Summary : Linker fails to honor specific placement for function from RTS library Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : COFF Linker Release Notes: Linker now honors section placement specification. Workaround: Do not include libc.a option. ------------------------------------------------------------------------------- FIXED SDSCM00043223 ------------------------------------------------------------------------------- Summary : Compiler may miss alias given struct-of-array-of-structs Fixed in : 5.1.0B1 Severity : S1 - Critical / PS Affected Component : C/C++ Compiler (cl) Release Notes: In a particular situation involving a struct containing an array of structs, the compiler may miss an alias between a read and write of a scalar field in the nested struct. Defect occurs in TMS470 Compiler versions: 4.8.0B1, 4.9.0B1 - 4.9.3, 5.0.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 SDSCM00043229 ------------------------------------------------------------------------------- Summary : Instruction reordering alters logic Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: A sequence of code that initialises a struct by assignments to its fields, then copies the whole struct to another struct, then reads the fields individually, may sometimes read before the struct copy has happened. This situation has been observed when the initialisation is in an inlined function (and thus the struct-to-struct copy mimics the return from the callee), the struct read is defined within a scope that is not at top level, and another non-top-level scope defines a local array. Workaround: No general workaround is known, aside from compiling with -o0 or -o1.. This specific case can be worked around by removing the extra braces around the bulk of the body of main(), or by inhibiting the inlining of GetPrms(). ------------------------------------------------------------------------------- FIXED SDSCM00043326 ------------------------------------------------------------------------------- Summary : Extremely long (templated) type names may overflow buffer, causing crash Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: The optimizer may crash when it encounters an extremely long type name -- for example, a deep nested templated C++ class name -- while creating a printed representation. The crash is most likely, and perhaps only occurs, with -o2 or -o3. Defect occurs in TMS470 Compiler versions: 2.166e - 2.178e, 2.209e, 2.40.beta - 2.71, 4.1.0B1 - 4.1.7, 2.54.02 - 2.54.209, 2.54.03 - 2.54.129, 2.202.03e - 2.202.15e, 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.114, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.209, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.3, 4.7.1.201 - 4.7.1.202, 5.0.0B1 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00043468 ------------------------------------------------------------------------------- Summary : Compiler update for Silicon Erratum Cortex-R4#57 for TMS570LS3xxx Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Please reference errata SPNZ181, Cortex-R4#57 http://www.ti.com/lit/er/spnz181a/spnz181a.pdf The --arm_vmrs_si_workaround=on|off option was added to prevent a conditional VMRS instruction from being generated by the compiler. By default, the option is enabled (on). A warning will be emitted if a developer attempts to add a conditional VMRS instruction to the assembly file when the option is enabled. The developer can turn the option off using --arm_vmrs_si_workaround=off. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00043538 ------------------------------------------------------------------------------- Summary : The --unaligned_access=on option is not valid for v4 and v5e architectures Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Shell Release Notes: The ARM9 and ARM7 cores do not support unaligned accesses in the hardware. The compiler --unaligned_access=on option should not be used when generating code for these cores. For ARM11 and up, the hardware can be configured to support unaligned accesses. If the hardware support is enabled, the user can use the --unaligned_access=on option to enable the compiler to generate these accesses. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00043642 ------------------------------------------------------------------------------- Summary : Compiler incorrectly simplifies "(x >> k1) < k2" when k2 is constant smaller than int Fixed in : 5.1.0B1 Severity : S1 - Critical / PS Affected Component : C/C++ Compiler (cl) Release Notes: Given an IF with a predicate like "(x >> k1) < k2", the compiler will attempt to convert it to "x < (k2<.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 : 5.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: When converting control flow to predicated instructions, in rare cases the compiler could mistakenly discard some instructions which were unpredicatable or were already predicated. This will cause the generated code to work incorrectly in unpredictable ways. Defect occurs in TMS470 Compiler versions: 5.0.0B1 Workaround: No practical workaround ------------------------------------------------------------------------------- FIXED SDSCM00043868 ------------------------------------------------------------------------------- Summary : Linker cannot find include file specified with relative path Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Linker Release Notes: The linker properly resets the source path after processing an #include. Workaround: This bug occurs because the linker does not properly reset the source path after processing an #include, causing a second #include to be relative to the wrong path. Any intervening token between the two #include directive will overcome this, as will any macro expansion (even if empty). For example: #define SPACE #include "../first.cmd" SPACE #include "../second.cmd" ------------------------------------------------------------------------------- FIXED SDSCM00043948 ------------------------------------------------------------------------------- Summary : IF predicate with negative integer factor simplifies incorrectly Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: An IF predicate with a negative integer factor -- eg, "if (x*(-3) == -9)" -- may be simplified incorrectly, for instance to "if (x == -3)" instead of the correct "if (x == 3)". Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.116, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.209, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.5, 4.7.1.201 - 4.7.1.202, 5.0.0B1 Workaround: None. Avoid the situation. ------------------------------------------------------------------------------- FIXED SDSCM00043966 ------------------------------------------------------------------------------- Summary : Second instance of three-operand associative op may miscompile Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: If two three-operand expressions using the same associative operator and two of the same operands occur in the same function -- for example, x*x*x and 30*x*x -- the second expression may miscompile and be treated as identical to the first. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.116, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.209, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.5, 4.7.1.201 - 4.7.1.202, 5.0.0B1 Workaround: Compile at -o1 or -o0, or avoid the situation. ------------------------------------------------------------------------------- FIXED SDSCM00044012 ------------------------------------------------------------------------------- Summary : Optimizer crash Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: Certain intrinsic operations are commutative -- their operands can occur in either order. Many of these are parallel versions of common commutative operations, like _add2, or specialised versions, like _smpy. Minimum and maximum operations also have commutative intrinsics, _min2 and _maxu4 for example. When one of these commutative intrinsics appears in a reduction -- an expression like x = _op(x, k); -- inside nested loops, the optimiser may crash. It is looking for similar kinds of expressions, but isn't handling intrinsics correctly. The compiler will either produce correct code here, or crash; it will not silently produce incorrect code. Some of these intrinsics can be introduced by the compiler itself, based on the original source code. The motivating case for this bug report looks like for (i = a; i < b; i++) for (j = c; j < d; j++) { t = ...; if (t < min) min = t; } and the compiler transformed the IF into _min2. For the problem to occur, the required ingredients are a commutative intrinsic or expressions that can be transformed into one, inside a nest of two loops that are simple enough that the outer loop may be unrolled. The workaround is to add "#pragma UNROLL(1)" to the outer loop, or to compile at -o1 or -o0, to prevent the transformation where the crash occurs. Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.5, 4.10.0B1, 5.0.0B1 Workaround: Try "#pragma UNROLL(1)" ahead of the outermost for-loop, or compile with -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00044048 ------------------------------------------------------------------------------- Summary : Enabling vectorization produces incorrect code Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00045426 Release Notes: In certain cases, enabling vectorization could result in incorrect code being generated. Defect occurs in TMS470 Compiler versions: 4.4.10.100 - 4.4.10.116, 4.9.0B1 - 4.9.6, 5.0.0B1 - 5.0.0 Workaround: Disable vectorization or optimization. ------------------------------------------------------------------------------- FIXED SDSCM00044066 ------------------------------------------------------------------------------- Summary : opt470 experienced a segmentation fault Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: Corrected false assumption made while performing an optimization. Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00044216 ------------------------------------------------------------------------------- Summary : Link time optimization produces error about option --optimize_with_debug missing its argument Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: An optional parameter of on/off was added to the --optimize_with_debug option. During link time optimization (-o4), an internal tool incorrectly requires the option have a parameter, which it won't if the object file was built with an older tool chain. The bug has been fixed and the tool will accept the option with no parameter, which will be interpreted as --optimize_with_debug=on Defect occurs in TMS470 Compiler versions: 5.0.0B1 Workaround: Recompile older object files with the newer compiler, or switch back to using the older compiler for all stages of the build. ------------------------------------------------------------------------------- FIXED SDSCM00044227 ------------------------------------------------------------------------------- Summary : Compiler may not ensure uniqueness of static variables in C++ templates Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Parser Duplicate Defects : SDSCM00043437 Release Notes: In EABI mode, static variables in template functions and static data members of template classes may not be properly allocated and/or initialized. Templates are typically defined in header files, resulting in separate instances in each translation unit (source file). The tools must merge these multiple instances into unique instances, and ensure that static objects are allocated and initialized only once. There are three specific cases in which these mechanisms may fail, resulting in incorrect behavior of the program. They are: 1. A static variable in a template function, or a static variable in a member function of a template class, may not be allocated as a single unique object. This error occurs only when all of the following conditions occur: - the function is not declared inline, AND - the function is not implicity inline by virtue of having its body defined within the template class, AND - the function body is compiled in multiple translation units (i.e. the definition is in a header file). For example: template void f() { static int var; // ... } If this function definition is compiled into multiple translation units, the compiler may incorrectly create multiple instances of 'var'. Additionally, the compiler may incorrectly allocate 'var' into a section with other variables. This may cause unexpected behavior during linking, such as incorporating of unreferenced sections into the link, or changing the contents of the data section from link to link (depending on which copy of 'f()' arbitrarily gets linked in). A workaround for this defect is to declare the function f() as inline. 2. Under the same conditions described in case 1, if the static variable is initialized with a constructor, the constructor may incorrectly be called multiple times. For example: template void f() { static T var; // ... } The constructor T::T() may be called multiple times to initialize 'var'. Declaring f() as inline also works around this problem. 3. Similarly, if a static data member of a template class is initialized with a constructor, the constructor may incorrectly be called multiple times. This occurs only when all of the following conditions occur: - the definition (not the declaration) of the data member appears in multiple translation units, AND - the member is referenced in multiple translation units in which the definition occurs. For example: template class MyClass { static T var; // declaration }; // definition template T MyClass::var; // may call T::T() multiple times A workaround for case 3 is to move the definition from a header file to a .cpp file, so that it only occurs once. Workaround: 1. If a template function, or member function of a template class, has a static varaible, declare the function 'inline'. 2. If a template class has a static data member with initialization by constructor, put the definition of the data member in a .cpp file rather than a .h file. ------------------------------------------------------------------------------- FIXED SDSCM00044242 ------------------------------------------------------------------------------- Summary : FPEXC register not properly restored before existing assembly function Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Code Generator Release Notes: In VFPv2, the FPEXC register will be updated for any unsupported VFP instruction. The FPEXC register is now properly saved and restored when the FPEXC register might be modified inside an interrupt function when VFP is enabled for either VFPv2,3,4. Workaround: Disable VFP support. ------------------------------------------------------------------------------- FIXED SDSCM00044264 ------------------------------------------------------------------------------- Summary : Internal error on 0/(-DBL_MIN/2) Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Code Generator Release Notes: A constant expression of the form "0 / (-DBL_MIN / 2)" will cause the compiler to terminate with an internal error. In floating-point arithmetic, this is a well-formed expression. If denormal numbers are supported, the correct result is -0.0. Otherwise, the result is NaN, and the "invalid" floating point exception may be raised. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.6, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.1 Workaround: Move at least one of the operands into a variable. ------------------------------------------------------------------------------- FIXED SDSCM00044285 ------------------------------------------------------------------------------- Summary : scanf %[^ mistakenly writes EOF to output Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: When using ^ to negate the scan set [ sscanf(in, "%[^abc]", out) ], scanf would incorrectly copy EOF to the output string. It should instead stop reading input and return as normal. Workaround: Negate the scan set manually; don't use the negation operator. ------------------------------------------------------------------------------- FIXED SDSCM00044363 ------------------------------------------------------------------------------- Summary : LDM instruction generates internal error: unexpected operand in LDM/STM conversion Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: LDM instruction "LDM sp!, {lr}" generates internal error: unexpected operand in LDM/STM conversion The compiler now accepts LDM instructions with only one register in the register list operand. Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00044393 ------------------------------------------------------------------------------- Summary : Linker silently ignores an output section placement spec with missing ">" in the SECTIONS directive Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Linker Release Notes: When previously parsing linker command files, the linker required the ">" to specify memory addresses for sections (i.e. sec1 > MEM1). The ">" operator is now optional as the documentation states it should be. Workaround: Don't omit the ">" in the linker command file. ------------------------------------------------------------------------------- FIXED SDSCM00044450 ------------------------------------------------------------------------------- Summary : Parser allows virtual base classes that are too large Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Parser Release Notes: In EABI, due to the RTTI implementation, the compiler can only handle virtual base classes of a certain size. The parser incorrectly computed this size and did not emit a warning for very large virtual base classes that were too large. This would lead to data corruption. Defect occurs in TMS470 Compiler versions: 4.1.0B1 - 4.1.7, 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.6, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.0 Workaround: Do not allow any object to inherit from virtual base classes with total size larger than approximately 0x7ffff0 ------------------------------------------------------------------------------- FIXED SDSCM00044474 ------------------------------------------------------------------------------- Summary : Compiler generates Internal error: Constant table error Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00044071 Release Notes: Compiler generates Internal error: Constant table error Workaround: There is an issue with the compiler pass that embeds constant definitions so that the references to these constants efficiently reach the definitions. The issue manifests when encountering large string constants that are placed close together in straight line code. A possible workaround is to try assigning pointers to the large string constants and use the pointers. For example: Instead of func(parm1,parm2, "A very long string constant ....") try: const char *sptr = "A very long string constant ..."; : func(parm1,parm2,sptr); ------------------------------------------------------------------------------- FIXED SDSCM00044536 ------------------------------------------------------------------------------- Summary : Fix to CQ44227 causes incompatible object code resulting in link failure Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : ELF Linker Release Notes: The fix to CQ44227 creates an object code incompatibility with object code from previous toolsets, which can cause a C++ program consisting of code from both to fail to link. CQ44227 was an issue with static data members of template classes and functions, which require an initialization guard variable to insure one-time initialization. The guard variable was introduced into the same COMDAT section as the static data member. The issue is that if code from an older toolset (which does not contain the guard) is linked with code from a newer toolset (which does), the linker may choose the COMDAT group without the guard, thus leaving no definition for the guard. This can trigger an undefined symbol error, or, if the object code is in a library, cause the linker to hang. This problem occurs only under the following conditions: - a static variable in a template function or static data member requires initialization by constructor (as described in CQ44227) - For C6x, the program includes object code compiled by version 7.3.6 of the C6x compiler, as well as object code compiled by an eariler version. - For ARM, the program includes object code compiled by version 4.9.6 or 5.0.0, as well as object code compiled by an earlier version. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00044719 ------------------------------------------------------------------------------- Summary : Linker fails with unhandled exception Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Linker Release Notes: Linker fails with unhandled exception All version 5.0.0 object file manipulation tools crash when attempting to read a pre-5.0.0 EABI object file with build attribute OFBA_ARM_Tag_compatibility set. This build attribute is not usually set. This means that 5.0.0 cannot be used when OFBA_ARM_Tag_compatibility is written to the object file. Defect occurs in TMS470 Compiler versions: 5.0.0 Workaround: There is no workaround. ------------------------------------------------------------------------------- FIXED SDSCM00044735 ------------------------------------------------------------------------------- Summary : EXIDX_CANTUNWIND yields invalid memory read Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: If an exception is thrown that tries to propagate up through any C-compiled function, the RTS must call std::terminate(). The linker is responsible for fabricating CANTUNWIND entries in the EXIDX table for C functions so that the unwinder knows it has unwound to a C function. If the C function happens to be placed after the last C++ text section, the linker doesn't create such an EXIDX entry. This is a bug in the RTS. The EXIDX lookup does check whether it is running off the end of the EXIDX table, but when it does, it mistakenly attempts to read a value from just beyond the end of the table. This problem only occurs in EABI. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.6, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.0 Workaround: This bug can only occur when the program is terminating due to a problem with an uncaught exception. To work around the issue, ensure that C++ functions which might be called from a C function catch all exceptions. ------------------------------------------------------------------------------- FIXED SDSCM00044736 ------------------------------------------------------------------------------- Summary : Loop nest over two-dimensional array compiles wrong if inner loop has early exit Fixed in : 5.1.0B1 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 TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.6, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.1 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 SDSCM00044775 ------------------------------------------------------------------------------- Summary : Missed dependence between x[i+4] and x[i] when i unsigned Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00045067 Release Notes: A loop with a write to x[i+k1] and a read from x[i+k2], where i is an unsigned integral type and k1 and k2 are constants, may produce incorrect answers, because the compiler will not recognise the dependence between the two accesses. Whether or not the result is correct is due to variations in the scheduling of instructions in the compiler output. The compiler misses the dependences because it doesn't properly sign-extend the unsigned difference computation and ends up with a large positive number instead of the correct small negative one. Defect occurs in TMS470 Compiler versions: 4.8.0B1, 4.9.0B1 - 4.9.6, 5.0.0B1 - 5.0.1 Workaround: Change "i" from unsigned to signed, from UINT32 to INT32. ------------------------------------------------------------------------------- FIXED SDSCM00044817 ------------------------------------------------------------------------------- Summary : Assembler reports "Illegal mnemonic" for RFEFD when compiled for Thumb2 Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Assembler Release Notes: Assembler reports "Illegal mnemonic" for RFEFD instruction when compiled for Thumb2 Assembler now accepts REFEA , REFFD , SRSFD, SRSEA pseudo instructions while in thumb mode. Workaround: Change RFEFD assembly instruction to RFEIA. ------------------------------------------------------------------------------- FIXED SDSCM00045105 ------------------------------------------------------------------------------- Summary : Empty struct as field of parent struct may cause optimizer abort Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: If a struct contains another struct, and the inner struct has no fields, and the parent struct is copied whole through an assignment of struct-type variables, the optimizer may abort. Defect occurs in TMS470 Compiler versions: 4.9.1 - 4.9.6, 5.0.0B1 - 5.0.1 Workaround: Add a dummy field to the empty struct. ------------------------------------------------------------------------------- FIXED SDSCM00045211 ------------------------------------------------------------------------------- Summary : Linker GROUP directive fails to allow NOINIT output sections and regular output sections to be together in the group Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Linker Release Notes: An output section that includes NOINIT sections and regular sections is not allowed. The code to detect this error did not properly account for GROUPS, which can contain a mix of section types. However, this bug would only occur if a GROUP was declared to be type NOINIT in the linker command file. The type keyword should not be applied to GROUPs, as documented in SDSCM00032000, and this syntax will be disallowed when SDSCM00032000 is fixed. Defect occurs in TMS470 Compiler versions: 5.0.0B1 - 5.0.3 Workaround: None. However, the type keyword should not be applied to GROUPs. ------------------------------------------------------------------------------- FIXED SDSCM00045232 ------------------------------------------------------------------------------- Summary : Incorrect linker symbol value after multiple partial links Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : ELF Linker Release Notes: Linker symbols whose values depend on section placement were getting assigned absolute values instead of section relative values in partial links. These are symbols that are defined using the '.' operator, and/or those defined using the linker command file keywords such as START, END, LOAD_START etc. As a result, the final link would assign incorrect values to these symbols. Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.6, 5.0.0B1 - 5.0.1 Workaround: Create a large memory region in the linker command files for use during each partial link that defines memory starting at address zero. ------------------------------------------------------------------------------- FIXED SDSCM00045246 ------------------------------------------------------------------------------- Summary : Workaround for Stellaris ARM cache silicon errata Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: Added a workaround for the silicon errata as described in the document "Stellaris LM4FS1AH5BB Rev A1/A2". This workaround is enabled through the --stellaris_cache_si_workaround compiler switch. If a word-aligned value is loaded from an SRAM location into a core register, then altered by storing a byte or halfword at an unaligned offset, the altered word-aligned value is not correctly indicated when loaded into a core register. The loaded value from the SRAM location into a core register will reflect the original value, not the modified value. The following assembly sequence causes the altered value loaded into a core register to not load the correct value, even though the correct value is visible in the SRAM memory location: LDR R0, [SP, #+0]; STRB R0, [SP, #+1]; (STRH can cause silicon exception as well) LDR R0, [SP, #+0]; This assembly sequence causes erroneous values only if these three instructions are executed in this order. However, the three instructions do not have to be consecutive, which means that other instructions can be placed in between the first and the second instructions or the second and the third instructions and the false value will still occur. The solution is to insert after the STR: STR V1, [SP, #-4]; LDR V1, [SP, #-4]; This forces the cached value to be reloaded from memory The compiler switch will add the necessary extra STR, LDR instruction to and from the stack. The --unaligned_access=on option cannot be used with the --stellaris_cache_si_workaround switch. If a user tries to do so, a warning will be emitted and unaligned accesses will be disabled. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00045381 ------------------------------------------------------------------------------- Summary : Read of array element, before memcpy() overwrites it, may be out of order Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: The two statements a = x[0]; memcpy(&x[0], &x[1], K); may not occur in the correct order under certain conditions at -o2 and above. The memcpy() may overwrite the first element before it is saved in the variable. The problem is specific to memcpy(). Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.3 Workaround: The test case is using memcpy() to implement a shift register in an array. More efficient, and also avoiding the problem, is to use a circular-queue arrangement: instead of having the head of the queue always be x[0] and implementing a pop by shifting the whole array, have the head be x[head] and implement the pop as head=(head+1)%arraysize. Or use -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00045550 ------------------------------------------------------------------------------- Summary : Truncated pointer created by cast from integer constant Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: For an expression of the form ((t *)c1+c2), where t is an arbitrary type and c1 and c2 are integer constants small enough to fit in a type smaller than int, the optimizer could mistakenly truncate the sum of c1 and c2 to the smaller type. It is possible for other optimizations to create this expression through simplification of other expressions. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.3 Workaround: Don't use the optimizer at all for source files which contain pointer math of the form shown in the release notes. ------------------------------------------------------------------------------- FIXED SDSCM00045562 ------------------------------------------------------------------------------- Summary : Multiplication by power-of-2 wider than int may use wrong type Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: When multiplying a variable of a type the same size as int, or smaller, by a constant power of two with a type wider than int, the compiler may convert the multiply into a shift-left, and use the wrong type, thus computing the wrong answer. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.2 Workaround: Make the variable the same wider-than-int type as the constant. Casting it may also work. Or compile at -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00045660 ------------------------------------------------------------------------------- Summary : Different code generated on Linux and PC under the same option for the same source code Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: In some cases, the same code compiled with the same version of the compiler may produce different asm on Windows than on Linux. The reason is some unstable sorting of equivalent internal rules and inlineable call sites. The two systems will sort differently in these cases and the resulting asm will vary; in some cases, performance will also be different. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.2 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00045724 ------------------------------------------------------------------------------- Summary : CCS disassembles FMRX and FMXR instructions incorrectly on CortexR4 Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Disassembler (dis) Release Notes: CCS disassembles FMRX instruction as FMXR and FMXR instruction as FMRX on CortexR4 The assembled FMRX instruction is incorrectly disassembled as a VMSR instead of a VMRS instruction due to a decoding error. The assembled FMXR instruction is also incorrectly disassembled as a VMRS instead of a VMSR instruction. Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00045742 ------------------------------------------------------------------------------- Summary : Add support for the --symbol_map option with link time optimization (-o4) is being performed Fixed in : 5.1.0B1 Severity : S3 - Minor Classification : Enhancement Affected Component : ILinker (File Merge) Release Notes: For program level compile with --opt_level=4, previously the --symbol_map option was not allowed. The icode linker has been updated to handle the symbol_map option and --opt_level=4 will now work with symbol mapping. Defect occurs in ALPHA tool releases only. Workaround: There is no workaround for this. ------------------------------------------------------------------------------- FIXED SDSCM00045882 ------------------------------------------------------------------------------- Summary : Template type not correctly resolved at parse time. Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Parser Release Notes: Template type correctly resolved at parse time. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00046000 ------------------------------------------------------------------------------- Summary : Fail to provide __aeabi_cdrcmple, etc in Thumb mode EABI libraries Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: The following helper functions are missing from all v4, v5e, and v6 (not including Cortex-M0) EABI Thumb mode libraries: __aeabi_cdrcmple __aeabi_cfrcmple __aeabi_dcmpeq __aeabi_dcmpge __aeabi_dcmpgt __aeabi_dcmple __aeabi_dcmplt __aeabi_dcmpun __aeabi_dneg __aeabi_drsub __aeabi_fcmpeq __aeabi_fcmpge __aeabi_fcmpgt __aeabi_fcmple __aeabi_fcmplt __aeabi_fcmpun __aeabi_fneg __aeabi_frsub The following are missing from Cortex-M0 EABI libraries: __aeabi_cdcmpeq __aeabi_cfcmpeq Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.200 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 4.10.0B1, 5.0.0B1 - 5.0.3 Workaround: If using the TI compiler, the TI compiler presently doesn't call any of these functions, so no workaround should be necessary. If using any other vendor's compiler and linking with the TI toolchain, for v4, v5e, and v6, use the ARM mode library; for Cortex-M0, link with the other vendor's toolchain. ------------------------------------------------------------------------------- FIXED SDSCM00046015 ------------------------------------------------------------------------------- Summary : Recurrence with unsigned subscript can lead to wrong answer Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: A loop with a recurrence like "x[i] = ... x[i-1] ..." or "x[i+1] = ... x[i] ..." may produce the wrong answers when i (or any other part of a complex subscript) is of an unsigned type. Defect occurs in TMS470 Compiler versions: 4.8.0B1, 4.9.0B1 - 4.9.7, 5.0.0B1 - 5.0.3 Workaround: Use only signed variables for subscripts and loop index variables, or compile at -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00046016 ------------------------------------------------------------------------------- Summary : Internal error for STMFD Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Assembler Release Notes: When assembling for Cortex-M0, the assembler emits an internal error for the following instruction. It should instead emit an error message. STMFD sp!, {lr} Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00046018 ------------------------------------------------------------------------------- Summary : MSR ASPR encoded incorrectly when ASPR is lowercase with flags specified Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Assembler Release Notes: The assembler will mis-encode MSR when the destination is lowercase apsr and flags are specified. This is true for both ARM and Thumb 2 modes, and for both the register and immediate versions. Examples: MSR apsr_nzcvq, r0 MSR apsr_g, r0 MSR apsr_nzcvqg, r0 are encoded as: MSR CPSR_cxsf, R0 ; wrong flags MSR CPSR_, R0 ; invalid instruction MSR CPSR_cxsf, R0 ; wrong flags Defect occurs in TMS470 Compiler versions: 5.0.0B1 - 5.0.2 Workaround: Always specify ASPR in uppercase ------------------------------------------------------------------------------- FIXED SDSCM00046025 ------------------------------------------------------------------------------- Summary : Incorrect save/restore code for Cortex-M0 __aeabi_drsub and _dcmpun Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: The compiler calls helper functions in the library to handle basic tasks such as floating-point comparisons. TI's Cortex-M0 implementation of two of these functions, __aeabi_drsub and __aeabi_dcmpun, did not properly save and restore registers, and so calling these functions could corrupt the calling function's state, leading to unpredictable results. Workaround: If using the TI compiler, the TI compiler presently doesn't call any of these functions, so no workaround should be necessary. If using any other vendor's compiler, link with the other vendor's toolchain. ------------------------------------------------------------------------------- FIXED SDSCM00046026 ------------------------------------------------------------------------------- Summary : Cortex-M0 __aeabi_ulcmp ignores lower 32 bits of 64-bit compare Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: The compiler calls helper functions in the library to handle basic tasks such as 64-bit comparisons. TI's Cortex-M0 implementation of __aeabi_ulcmp ignores the lower 32 bits of a 64-bit comparison. Workaround: If using the TI compiler, the TI compiler presently doesn't call any of these functions, so no workaround should be necessary. If using any other vendor's compiler, link with the other vendor's toolchain. ------------------------------------------------------------------------------- FIXED SDSCM00046029 ------------------------------------------------------------------------------- Summary : Cortex-M0 __aeabi_uldivmod fails to return ULLONG_MAX for 1/0 Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: ARM EABI requires that __aeabi_uldivmod return ULLONG_MAX when the divisor is zero and the dividend is non-zero. The TI implementation of this function for Cortex-M0 fails to do so. Workaround: For Cortex-M0, link with another vendor's linker and RTS. ------------------------------------------------------------------------------- FIXED SDSCM00046032 ------------------------------------------------------------------------------- Summary : EABI rcmple functions fail to preserve A1-A4 Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: The EABI states that all 6 "3-way, status-returning comparison functions preserve all core registers except ip, lr, and the CPSR." TI's implementation of __aeabi_cdrcmple and __aeabi_cfrcmple clobber A1-A4 and A1-A2 respectively. Workaround: If using the TI compiler, the TI compiler presently doesn't call either of the affected functions, so no workaround should be necessary. If using any other vendor's compiler, link with the other vendor's toolchain. ------------------------------------------------------------------------------- FIXED SDSCM00046092 ------------------------------------------------------------------------------- Summary : Constant expressions not rounded correctly for some values Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The TI compiler supports only IEEE "round to even" mode. The compiler folds constant expressions using the FPSIM package. When rounding "exactly halfway" values, the constant folder rounded toward infinity rather than "round to even". This means that for some values, the value should be rounded *down* to the nearest even number, not up to an odd one. This is very unlikely to cause a problem for most programs; the symptom would be that the very last bit would be incorrect, which is a very, very small error. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.117, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.3 Workaround: If maximum precision is required, avoid the use of constant float expressions; place each operand in a variable. The problem can also occur if the optimizer can determine the exact value of the operands. If using the optimizer, put at least one operand in a volatile variable. ------------------------------------------------------------------------------- FIXED SDSCM00046190 ------------------------------------------------------------------------------- Summary : Compiler may mishandle C symbols that resemble C++ mangled names (esp long sequences of underscores) Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: The compiler may mishandle C code with variables whose names resemble C++ mangled names. The one known instances is variables with a sequence of four or more consecutive underscores (eg, "x_____y"). In this case, one pass in the compiler dropped enough of the names to mistakenly think two distinct variables were only one, leading to incorrect results. Defect occurs in TMS470 Compiler versions: 4.9.0B1 - 4.9.7, 5.0.0B1 - 5.0.3 Workaround: Don't use variables or functions with long sequences of underscores in C code. ------------------------------------------------------------------------------- FIXED SDSCM00046400 ------------------------------------------------------------------------------- Summary : op-assign of float expression to bit-field results in corrupted code Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: A bit-field may be assigned to with an op-assign (e.g. +=) operator. If the left hand side of the operator is a bit-field and right hand side is an expression with floating-point type, the compiler will in some cases write a corrupted value to the bit-field. Defect occurs in TMS470 Compiler versions: 4.4.0B1 - 4.4.18, 4.5.0B1 - 4.5.2, 4.4.10.100 - 4.4.10.118, 4.6.0B1 - 4.6.6, 4.4.15.201 - 4.4.15.210, 4.7.0B1 - 4.7.1, 4.8.0B1, 4.9.0B1 - 4.9.7, 4.7.1.201 - 4.7.1.202, 5.0.0B1 - 5.0.3 Workaround: Assign the value of the floating-point expression into a local integer variable and assign the local variable to the bit-field. ------------------------------------------------------------------------------- FIXED SDSCM00046408 ------------------------------------------------------------------------------- Summary : The compiler should accept the _sxth, _sxtb, _uxth, and _uxtb intrinsics for Cortex-M3 Fixed in : 5.1.0B1 Severity : S3 - Minor Affected Component : Parser Release Notes: The _sxth, _sxtb, _uxth, _uxtb intrinsics are now supported for Cortex-M3. Workaround: The operations of these intrinsics can be expressed in C without intrinsics: int x; unsigned y; (short)x; // _sxth (signed char)x; // _sxtb (unsigned short)y; // _uxth (unsigned char) y; // _uxtb ------------------------------------------------------------------------------- FIXED SDSCM00049564 ------------------------------------------------------------------------------- Summary : Assembler check for CBNZ range is too lenient Fixed in : 5.1.0B1 Severity : S2 - Major Affected Component : Assembler Release Notes: The assembler should emit a diagnostic when a CBNZ to an out-of-range label is used, but it doesn't emit a diagnostic in every case that it should. It checks that the range is less than or equal to 128, but it should check that the range is less than or equal to 126. Code which uses a CBNZ (which could be generated by the compiler) to a label 128 bytes away will be silently accepted by the assembler, but will be broken. Workaround: None. =============================================================================== 17. Current Known Issues =============================================================================== The following 66 known issues exist for TMS470 Code Generation Tools release 5.1.13 as of September 2015. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008248 ------------------------------------------------------------------------------- Summary : Compilers on PC will not work without TMP set Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00034609 Description: When compiling on the PC, the code generator cannot find the icode file produced by the parser if the environment variable TMP is no set. If TMP is set, then all appears well. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008465 ------------------------------------------------------------------------------- Summary : Language Conformance: crash because of void pointer dereference Affected Component : Parser Description: Compiler generates multiple INTERNAL ERRORs when code like the following is compiled: void dr106_1(void *pv, int i) { *pv; i ? *pv : *pv; *pv, *pv; } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008534 ------------------------------------------------------------------------------- Summary : Linker -xml_link_info option doesn't work when in a command file Affected Component : Linker Description: The option --xml_link_info=file.xml does not work when it is placed inside a linker command file. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008537 ------------------------------------------------------------------------------- Summary : assembler expression ~(0x80000000) evaulates as 0x80000000 Affected Component : Assembler Description: The following expression is evaluating incorrectly in the assembler: .eval ~(0x80000000), mask mask ends up getting assigned 0x80000000, whereas I expect it to be 0x7FFFFFFF. It seems that any constant with bit 31 set will incorrectly return 0x80000000 ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008543 ------------------------------------------------------------------------------- Summary : Forward reference in .space generates an internal error Affected Component : Assembler Description: If you attempt to assemble: .space 0+a b a .set 1 the assembler will generate an internal error. This happens with v3.83 and v4.1.0B1 on Solaris. If you change the code to: .space a b b .set 1 the correct error message is generated, 'Absolute, well-defined integer value expected'. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008685 ------------------------------------------------------------------------------- Summary : DWARF does not correctly represent variables stored in register pairs Affected Component : Code Generator Description: In the attached example, variables 'var1' and 'var2' are both long long types, and are stored in A7:A6 and B5:B4. However, the DWARF information shows var1 only to be in A6, and var2 only to be in B4: [000000e8] DW_TAG_variable DW_AT_name var1 DW_AT_symbol_name _var1 DW_AT_type [00000113] DW_AT_location { DW_OP_reg6 } [000000fa] DW_TAG_variable DW_AT_name var2 DW_AT_symbol_name _var2 DW_AT_type [00000113] DW_AT_location { DW_OP_reg20 } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008928 ------------------------------------------------------------------------------- Summary : Extern inline functions are not supported in the C/C++ Compiler Affected Component : Parser Duplicate Defects : SDSCM00018364 Description: Users cannot create global accessible code with INLINE functions. The V3.00 compiler/code generator does not create globally accessible code for functions which are declared inline. A simple example is: inline int x() { return 1; } int y() {return 2;} When compiled with 'cl6x -k -c test.c', a warning is produced: 'test.c', line 1: warning: function 'x' was declared but never referenced and the resulting assembler file (test.asm) does not contain any code for x(). The documentation states that code declared inline will be inlined in that module but global code will also be generated (section 2.10.3.2 in v3.00 C Compiler manual). The new compiler is overly aggressive in its optimizations. If y() is modified to call x() then code is generated for x() unless the optimizer is also invoked (by using -x2). ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00014430 ------------------------------------------------------------------------------- Summary : calloc doesn't check arguments to make sure the requested size is reasonable Affected Component : Runtime Support Libraries (RTS) Description: The function calloc() is required to return a pointer to memory representing "nelem" copies of "size" bytes, or NULL if the request cannot be satisfied. However, for some values of "nelem" and "size" (specifically when the result of nelem*size wraps around), calloc can return a pointer to an object that is not large enough, rather than NULL. For example, on a 32-bit target, if the user calls calloc(0x00010001, 0x00010001), even though each argument by itself is reasonable, the request cannot be satisfied because the product is 0x000100020001, which exceeds size_t. (Note that we cannot check for overflow by checking if the product is less than either argument, which is commonly done for unsigned addition.) Arguably, we can try to claim that it is undefined behavior to make a call to calloc where the product would exceed size_t, but there doesn't seem to be anything in the standard which says so. The problem is worse on 16-bit targets, where calloc(0x0101, 0x0101) is enough to overflow size_t. It may not be obvious to the user that this overflows. Another concern is that it is hard to figure out whether a multiplication will overflow without having a double-width multiply available. ------------------------------------------------------------------------------- KNOWN ISSUE 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 SDSCM00033221 ------------------------------------------------------------------------------- Summary : The linker allows linking of VFP ARM object files with non-VFP TI object files, but does not allow linking of two VFP files Affected Component : C/C++ Compiler (cl) Description: The linker does not generate an error if the user attempts to link together an object file compiled with the ARM tools with VFP support and an object file compiled with TI tools without VFP support. Also, the linker does generate an error message when trying to link together two VFP files, one compiled with ARM tools and the other with TI tools. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00036770 ------------------------------------------------------------------------------- Summary : LDREXD and STREXD instructions erroneously generate errors on Cortex A8 and R4 Affected Component : Assembler Description: LDREXD and STREXD are valid instructions on Cortex R4 and A8 architectures but the assembler generates errors. The first error states that [Rn] must be a register indirect and the second complains of unexpected trailing operands. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00036773 ------------------------------------------------------------------------------- Summary : LDM/STM -DA/FA/IB/ED viariant instructions erroneously accepted by assembler for Cortex-M3 Affected Component : Assembler Description: LDM and STM instructions ending with DA, FA, IB and ED are not available in the Thumb instruction set, but the assembler accepts these for Cortex-M3 and converts them to LDM and STM instructions ending with IA.W. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00036874 ------------------------------------------------------------------------------- Summary : Section relative ELF symbol values in partially linking object files should hold the section offset for the symbol Affected Component : ELF Linker Description: The symbol value in an ELF relocatable file should be the offset from the beginning of the section. Typically the sections all start at address 0, so the value corresponds to its address in the file. In a partially linking object file, the sections will start at different addresses. The symbol values contain the absolute address instead of the offset. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00037008 ------------------------------------------------------------------------------- Summary : Linker outputting wrong build attribute name for EABI TAG_VFP_arch on ARM targets Affected Component : ELF Linker Description: For TMS470, linker outputs EABI build attribute TAG_VFP_arch name as "Producer Minor Version + 1" instead of the correct name for the specific tag value. The TI build attribute TAG_VFP_arch name is printed correctly. The names are entered correctly for the EABI VFP_arch tag values but are not being accessed. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00037086 ------------------------------------------------------------------------------- Summary : ARM assembler allows incorrect VFP registers for some instructions on D16 VFP architectures Affected Component : Assembler Description: ARM assembler allows the use of VFP registers D16-D31 on D16 VFP targets for the following VFP instructions: single and multiple loads and stores, pop, push, and register transfers between VFP and core registers. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00037227 ------------------------------------------------------------------------------- Summary : ARM disassembler error for VMRS instruction Affected Component : Disassembler (dis) Description: The ARM disassembler errorneously disassembles "VMRS APSR_[bits], FPSCR" as "VMSR PC, FPSCR". The instruction is formatted as "FMSTAT" in the code generator in vfp.md (vfp_transfer_status_to_cpsr). ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00037308 ------------------------------------------------------------------------------- Summary : Assembler does not encode the proper offset for a VLDR immediate instruction in thumb 2 mode Affected Component : Assembler Description: In thumb 2 mode, the value of the PC register at a given instruction is PC+4 (in ARM it is PC+8). When encoding the VLDR instruction the assembler always encodes the instruction as if the PC is PC+8. This will cause the VLDR instruction to never work correctly in thumb 2 mode. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00038278 ------------------------------------------------------------------------------- Summary : ARM floating point conversion routines do not support NaN Affected Component : Runtime Support Libraries (RTS) Description: The ARM assembly routines that handle converting floating point types do not handle NaN correctly. In these routines NaN is considered to be infinity. ------------------------------------------------------------------------------- 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 SDSCM00039220 ------------------------------------------------------------------------------- Summary : Assembler does not accept the SP operand of the SRSDB instruction Affected Component : Assembler Description: The assembler accepts SRSDB #, but the reference manual specifies that the instruction should have an SP! operand. ------------------------------------------------------------------------------- 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 SDSCM00039626 ------------------------------------------------------------------------------- Summary : ARM assembler does not issue a warning for PC-relative loads when --embedded_constants=off Affected Component : Assembler Description: When the --embedded_constants=of option is used, the assembler is supposed to issue an error message if it detects any PC-relative loads. It does this for LDR instructions that are 32-bits long, but not for the 16-bit versions. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00039636 ------------------------------------------------------------------------------- Summary : When creating a partial linked ELF object file, the linker uses virtual addresses instead of relative addresses. Affected Component : Linker Description: In ELF, relocatable object files should always using section relative values for relocation offsets and symbols values. When creating a partially linked object file the linker uses virtual addresses for these values. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00040522 ------------------------------------------------------------------------------- Summary : _ssatl intrinsic allows 3rd argument to be 0 resulting in an assembler error. Affected Component : Parser Description: The SSAT instruction does not accept a 0 for the immediate argument. We should ensure in the parser that 0 is not allowed. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00040523 ------------------------------------------------------------------------------- Summary : The _ssat16 intrinsic allows literals in the range of 0-31, but the SSAT16 instruction only accepts values from 1-16 Affected Component : Parser Description: The parser should catch this so the assembler doesn't generate an error. ------------------------------------------------------------------------------- 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 SDSCM00042418 ------------------------------------------------------------------------------- Summary : Internal error when compiling code with WEAK functions; linker crash Affected Component : C/C++ Compiler (cl) Description: /* Command line: cl470 --abi=eabi weak2.c -z -l c:\Programme\TexasInstruments\ccsv4\tools\compiler\tms470\lib\libc.a Resulting output: warning: output section ".data" refers to load symbol "weakFunc" and hence cannot be compressed; compression "rle" is ignored warning: output section ".data" refers to load symbol "weakFunc" and hence cannot be compressed; compression "rle" is ignored table.c:3601:internal fatal error #10225: (.cinit..data.load) This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. INTERNAL ERROR: lnk470 aborted 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 Toolchain: TMS470 4.6.4 or 4.6.6 on 32-bit WinXP SP3. */ #pragma WEAK(weakFunc); extern void weakFunc(); void (*ptr)() = weakFunc; int main() { if (ptr) ptr(); } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00042434 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 6.4 for bitfield definitions Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00043122 Description: Compiler misreports Misra warning 6.4 for bitfield definitions. typedef unsigned int uint16_t; typedef unsigned int bool_t; #define FALSE ((bool_t)0U) #define TRUE ((bool_t)1U) typedef struct mystructtag { uint16_t u16_hw_rev1; bool_t bl_hardware_supported:1; /* this violates rule 6.4 */ } st_software_info_t ; This generates the warning: "misra_test.c", line 9: warning: (MISRA-C:2004 6.4/R) Bit fields shall only be defined to be of type unsigned int or signed int Related forum thread: http://e2e.ti.com/support/development_tools/compiler/f/343/t/147639.aspx According to Misra, this is not a Misra violation. http://www.misra- c.com/forum/viewtopic.php?f=62&t=1167&sid=6fd53ec7591d33a4fa1b38e975c580bc ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00042435 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 10.1 Affected Component : C/C++ Compiler (cl) Description: Compiler misreports Misra warning 10.1 with the following code: typedef unsigned int uint16_t; typedef unsigned int bool_t; #define FALSE ((bool_t)0U) #define TRUE ((bool_t)1U) typedef struct mystructtag { uint16_t u16_hw_rev1; bool_t bl_hardware_supported:1; /* this violates rule 6.4 */ } st_software_info_t ; void main(void) { uint16_t u16_rev1_min, u16_tmp; st_software_info_t sts_sw_info; u16_rev1_min = 900U; sts_sw_info.bl_hardware_supported = FALSE; if (sts_sw_info.bl_hardware_supported == FALSE) /* this violates rule 10.1 */ { /* do something... */ } if (sts_sw_info.u16_hw_rev1 >= u16_rev1_min) /* this violates rule 10.1 */ { /* do something... */ } u16_tmp = sts_sw_info.u16_hw_rev1; if (u16_tmp >= u16_rev1_min) /* this does not violates rule 10.1 */ { /* do something... */ } The warning is: "misra_test.c", line 22: warning: (MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if it is not a conversion to a wider integer type of the same signedness "misra_test.c", line 27: warning: (MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if it is not a conversion to a wider integer type of the same signedness Related forum thread:http://e2e.ti.com/support/development_tools/compiler/f/3- 43/t/147639.aspx Related Misra threads that say this is not a Misra violation: http://www.misra- c.com/forum/viewtopic.php?f=62&t=1167&sid=6fd53ec7591d33a4fa1b38e975c580bc http://www.misra- c.com/forum/viewtopic.php?f=66&t=1168&sid=6fd53ec7591d33a4fa1b38e975c580bc ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00042600 ------------------------------------------------------------------------------- Summary : Ill advised enum scalar usage gets MISRA diagnostic, but similar usage of enum array does not Affected Component : C/C++ Compiler (cl) Description: The test case given assigned a integer to an enum scalar variable. MISRA checking correctly flags this with a diagnostic. The test case goes on to do the same thing with an enum array expression. It should get the same MISRA diagnostic, but does not. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00042945 ------------------------------------------------------------------------------- Summary : -pdse=195 causes an error under EABI if any standard header file is included Affected Component : Runtime Support Libraries (RTS) Description: This is the same bug as CQ19871. The problem appears to be that _AEABI_PORTABILITY_CHECK is defined in terms of _AEABI_PORTABILITY_LEVEL != 0 where _AEABI_PORTABILITY_LEVEL is not defined. This same idiom is used in many header files. ------------------------------------------------------------------------------- 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 SDSCM00044035 ------------------------------------------------------------------------------- Summary : float library functions misbehave with -me --float_support=fpalib Affected Component : Runtime Support Libraries (RTS) Description: Fails with optmization, passes with --no_high_level_opt, but the optimizer seems to be doing the right thing. Something is swapping the words in the double. If the words for each float constant in the assembly code are reversed, the test case works. I don't know whether the compiler is creating the float constants with the wrong endianness or the library is handling it with the wrong endianness. See also the closely related SDSCM00044038 ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00044038 ------------------------------------------------------------------------------- Summary : float library functions misbehave with --abi=eabi -mv5e -me --float_support=fpalib Affected Component : Runtime Support Libraries (RTS) Description: Looking at the assembly code test_number gets converted to a double like I would expect but the comparison fails. See also the closely related SDSCM00044035 ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00044056 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 10.1 Affected Component : C/C++ Compiler (cl) Description: Compiler misreports MISRA warning 10.1/R for the following code. typedef enum _MyEnum { One, Two } MyEnum; MyEnum MyVariable; int foo(void) { int result = 1; if (One == MyVariable) // fails here with MISRA-C:2004 10.1/R { result = 2; } return result; } Our coding style convention requires that the variable is at the right hand side. Therefore I don't want to swap One and MyVariable, although that makes the warning to disappear. Is that a bug in the MISRA checker? If not, why is the comparison of two terms not commutable? ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00045452 ------------------------------------------------------------------------------- Summary : Compiler misreports MISRA warning 17.6 Affected Component : C/C++ Compiler (cl) Description: Compiler misreports MISRA warning 17.6 with the attached code. (MISRA-C:2004 17.6/R) The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist In the following code, the assignment of &myLocalStruct->data to myDataPtr in myFunc has MISRA 17.6 reported. myDataPtr only persists for the duration of the function, and therefore does not persist longer than data passed into that function. typedef struct { uint8 data; } Struct_T; void myFunc(Struct_T *myLocalStruct); void main(void); void myFunc(Struct_T *myLocalStruct) { uint8 *myDataPtr; myDataPtr = &myLocalStruct->data; /* (MISRA-C:2004 17.6/R) reported here */ } void main(void) { Struct_T myStruct = { 0U }; myFunc(&myStruct); } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00045473 ------------------------------------------------------------------------------- Summary : Compiler misreports violation of Misra 9.2 for zero initialization of structures Affected Component : C/C++ Compiler (cl) Description: Compiler misreports violation of Misra 9.2 for zero initialization of structures. (MISRA-C:2004 9.2/R) Braces shall be used to indicate and match the structure in the non-zero initialisation of arrays and structures typedef struct { unsigned char nModuleId; unsigned char nInstanceId; unsigned char nApiId; unsigned char nErrorId; } DetLog_T; DetLog_T sctDetLog_M[0x100] = { 0U }; ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00046102 ------------------------------------------------------------------------------- Summary : MISRA 12.8 and MISRA 10.5 false positives Affected Component : Parser Description: I was wondering if the compiler's MISRA checking is reporting false positives. I have the following code #define DEF_X (0x00000001UL) #define DEF_Y (4U) static void foo(void) { uint32 nReadData; nReadData = DEF_X << DEF_Y; } This gives me a MISRA error... #1397-D (MISRA-C:2004 10.5/R) If the bitwise operators ~ and << are applied to #an operand of underlying type unsigned char or unsigned short, the result #shall be immediately cast to the underlying type of the operand. But the underlying type is a "UL" or 32bit unsigned integer. If I try to fix the error using the code... nReadData = (uint32)DEF_X << DEF_Y; This gives me a MISRA error... #1407-D (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 But the right hand operator has a value of 4 and the left hand operator is 32 bits. The only way I can solve the problem is by assigning the #define values to temporary variables and then doing the shift operation with these. With this in mind I think the misra checking is not handling the #define values correctly.. Am I correct in this assumption? ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00046352 ------------------------------------------------------------------------------- Summary : Disassembler does not emit certain instructions in UAL form by default Affected Component : Disassembler (dis) Description: See the test case for SDSCM00046351. For instructions combining the S flag and a condition code, UAL requires the S to appear before the condition code, but the disassembler puts it afterward, in the pre-UAL style: UAL syntax: LSLSEQ R2, R2, #2 LSLSNE R2, R2, #2 disassembler output: (7A8) MOVEQS R2, R2, LSL #2 MOVNES R2, R2, LSL #2 I've no idea whether UAL expects the LSL or MOV syntax. rv40fromelf -c ouputs the LSL form, so I assume that's the UAL form. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00046409 ------------------------------------------------------------------------------- Summary : __ldrex pointer parameter should be "volatile void*" Affected Component : C/C++ Compiler (cl) Description: (This question was originally posted in the Stellaris area but Dave pointed out that it really belongs here) __ldrex and __strex intrinsics don't qualify parameter with volatile. According to ARM, the pointer parameter should be "volatile void*". http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491c/CJA- FAFAF.html I have a variable which many source tasks race to change from zero to non- zero; this should use LL-SC. But only one sink task can change it when already non-zero. The sink task therefore doesn't need LL-SC, merely a volatile read and volatile write. However, the compiler won't let me mark the variable as volatile. These intrinsics should accept a pointer to volatile, because they access the location with volatile semantics, and the volatile qualifier can be implicitly added but not removed. volatile uint8_t active; do { if (__ldrexb(&active)) return; } while (__strexb(5, &active)); Is there some reason that these instructions wouldn't behave as expected with volatile variables? ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00048267 ------------------------------------------------------------------------------- Summary : Warning generated when using __curpc intrinsic on Thumb 2 Affected Component : Code Generator Description: When using the __curpc intrinsic in Thumb 2 mode, the compiler generates code for which the assembler gives a warning. This should not affect the execution of the __curpc instruction, but could indicate incorrect execution of surrounding instructions. "file.asm", WARNING! at line 54: [W0004] Invalid instruction modifier(s) ignored MOVR A1, PC; MOVE REG-TO-REG ; [DPU_4_PIPE0] |2| ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00048287 ------------------------------------------------------------------------------- Summary : Linker fails to warn when stack is not explicitly allocated to a memory range Affected Component : Linker Description: The linker command file for the attached test case does not allocate the .stack section to any memory range. It also uses the --warn_sections option. Thus, you would expect a diagnostic stating that .stack is being allocated without a SECTIONS specification. However, no diagnostic is issued. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00048976 ------------------------------------------------------------------------------- Summary : The assembler does not support UAL syntax .N and .W instruction extensions when building for non-Cortex devices Affected Component : Assembler Description: The ARM assembly tools manual, in the section on Unified Assembly Language Syntax Support, discusses UAL syntax. It says UAL syntax is supported for ARMv6 and earlier devices when the --ual switch is used. It also specifically indicates the .W and .N instruction extensions are supported. However, this test case ... .text .thumb bne.n dd nop dd: nop Does not assemble for any device ARMv6 or earlier. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049108 ------------------------------------------------------------------------------- Summary : Should accept cmp r9,#-32768 and turn it into cmn r9,#32768 in Thumb-2 mode Affected Component : Assembler Description: The assembler should accept "cmp r9,#-32768" and encode it as "cmn r9,#32768". ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049121 ------------------------------------------------------------------------------- Summary : Assembler mistakenly treats qadd16 instruction as qadd if presented in lowercase Affected Component : Assembler Description: Assembler mistakenly treats qadd16 as QADD but correctly handles QADD16. [ See also SDSCM00049122 ] ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049122 ------------------------------------------------------------------------------- Summary : ARM assembler handles lower case instructions differently than upper case ones Affected Component : Assembler Description: Writing an instruction sequence in lower case can cause the assembler to incorrectly emit diagnostics. If these same instructions are written in upper case, no diagnostic is issued. Some examples include ... it eq addeq r9,r9,#1 qsub16 r5,r14,r7 [ See also SDSCM00049121 SDSCM00049110 ] ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049284 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 10.1 Affected Component : Parser Description: Compiler misreports MISRA warning 10.1/R for the following code. typedef enum _MyEnum { One, Two } MyEnum; MyEnum MyVariable; int foo(void) { int result = 1; if (One == MyVariable) // fails here with MISRA-C:2004 10.1/R { result = 2; } return result; } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049356 ------------------------------------------------------------------------------- Summary : Violation of MISRA rule 14.3 is not reported. Affected Component : C/C++ Compiler (cl) Description: The example below should flag rule 16.10 but it doesn't. Run armcl -- check_misra=14.3 extern volatile int enLocalJobId; #define E_CYMNG_NULL_JOB 0 void foo() { while( enLocalJobId == E_CYMNG_NULL_JOB ) {;} } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049553 ------------------------------------------------------------------------------- Summary : ARM intrinsics documentation does not match interface supplied by compiler Affected Component : Documentation Description: There are many cases where the documentation for an intrinsic does not match the interface supported by the compiler. Two examples are: int _smmul(int src1 , int src2 , int acc ); is actually defined by the compiler as int_smmul (intsrc1, intsrc2); (3rd parameter is in excess). int _smsub(int src1 , int src2 );is actually defined by the compiler asint _smsub (shortsrc1, shortsrc2, inttmp); (int instead of short and missing 3rd parameter) All of the intrinsics need to be reviewed for possible mismatch. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049741 ------------------------------------------------------------------------------- Summary : In R4 big endian TI object code, CCS may not read unsigned char function parameters properly. Affected Component : C/C++ Compiler (cl) Description: In R4 big endian TI object code, unsigned char arguments may be stored in 4 bytes word. CCS only reads the significant bytes of the parameters and reports zeros. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049805 ------------------------------------------------------------------------------- Summary : ARM GCC objdump crashes when disassembling TI produced executable Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00051842, SDSCM00050016 Description: Use the TI ARM compiler to build the usual hello world example program. Then try to use arm-none-eabi-objdump -S to disassemble it. objdump crashes. It is unclear whether this is a problem with the TI tools, or the GCC tools. This is definitely a bug in GNU binutils; see https://sourceware.org/bugzilla/show_bug.cgi?id=16822 [ See also SDSCM00050016 ] ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049911 ------------------------------------------------------------------------------- Summary : __aeabi_dcmpun returns 1 for Inf and -Inf Affected Component : Runtime Support Libraries (RTS) Description: ARM EABI function __aeabi_dcmpun is a binary function which returns 1 if either operand is NaN, and 0 otherwise. However, when either operand is +-Inf, it returns 1. __aeabi_dcmpun does not have this bug. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050131 ------------------------------------------------------------------------------- Summary : Local struct with non-constant initializer treated as static scope variable Affected Component : Parser Description: We've discovered a problem where the C++ compiler places a local structure variable not on the stack but in the data segment, as if it was a static structure. The problem is especially insidious because the issue will only have an impact on re-entrance. The problem seems to occur only for C++ files, and only if the structure initializer list contains a variable. Constant initializer lists do not trigger the issue. The structure in the first function will be allocated on the stack, but the structure in the second will be compiled as if it was declared static. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050262 ------------------------------------------------------------------------------- Summary : LTO does not maintain mapping between input sections and LTO sections for .const:.string and .init_array Affected Component : C/C++ Compiler (cl) Description: The linker must maintin a mapping between input sections and the sections created in the temporary lto object file. This is important because it allows the user to specify special placement for sections when using LTO and it allows the original section names to be used in the map file and diagnostics. If we loose this mapping, the file is reported as and is confusing. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050391 ------------------------------------------------------------------------------- Summary : Compiler incorrectly warns that const members of a struct require a constructor to be initialized Affected Component : C/C++ Compiler (cl) Description: For this code ... struct sss { const int i; }; The compiler issues this diagnostic ... "file.cpp", line 1: warning: class "sss" defines no constructor to initialize the following: const member "sss::i" It is possible to initialize a struct sss variable without a constructor ... struct sss g = { 10 }; ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050841 ------------------------------------------------------------------------------- Summary : Compiler mistakenly issues MISRA diagnostic 12.9 "The unary minus operator shall not be applied to an [unsigned] expression" Affected Component : C/C++ Compiler (cl) Description: For code similar to ... double_val = -1.0 * double_val; The compiler mistakenly issues the MISRA diagnostic ... "file.c", line 6: warning: (MISRA-C:2004 12.9/R) The unary minus operator shall not be applied to an expression whose underlying type is unsigned ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050842 ------------------------------------------------------------------------------- Summary : Compiler mistakenly issues MISRA diagnostic 17.6 "The address of an object with automatic storage shall not be assigned ..." Affected Component : C/C++ Compiler (cl) Description: For a source line similar to ... ptr_to_struct1->field = ptr_to_struct2->field; The compiler mistakenly issues the MISRA diagnostic ... "file.c", line 15: warning: (MISRA-C:2004 17.6/R) The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist ("ptr_to_struct2") ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050843 ------------------------------------------------------------------------------- Summary : Compiler mistakenly issues MISRA diagnostic 12.2 "The value of an expression shall be the same under any order of evaluation" Affected Component : C/C++ Compiler (cl) Description: For a source line similar to ptr_to_struct->array[ptr_to_struct->field] = value; The compiler mistakenly issues the MISRA diagnostic ... "file.c", line 15: warning: (MISRA-C:2004 12.2/R) The value of an expression sha ll be the same under any order of evaluation that the standard permits ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050851 ------------------------------------------------------------------------------- Summary : Compiler may fail with INTERNAL ERROR message when --check_misra=none is used Affected Component : C/C++ Compiler (cl) Description: When --check_misra=none is used, the compiler may fail with a message similar to ... INTERNAL ERROR: armacpia experienced a segmentation fault while processing function main file file.c line 10 [ Appears to be Windows-only ] ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050901 ------------------------------------------------------------------------------- Summary : Memory access larger than the containing struct is generated when accessing packed bitfields. Affected Component : Code Generator Description: The problem occurs when accessing the following field: struct __attribute__((packed) S { uint64_t x:33 } s; s.x; Our compiler generates a 64-bit access for the field. This is incorrect since the struct itself is only 40 bits in size. The fundamental problem is that our field extraction code only supports generating a single scalar access for a given field. In this case we really need to generate two accesses, a 32 bit access followed by an 8 bit access. This could be a problem if the struct happens to end up next to an special memory region (end of memory, peripheral, etc). ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051003 ------------------------------------------------------------------------------- Summary : False reports of MISRA errors 10.1 and 103 Affected Component : C/C++ Compiler (cl) Description: Source lines similar to these ... uint32_t *uintptr = NULL; /* sees 10.1 */ uintptr = &(struct_ptr->a); /* sees 10.1 */ uintptr = (uint32_t*)&(struct_ptr->a); /* sees 10.3 */ ... see the MISRA errors listed. However, these source lines are correct. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051194 ------------------------------------------------------------------------------- Summary : Should accept MOV R0, #0x7fffffff and turn it into MVN R0, #0x80000000 Affected Component : Assembler Description: These instructions do exactly the same thing, but the first is not technically legal MOV R0,#0x7fffffff MVN R0,#0x80000000 ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051350 ------------------------------------------------------------------------------- Summary : MISRA 16.4 warning on function prototypes for builtins Affected Component : Parser Description: The parser should not emit a warning for MISRA 16.4 for prototypes for functions that happen to be builtin functions. There's no way for the user to figure out what the right parameter names are. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051511 ------------------------------------------------------------------------------- Summary : ARM Compiler Missing Stack Usage information when using --no_stm Affected Component : C/C++ Compiler (cl) Description: The call stack in CCS isn't working anymore when using the --no_stm switch. It seems that the debug information for the stack usage are missing when using the --no_stm switch. The following assembly directives are missing wehen --no_stm is in use: .dwcfi cfa_offset, 8 .dwcfi save_reg_to_mem, 14, -4 .dwcfi save_reg_to_mem, 3, -8 The issue appears on version 5.1.9 and 5.2.2. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051702 ------------------------------------------------------------------------------- Summary : Compiler falsely reports MISRA error 10.1 The value of an expression of integer type shall not be implicitly converted Affected Component : Parser Description: The following test case void test_func(uint32_t *ptr); void another_fxn() { uint32_t fail = 0u; test_func(&fail); } Causes the compiler to issue this MISRA diagnostic ... "file.c", line 15: 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 not constant and is a function argument test_func(&fail); ^ However, no type conversion is present. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00052173 ------------------------------------------------------------------------------- Summary : Inclusion of math.h should not require intrinsics be enabled Affected Component : Runtime Support Libraries (RTS) Description: math.h (or other headers included by it) often include intrinsics for speed. When intrinsics are not enabled, errors are generated. Currently, on TMS470, this is caused by _ftoi, _hi, and _lo. On MSP430 and C2000, this is caused by __f32_bits_as_u32 and __f64_bits_as_u64.