C6000 C/C++ CODE GENERATION TOOLS 7.3.21 March 2015 Defect History ------------------------------------------------------------------------------- Table of Contents ------------------------------------------------------------------------------- 1. Defects fixed in C6000 Code Generation Tools release 7.3.21 2. Defects fixed in C6000 Code Generation Tools release 7.3.20 3. Defects fixed in C6000 Code Generation Tools release 7.3.19 4. Defects fixed in C6000 Code Generation Tools release 7.3.18 5. Defects fixed in C6000 Code Generation Tools release 7.3.17 6. Defects fixed in C6000 Code Generation Tools release 7.3.16 7. Defects fixed in C6000 Code Generation Tools release 7.3.15 8. Defects fixed in C6000 Code Generation Tools release 7.3.14 9. Defects fixed in C6000 Code Generation Tools release 7.3.13 10. Defects fixed in C6000 Code Generation Tools release 7.3.12 11. Defects fixed in C6000 Code Generation Tools release 7.3.11 12. Defects fixed in C6000 Code Generation Tools release 7.3.10 13. Defects fixed in C6000 Code Generation Tools release 7.3.9 14. Defects fixed in C6000 Code Generation Tools release 7.3.8 15. Defects fixed in C6000 Code Generation Tools release 7.3.7 16. Defects fixed in C6000 Code Generation Tools release 7.3.6 17. Defects fixed in C6000 Code Generation Tools release 7.3.5 18. Defects fixed in C6000 Code Generation Tools release 7.3.4 19. Defects fixed in C6000 Code Generation Tools release 7.3.3 20. Defects fixed in C6000 Code Generation Tools release 7.3.2 21. Defects fixed in C6000 Code Generation Tools release 7.3.1 22. Defects fixed in C6000 Code Generation Tools release 7.3.0 23. Defects fixed in C6000 Code Generation Tools release 7.3.0B3 24. Defects fixed in C6000 Code Generation Tools release 7.3.0B1 25. Current Known Issues =============================================================================== 1. Defects fixed in C6000 Code Generation Tools release 7.3.21 =============================================================================== The following 5 defects were fixed in C6000 Code Generation Tools release 7.3.21, released March 2015. ------------------------------------------------------------------------------- FIXED SDSCM00050103 ------------------------------------------------------------------------------- Summary : Buffer the output of warning and error messages to facilitate better error reporting during parallel compilation Fixed in : 7.3.21 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 C6000 Compiler versions: 7.3.8 - 7.3.20, 7.4.0B1 - 7.4.13, 8.0.0B1 - 8.0.1 Workaround: Workaround is to manually buffer the compiler output using a script or with the --write_diagnostics_file option. ------------------------------------------------------------------------------- FIXED SDSCM00051314 ------------------------------------------------------------------------------- Summary : Under --opt_level=3 compiler generated code ignores pointer check for NULL present in the source Fixed in : 7.3.21 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: A for-loop which includes at least two early exits, with one exit testing if a pointer is NULL and another testing if something reached by that pointer is NULL, may compile incorrectly and dereference a NULL pointer. The problem is specific to C6000. Defect occurs in C6000 Compiler versions: 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.20, 7.4.0B1 - 7.4.12, 7.5.0B1, 7.6.0B1 - 7.6.0, 8.0.0B1 - 8.0.0 Workaround: Compile at -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00051346 ------------------------------------------------------------------------------- Summary : After unrolling loop, compiler ignores the iterations left over Fixed in : 7.3.21 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: A loop may unroll incorrectly, losing some iterations, if its known trip counts are divisible by a factor that is not evenly divisible by the unroll factor. In this case, the known trip counts are 143 and 165, which share the factor 11. The compiler unrolls by 2X, which makes the trip counts 71 and 82 (with one excess iteration), and erroneously determines that the new factor is 5. Defect occurs in C6000 Compiler versions: 6.1.0B2 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.20, 7.4.0B1 - 7.4.12, 7.6.0B1 - 7.6.0, 8.0.0B1 - 8.0.0 Workaround: Use "#pragma UNROLL(1)" to inhibit unrolling, or compile with -o1 or -o0. In at least some cases, using -ms1 or greater, or -mf2 or less, will also inhibit unrolling in a way that avoids the problem. ------------------------------------------------------------------------------- FIXED SDSCM00051463 ------------------------------------------------------------------------------- Summary : Automatic library resolution fails when a a load image file is included in the link Fixed in : 7.3.21 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 C6000 Compiler versions: 7.3.0B1 - 7.3.20, 7.4.0B1 - 7.4.12, 7.6.0B1 - 7.6.0, 8.0.0B1 - 8.0.1 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 : 7.3.21 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 C6000 Compiler versions: 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.20, 7.4.11 - 7.4.13, 7.6.0B1 - 7.6.0, 8.0.0B1 - 8.0.1 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. =============================================================================== 2. Defects fixed in C6000 Code Generation Tools release 7.3.20 =============================================================================== The following 6 defects were fixed in C6000 Code Generation Tools release 7.3.20, released January 2015. ------------------------------------------------------------------------------- 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 : 7.3.20 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 SDSCM00051097 ------------------------------------------------------------------------------- Summary : Output section splitting creates a zero-length section Fixed in : 7.3.20 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 C6000 Compiler versions: 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.19, 7.4.0B1 - 7.4.11, 7.6.0B1 - 7.6.0, 8.0.0B1 - 8.0.0 Workaround: 1) Do not split the section in question. 2) Change the zero-length section so that it has at least one more byte. ------------------------------------------------------------------------------- FIXED SDSCM00051143 ------------------------------------------------------------------------------- Summary : Need compiler fix for SPLOOP-SPKERNEL-interrupt bug Fixed in : 7.3.20 Severity : S2 - Major Affected Component : Code Generator Duplicate Defects : SDSCM00051127 Release Notes: Preliminary! Subject to revision: Two defects on C674 and C66 ISA cores have been identified: (1) When: - On a C6600 core, and - An SPLOOP - with an instruction "A" that is a 3 or 4 cycle multicycle instruction - and instruction "A" is one of those instruction/unit combinations listed below - and instruction "A" writes a register two cycles lexically "after" the SPKERNEL instruction - and a single cycle instruction "B" in the post-epilog code uses the same write port as instruction "A" two cycles after the SPKERNEL instruction - and an interrupt occurs during SPLOOP execution The hardware can incorrectly detect a write port conflict and not write the results of the instruction "A" from the loop buffer. Note that some instructions appear in the S unit list and not the L unit list (marked with a *). This is correct. Note that all of these instruction/unit combinations are only on C66 CPUs. L unit DADDSP L unit DSUBSP L unit DINTSP L unit DINTSPU L unit DINTHSP L unit DINTHSPU L unit FADDSP L unit FSUBSP L unit DSPINTH L unit DSPINT L unit FADDDP L unit FSUBDP L unit DMVD S unit DADDSP S unit DSUBSP S unit DINTSP S unit DINTSPU S unit DINTHSP S unit DINTHSPU S unit FADDSP S unit FSUBSP S unit DSPINTH S unit DSPINT S unit FADDDP S unit FSUBDP S unit SPINT * Compiler currently does not generate SPINT on S for C66 (only on L) S unit INTSP * Compiler currently does not generate INTSP on S for C66 (only on L) S unit INTSPU * Compiler currently does not generate INTSPU on S for C66 (only on L) S unit DMVD (2) When: - On a C6740 or C6600 core, and - an SPLOOP - with an instruction "A" that reserves its functional unit for more than one cycle (list of instructions below) - and instruction "A"'s functional unit reservations occur one or two cycles lexically "after" the SPKERNEL instruction - and an instruction "B" lexically "after" the SPKERNEL instruction in the post-epilog code uses the same functional unit in the same cycle as the "A" instruction - and an interrupt occurs during SPLOOP execution the hardware can incorrectly throw an exception. CMPEQDP, CMPLTDP, CMPGTDP - reserves S1 or S2 for 2 cycles ADDDP, SUBDP - reserves L1, L2, S1, or S2 for 2 cycles MPYI, MPYID, MPYDP, - reserves M1 or M2 for 4 cycles MPYSPDP - reserves M1 or M2 for 2 cycles Defect occurs in C6000 Compiler versions: 7.3.0B1 - 7.3.19, 7.4.8 - 7.4.12, 8.0.0B1 - 8.0.0 Workaround: There are two possible workarounds: (1) Use --disable:sploop on those files whose loops are susceptible to the HW defects (see description of the silicon defects, above). (2) Disable interrupts around the inner loops that are susceptible to the HW defects with the intrinsics _disable_interrupts(), _enable_interrupts(), and _restore_interrupts(...). Please see section 7.5.9 of the TMS320C6000 Optimizing Compiler v7.6 User's Guide, spru187v for guidance on proper usage of these intrinsics. ------------------------------------------------------------------------------- FIXED SDSCM00051234 ------------------------------------------------------------------------------- Summary : asm(" nop 5") changes position with another asm statement Fixed in : 7.3.20 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: When multiple, consecutive inline assembly statements are used together on C6000, they may potentially become reversed in order. This is caused by pipelining, so disabling the pipeliner (option -mu) should resolve the problem. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.19, 7.4.11 - 7.4.12, 7.6.0B1 - 7.6.0, 8.0.0B1 - 8.0.0 Workaround: Disable the pipeliner (option -mu) for files containing affected inline assembly statements. ------------------------------------------------------------------------------- FIXED SDSCM00051241 ------------------------------------------------------------------------------- Summary : Output section splitting creates a zero-length section Fixed in : 7.3.20 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 C6000 Compiler versions: 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.19, 7.4.0B1 - 7.4.11, 7.6.0B1 - 7.6.0, 8.0.0B1 - 8.0.0 Workaround: 1) Do not split the section in question. 2) Change the zero-length section so that it has at least one more byte. ------------------------------------------------------------------------------- FIXED SDSCM00051273 ------------------------------------------------------------------------------- Summary : Performance degrades moving from v7.2.8 to v7.4.11 Fixed in : 7.3.20 Severity : S2 - Major Classification : Performance Affected Component : Optimizer Release Notes: A loop whose index variable has a type shorter than int may not achieve the expected performance. The known case is a downcounting loop using an unsigned-char variable i, which also uses the expression i-1 in the loop. The two instances of i-1 (for the decrement and the explicit use) in combination with the shorter-than-int type of i are apparently the two factors required to exhibit the problem. Defect occurs in C6000 Compiler versions: 7.3.0B1 - 7.3.20, 7.4.0B1 - 7.4.12, 8.0.0B1 - 8.0.0 Workaround: Use signed-int loop variables instead of types shorter than int. =============================================================================== 3. Defects fixed in C6000 Code Generation Tools release 7.3.19 =============================================================================== The following 3 defects were fixed in C6000 Code Generation Tools release 7.3.19, released November 2014. ------------------------------------------------------------------------------- FIXED SDSCM00050725 ------------------------------------------------------------------------------- Summary : Hang/crash in partitioning for C674x Fixed in : 7.3.19 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The INTERNAL ERROR is caused by an instruction scheduling partitioning failure. Workaround: Use -o0. ------------------------------------------------------------------------------- FIXED SDSCM00050960 ------------------------------------------------------------------------------- Summary : Array memory allocated by new is not initialized to 0 Fixed in : 7.3.19 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Corrected bug where some calls to new[] did not properly initialize memory. Defect occurs in C6000 Compiler versions: 7.3.19 - 7.3.18, 7.4.7 - 7.4.11 Workaround: Manually initialize memory. ------------------------------------------------------------------------------- FIXED SDSCM00050996 ------------------------------------------------------------------------------- Summary : The file misra.txt is not included with MSP430 and C6000 compiler tools installation Fixed in : 7.3.19 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The file misra.txt, that contains the list of MISRA rules checked by the compiler, is not included with MSP430 and C6000 compiler tools installation. Workaround: None. =============================================================================== 4. Defects fixed in C6000 Code Generation Tools release 7.3.18 =============================================================================== The following 10 defects were fixed in C6000 Code Generation Tools release 7.3.18, released September 2014. ------------------------------------------------------------------------------- FIXED SDSCM00049997 ------------------------------------------------------------------------------- Summary : Loop with volatile loop control expression removed Fixed in : 7.3.18 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 C6000 Compiler versions: 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.17, 7.4.0B1 - 7.4.8, 7.5.0B1, 7.6.0B1 - 7.6.0 Workaround: Declare the loop counter variable as volatile ------------------------------------------------------------------------------- FIXED SDSCM00050051 ------------------------------------------------------------------------------- Summary : Table driven exception handling code does not check for malloc returning NULL Fixed in : 7.3.18 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 C6000 Compiler versions: 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.17, 7.4.0B1 - 7.4.11, 7.5.0B1, 7.6.0B1 - 7.6.0, 8.0.0B1 - 8.0.0 Workaround: Allocate more space to .sysmem ------------------------------------------------------------------------------- FIXED SDSCM00050202 ------------------------------------------------------------------------------- Summary : MISRA-C rule 19.11 false positive Fixed in : 7.3.18 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 SDSCM00050243 ------------------------------------------------------------------------------- Summary : Scary but harmless warning: FAILURE in mark_use_of_function_local_static() Fixed in : 7.3.18 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 C6000 Compiler versions: 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.17, 7.4.0B1 - 7.4.8, 7.5.0B1, 7.6.0B1 - 7.6.0, 8.0.0B1 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 SDSCM00050505 ------------------------------------------------------------------------------- Summary : TDEH emergency buffer should be allocated on stack Fixed in : 7.3.18 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 C6000 Compiler versions: 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.17, 7.4.0B1 - 7.4.11, 7.6.0B1 - 7.6.0, 8.0.0B1 - 8.0.0 Workaround: Allocate more space to .sysmem ------------------------------------------------------------------------------- FIXED SDSCM00050520 ------------------------------------------------------------------------------- Summary : strip crashes on files with more than 64k sections Fixed in : 7.3.18 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 C6000 Compiler versions: 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.17, 7.4.0B1 - 7.4.8, 7.6.0B1 - 7.6.0, 8.0.0B2 - 8.0.0B1 Workaround: Don't strip the file ------------------------------------------------------------------------------- FIXED SDSCM00050554 ------------------------------------------------------------------------------- Summary : cmp6x (compressor) fails with error message "Backtracked too many times" Fixed in : 7.3.18 Severity : S2 - Major Affected Component : Compressor (cmp) Release Notes: This update fixes an issue where the cmp6x executable was abnormally terminating with an error message "Backtracked too many times". Workaround: Use the --no_compress option. Code size will likely be worse. ------------------------------------------------------------------------------- FIXED SDSCM00050597 ------------------------------------------------------------------------------- Summary : Backward reference to array-in-struct may miss an alias Fixed in : 7.3.18 Severity : S2 - Major Affected Component : Optimizer Release Notes: Given a struct containing two adjacent fields that are arrays of the same type -- ie, "struct { short a[100]; short b[100]; }" -- a loop with accesses like "p->b[i] = p->b[i-1]" may compile incorrectly. Defect occurs in C6000 Compiler versions: 7.3.0B1 - 7.3.17, 7.4.0B1 - 7.4.10, 7.6.0B1 - 7.6.0, 8.0.0B1 - 8.0.0B4 Workaround: Insert a field between the two arrays that has a different element type, or move the troublesome array to the beginning of the struct, or compile at -o1 or -o0. The key details are adjacent array fields of the same element type and an array index with a negative offset. ------------------------------------------------------------------------------- FIXED SDSCM00050603 ------------------------------------------------------------------------------- Summary : Variable write not happening in inlined CPP function Fixed in : 7.3.18 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00050941 Release Notes: In circumstances that are not well understood, structure fields may not be written correctly in the presence of complicated conditional code. Defect occurs in C6000 Compiler versions: 7.3.15 - 7.3.17, 7.4.7 - 7.4.10 Workaround: Compile at -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00050997 ------------------------------------------------------------------------------- Summary : lnk6x does not pad code sections properly when user specifies non-zero fill value Fixed in : 7.3.18 Severity : S2 - Major Affected Component : ELF Linker Release Notes: When a non-zero fill value such as 0xefefefef, which itself is a legal encoding of a fetch packet header, is used then the linker may corrupt the encoding of the last execute packet in a section affected by the specified fill value when the linker uses the provided fill value to pad the end of a code section. Workaround: Problem can be worked around by using a more innocuous fill value. A 0x00000000 fill value is preferred since it encodes as a single cycle NOP in an output section containing executable code. =============================================================================== 5. Defects fixed in C6000 Code Generation Tools release 7.3.17 =============================================================================== The following 4 defects were fixed in C6000 Code Generation Tools release 7.3.17, released May 2014. ------------------------------------------------------------------------------- FIXED SDSCM00041127 ------------------------------------------------------------------------------- Summary : Missing snprintf() export when using stdio.h in C++ files Fixed in : 7.3.17 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: The MSP430's stdio.h file does not export std::snprintf() when stdio.h is used in a C++ file like it does for other C standard functions. Workaround: Call std::snprintf() instead of snprintf() when including header file stdio.h, or modify stdio.h to add "using std::snprintf()" within the final #if __cplusplus block. ------------------------------------------------------------------------------- FIXED SDSCM00049421 ------------------------------------------------------------------------------- Summary : Auto-generated stress test terminate abnormally in optimizer Fixed in : 7.3.17 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 C6000 Compiler versions: 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.16, 7.4.0B1 - 7.4.7, 7.6.0B1 - 7.6.0 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 SDSCM00049832 ------------------------------------------------------------------------------- Summary : Using optimization causes incorrect result Fixed in : 7.3.17 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The attached test case builds and runs correctly when built without optimization. When built with --opt_level=2 or higher, incorrect results are printed out. The cause of this bug is a wrong constant assignment coalesce in a loop body. The coalesce of these two assignment neglect the data dependency between them. Sometimes it could cause wrong result. Defect occurs in C6000 Compiler versions: 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.16, 7.4.7, 7.6.0B1 - 7.6.0 Workaround: There is no work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00050023 ------------------------------------------------------------------------------- Summary : SIGSEGV when using pragma on a template function Fixed in : 7.3.17 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 C6000 Compiler versions: 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.16, 7.4.0B1 - 7.4.7, 7.5.0B1, 7.6.0B1 - 7.6.0 Workaround: Do not apply any pragma to a template function. Move the function outside the template class. =============================================================================== 6. Defects fixed in C6000 Code Generation Tools release 7.3.16 =============================================================================== The following 9 defects were fixed in C6000 Code Generation Tools release 7.3.16, released April 2014. ------------------------------------------------------------------------------- FIXED SDSCM00045417 ------------------------------------------------------------------------------- Summary : bool and _Bool are not defined correctly in strict ANSI C mode Fixed in : 7.3.16 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 C6000 Compiler versions: 6.1.0 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.15, 7.4.0B1 - 7.4.6, 7.5.0B1, 7.6.0B1 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 SDSCM00048498 ------------------------------------------------------------------------------- Summary : MISRA-C rule 12.8 incorrectly reported for an expression like ((uint32_t)2U << 8U); Fixed in : 7.3.16 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 C6000 Compiler versions: 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.15, 7.4.0B1 - 7.4.6, 7.6.0B1 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00049229 ------------------------------------------------------------------------------- Summary : Symbols are missing in .debug_pubnames part of the Dwarf information Fixed in : 7.3.16 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. Defect occurs in C6000 Compiler versions: 7.3.14 - 7.3.15, 7.4.0 - 7.4.6, 7.6.0B1 Workaround: There is no work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00049271 ------------------------------------------------------------------------------- Summary : INTERNAL ERROR results when building code that uses features from C++ testing framework Fixed in : 7.3.16 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 SDSCM00049383 ------------------------------------------------------------------------------- Summary : dinkumware test t257 failed during release validation Fixed in : 7.3.16 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: On the C6000 7.3.x branch only, the assembler would incorrectly mark XXXXXXX object files as allowing the style of templates which clobber A15 because the compiler failed to emit a definition of build attribute Tramps_Use_SOC. A15 is a SOE ("callee-saved") register, so the value must be preserved by the callee. However, if a call site were turned into a trampoline call, the value in A15 would be clobbered. This is possible on non-Tesla C6000 targets because, but much less likely because SOC trampolines clobber B31, which is a SOC "caller-saved" register. Defect occurs in C6000 Compiler versions: 7.3.0B1 - 7.3.15 Workaround: Disable trampolines with linker option --trampolines=off. Note that Tesla object files generated with compiler version 7.3.0B1 through 7.3.15 must be recompiled with 7.3.16 or higher, or the problem will persist even after upgrading the linker to 7.3.16 or higher. ------------------------------------------------------------------------------- FIXED SDSCM00049407 ------------------------------------------------------------------------------- Summary : FAILURE in optimizer on local static variables with --opt_level=4 Fixed in : 7.3.16 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00049409 Release Notes: In rare cases, the optimizer may emit a spurious diagnostic message which says "FAILURE in mark_use_of_function_local_static." This message includes some symbol names, the first of which will be partially garbled. This message does not affect the generated code, so it may be ignored. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.15, 7.4.0B1 - 7.4.6, 7.5.0B1 Workaround: Ignore the message "FAILURE in mark_use_of_function_local_static." ------------------------------------------------------------------------------- FIXED SDSCM00049509 ------------------------------------------------------------------------------- Summary : SET_DATA_SECTION does not work if issued from within a _Pragma operator Fixed in : 7.3.16 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The test case attached has these lines ... #define PRAGMA(x) _Pragma(#x) PRAGMA(SET_DATA_SECTION("dsname")) This code compiles fine with several other TI compilers. However, for the C6000 compiler, this results in ... "file.c", line 5: error: this pragma cannot be used in a _Pragma operator (a #pragma directive must be used) "file.c", line 5: error: expected a "(" "file.c", line 5: error: expected a ")" Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00049539 ------------------------------------------------------------------------------- Summary : Vector code with variables of same name (as thru inlining) may produce wrong answers Fixed in : 7.3.16 Severity : S2 - Major Affected Component : Optimizer Release Notes: A loop that can be vectorised, when it contains expressions with different variables of same name (as thru inlining the same callee at more than one site) may produce wrong answers. The test case here uses vectors of type complex and uses inlined functions for some calls within the loop. Defect occurs in C6000 Compiler versions: 6.1.0B2 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.15, 7.4.0B1 - 7.4.7, 7.6.0B1 - 7.6.0B2 Workaround: Compile at -o1 or -o0, or inhibit inlining of the functions that matter. It may also work to add "#pragma UNROLL(1)" to relevant loops to inhibit vectorisation. ------------------------------------------------------------------------------- FIXED SDSCM00049603 ------------------------------------------------------------------------------- Summary : C Initialization records are created for NOLOAD sections Fixed in : 7.3.16 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 C6000 Compiler versions: 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.15, 7.4.0B1 - 7.4.7, 7.6.0B1 Workaround: Specify the type as NOINIT in addition to NOLOAD =============================================================================== 7. Defects fixed in C6000 Code Generation Tools release 7.3.15 =============================================================================== The following 10 defects were fixed in C6000 Code Generation Tools release 7.3.15, released January 2014. ------------------------------------------------------------------------------- FIXED SDSCM00046180 ------------------------------------------------------------------------------- Summary : MISRA check 14.1 should not treat while(0) as potential infinte loop Fixed in : 7.3.15 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 SDSCM00046242 ------------------------------------------------------------------------------- Summary : --gen_pic without --abi=eabi generates illegal builtin operator Fixed in : 7.3.15 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: --gen_pic is only supported for --abi=eabi Workaround: Add --abi=eabi ------------------------------------------------------------------------------- FIXED SDSCM00047666 ------------------------------------------------------------------------------- Summary : Definition of SIZE_MAX is wrong Fixed in : 7.3.15 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 C6000 Compiler versions: 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.14, 7.4.0B1 - 7.4.6 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00048289 ------------------------------------------------------------------------------- Summary : Errors of the linker due to the difference in version of CGT Fixed in : 7.3.15 Severity : S2 - Major Affected Component : Linker Duplicate Defects : SDSCM00048621 Release Notes: The fix for SDSCM00044393 was intended to allow the following linker command file syntax: SECTIONS { OUTSECT_NAME MEMORY_RANGE_NAME } The Assembly Language Tools User Guide erroneously stated that this syntax was accepted. However, allowing the above syntax introduces ambiguity in the linker command file grammar, which caused previously accepted command files to produce errors, resulting in this bug (SDSCM00048289). This change removes the fix applied for SDSCM00044393. The above syntax will no longer be accepted. The linker will now issue a warning if an output section is specified but no placement information is found for it. The documentation will be updated to specify that load allocation may be specified with the syntax "load = allocation" or "> allocation". The above syntax will result in a warning that no placement was specified for OUTSECT_NAME and a default placement will be applied. Valid linker command files that were rejected due to the ambiguity will now be accepted. Workaround: The problem can be avoided by using memory range names that are different from section names. For example, this linker command file may cause the error because "RAM" is both a memory range name and a section name: MEMORY { RAM : } SECTIONS { RAM : > RAM } But this one would not cause the error: MEMORY { RAM_MEM : } SECTIONS { RAM : > RAM_MEM } Also okay: MEMORY { RAM : } SECTIONS { RAM_SECT : > RAM } ------------------------------------------------------------------------------- FIXED SDSCM00048440 ------------------------------------------------------------------------------- Summary : SIGSEGV when using MISRA checks on code with an anonymous struct Fixed in : 7.3.15 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 C6000 Compiler versions: 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.14, 7.4.0B1 - 7.4.6 Workaround: Do not use anonymous structs or unions when using MISRA ------------------------------------------------------------------------------- FIXED SDSCM00048712 ------------------------------------------------------------------------------- Summary : ARM assembler seg faults on certain input Fixed in : 7.3.15 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 : 7.3.15 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 SDSCM00048895 ------------------------------------------------------------------------------- Summary : Sometimes a loop iterates one time too many, when built with --opt_level=2 Fixed in : 7.3.15 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: This bug happens after a loop is software pipelined. It runs one more iteration because the check of the terminaton condition is wrong. Usually you can see that the decrement instruction and the comparison instruction are placed in the same cycle which is wrong. Defect occurs in C6000 Compiler versions: 7.3.0B1 - 7.3.14, 7.4.4 - 7.4.6, 7.5.0B1 Workaround: There is no work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00049035 ------------------------------------------------------------------------------- Summary : Value of "weak" global incorrectly propagated into function Fixed in : 7.3.15 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 C6000 Compiler versions: 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.14, 7.4.0B1 - 7.4.6 Workaround: Do not use an explicit initializer with weak symbol definitions, or use optimization level -o2 or lower. ------------------------------------------------------------------------------- FIXED SDSCM00049206 ------------------------------------------------------------------------------- Summary : #pragma CLINK does not work on initialized data Fixed in : 7.3.15 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The CLINK pragma now works as expected for initialized data. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.14, 7.4.0B1 - 7.4.6, 7.5.0B2 - 7.5.0B1 Workaround: Only uninitialized data can be marked CLINK. To make data CLINK, make it unitialized and do the initialization at startup. =============================================================================== 8. Defects fixed in C6000 Code Generation Tools release 7.3.14 =============================================================================== The following 7 defects were fixed in C6000 Code Generation Tools release 7.3.14, released October 2013. ------------------------------------------------------------------------------- FIXED SDSCM00047502 ------------------------------------------------------------------------------- Summary : linker fails with internal error if .cinit and .data are in the same GROUP Fixed in : 7.3.14 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 C6000 Compiler versions: 7.3.0B1 - 7.3.13, 7.4.0B1 - 7.4.5 Workaround: Move .cinit so that it is not in any GROUP ------------------------------------------------------------------------------- FIXED SDSCM00047542 ------------------------------------------------------------------------------- Summary : Assembler silently converts relocatable symbol to absolute value when instruction requires absolute value Fixed in : 7.3.14 Severity : S2 - Major Affected Component : Assembler Release Notes: The MMOVI32 instruction requires a floating point immediate in hex format as the second operand. When it is given a relocatable symbol instead, it converts it to an absolute value. The assembler should issue an error instead. When the final value of the symbol is known, it will not be updated since the instruction required a known immediate and the assembler treated the symbol as one. Workaround: Do not use a symbol for the immediate operand in MMOVI32. ------------------------------------------------------------------------------- FIXED SDSCM00047564 ------------------------------------------------------------------------------- Summary : Valid regpair MV and NEG instructions rejected for C66x Fixed in : 7.3.14 Severity : S3 - Minor Affected Component : Assembler Release Notes: The assembler does not allow 40-bit MV or NEG with cross-path use, even though the hardware can actually support it. Defect occurs in C6000 Compiler versions: 7.3.0B1 - 7.3.13, 7.4.0B1 - 7.4.5 Workaround: Use ADD 0,xslong,slong and SUB 0,xslong,slong instead ------------------------------------------------------------------------------- FIXED SDSCM00047615 ------------------------------------------------------------------------------- Summary : std::vector::pop_back failure with -mv6600 -O3 Fixed in : 7.3.14 Severity : S2 - Major Affected Component : Optimizer Release Notes: The right combination of a class with an STL vector element and a pop_back() call on that vector may compile incorrectly. Defect occurs in C6000 Compiler versions: 7.2.9 - 7.2.12, 7.3.5 - 7.3.13, 7.4.0B1 - 7.4.5 Workaround: Compile at -o0 or -o1. ------------------------------------------------------------------------------- FIXED SDSCM00047792 ------------------------------------------------------------------------------- Summary : Multiple .cdecls instances sharing header files cause assembler error "struct/union/enum tag can't be global" Fixed in : 7.3.14 Severity : S2 - Major Affected Component : Assembler Release Notes: When multiple .cdecls clauses in an assembly file include headers that share the same definitions, duplicate code will be generated causing an assembler error. The assembler error will state that structure or enumeration tags can't be "global". The Assembly Language Tools User's Guide states that multiple .cdelcs instances do not share the same C/C++ environment. Therefore, headers that share the same definitions must be included in the same .cdecls instance. Workaround: Include headers sharing definitions in either a single .cdecls clause: .cdecls C, LIST %{ #include "header1.h" #include "header2.h" %} OR inside a single header file: .cdecls C, LIST, "header.h" ------------------------------------------------------------------------------- FIXED SDSCM00047883 ------------------------------------------------------------------------------- Summary : bsearch failure when using -pr relaxed ANSI mode or --gcc mode from C++ Fixed in : 7.3.14 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 SDSCM00048073 ------------------------------------------------------------------------------- Summary : Linker fails with INTERNAL ERROR: lnk6x experienced an unhandled exception Fixed in : 7.3.14 Severity : S2 - Major Affected Component : Linker Release Notes: Linker sometimes fails with "INTERNAL ERROR: lnk6x experienced an unhandled exception" Workaround: Build all object files and the rts library with the same version of the compiler tools. =============================================================================== 9. Defects fixed in C6000 Code Generation Tools release 7.3.13 =============================================================================== The following 7 defects were fixed in C6000 Code Generation Tools release 7.3.13, released August 2013. ------------------------------------------------------------------------------- FIXED SDSCM00013456 ------------------------------------------------------------------------------- Summary : fgets in _IONBF mode does not respect size limit Fixed in : 7.3.13 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 C6000 Compiler versions: 4.37 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.12, 7.4.0B1 - 7.4.4 Workaround: Do not use _IONBF mode ------------------------------------------------------------------------------- FIXED SDSCM00037672 ------------------------------------------------------------------------------- Summary : GCC cast-to-union wrongly rejected in initialization constant Fixed in : 7.3.13 Severity : S2 - Major Affected Component : Parser Release Notes: union u { int i; int *p; }; struct s { int n; union u a; } v = {1, (union u) 2 }; Initialization will be flagged with "cast to type "union u" is not allowed". In GCC compatibility mode the cast should be allowed. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00042344 ------------------------------------------------------------------------------- Summary : Compiler generates internal error: illegal initialization or segmentation fault Fixed in : 7.3.13 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Compiler sometimes generates internal error: illegal initialization or segmentation fault when using gcc extension nested designed initializers. Workaround: The seg fault can be worked around if the nested designated initializer is removed: static struct cfg config[] = { // the first definition makes the segmentation fault. Comment it and everything is fine. { .module_id = MODULE_1, .param_length = sizeof(struct module_1_params), .param = (struct module_1_params []){{1}} /* remove this designated initializer */ }, { .module_id = MODULE_2, .param_length = 5, .param = (int[]){0,1,2,3,4} }, { .module_id = MODULE_3, .param_length = 2, .param = (int[]){0,1} } }; ------------------------------------------------------------------------------- FIXED SDSCM00043860 ------------------------------------------------------------------------------- Summary : Printf format %#06x prints zeros in the wrong place Fixed in : 7.3.13 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 C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.12, 7.4.0B1 - 7.4.4 Workaround: Avoid using both # and 0 flags when using the x conversion specifier. ------------------------------------------------------------------------------- FIXED SDSCM00045147 ------------------------------------------------------------------------------- Summary : Automatic RTS library build fails for C6713 (coff, LE). Fixed in : 7.3.13 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00045236 Release Notes: An automatic RTS build for a C6700 library no longer results in a scheduling error. Defect occurs in C6000 Compiler versions: 7.3.4 - 7.3.12, 7.4.0B1 - 7.4.5 Workaround: The error in this case is not a true error and the library can actually still be used without issue. ------------------------------------------------------------------------------- FIXED SDSCM00047263 ------------------------------------------------------------------------------- Summary : different binaries after compilation Fixed in : 7.3.13 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 C6000 Compiler versions: 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.12, 7.4.0B1 - 7.4.3 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 SDSCM00047563 ------------------------------------------------------------------------------- Summary : Disassembler applies X cross path to wrong operand of MPYSPDP Fixed in : 7.3.13 Severity : S2 - Major Affected Component : Disassembler (dis) Release Notes: According to the TMS320C67x/C67x+ DSP CPU and Instruction Set Reference Guide (SPRU733A), only the second operand (the double-precision input) may be fetched from the cross path. However, the disassembler was instead showing the first operand (the single-precision input) as being fetched from the cross path. Defect occurs in C6000 Compiler versions: 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.12, 7.4.0B1 - 7.4.4 Workaround: The encoding is correct; it is only the disassembler that gets it wrong. Don't rely on the disassembler's output for the MPYSPDP instruction if the cross path is used. =============================================================================== 10. Defects fixed in C6000 Code Generation Tools release 7.3.12 =============================================================================== The following 15 defects were fixed in C6000 Code Generation Tools release 7.3.12, released May 2013. ------------------------------------------------------------------------------- FIXED SDSCM00044738 ------------------------------------------------------------------------------- Summary : EABI partial linking omits referenced library functions which refer to unresolved symbols Fixed in : 7.3.12 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 C6000 Compiler versions: 7.2.0B1 - 7.2.12, 7.3.6 - 7.3.11, 7.4.0B1 - 7.4.3 Workaround: There is no work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00045173 ------------------------------------------------------------------------------- Summary : Missing qsort and bsearch implementations for comparison functions with C++ linkage Fixed in : 7.3.12 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 C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.11, 7.4.0B1 - 7.4.2 Workaround: Declare the comparison function extern "C" ------------------------------------------------------------------------------- FIXED SDSCM00045373 ------------------------------------------------------------------------------- Summary : EXIDX section for alias function leads to INTERNAL ERROR unhandled exception Fixed in : 7.3.12 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 C6000 Compiler versions: 7.3.0B1 - 7.3.11, 7.4.0B1 - 7.4.3 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 SDSCM00045572 ------------------------------------------------------------------------------- Summary : --gen_profile_info discards exception-handling data Fixed in : 7.3.12 Severity : S2 - Major Affected Component : Code Generator Release Notes: If the --gen_profile_info option is used with --abi=eabi and --exceptions, the resulting executable file may be incorrect. The exception handling portion of the code may be missing from the instrumented executable. Specifically, catch blocks and code following a catch block will not be included in the executable file. Defect occurs in C6000 Compiler versions: 7.0.0 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.11, 7.4.0B1 - 7.4.3 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00046084 ------------------------------------------------------------------------------- Summary : Hex utility incorrectly picks empty section over a non-empty section with duplicate name Fixed in : 7.3.12 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 C6000 Compiler versions: 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.11, 7.4.0B1 - 7.4.3 Workaround: Use a different output section for the duplicate .text section ------------------------------------------------------------------------------- FIXED SDSCM00046142 ------------------------------------------------------------------------------- Summary : SUBDP with cross path decoded incorrectly in disassembler Fixed in : 7.3.12 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: This is a disassembly bug only happen to SUBDP instruction with its 1st operand is a crosspath operand. Defect occurs in C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.8 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.11, 7.4.0B1 - 7.4.3 Workaround: There is no work around available for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00046156 ------------------------------------------------------------------------------- Summary : Incorrect calculations in loop Fixed in : 7.3.12 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: A loop containing an auto-initialised array definition that is short enough to be a valid vector -- 64 bits for most C6x or 128 bits for c66, or 128 bits for ARM Neon -- may unroll and vectorise in a way that mishandles the array and causes incorrect behavior. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.11, 7.4.0B1 - 7.4.3 Workaround: Move the auto-initialised array out of the loop, or add dummy array elements to make it larger than a candidate vector, or add "#pragma UNROLL(1)" to inhibit vectorisation, or compile at -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00046175 ------------------------------------------------------------------------------- Summary : INTERNAL ERROR: cg6x experienced a segmentation fault while processing function Fixed in : 7.3.12 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 C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.11, 7.4.1 - 7.4.3 Workaround: There is no work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00046177 ------------------------------------------------------------------------------- Summary : ELF section header table not guaranteed to be aligned Fixed in : 7.3.12 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 C6000 Compiler versions: 7.0.0 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.11, 7.4.0B1 - 7.4.3 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00046231 ------------------------------------------------------------------------------- Summary : DATA_ALIGN should not be able to reduce alignment below default array alignment Fixed in : 7.3.12 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 : 7.3.12 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 C6000 Compiler versions: 7.2.0B1 - 7.2.11, 7.3.8 - 7.3.11, 7.4.0B1 - 7.4.2 Workaround: Use -b can always to wrok around this long type merging problem. But it is not needed with this fix. ------------------------------------------------------------------------------- FIXED SDSCM00046812 ------------------------------------------------------------------------------- Summary : Instructions are placed in the wrong order Fixed in : 7.3.12 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 C6000 Compiler versions: 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.11, 7.4.0B1 - 7.4.3 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 : 7.3.12 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 C6000 Compiler versions: 4.37 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.11, 7.4.0B1 - 7.4.3 Workaround: None known. ------------------------------------------------------------------------------- FIXED SDSCM00046849 ------------------------------------------------------------------------------- Summary : stdin stdout stderr macros need to be usable without using namespace std for _ftable Fixed in : 7.3.12 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 C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.11, 7.4.0B1 - 7.4.3 Workaround: Include stdio.h instead of cstdio ------------------------------------------------------------------------------- FIXED SDSCM00046910 ------------------------------------------------------------------------------- Summary : Using an invalid option with valid hex command file causes SIGSEGV Fixed in : 7.3.12 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 C6000 Compiler versions: 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.11, 7.4.0B1 - 7.4.3 Workaround: Fix or eliminate the invalid option. =============================================================================== 11. Defects fixed in C6000 Code Generation Tools release 7.3.11 =============================================================================== The following 11 defects were fixed in C6000 Code Generation Tools release 7.3.11, released March 2013. ------------------------------------------------------------------------------- FIXED SDSCM00042332 ------------------------------------------------------------------------------- Summary : Don't generate typeinfo when not used Fixed in : 7.3.11 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 : 7.3.11 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 C6000 Compiler versions: 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.10, 7.4.0B1 - 7.4.2 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 : 7.3.11 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The expression ... var_int16 = 4 * 256; contains no implicit conversions. However, MISRA rule 10.1 about no implicit conversions is still emitted for that expression. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00042600 ------------------------------------------------------------------------------- Summary : Ill advised enum scalar usage gets MISRA diagnostic, but similar usage of enum array does not Fixed in : 7.3.11 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 SDSCM00043229 ------------------------------------------------------------------------------- Summary : Instruction reordering alters logic Fixed in : 7.3.11 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 SDSCM00045550 ------------------------------------------------------------------------------- Summary : Truncated pointer created by cast from integer constant Fixed in : 7.3.11 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 C6000 Compiler versions: 6.1.0B1 - 6.1.22, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.10, 7.4.0B1 - 7.4.2 Workaround: Don't use the optimizer at all for source files which contain pointer math of the form shown in the release notes. ------------------------------------------------------------------------------- FIXED SDSCM00045894 ------------------------------------------------------------------------------- Summary : Use of option -pdse195 causes an incorrect error to be generated Fixed in : 7.3.11 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: An issue where diagnostics resulting from the evaluation of unused preprocessor tokens has been fixed. This issue only arose when error #195 was escalated to warning or error. For example, when compiling the following code with the option -pdse195: #define MY_CONCAT_DEFINE 1 #define MY_CONCAT_MACRO(a, b) a##b #if (MY_CONCAT_MACRO(MY_,CONCAT_DEFINE) == 0) #error ("Define is zero") #endif int x; The compiler generates the following incorrect error message: "test.c", line 5: error: zero used for undefined preprocessing identifier #if (MY_CONCAT_MACRO(MY_,CONCAT_DEFINE) == 0) ^ "test.c", line 5: error: zero used for undefined preprocessing identifier #if (MY_CONCAT_MACRO(MY_,CONCAT_DEFINE) == 0) ^ 2 errors detected in the compilation of "test.c". >> Compilation failure Defect occurs in C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.22, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.10, 7.4.0B1 - 7.4.2 Workaround: Compiling without -pdse195 will remove the errors caused by this issue. Alternatively, consider -pdsw195 if the diagnostic should be seen but not bar the program from compiling. ------------------------------------------------------------------------------- FIXED SDSCM00046015 ------------------------------------------------------------------------------- Summary : Recurrence with unsigned subscript can lead to wrong answer Fixed in : 7.3.11 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 C6000 Compiler versions: 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.10, 7.4.0B1 - 7.4.2 Workaround: Use only signed variables for subscripts and loop index variables, or compile at -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00046190 ------------------------------------------------------------------------------- Summary : Compiler may mishandle C symbols that resemble C++ mangled names (esp long sequences of underscores) Fixed in : 7.3.11 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 C6000 Compiler versions: 6.1.0B1 - 6.1.22, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.10, 7.4.0B1 - 7.4.2 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 : 7.3.11 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 C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.10, 7.4.0B1 - 7.4.2 Workaround: Assign the value of the floating-point expression into a local integer variable and assign the local variable to the bit-field. ------------------------------------------------------------------------------- FIXED SDSCM00046414 ------------------------------------------------------------------------------- Summary : Compiler may incorrectly read too soon when single element and aggregate are used together Fixed in : 7.3.11 Severity : S2 - Major Affected Component : Optimizer Release Notes: The conditions which expose the defect are the following: 1) -o2 or -o3 2) A local array where reads from adjacent addresses occur after a write to the array. This could be array elements or struct fields. Or, a local union containing a struct which is first initialized one field at a time. Then, the whole struct is written to. Finally, the struct is read one field at a time. Note: this case can arise implicitly if a local struct is defined in an inner scope. Below is a local union example: union sample_union { POINT_XY point; int an_array[2]; }; int CheckArea( POINT_XY* corner ) { union sample_union abc; int x, y; // write to struct in union one field at a time abc.point.x = 5; abc.point.y = 6; ... // write to whole struct in union abc.point = corner; ... // read from struct in union one field at a time x = abc.point.x; y = abc.point.y; } 3) The structure is defined as local variables in the function, not global. 4) The phenomenon is not occur if the structure is defined in the upper function, and the structure pointer is sent from upper function to the function as an argument. Summary: Cases where the compiler does both individual field accesses and combined aggregate accesses may lead to incorrect results. The symptom is that data is read before it has been written. In this particular example, two adjacent struct fields, in the same struct of a local array of structs, are combined into the same read and read before the individual fields have been written. Defect occurs in C6000 Compiler versions: 6.0.13 - 6.0.31, 6.1.0B1 - 6.1.23, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.10, 7.4.0B1 - 7.4.2 Workaround: Compile at -o1, or use a pointer or global instead of a local array, or add a dummy field to the struct to prevent an aggregate read. =============================================================================== 12. Defects fixed in C6000 Code Generation Tools release 7.3.10 =============================================================================== The following 9 defects were fixed in C6000 Code Generation Tools release 7.3.10, released February 2013. ------------------------------------------------------------------------------- FIXED SDSCM00042581 ------------------------------------------------------------------------------- Summary : Linker fails with internal error: lnk6x failed to allocate memory Fixed in : 7.3.10 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 C6000 Compiler versions: 7.0.0B2 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.11, 7.3.0 - 7.3.9, 7.4.0B1 - 7.4.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 SDSCM00044393 ------------------------------------------------------------------------------- Summary : Linker silently ignores an output section placement spec with missing ">" in the SECTIONS directive Fixed in : 7.3.10 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 SDSCM00044503 ------------------------------------------------------------------------------- Summary : Linker does not handle double-slash (//) in path names properly Fixed in : 7.3.10 Severity : S2 - Major Affected Component : Linker Release Notes: Linker does not handle double-slash (//) in path names properly. A command line the following: cl6x -z -o=main.out a/b//c/d/file.obj fails with the following message: "/tmp/14635KpAAoj", line 4: fatal error: unrecognized file: "a/b" >> Compilation failure This only happens when an options command file is used to pass the options to the linker; the compiler will now ensure that these filepaths are quoted to allow the linker to parse them unambiguously. Defect occurs in C6000 Compiler versions: 7.3.6 - 7.3.9 Workaround: The workaround is to avoid passing the arguments using an option command file to the linker (--no_cmd_file), but this can be problematic for builds with many options. ------------------------------------------------------------------------------- FIXED SDSCM00045036 ------------------------------------------------------------------------------- Summary : Internal error when no suitable delete operator is present in destructor Fixed in : 7.3.10 Severity : S2 - Major Affected Component : Parser Release Notes: There are 3 delete operators as defined by the standard (6 if you count array deletes) void operator delete (void* ptr) throw (); void operator delete (void* ptr, const std::nothrow_t& nothrow_constant) throw(); void operator delete (void* ptr, void* voidptr2) throw(); The default operator delete is the first one there, and is required to be visible to virtual destructor definitions. The one provided by the code is the non-default third overloaded version of operator delete. Another rule regards member functions, and states that if a member function shadows a function declared in another scope, and the function declared in another scope is overloaded, those overloaded functions are invisible to the class. With both of these code-related issues together, the compiler enters into an erroneous state. The member function operator delete causes the default operator delete to become invisible to the class' scope. Finally, while defining the virtual destructor, a default delete function cannot be found (which must be called according to the IA64 rules for virtual constructors), resulting in a segfault. Workaround: The best workaround here is for the user to provide an appropriate operator delete in the class. ------------------------------------------------------------------------------- FIXED SDSCM00045381 ------------------------------------------------------------------------------- Summary : Read of array element, before memcpy() overwrites it, may be out of order Fixed in : 7.3.10 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 C6000 Compiler versions: 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.22, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.11, 7.3.0B1 - 7.3.9, 7.4.0B1 - 7.4.2 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 SDSCM00045562 ------------------------------------------------------------------------------- Summary : Multiplication by power-of-2 wider than int may use wrong type Fixed in : 7.3.10 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 C6000 Compiler versions: 6.1.0B1 - 6.1.22, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.10, 7.3.4 - 7.3.9, 7.4.0B1 - 7.4.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 : 7.3.10 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 C6000 Compiler versions: 6.1.0B1 - 6.1.22, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.10, 7.3.0B1 - 7.3.9, 7.4.0B1 - 7.4.2 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00046075 ------------------------------------------------------------------------------- Summary : disassembler display wrong hex prefix for constant in compact instruction Fixed in : 7.3.10 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: This bug happens in disassembler. Some numbers from ucst5 field of the instruction are printed with an extra "0x" prefix which make the number a wrong value if it is interpreated in hex format. For example: 00000148 b00d LDW.D2T2 *B4[5],B0 0000014a 1e2f ADDK.S2 0x24,B4 0000014c 00004000 NOP 3 decode the compact instruction binary code 0x1e2f, it is 0001,1110,0010,1111 based on F-25 in C6000 CPU manual, Sx5 format, the constant should be from 15~13 as ucst 2-0, 12~11 should be ucst4-3 so we have ucst value =11000, which is 24 not 0x24 as displayed. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.22, 7.2.0B1 - 7.2.11, 7.3.8 - 7.3.9, 7.4.0B1 - 7.4.2 Workaround: No work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00049284 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 10.1 Fixed in : 7.3.10 Severity : S3 - Minor Affected Component : Parser Release Notes: No Information Available; please see defect details. Workaround: None. =============================================================================== 13. Defects fixed in C6000 Code Generation Tools release 7.3.9 =============================================================================== The following 6 defects were fixed in C6000 Code Generation Tools release 7.3.9, released November 2012. ------------------------------------------------------------------------------- FIXED SDSCM00042974 ------------------------------------------------------------------------------- Summary : Resource conflict between instruction in SPLOOP and instruction in its epilog causing hardware exception Fixed in : 7.3.9 Severity : S2 - Major Affected Component : Code Generator Duplicate Defects : SDSCM00044918 Release Notes: This bug only happens at the epilog area of a SPLOOP. It could cause resource conflict which leads to a hardware exception. There is no obvious link between the user's C source code to this bug so it is hard to avoid this problem at the source code level. The fix of this bug could cause performance degradation. Usually this happens for an early exit SPLOOP where the loop's trip count is less than the number of iterations running in parallel. The performance could be severly worse if this SPLOOP is the inner loop and the outer loop executes many times. If this happens, there is no work around to fix this problem. This fix could also cause code size increase. But it is minimal. Usually it is one NOP per SPLOOP. Defect occurs in C6000 Compiler versions: 7.2.4 - 7.2.10, 7.3.0B1 - 7.3.8, 7.4.0B1 - 7.4.1 Workaround: This is no work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00044183 ------------------------------------------------------------------------------- Summary : Compiler aborts with internal error "Corrupted IR detected during check_mve/spilling" with -o2 Fixed in : 7.3.9 Severity : S2 - Major Affected Component : Code Generator Duplicate Defects : SDSCM00044316 Release Notes: Compiler aborts with internal error "Corrupted IR detected during check_mve/spilling" when compiling with -o2 optimization. This problem can only happen in software pipelining with pair register uses. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.10, 7.3.5 - 7.3.8, 7.4.0B1 - 7.4.2 Workaround: There is no work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00044285 ------------------------------------------------------------------------------- Summary : scanf %[^ mistakenly writes EOF to output Fixed in : 7.3.9 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 SDSCM00045105 ------------------------------------------------------------------------------- Summary : Empty struct as field of parent struct may cause optimizer abort Fixed in : 7.3.9 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 C6000 Compiler versions: 6.0.29 - 6.0.31, 6.1.20 - 6.1.22, 7.2.5 - 7.2.9, 7.3.0 - 7.3.8, 7.4.0B1 - 7.4.1 Workaround: Add a dummy field to the empty struct. ------------------------------------------------------------------------------- FIXED SDSCM00045197 ------------------------------------------------------------------------------- Summary : strip6x segmentation fault on ELF executable Fixed in : 7.3.9 Severity : S2 - Major Affected Component : Strip Utility Release Notes: No Information Available; please see defect details. Workaround: The crash occurs when trying to delete an unused ELF segment, which only appear in executable files. Try stripping the object files before linking. As noted previously the problem arises from strip6x trying to delete a segment and exposing a bookkeeping issue. This brings up the question on why it's trying to delete the segment. The section associated with this segment is .plt_resmgr_handles, which looks like it contains the uninitialized variable 'gGlobalFreeQHnd'. The test case file's segment table entries don't look quite right so this may also be an issue in how this file was linked. It looks like .plt_resmgr_handles is allocated with .text into the same segment (uninitialized and initialize data/code combined). One thing to try would be to ensure .plt_resmgr_handles is placed into its own section/segment. ------------------------------------------------------------------------------- FIXED SDSCM00045232 ------------------------------------------------------------------------------- Summary : Incorrect linker symbol value after multiple partial links Fixed in : 7.3.9 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 C6000 Compiler versions: 7.3.0B1 - 7.3.8, 7.4.0B1 - 7.4.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. =============================================================================== 14. Defects fixed in C6000 Code Generation Tools release 7.3.8 =============================================================================== The following 8 defects were fixed in C6000 Code Generation Tools release 7.3.8, released August 2012. ------------------------------------------------------------------------------- FIXED SDSCM00043174 ------------------------------------------------------------------------------- Summary : Linker fails to honor specific placement for function from RTS library Fixed in : 7.3.8 Severity : S2 - Major Affected Component : COFF Linker Release Notes: Linker now honors section placement specification. Workaround: Do not include libc.a option. ------------------------------------------------------------------------------- FIXED SDSCM00044450 ------------------------------------------------------------------------------- Summary : Parser allows virtual base classes that are too large Fixed in : 7.3.8 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 C6000 Compiler versions: 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.9, 7.3.0B1 - 7.3.7, 7.4.0B1 - 7.4.0 Workaround: Do not allow any object to inherit from virtual base classes with total size larger than approximately 0x7ffff0 ------------------------------------------------------------------------------- FIXED SDSCM00044561 ------------------------------------------------------------------------------- Summary : ASG error in cg6x Fixed in : 7.3.8 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Code causes the following codegen crash: INTERNAL ERROR: no match for ASG Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00044618 ------------------------------------------------------------------------------- Summary : lnk6x runs out of memory when using --preferred_order in large application Fixed in : 7.3.8 Severity : S2 - Major Affected Component : ELF Linker Release Notes: The linker can experience significant system memory usage and some leakage while using the --preferred_order option during the link step of a large application build. The leakage can be significant if the application is compiled with debug (-g option). In some cases where available system memory is limited (2GB PC system, for example), the excessive system memory usage can cause the linker to run out of memory. Workaround: Avoid use of --preferred_order option during the link step. ------------------------------------------------------------------------------- FIXED SDSCM00044735 ------------------------------------------------------------------------------- Summary : EXIDX_CANTUNWIND yields invalid memory read Fixed in : 7.3.8 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 C6000 Compiler versions: 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.9, 7.3.0B1 - 7.3.7, 7.4.0B1 - 7.4.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 SDSCM00044775 ------------------------------------------------------------------------------- Summary : Missed dependence between x[i+4] and x[i] when i unsigned Fixed in : 7.3.8 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 C6000 Compiler versions: 7.2.0B1 - 7.2.9, 7.3.0B1 - 7.3.7, 7.4.0B1 - 7.4.0 Workaround: Change "i" from unsigned to signed, from UINT32 to INT32. ------------------------------------------------------------------------------- FIXED SDSCM00044799 ------------------------------------------------------------------------------- Summary : pprof6x aborts during compile which uses profile data to analyze the call graph Fixed in : 7.3.8 Severity : S2 - Major Affected Component : Path Profiler (pprof) Release Notes: pprof6x may abort the compilation when using profile data (--use_profile_info option) and analyzing callgraph information (--analyze=callgraph option). The issue will at least come up in cases where the application contains at least one C++ global object that requires initialization and is using entry/exit hook functions. Defect occurs in: C6000 v7.2.0 - 7.2.9, 7.3.0 - 7.3.7, 7.4.0 Workaround: Can possibly avoid the problem by removing the use of --entry_hook option. A more drastic workaround would be to avoid using the --use_profile_info option. ------------------------------------------------------------------------------- FIXED SDSCM00045988 ------------------------------------------------------------------------------- Summary : Internal error: no match for ASG involving _mem2 Fixed in : 7.3.8 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The compiler crashed with a "Internal error: no match for ASG involving _mem2" message. The fix is that the compiler now properly recognizes unaligned half- word memory accesses using the mem intrinsic. Workaround: None. =============================================================================== 15. Defects fixed in C6000 Code Generation Tools release 7.3.7 =============================================================================== The following 5 defects were fixed in C6000 Code Generation Tools release 7.3.7, released July 2012. ------------------------------------------------------------------------------- FIXED SDSCM00044048 ------------------------------------------------------------------------------- Summary : Enabling vectorization produces incorrect code Fixed in : 7.3.7 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 C6000 Compiler versions: 7.2.0B1 - 7.2.9, 7.3.0B1 - 7.3.6, 7.4.0B1 - 7.4.0 Workaround: Disable vectorization or optimization. ------------------------------------------------------------------------------- FIXED SDSCM00044377 ------------------------------------------------------------------------------- Summary : Disassembler fails to decode LDNDW when scaling mode is used Fixed in : 7.3.7 Severity : S3 - Minor Affected Component : Disassembler (dis) Release Notes: The disassembler would mistakenly fail to disassemble LDNDW and STNDW when scaling mode was used. The instruction would instead be shown as a .word. Defect occurs in C6000 Compiler versions: 7.2.9, 7.3.4 - 7.3.6, 7.4.0B2 - 7.4.0 Workaround: This bug does not impact the correctness of the code. Be aware that a .word in a text section might be LDNDW or STNDW. ------------------------------------------------------------------------------- FIXED SDSCM00044445 ------------------------------------------------------------------------------- Summary : codegen access wrong address which causes hardware exception Fixed in : 7.3.7 Severity : S2 - Major Affected Component : Code Generator Release Notes: This bug can manifest for loops that qualify for software pipelining and loop prolog collapsing during which the prolog of the loop is collapsed (by instruction speculation and predication) into the loop kernel in order to reduce overall loop codesize. In this situation, during loop prolog collapsing, the compiler illegally speculated a load instruction without checking all of the load's data dependencies. Defect occurs in C6000 Compiler versions: 7.3.5 - 7.3.6 Workaround: This defect can be worked around by disabling loop prolog collapsing (--disable:pc) with small risk for loop codesize increase. ------------------------------------------------------------------------------- FIXED SDSCM00044463 ------------------------------------------------------------------------------- Summary : gcc packed attribute causes both codegen and optimizer error Fixed in : 7.3.7 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: If a struct type is given the "packed" attribute via "__attribute__((packed))" but anonymous structs and unions within it are not given that attribute, the compiler may crash. Without optimisation or with -o0 or -o1, the problem will happen only without "--abi=eabi"; with -o2 and above, the problem will happen with or without "--abi=eabi". Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.9, 7.3.0B1 - 7.3.6, 7.4.0B1 - 7.4.0 Workaround: Add "__attribute__((packed))" to all nested structs and unions. ------------------------------------------------------------------------------- FIXED SDSCM00044536 ------------------------------------------------------------------------------- Summary : Fix to CQ44227 causes incompatible object code resulting in link failure Fixed in : 7.3.7 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. =============================================================================== 16. Defects fixed in C6000 Code Generation Tools release 7.3.6 =============================================================================== The following 21 defects were fixed in C6000 Code Generation Tools release 7.3.6, released June 2012. ------------------------------------------------------------------------------- FIXED SDSCM00037422 ------------------------------------------------------------------------------- Summary : Incorrect layout in .cdecls struct Fixed in : 7.3.6 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 : 7.3.6 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 C6000 Compiler versions: 6.1.19 - 6.1.21, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.9, 7.3.0B1 - 7.3.5, 7.4.0B1 - 7.4.0B2 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 SDSCM00042194 ------------------------------------------------------------------------------- Summary : Partial link drops weak function symbol Fixed in : 7.3.6 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 : 7.3.6 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 SDSCM00042408 ------------------------------------------------------------------------------- Summary : Linker creates overlapping sections when section allocation is done using ">>" operator Fixed in : 7.3.6 Severity : S2 - Major Affected Component : Linker Duplicate Defects : SDSCM00043075 Release Notes: Linker may create overlapping sections when section allocation is done using ">>" operator Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00042789 ------------------------------------------------------------------------------- Summary : Register allocation fails at ii=4, but succeeded in 7.3.0 compiler Fixed in : 7.3.6 Severity : S1 - Critical / PS Classification : Performance Affected Component : Code Generator Release Notes: In some rare cases register allocation might fail on a software pipelined loop, when it succeeded in a previous compiler release. This would typically occur on loops where most or all of the registers are allocated. Workaround: No known workarond ------------------------------------------------------------------------------- FIXED SDSCM00043207 ------------------------------------------------------------------------------- Summary : Compiler reads from stack frame after releasing it Fixed in : 7.3.6 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The compiler may incorrectly move an access of a stack location past the function return point where the stack location has been deallocated. Workaround: No direct workaround known if the issue appears, though it's likely that different optimization flags will hide the issue. ------------------------------------------------------------------------------- FIXED SDSCM00043700 ------------------------------------------------------------------------------- Summary : Stack and aggregates should be 8-byte aligned for C66 Fixed in : 7.3.6 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: For various reasons, the stack should be aligned to 8-bytes, not 16 for C66x. First, the compiler does not fully implement 16-byte stack alignment. Also, in the case of interrupts, the stack would not stay 16-byte aligned in certain situations. Also, 16-byte alignment is unneeded since there is not a 16-byte aligned load or store instruction on C66. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00043705 ------------------------------------------------------------------------------- Summary : Novel Test failure N1204B03.cpp, N1204B26.cpp Fixed in : 7.3.6 Severity : S2 - Major Affected Component : Optimizer Release Notes: If a function is called twice, and in one call an argument is a constant (integer literal, for example) and in another call the same argument is a static local variable, the compiler may erroneously arrange to pass the constant on both calls, ignoring the actual value of the variable. Defect occurs in C6000 Compiler versions: 6.1.16 - 6.1.20, 7.0.3 - 7.0.5, 7.1.0B2 - 7.1.0B3, 7.2.0B1 - 7.2.9, 7.3.0B1 - 7.3.5, 7.4.0B1 Workaround: Don't use static-local variables in arguments to function calls. ------------------------------------------------------------------------------- FIXED SDSCM00043713 ------------------------------------------------------------------------------- Summary : Linker fails with internal error Fixed in : 7.3.6 Severity : S2 - Major Affected Component : Linker Duplicate Defects : SDSCM00043752 Release Notes: Linker sometimes fails with internal error: lnk.exe experienced an unhandled exception The linker no longer makes the assumption that the decompression routine's section can be automatically removed when the linker determines the decompression routine is not needed. Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00043770 ------------------------------------------------------------------------------- Summary : Intentional alias between two congruent IF tests may simplify incorrectly Fixed in : 7.3.6 Severity : S2 - Major Affected Component : Optimizer Release Notes: Code like p = &x; if (x) ... *p = ... if (x) ... may compile incorrectly, as the compiler will miss the effect that the write to *p has on the value of x in the second IF. Defect occurs in C6000 Compiler versions: 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.21, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.9, 7.3.0B1 - 7.3.5, 7.4.0B1 - 7.4.0B2 Workaround: Compile at -o0, or avoid creating aliases and then using both paths to access a single variable. ------------------------------------------------------------------------------- FIXED SDSCM00043789 ------------------------------------------------------------------------------- Summary : cg6x run out of memory Fixed in : 7.3.6 Severity : S2 - Major Affected Component : Code Generator Release Notes: This bug is caused by final scheduling of insrtuctions after interblock scheduling. The scheduler tries to work out a scheduling by inserting infinite number of empty blocks. No obvious C source codes could trigger this bug. Defect occurs in C6000 Compiler versions: 6.1.20 - 6.1.21, 7.2.0B1 - 7.2.9, 7.3.0B1 - 7.3.5, 7.4.0B1 Workaround: No work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00043807 ------------------------------------------------------------------------------- Summary : Register initialization lost during instruction predication Fixed in : 7.3.6 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 C6000 Compiler versions: 7.3.0B1 - 7.3.5, 7.4.0B1 Workaround: No practical workaround ------------------------------------------------------------------------------- FIXED SDSCM00043868 ------------------------------------------------------------------------------- Summary : Linker cannot find include file specified with relative path Fixed in : 7.3.6 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 SDSCM00043874 ------------------------------------------------------------------------------- Summary : START() and SIZE() in linker script, changed behavior Fixed in : 7.3.6 Severity : S2 - Major Affected Component : Linker Release Notes: No Information Available; please see defect details. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00043948 ------------------------------------------------------------------------------- Summary : IF predicate with negative integer factor simplifies incorrectly Fixed in : 7.3.6 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 C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.21, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.9, 7.3.0B1 - 7.3.5, 7.4.0B1 - 7.4.0B2 Workaround: None. Avoid the situation. ------------------------------------------------------------------------------- FIXED SDSCM00043966 ------------------------------------------------------------------------------- Summary : Second instance of three-operand associative op may miscompile Fixed in : 7.3.6 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 C6000 Compiler versions: 6.1.0B1 - 6.1.21, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.9, 7.3.0B1 - 7.3.5, 7.4.0B1 - 7.4.0B2 Workaround: Compile at -o1 or -o0, or avoid the situation. ------------------------------------------------------------------------------- FIXED SDSCM00044012 ------------------------------------------------------------------------------- Summary : Optimizer crash Fixed in : 7.3.6 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 C6000 Compiler versions: 6.1.0B2 - 6.1.21, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.9, 7.3.0B1 - 7.3.5, 7.4.0B1 - 7.4.0B2 Workaround: Try "#pragma UNROLL(1)" ahead of the outermost for-loop, or compile with -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00044066 ------------------------------------------------------------------------------- Summary : opt470 experienced a segmentation fault Fixed in : 7.3.6 Severity : S2 - Major Affected Component : Optimizer Release Notes: Corrected false assumption made while performing an optimization. Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00044227 ------------------------------------------------------------------------------- Summary : Compiler may not ensure uniqueness of static variables in C++ templates Fixed in : 7.3.6 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 SDSCM00044302 ------------------------------------------------------------------------------- Summary : opt6x emits an invalid symbol uid in the I-file as part of a load speculation advice record Fixed in : 7.3.6 Severity : S2 - Major Affected Component : Optimizer Release Notes: Load-speculation advice, generated internally by the optimiser, may refer to symbols using an invalid index, which may cause a crash during compilation. Defect occurs in C6000 Compiler versions: 7.3.0B1 - 7.3.5, 7.4.0B1 - 7.4.0B2 Workaround: None. =============================================================================== 17. Defects fixed in C6000 Code Generation Tools release 7.3.5 =============================================================================== The following 7 defects were fixed in C6000 Code Generation Tools release 7.3.5, released April 2012. ------------------------------------------------------------------------------- FIXED SDSCM00042914 ------------------------------------------------------------------------------- Summary : Linker segfault using partial link output file of C++ source with ELF and exceptions enabled Fixed in : 7.3.5 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 SDSCM00042923 ------------------------------------------------------------------------------- Summary : Should never report overflow for R_C6000_PREL31 Fixed in : 7.3.5 Severity : S3 - Minor Affected Component : Linker Release Notes: No Information Available; please see defect details. Workaround: Allocate .c6xabi.exidx and .c6xabi.extab and all text sections within 2^31 bytes of each other, or just ignore the warnings. ------------------------------------------------------------------------------- FIXED SDSCM00043316 ------------------------------------------------------------------------------- Summary : Arithmetic fails in GROUP directive Fixed in : 7.3.5 Severity : S2 - Major Affected Component : Linker Release Notes: Arithmetic expressions are now permitted as address specifiers in the SECTIONS section of a linker command file, as in the MEMORY section. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.6 - 7.2.8, 7.3.0B1 - 7.3.4, 7.4.0B1 Workaround: The constant address may be specified directly rather than through an expression. ------------------------------------------------------------------------------- FIXED SDSCM00043376 ------------------------------------------------------------------------------- Summary : data array copy got wrong results after calling initTimer() Fixed in : 7.3.5 Severity : S2 - Major Affected Component : Code Generator Release Notes: This bug only happens when SPLOOP is interrupted and there are registers in the SPLOOP that have two live ranges, or there are multiple assigned registers in the SPLOOP. When interrupt is returned back to the SPLOOP, the register content can not be correctly restored thus leads to error. Defect occurs in C6000 Compiler versions: 7.2.6 - 7.2.8, 7.3.0B1 - 7.3.4, 7.4.0B1 Workaround: There is no work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00043377 ------------------------------------------------------------------------------- Summary : In the generated assembly file comments always say no -ms option even when -ms option is used for the build Fixed in : 7.3.5 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: In the compiler generated assembly file, the comments always say no -ms option was used even when -ms option is used for the build. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00043642 ------------------------------------------------------------------------------- Summary : Compiler incorrectly simplifies "(x >> k1) < k2" when k2 is constant smaller than int Fixed in : 7.3.5 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< /* interrupt routine starts here */ unsigned int save_itsr = ITSR; /* loop code here */ ITSR = save_itsr; ------------------------------------------------------------------------------- FIXED SDSCM00043152 ------------------------------------------------------------------------------- Summary : Optimizer issues information advice using optimizer's temporary symbols instead of using symbols from user code Fixed in : 7.3.4 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 C6000 Compiler versions: 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.30, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.8, 7.3.0B1 - 7.3.3, 7.4.0B1 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 SDSCM00043223 ------------------------------------------------------------------------------- Summary : Compiler may miss alias given struct-of-array-of-structs Fixed in : 7.3.4 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 C6000 Compiler versions: 7.2.0B1 - 7.2.8, 7.3.0B1 - 7.3.3, 7.4.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 SDSCM00043233 ------------------------------------------------------------------------------- Summary : Use of -mb option to force 6200 array alignment can result in link failure with rts6200.lib Fixed in : 7.3.4 Severity : S2 - Major Affected Component : Shell Release Notes: The -mb option is now deprecated, but to enable proper linking against rts6200 library, we have to force the option to also disable generation of push/pop and custom call convention (call_stub) symbols. Defect occurs in C6000 Compiler versions: 7.2.0 - 7.2.8, 7.3.0B1 - 7.3.3, 7.4.0B2 - 7.4.0B1 Workaround: Manually include --disable_push_pop and --disable_custom_call_conv when using -mb. These options will prevent the generation of C64+ specific symbols that would prevent you from linking against a 6200 RTS library. ------------------------------------------------------------------------------- FIXED SDSCM00043326 ------------------------------------------------------------------------------- Summary : Extremely long (templated) type names may overflow buffer, causing crash Fixed in : 7.3.4 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 C6000 Compiler versions: 4.10 - 4.22, 4.37 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.30, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.8, 7.3.0B1 - 7.3.3, 7.4.0B1 Workaround: None. =============================================================================== 19. Defects fixed in C6000 Code Generation Tools release 7.3.3 =============================================================================== The following 21 defects were fixed in C6000 Code Generation Tools release 7.3.3, released February 2012. ------------------------------------------------------------------------------- FIXED SDSCM00032350 ------------------------------------------------------------------------------- Summary : Enable default --symdebug:dwarf_subsections=on for COFF Fixed in : 7.3.3 Severity : S2 - Major Affected Component : COFF Linker Release Notes: No Information Available; please see defect details. Workaround: Use the --symdebug:dwarf_subsections=on when compiling. ------------------------------------------------------------------------------- FIXED SDSCM00037170 ------------------------------------------------------------------------------- Summary : Embed does not handle cross-filesystem rename correctly Fixed in : 7.3.3 Severity : S2 - Major Affected Component : Embed Utility Release Notes: The embed utility needs to copy the file across file systems before renaming it. Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00040101 ------------------------------------------------------------------------------- Summary : Compiler generates temporary files when compiling C++ files with templates and -pm that are not automatically deleted Fixed in : 7.3.3 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: When compiling C++ files which use templates with -pm option the compiler generates temporary files that are not automatically deleted. Defect occurs in C6000 Compiler versions: 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.29, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.7, 7.3.0B1 - 7.3.2 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00041971 ------------------------------------------------------------------------------- Summary : Spurious remark generated from __STDC_VERSION__ ref in stddef.h in C++ mode Fixed in : 7.3.3 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 SDSCM00042053 ------------------------------------------------------------------------------- Summary : Near a software pipelined loop that comes from an include file, the .dwpsn directives have the wrong file name Fixed in : 7.3.3 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Fixed a bug where debug information near an inlined loop could contain the incorrect file name. Defect occurs in C6000 Compiler versions: 6.0.1B1 - 6.0.29, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.7, 7.3.1 - 7.3.2 Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00042202 ------------------------------------------------------------------------------- Summary : 7.2.6 compiler does not inline constructors in some instances in EABI Fixed in : 7.3.3 Severity : S3 - Minor Affected Component : Parser Release Notes: In some instances under EABI mode, the C6x compiler may not inline constructors and destructors as efficiently when compiled for COFF. Workaround: There is no workaround at this time. ------------------------------------------------------------------------------- FIXED SDSCM00042256 ------------------------------------------------------------------------------- Summary : Parser generates illegal EH table on modified cpp_peren_eh testcase Fixed in : 7.3.3 Severity : S2 - Major Affected Component : Parser Duplicate Defects : SDSCM00042253 Release Notes: This bug only happens for C++ file for which the exception handing is enabled under EABI. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.7, 7.3.0B1 - 7.3.2 Workaround: No work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00042368 ------------------------------------------------------------------------------- Summary : Parser generates segmentation fault Fixed in : 7.3.3 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Parser generates segmentation fault when compiling the following source file: static const int a[1]; int main(void) { (void)a[0]; return 0; } static const int a[1] = { 0 }; Workaround: Move the second static const int declaration above the reference. ------------------------------------------------------------------------------- FIXED SDSCM00042395 ------------------------------------------------------------------------------- Summary : linker sorts input section specifications incorrectly Fixed in : 7.3.3 Severity : S2 - Major Affected Component : ELF Linker Release Notes: Linker sorts input sections specifications incorrectly. Even though a fairly restrictive input section specification is used to dictate the placement of the .text section from a particular file in a library, the section is mapped into a different output section by a less restrictive input section specification that is actually specified after the more restrictive input section specification. Workaround: Can repeat a restrictive input section specification that appears to be ignored by the linker, however, the workaround may cause the linker to emit a warning about "no matching section" ------------------------------------------------------------------------------- FIXED SDSCM00042454 ------------------------------------------------------------------------------- Summary : _extu((x>>a), b, c) incorrectly simplified when b>c Fixed in : 7.3.3 Severity : S2 - Major Affected Component : Optimizer Release Notes: Use of a right shift operator in a _extu intrinsic generates incorrect code with optimization. Defect occurs in C6000 Compiler versions: 7.3.1 - 7.3.2 Workaround: Compile at -o0, or use _ext instead of _extu if that works in the particular situation, or use _extu(x, 0, a) instead of x>>a as the argument to _extu. ------------------------------------------------------------------------------- FIXED SDSCM00042506 ------------------------------------------------------------------------------- Summary : Quest/colon (?:) expression on floats, cast to int, may cause compiler hang Fixed in : 7.3.3 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The compiler may hang in the optimiser stage when given a quest/colon (?:) expression of floating-point type which is cast to int, when compiling at -o2 or higher. The problem is specific to ?:, not to other expressions, and requires the mixture of floating and integral types. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.7, 7.3.0B1 - 7.3.2 Workaround: The original report noted that using roundf() instead of their rounding macro would avoid the problem. Compiling at -o0 or -o1 will also avoid it. Avoiding creating a floating-point-typed ?: that is cast to int should also avoid the problem, but we have no specific guidelines. ------------------------------------------------------------------------------- FIXED SDSCM00042561 ------------------------------------------------------------------------------- Summary : CGTools 6.0.29 generates wrong code with o3 Fixed in : 7.3.3 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: This bug is caused by incorrect optimization on IF branches. There is no obvious or simple trigger condition we can list at the C source code level. When this bug happens, instructions on a branch could be wrongly executed thus leads to wrong results. Defect occurs in C6000 Compiler versions: 6.0.29, 7.2.0B1 - 7.2.8, 7.3.0B1 - 7.3.2 Workaround: There is no work around for this bug other than disabling optimizations. ------------------------------------------------------------------------------- FIXED SDSCM00042563 ------------------------------------------------------------------------------- Summary : Optimiser crashes on certain loop cases Fixed in : 7.3.3 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Certain loop structures, which we are not able to describe concisely, can cause the optimiser to crash when compiling at -o2 or higher. The one known example involves C++ code and a lot of inlining; adjusting the inlining avoids the problem. Workaround: Compile at -o1. In this particular example, removing an "inline" keyword from a function avoids the problem, because it changes the complexity of the function causing the crash. ------------------------------------------------------------------------------- FIXED SDSCM00042570 ------------------------------------------------------------------------------- Summary : Missing MISRA 19.15 Fixed in : 7.3.3 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00045280 Release Notes: MISRA 19.15 not selectable in CCS v5.1. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00042619 ------------------------------------------------------------------------------- Summary : Optimizer crashes given unrolled nested loops and lots of aliasing Fixed in : 7.3.3 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The C6x compiler will attempt to improve performance, when it cannot tell when certain memory accesses may alias, by testing at runtime for overlap among objects and choosing either an optimistic or conservative version of a loop, depending on the measured safety. The runtime test is composed of a collection of pairwise comparisons of object starting and ending addresses. There is a limit to how big the test can be -- otherwise it might take longer to test than to run the loop -- but that limit is checked *after* the predicate is built. In this example, the predicate was huge, large enough that its construction caused a stack overflow on Windows. The patch for this bug tests for such exceptional cases early enough to avoid the overflow. Why was the predicate huge? The loop was something like for (j = 0; j < x->n; j++) { for (i = 0; i < 34; i++) x->y->a[j][i] = x->aa[j][i]; for (i = 0; i < 34; i++) x->y->b[j][i] = x->bb[j][i]; } } where n is a char and a[], aa[], b[], and bb[] are all arrays of char. The inner-loop trip counts are constant and small enough to allow the inner loops to unroll completely. Each of the resulting 68 statements in the now-single loop contains multiple memory references, and the outer-loop trip count is also a memory reference. Pointers-to-char are allowed to point to objects of any type, which means that nearly any two memory references within the loop may be aliased and will be included in the runtime test. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.7, 7.3.0B1 - 7.3.2, 7.4.0B1 Workaround: Add "#pragma UNROLL(1)" (or another small unroll factor, like 2 or 3) in front of the inner loops, to prevent complete unrolling. Using a local scalar temp variable for the outer-loop trip count may also help (and tends to help performance in many cases anyway). Adding "restrict" declarations to some of the pointers may also help. Finally, if the areas copied are contiguous, using memcpy() instead of an explicit loop is likely to be faster, less troublesome, and easier to maintain. ------------------------------------------------------------------------------- FIXED SDSCM00042632 ------------------------------------------------------------------------------- Summary : Functions declared static get global visibility when compiled with optimization in EABI mode Fixed in : 7.3.3 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00048452 Release Notes: Fixed a bug wherein two functions, one static and one global where one function contains code and the other simply calls the first, were aliased together, essentially removing the static state of one function and causing it to be visible globally. Workaround: Avoid mixing static and nonstatic functions that only call the other. Only do so when both functions are static or neither function is. ------------------------------------------------------------------------------- FIXED SDSCM00042669 ------------------------------------------------------------------------------- Summary : Compiler aborts with message about "Corrupted IR detected during check_mve/spilling" Fixed in : 7.3.3 Severity : S2 - Major Affected Component : Code Generator Release Notes: In extremely rare circumstances, the compiler may abort and issue an error message such as the following: "Renamed pair with base above window. Corrupted IR detected during check_mve/spilling" Workaround: Turning off software pipelining will prevent the problem, although that could severely affect performance. ------------------------------------------------------------------------------- FIXED SDSCM00042704 ------------------------------------------------------------------------------- Summary : Conversion from double to __int40_t in EABI gives garbage in upper bits Fixed in : 7.3.3 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: For EABI, all of the __int40_t <-> floating-point conversions mistakenly operated only on the lower 32 bits of the integer value. When converting from signed or unsigned __int40_t to a floating-point type, garbage bits would be used for the most significant 8 bits of the integer value, potentially giving floating-point values that were very wrong. When converting from a floating-point type to signed or unsigned __int40_t, the result would have garbage bits in the most significant 8 bits, potentially giving __int40_t value that were very wrong. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.7, 7.3.0B1 - 7.3.2 Workaround: Convert to "long long" instead. ------------------------------------------------------------------------------- FIXED SDSCM00042717 ------------------------------------------------------------------------------- Summary : Compiler stops with error: "Corrupted IR detected" message Fixed in : 7.3.3 Severity : S2 - Major Affected Component : Code Generator Release Notes: In extremely rare cases when compiling linear assembly source code which contains inner loops, the compiler may stop and emit an error that says, "Corrupted IR detected during check_mve/spilling". Workaround: Lowering the optimization level to -o1 will avoid the issue. ------------------------------------------------------------------------------- FIXED SDSCM00042768 ------------------------------------------------------------------------------- Summary : norm_l(0) and norm_s(0) give the wrong value Fixed in : 7.3.3 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: norm_l and norm_s are supposed to return the number of left shifts needed to left-justify the signed input value. The definitions of these macros gsm.h would return non-zero values. This often doesn't matter, because a common idiom is L_shl(x, norm_l(x)), which for x==0 will have the value 0 no matter what norm_l(0) returns. However, if the value of norm_l(0) is directly needed, the value was wrong. Defect occurs in C6000 Compiler versions: 4.10 - 4.22, 4.37 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.30, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.8, 7.3.0B1 - 7.3.2 Workaround: Edit gsm.h and change the definitions of norm_l and norm_s ------------------------------------------------------------------------------- FIXED SDSCM00042867 ------------------------------------------------------------------------------- Summary : ftell returns wrong error code in EABI Fixed in : 7.3.3 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: EABI actually calls for an errno value of 152, but it was being assigned a value of 5 (the expected COFF ABI behavior). Now, errno will be assigned the correct value based on whether EABI or COFF is used. C6000 - Bug occurs in 7.3.2; fixed in 7.3.3 Bug occurs in 7.2.8; fixed in 7.2.9 Workaround: Go into source for ftell() and fgetpos() and change "errno = 5" to "errno = EFPOS" =============================================================================== 20. Defects fixed in C6000 Code Generation Tools release 7.3.2 =============================================================================== The following 26 defects were fixed in C6000 Code Generation Tools release 7.3.2, released November 2011. ------------------------------------------------------------------------------- FIXED SDSCM00038452 ------------------------------------------------------------------------------- Summary : C6000 Compiler generates resource conflict in 64+ assembly output Fixed in : 7.3.2 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: This bug is caused by missing DEF-DEF edge when the relevant register is not liveout of the block. Very rare this bug can be triggered. If this bug happens, we will see hardware exception that two writes to the same register at the same cycle. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.20, 7.2.0B1 - 7.2.7, 7.3.0B1 - 7.3.1 Workaround: Use --disable:isched switch ------------------------------------------------------------------------------- FIXED SDSCM00041042 ------------------------------------------------------------------------------- Summary : Absolute difference of unsigned-char, accumulated in signed integer, may produce incorrect answer Fixed in : 7.3.2 Severity : S2 - Major Affected Component : Optimizer Release Notes: A loop that performs an absolute difference of two unsigned-chars (ie, abs(x[i]- y[i]), where x[] and y[] are arrays of unsigned-char), and accumulates the total in a signed integer, may produce the wrong answer when compiled at -o2 or above. Workaround: Change the accumulator to an unsigned integer variable, or compile at -o1 or -o0, or add "#pragma UNROLL(1)" to the loop containing the operation. ------------------------------------------------------------------------------- FIXED SDSCM00041468 ------------------------------------------------------------------------------- Summary : When linker is invoked with --abi=ebai and the linker opens a COFF library, it should issue a diagnostic Fixed in : 7.3.2 Severity : S3 - Minor Affected Component : Linker Release Notes: None Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00041471 ------------------------------------------------------------------------------- Summary : dis6x crash with very long identifier names Fixed in : 7.3.2 Severity : S2 - Major Affected Component : Disassembler (dis) Release Notes: dis6x crash Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00041565 ------------------------------------------------------------------------------- Summary : Optimizer error, 2-dimensional array, 2 multiplications Fixed in : 7.3.2 Severity : S2 - Major Affected Component : Optimizer Release Notes: The optimiser may abort if it encounters a sum of a pair of multiplies which can be represented as a _dotp2 call, if the operands are adjacent array references. Multiplies of scalar variables are not affected, and _dotp2 possibilities that require unrolling a loop are not affected. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.6, 7.3.0B1 - 7.3.1 Workaround: One workaround is to replace tmpa = (int)a[i][0] * a[i][0]; tmpb = (int)a[i][1] * a[i][1]; with int tmp0 = a[i][0]; int tmp1 = a[i][1]; tmpa = (int)tmp0 * tmp0; tmpb = (int)tmp1 * tmp1; ------------------------------------------------------------------------------- FIXED SDSCM00041569 ------------------------------------------------------------------------------- Summary : Optimizer removes weak object pointer check Fixed in : 7.3.2 Severity : S3 - Minor Affected Component : Optimizer Release Notes: The optimiser believed that UAND-of-NAME was always non-NULL. That's not true for weak symbols. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.6, 7.3.0B1 - 7.3.1 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00041595 ------------------------------------------------------------------------------- Summary : Compiler produces incorrect result at -o2 for C64x Fixed in : 7.3.2 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Optimizer sometimes produces incorrect results at -o2 Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00041776 ------------------------------------------------------------------------------- Summary : Optimizer substitutes packed bitfield reference without masking value at -o1 Fixed in : 7.3.2 Severity : S2 - Major Affected Component : Optimizer Release Notes: Under certain specific circumstances, the compiler may replace an assignment to a bitfield with a temporary variable whose value has not been properly truncated as the original assignment did. To cause the bug, several passes that do the right thing must be inhibited; one known way is to use -o1 and a packed struct. Workaround: Compile at -o0 or -o2, or avoid packed bitfields. ------------------------------------------------------------------------------- FIXED SDSCM00041828 ------------------------------------------------------------------------------- Summary : Internal error when compiling c++ code Fixed in : 7.3.2 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00028905 Release Notes: Use of an anonymous namespace in eabi mode causes a parser crash: namespace { class X : public Y { public: X () : Y("Test") { } }; } cl470.exe -mv7M3 -g -me --abi=eabi t.cpp INTERNAL ERROR: acpia470 experienced a segmentation fault while processing Defect occurs in C6000 Compiler versions: 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.6, 7.3.0B1 - 7.3.1 Workaround: Give a name to the namespace: namespace ABC { class X : public Y { public: X () : Y("Test") { } }; } ------------------------------------------------------------------------------- FIXED SDSCM00041883 ------------------------------------------------------------------------------- Summary : On C6600, interrupt in _push_rts could cause stack to be not aligned to 16-bytes as required Fixed in : 7.3.2 Severity : S2 - Major Affected Component : Runtime Intrinsics Release Notes: This bug only happens when interrupt routine is called during the normal function call's push/restore registers. The push and restore register operation will violate the stack 128 bit alignment convention on C66. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.6, 7.3.0 - 7.3.1 Workaround: No work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00041888 ------------------------------------------------------------------------------- Summary : Compiler incorrectly exposes static function as global, when building with optimization and EABI Fixed in : 7.3.2 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Fixed bug where a static function that only calls another function would be considered a global symbol. The .symalias assembly directive turns any symbol attached to it into a global symbol. When compiling in EABI mode, if a static function is aliased with another function, it will be exposed incorrectly as a global symbol. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.6, 7.3.0 - 7.3.1 Workaround: Avoid writing a static function that only calls another function. If this is unavoidable, treat the static function as if it were global within the rest of the code. ------------------------------------------------------------------------------- FIXED SDSCM00041925 ------------------------------------------------------------------------------- Summary : C++ name mangling for global string object causes linker conflict if project contains files with same filename Fixed in : 7.3.2 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: In a project where global std:string objects are defined with different names but in files in different directories but with the same filename, the linker generates a multiply defined error message for the objects. Workaround: Use unique file names. ------------------------------------------------------------------------------- FIXED SDSCM00041961 ------------------------------------------------------------------------------- Summary : C6x codegen generates incorrect DWARF info for signed long bitfield. Fixed in : 7.3.2 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: This bug only happens when there is a bitfield defined with a 40 bit integral type. It will cause wrong debug information. Nothing else. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.20, 7.2.0B1 - 7.2.6, 7.3.0 - 7.3.1 Workaround: There is no work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00042028 ------------------------------------------------------------------------------- Summary : Assembly listing file output doesn't agree with .map file output. Fixed in : 7.3.2 Severity : S2 - Major Affected Component : Absolute Lister Release Notes: When compressor is used with C6600 (the default), the absolute listing files will not reflect the compressed addresses, but will instead show the original uncompressed instruction addresses. Defect occurs in C6000 Compiler versions: 7.2.3 - 7.2.6, 7.3.0 - 7.3.1 Workaround: No known workaround. ------------------------------------------------------------------------------- FIXED SDSCM00042045 ------------------------------------------------------------------------------- Summary : Two-dimensional arrays of pointers may lead to optimiser abort Fixed in : 7.3.2 Severity : S1 - Critical / PS Affected Component : Optimizer Release Notes: Certain cases of two-dimensional arrays, possibly only those containing pointers, may cause an optimiser abort. The case observed involves a 2-by-N array of pointers, and a loop in which *array[0][i], *array[1][i], *(array[0][i]+1), and *(array[1][i]+1) were all written. Defect occurs in C6000 Compiler versions: 6.1.6 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.6, 7.3.0B1 - 7.3.1 Workaround: 1. Compile at -o1 or -o0, instead of -o2 or -o3. 2. Change the two-dimensional array into a larger one-dimensional array or simply a pointer-to-pointer-to-pointer. 3. Split the two-dimensional array[2][K] into two, array0[K] and array1[K], and use array0[i] instead of array[0][i], etc. This test case always used literal 0 or 1 for the first index, so the substitution is easy. This is the best-performing of the three options. ------------------------------------------------------------------------------- FIXED SDSCM00042061 ------------------------------------------------------------------------------- Summary : Library building fails when TEMP is moderately long (50+ characters) Fixed in : 7.3.2 Severity : S1 - Critical / PS Affected Component : Runtime Support Libraries (RTS) Release Notes: The ar470 command line is over 32k characters, which runs afoul of the insurmountable upper limit of the Win32 API CreateProcess. When this happens, the user will see a mysterious error which looks something like this: process_begin: CreateProcess(c:\progra~1\texasi~1\tms470~2.1\bin\ar470.exe, c:/progra~1/texasi~1/tms470~2.1/bin/ar470 -qa d:/docume~1/user.name/locals~1/temp/ti5b2e~1/rtsv7a8_a_le_eabi.lib e:/docume~1/user.name/locals~1/temp/ti5b2e~1/obj/decode.obj f:/docume~1/user.name/locals~1/temp/ti5b2e~1/obj/xatexit.obj, ...) failed. make (e=87): The parameter is incorrect. Defect occurs in C6000 Compiler versions: 7.3.0B3 - 7.3.1 Workaround: 1) Set TEMP to a shorter path before running CCS, or 2) Run mklib manually from the command line ------------------------------------------------------------------------------- FIXED SDSCM00042073 ------------------------------------------------------------------------------- Summary : Missing dependence causes invalid instruction schedule Fixed in : 7.3.2 Severity : S2 - Major Affected Component : Optimizer Release Notes: A part of alias analysis that attempt to disambiguate arrays from non-arrays can be faked out by a pointer to a struct that is incremented (a la *p++) within a loop. The incremented pointer is assumed to always point to an array, which therefore can't alias an access to a non-array. Defect occurs in C6000 Compiler versions: - 4.45, 7.3.2 - 7.3.1 Workaround: Don't increment a pointer-to-nonarray with ++ in a loop. ------------------------------------------------------------------------------- FIXED SDSCM00042088 ------------------------------------------------------------------------------- Summary : Use of unordered operator causes errors for that section in the XML map file Fixed in : 7.3.2 Severity : S2 - Major Affected Component : Linker Release Notes: None Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00042132 ------------------------------------------------------------------------------- Summary : Code moved before NULL pointer check in 'if' statement Fixed in : 7.3.2 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00046012 Release Notes: Given a sequence like pqd = ((pq)->dynamic); if ( (((pqd)==0) ? pq->queue[0] : pq->queue[pqd->head]) == qent ) the compiler may arrange to dereference pqd->head before it has tested that pqd is non-NULL, causing incorrect behavior if the processor traps on the bad access. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.7, 7.3.0B1 - 7.3.1 Workaround: Compile at -o1 or -o0, or try declaring one of the affected variables "volatile" to inhibit optimisation. ------------------------------------------------------------------------------- FIXED SDSCM00042146 ------------------------------------------------------------------------------- Summary : Quotes in PATH, TEMP, etc on Windows breaks mklib Fixed in : 7.3.2 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: If the PATH environment variable has quotes in it, mklib will crash with a mysterious error like "CreateProcess(NULL, cl470 atexit.c ...) failed. The system cannot find the file specified." It is not legal to have literal quotes in PATH, but as an enhancement, mklib will attempt to remove quotes from PATH and try again. Defect occurs in C6000 Compiler versions: 7.3.0B3 - 7.3.1 Workaround: Do not use literal quotes in PATH or TEMP ------------------------------------------------------------------------------- FIXED SDSCM00042149 ------------------------------------------------------------------------------- Summary : Signed bitfield in union with unsigned integer treated as unsigned Fixed in : 7.3.2 Severity : S1 - Critical / PS Affected Component : C/C++ Compiler (cl) Release Notes: Given a union containing a scalar integer field and a struct field consisting entirely of bitfields, such that the integer and the bitfield struct have the same number of bits, a signed bitfield may be treated (incorrectly) as unsigned if the scalar integer is unsigned. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.6, 7.3.0B1 - 7.3.1 Workaround: Use types of the same signedness in unions of integers and bitfield structs. Or compile at -o0. ------------------------------------------------------------------------------- FIXED SDSCM00042166 ------------------------------------------------------------------------------- Summary : adjacent bit field in a structure got overwritten by writing to another bit field Fixed in : 7.3.2 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: This bug happens when bit field bit width is between 32 and 40. The codegen will try to access it with a long data type which has 64 bit memory space. It might over write its neighbouring field. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.7, 7.3.1 Workaround: No work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00042199 ------------------------------------------------------------------------------- Summary : Compiler generates unexpected memset call in derived class constructor (affects performance) Fixed in : 7.3.2 Severity : S2 - Major Affected Component : Parser Release Notes: In some circumstances, the compiler is needlessly generating a call to memset for some C++ constructor calls when compiling with --abi=eabi (ELF mode). This can inhibit the inlining of simple constructors. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.6, 7.3.0B1 - 7.3.1 Workaround: There is no identified workaround. ------------------------------------------------------------------------------- FIXED SDSCM00042217 ------------------------------------------------------------------------------- Summary : Compiler may miss alias involving union within struct Fixed in : 7.3.2 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The compiler may miss an alias involving references to a union within a struct, as in a read from p->u.a followed by a write to p->u.b, where u is a union and a and b are its fields, and a and b are of incompatible types. Defect occurs in C6000 Compiler versions: 7.3.0B1 - 7.3.1 Workaround: Compile at -o1 or -o0, or refer to the union directly (u.a) rather than as part of a larger object (x.u.a or y->u.a), or avoid unions. ------------------------------------------------------------------------------- FIXED SDSCM00042309 ------------------------------------------------------------------------------- Summary : v7.3 compiler doesn't generate string literals in the .const:.string section and this breaks compatibility Fixed in : 7.3.2 Severity : S2 - Major Affected Component : Code Generator Release Notes: The .const:.string section will now be generated in non-PIC mode. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00042340 ------------------------------------------------------------------------------- Summary : Compiler mistakenly issues diagnostic about destructor for base class is not virtual Fixed in : 7.3.2 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The no virtual base class destructor diagnostic will no longer be emitted when the base class has a virtual destructor. Workaround: Do not use the -pdr option. =============================================================================== 21. Defects fixed in C6000 Code Generation Tools release 7.3.1 =============================================================================== The following 35 defects were fixed in C6000 Code Generation Tools release 7.3.1, released September 2011. ------------------------------------------------------------------------------- FIXED SDSCM00040151 ------------------------------------------------------------------------------- Summary : Getting compile time generated symbol re-definition error during linking C674x ELF target Fixed in : 7.3.1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The linker may generate "duplicate symbol" errors for symbols named like _TI_DW_.debug_info. when linking object files. Using ofd, it can be seen that these symbols are signatures for COMDAT groups. This is an error in COMDAT generation in the assembler and linker. Defect occurs in C6000 Compiler versions: 7.2.0 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: No workaround exists. ------------------------------------------------------------------------------- FIXED SDSCM00040319 ------------------------------------------------------------------------------- Summary : OFD crashes while printing debug info from relocatable file Fixed in : 7.3.1 Severity : S2 - Major Affected Component : OFD Utility Release Notes: None Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00040376 ------------------------------------------------------------------------------- Summary : Assignment to 2D-array, which has more than 20 items, resulted in INTERNAL ERROR. Fixed in : 7.3.1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00040778 Release Notes: A loop that only writes long constants to a long integer array causes an internal compiler error. For example: long int arr[3][24]; for (i = 0; i < 3; i++) { data[i][0] = 0l; data[i][1] = 1l; data[i][2] = 2l; } >cl6x -o2 -mv6400+ file.c >> INTERNAL ERROR: >>>Register allocation failed: main This may be a serious problem. Please contact customer support with a description of this problem and a sample of the source files that caused this INTERNAL ERROR message to appear. Cannot continue compilation - ABORTING! >> Compilation failure ------------------------------------ Fix is currently scheduled for 7.2.5 update planned 7/29/11 and 6.1.20 update planned for 8/5/11. Workaround: Compile at optimization level -o1. ------------------------------------------------------------------------------- FIXED SDSCM00040400 ------------------------------------------------------------------------------- Summary : Bitfield alias may be missed when struct is smaller than field type Fixed in : 7.3.1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: An alias may be missed, and incorrect answers result, when a struct contains a bitfield and the struct's total size is smaller than the size of the bitfield's type. Eg, a field like "int x:6" -- the bitfield is 6 bits but int is 16 or 32. Making both direct and indirect accesses to the same field may be an additional requirement to exhibit this problem. Defect occurs in C6000 Compiler versions: 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.8 - 6.0.29, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: Compile at -o1 or -o0, or add a dummy field to the struct to make its total size larger than that of the bitfield's type, or change the bitfield to a regular field, or avoid using both direct and indirect accesses to the same field. ------------------------------------------------------------------------------- FIXED SDSCM00040497 ------------------------------------------------------------------------------- Summary : DSECT failure Fixed in : 7.3.1 Severity : S2 - Major Affected Component : Linker Release Notes: In some cases, code allocated to a DSECT type output section may be included in the output file. This is known to occur if the code in the DSECT references a function that is not allocated to a DSECT. Defect occurs in C6000 Compiler versions: 5.1.0B1 - 5.1.5, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.1B2, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: In some cases, a NOLOAD section may be used instead of a DSECT. ------------------------------------------------------------------------------- FIXED SDSCM00040622 ------------------------------------------------------------------------------- Summary : Compiler may miss alias of struct returned from call if contains bitfield and fits in int Fixed in : 7.3.1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The compiler may convert local struct variables of struct type into simple ints, if the struct is small enough and all fields are bitfields. If such a converted struct is also returned from a function call, the compiler may miss an alias between the returned-value struct and the local struct. Defect occurs in C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1 - 6.0.29, 7.0.0B2 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: Compile at -o1 or -o0, or add a dummy field to make the struct larger than int, or use regular fields instead of bitfields. ------------------------------------------------------------------------------- FIXED SDSCM00040626 ------------------------------------------------------------------------------- Summary : If it gets the struct that has bit field member that is return value of function, the correct value can not refer. Fixed in : 7.3.1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: There were two stores to the structure: 1) Setting bitfields to 1 2) Setting bitfields to 2 The bug caused the stores to be switched around, causing the store of 1's to happen after the store of 2's, leading to the incorrect final value. Workaround: Avoid defining the fields of a structure twice before using them, especially between manipulations of pointers. ------------------------------------------------------------------------------- FIXED SDSCM00040650 ------------------------------------------------------------------------------- Summary : Error when specifying 400 or more to precision of output format specifier Fixed in : 7.3.1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The minimum max conversion (precision) printf size to be C89 compliant is 509. The conversion size is now C89 compliant. Workaround: Specify a printf precision of less than 400 ------------------------------------------------------------------------------- FIXED SDSCM00040657 ------------------------------------------------------------------------------- Summary : After the initialized array is used to assign into other variable in loop, when it is used the assigned variable, the value o Fixed in : 7.3.1 Severity : S2 - Major Affected Component : Optimizer Release Notes: An initialized local array variable inside a loop was incorrectly setup. Workaround: Use -o0 or -o1. ------------------------------------------------------------------------------- FIXED SDSCM00040658 ------------------------------------------------------------------------------- Summary : Taking the address of a static local variable may lead to a missed alias Fixed in : 7.3.1 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00040663 Release Notes: Accessing a static local variable both directly and indirectly, by taking its address, may miss an alias and produce incorrect behavior. Defect occurs in C6000 Compiler versions: 6.1.19 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: Compiling at -o0 should work, and compiling at -o1 may work. If the variable whose address is taken is not static, there is no problem. Sometimes it helps if the variable *holding* the address is not static. ------------------------------------------------------------------------------- FIXED SDSCM00040665 ------------------------------------------------------------------------------- Summary : Anonymous function call that can resolve to direct pure call may cause compiler crash Fixed in : 7.3.1 Severity : S2 - Major Affected Component : Optimizer Release Notes: If an anonymous function call -- a call using a pointer-to-function variable rather than a direct function name -- can be resolved to a direct call to a known function with no side effects, in some cases the compiler may crash. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: Compile at -o0 or -o1, or avoid anonymous function calls. ------------------------------------------------------------------------------- FIXED SDSCM00040691 ------------------------------------------------------------------------------- Summary : Video codec performance degraded when cgtools migrated to 7.2.4 Fixed in : 7.3.1 Severity : S2 - Major Classification : Performance Affected Component : C/C++ Compiler (cl) Release Notes: A loop which chooses between faster and safer versions at run time based on a pointer comparison may not derive all the benefit from the comparison in the faster case. Workaround: Use "restrict" on the destination pointer, when valid; that will avoid the need for the run-time comparison and produce a faster version at compile time. Or, since the original loop was equivalent to memcpy(), just use memcpy(). ------------------------------------------------------------------------------- FIXED SDSCM00040777 ------------------------------------------------------------------------------- Summary : INTERNAL ERROR occurs. Usage of array variable of "unsigned long" type. Fixed in : 7.3.1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00040780 Release Notes: The compiler was generating instructions for the loop that, when applied to the function as a whole, resulted in code for which it was impossible to allocate registers. These instructions have since been simplified, and all cases which expressed this specific issue have been fixed. Workaround: Disable software pipelining with the -u option. ------------------------------------------------------------------------------- FIXED SDSCM00040791 ------------------------------------------------------------------------------- Summary : A loop whose initial value has a side effect may compile incorrectly Fixed in : 7.3.1 Severity : S2 - Major Affected Component : Optimizer Release Notes: A loop like for (j = --i; j > 0; j >>= 1) may iterate the wrong number of times. The key detail is that j's initial value is --i, which also updates i. The problem has only been seen in loops that iterate by >>=, but it could possibly affect other loops. Defect occurs in C6000 Compiler versions: 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.29, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: Move the side effect (decrement in this case) ahead of the loop. ------------------------------------------------------------------------------- FIXED SDSCM00040793 ------------------------------------------------------------------------------- Summary : Accessing the same variable both directly and via pointer-to-void may miss the alias Fixed in : 7.3.1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: If the same variable is referred to both directly and via a pointer-to-void parameter, the compiler may not detect that both accesses are to the same variable. Defect occurs in C6000 Compiler versions: 6.1.19 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: Compile at -o0 or -o1, or avoid creating an alias via pointer-to-void. ------------------------------------------------------------------------------- FIXED SDSCM00040908 ------------------------------------------------------------------------------- Summary : Hex converter crashes with segmentation fault Fixed in : 7.3.1 Severity : S2 - Major Affected Component : Hex Converter (hex) Release Notes: Hex converter crashes with segmentation fault if more than 15 --exclude options are used. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: Use arm version 4.9.0 or later. ------------------------------------------------------------------------------- FIXED SDSCM00041130 ------------------------------------------------------------------------------- Summary : Complicated nested IFs may access memory in wrong order Fixed in : 7.3.1 Severity : S2 - Major Affected Component : Optimizer Release Notes: Given two sufficiently complicated memory accesses inside the predicates of nested IFs -- typically indexed accesses to part of a struct -- the compiler may reorder the accesses inappropriately. The effect is that the inner access, or one dependent on the inner IF, may happen when it should have been disallowed. The consequence may be a faulting access on targets that check for such things; targets that don't check won't see any problem, because the incorrect access will be discarded. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: In the given test case, using a temporary variable to hold the inner IF's access (it looked like m.u[i].c.r[j].a) avoided the problem. Moving the complicated access outside the IF predicate is probably key. ------------------------------------------------------------------------------- FIXED SDSCM00041166 ------------------------------------------------------------------------------- Summary : C++ static consts are not optimized away and have space reserved in .bss Fixed in : 7.3.1 Severity : S2 - Major Affected Component : Code Generator Release Notes: The parser now removes unreferenced static const variables. Workaround: Use -o3 ------------------------------------------------------------------------------- FIXED SDSCM00041224 ------------------------------------------------------------------------------- Summary : Compiler generating illegal cross path read in software pipelined loop Fixed in : 7.3.1 Severity : S2 - Major Affected Component : Code Generator Duplicate Defects : SDSCM00041357 Release Notes: There is no easy correlation between the C source code and the trigger codntions of this bug. However, it usually happens when there is a vector register spill. When this bug happens, the compiler quits. The user can not get the object file and the assembler will emit an error message. Defect occurs in C6000 Compiler versions: 7.2.4 - 7.2.6, 7.3.0B1 - 7.3.0 Workaround: In this particular case, the use of --disable:side_spill will prevent the problem. However, performance may be decreased. ------------------------------------------------------------------------------- FIXED SDSCM00041264 ------------------------------------------------------------------------------- Summary : Optimiser may combine _mpy and _mpyh into _mpy2ll incorrectly given -me Fixed in : 7.3.1 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00041703 Release Notes: The compiler may combine _mpy and _mpyh of the same operands into _mpy2ll and then extract from the result. With -me, the operations are combined in the wrong order. Defect occurs in C6000 Compiler versions: 6.1.14 - 6.1.14, 7.0.1 - 7.0.2, 7.1.0B1 - 7.1.0B1, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: Compile at -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00041312 ------------------------------------------------------------------------------- Summary : Register allocation in Software Pipelining is wrong because of errors in conflict graph Fixed in : 7.3.1 Severity : S2 - Major Affected Component : Code Generator Release Notes: Register allocation is wrong in the kernel of a software pipeline loop. The reason is that the conflict graph built for this kernel does not cover all the references. In this case, one of the def of a register falls just one cycle following the kernel. The conflict graph builder wrongly thinks this def does not belong to the kernel. The fix corrects this error. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00041384 ------------------------------------------------------------------------------- Summary : internal error on CMPxx instruction with reg-pair operand Fixed in : 7.3.1 Severity : S2 - Major Affected Component : Code Generator Release Notes: This defect can only occur when compiling with -mvtesla. The compiler will produce an error and stop if a linear assembly source file has a CMPGT, CMPLT, CMPGTU, or CMPLTU instruction with a register pair source operand. Workaround: There is no workaround other than not using CMP instructions in linear assembly that use 40-bit (reg pair) source operands. ------------------------------------------------------------------------------- FIXED SDSCM00041395 ------------------------------------------------------------------------------- Summary : scanf %1f should stop after one character Fixed in : 7.3.1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: The scanf format %1f should stop after one character of input, but it ignores the field width and keeps parsing as long as the input looks like a floating-point number. Defect occurs in C6000 Compiler versions: 4.10 - 4.22, 4.37 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.29, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041396 ------------------------------------------------------------------------------- Summary : sscanf(" ", "%s", arg) should not modify arg Fixed in : 7.3.1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: When the scanf format %s is used, if there are no non-whitespace characters in the input, the conversion should fail and should not modify the argument. Defect occurs in C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.29, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: Use a temporary variable as the destination of the format conversion, and only assign it to the desired location if sscanf does not fail. ------------------------------------------------------------------------------- FIXED SDSCM00041397 ------------------------------------------------------------------------------- Summary : scanf %4[..] consumes 5 characters Fixed in : 7.3.1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: With a format string containing a %[ conversion specifier with field width, and input containing a sequence of characters that matches the scanset and has more characters than the field width, a call to vfscanf shall assign the number of characters equal to the field width to the corresponding pointer to character array leaving characters after the input item unread. 7.19.6.9;2a (161) The bug here is that, while _scanfi assigns the correct number of characters, it fails to unget the following character, which belongs to the next conversion. Defect occurs in C6000 Compiler versions: 4.10 - 4.22, 4.37 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.29, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041398 ------------------------------------------------------------------------------- Summary : scanf %[..] matching failure should return immediately Fixed in : 7.3.1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: When a conversion fails, scanf should return immediately. In these test cases, scanf erroneously keeps going. scanf eventually reports a return value that is too large. Defect occurs in C6000 Compiler versions: 4.10 - 4.22, 4.37 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.29, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041442 ------------------------------------------------------------------------------- Summary : printf("%#.4o",345) adds too many zeros Fixed in : 7.3.1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: When using the # printf format flag, printf should only add an extra "0" at the beginning of the number if it isn't already "0". Defect occurs in C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.29, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00041447 ------------------------------------------------------------------------------- Summary : printf("%#.0o",0) fails to write "0" Fixed in : 7.3.1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: For *printf functions, the C standard requires that if the value is 0, the precision is 0, and the # flag is used, a single "0" will be printed. Defect occurs in C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.29, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041470 ------------------------------------------------------------------------------- Summary : cmp6x takes more than 1 hour during template instantiation Fixed in : 7.3.1 Severity : S2 - Major Affected Component : Compressor (cmp) Duplicate Defects : SDSCM00041178 Release Notes: The C6000 compressor (cmp6x) had a bug in a function intended to cache code labels. This would slow down processing of long code sections. The longer the section, the exponentially worse the slowdown would be. For a code section with over 200,000 instructions, the compressor could run for more than an hour. This is made worse by using C++ templates in COFF mode, which uses late template instantiation, which means the compressor will run over and over while compressing templates, which can get to be very large. Defect occurs in C6000 Compiler versions: 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.6, 7.3.0B1 - 7.3.0 Workaround: Use --no_compress ------------------------------------------------------------------------------- FIXED SDSCM00041550 ------------------------------------------------------------------------------- Summary : sscanf %% failure not handled correctly Fixed in : 7.3.1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: scanf fails in these ways when the %% conversion specifier fails: When any sort of error occurs with %%, scanf immediately returns EOF. It should instead return EOF only if there were 0 previous successful conversions and there was an input failure. If the failure was either a matching failure, or there were any previous successful conversions, it should return the number of previous successful conversions. When the failure is a matching failure, scanf should unget the character that didn't match. It fails to do so. Defect occurs in C6000 Compiler versions: 4.10 - 4.22, 4.37 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.29, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041551 ------------------------------------------------------------------------------- Summary : scanf %d and %f should immediately return upon input failure, even if ordinary characters were matched Fixed in : 7.3.1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: scanf should immediately return when an input failure occurs, even if ordinary characters in the format were already successfully matched. This bug affects all of the integer and float conversions. Defect occurs in C6000 Compiler versions: 4.10 - 4.22, 4.37 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.29, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041552 ------------------------------------------------------------------------------- Summary : sscanf.c _chkmbc should return EOF on input failure Fixed in : 7.3.1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: It should be possible for sscanf to return EOF on a string if an input error occurs (the end of the input string is reached before the format string is exhausted), but it does not return EOF as appropriate. Defect occurs in C6000 Compiler versions: 4.10 - 4.22, 4.37 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.29, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041553 ------------------------------------------------------------------------------- Summary : scanf input failure when looking for ordinary characters always returns EOF Fixed in : 7.3.1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: When matching ordinary characters in the format string, if there is an input failure, scanf should return EOF only if there were no previous successful conversions. If there were any, it should return the number of previous successful conversions. Defect occurs in C6000 Compiler versions: 4.10 - 4.22, 4.37 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.29, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041554 ------------------------------------------------------------------------------- Summary : scanf %e and %[ should not return EOF on matching failure Fixed in : 7.3.1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: When using %f (or other floating-point conversion specifier) or %[, if a matching failure occurs before even one character is matched, scanf will return EOF instead of 0 as the standard requires. Defect occurs in C6000 Compiler versions: 4.10 - 4.22, 4.37 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.29, 6.1.0B1 - 6.1.20, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00041786 ------------------------------------------------------------------------------- Summary : Certain oversized vectorisation cases cause optimiser crash Fixed in : 7.3.1 Severity : S2 - Major Affected Component : Optimizer Release Notes: Certain very wide vectorisation cases may cause an optimiser crash. Loops involving operations with one short operand and one int operand may trigger the crash. Loops doing a saturated subtraction of shorts and saving the result in a short may trigger the crash. In both cases, an UNROLL pragma will work around the problem; see Workarounds. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.6, 7.3.0B1 - 7.3.0 Workaround: Add "#pragma UNROLL(4)" (or 2 or 1) to the affected loops. In one instance, vectorising a saturating subtract of shorts, store the result in an int instead of a short. In all cases, compiling at -o1 or -o0 will also avoid the problem. =============================================================================== 22. Defects fixed in C6000 Code Generation Tools release 7.3.0 =============================================================================== The following 17 defects were fixed in C6000 Code Generation Tools release 7.3.0, released July 2011. ------------------------------------------------------------------------------- FIXED SDSCM00008276 ------------------------------------------------------------------------------- Summary : Linker accepts illegal address ranges and truncates to a valid address Fixed in : 7.3.0 Severity : S3 - Minor Affected Component : Linker Release Notes: The linker will now generate an out of range error: "./test.cmd", line 4: error: integer constant does not fit within 32-bits: "0x123456789" error: errors encountered during linking; "test.out" not built Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00031246 ------------------------------------------------------------------------------- Summary : Zero length Section allocation problem Fixed in : 7.3.0 Severity : S3 - Minor Affected Component : Linker Duplicate Defects : SDSCM00039877 Release Notes: A zero length output section in a linker command file that contains the dot expression . += 0x0 will cause a linker error: .trace: fill = 0x0 { _SYS_PUTCBEG = .; . += 0x0; _SYS_PUTCEND = . - 1; } > L1SARAM PAGE 1 placement fails for object ".trace", size 0x0 (page 1). Available ranges: L1SARAM size: 0x1000 unused: 0x22e max hole: 0x22c error: errors encountered during linking; Workaround: Comment out the . += 0x0 expression: .trace: fill = 0x0 { _SYS_PUTCBEG = .; /*. += 0x0;*/ _SYS_PUTCEND = . - 1; } > L1SARAM PAGE 1 ------------------------------------------------------------------------------- FIXED SDSCM00040365 ------------------------------------------------------------------------------- Summary : Mixing direct and indirect accesses to same variable may give wrong answer Fixed in : 7.3.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Fix is currently scheduled for 7.2.5 update planned 7/29/11 and 6.1.20 update planned for 8/5/11. Referring to the same variable both directly and indirectly -- eg, given p[0]=&a, using both *p[0] and a in the same function -- may produce the wrong answer when the alias between the two references is missed. Defect occurs in C6000 Compiler versions: 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.8 - 6.0.28, 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.4, 7.3.0B1 - 7.3.0B3 Workaround: Compile at -o1 or -o0, or avoid referring to same variable both directly or indirectly. ------------------------------------------------------------------------------- FIXED SDSCM00040369 ------------------------------------------------------------------------------- Summary : Assignment to local struct variable with recurrence may assign some fields incorrectly Fixed in : 7.3.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Given a struct type that contains a pointer to the same type, as in struct st { struct st *next; int val; } and a local variable X of that type, and an assignment to that variable like X = *(X.next); some fields of X may not be written correctly. (Because X.next is written before the read of *(X.next) has completed.) Fix is currently scheduled for 7.2.5 update planned 7/29/11 and 6.1.20 update planned for 8/5/11. Workaround: Change the local variable to a global, or declare it volatile, or make sure the pointer field ("next" in this example) is the last one listed in the type definition. ------------------------------------------------------------------------------- FIXED SDSCM00040372 ------------------------------------------------------------------------------- Summary : Variable with volatile inside loop resulted in codegen INTERNAL ERROR. Fixed in : 7.3.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Fix is currently scheduled for 7.2.5 update planned 7/29/11 and 6.1.20 update planned for 8/5/11. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00040459 ------------------------------------------------------------------------------- Summary : Division or modulo by most-negative-value of type may produce incorrect answer Fixed in : 7.3.0 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00040790, SDSCM00040538 Release Notes: Division or modulo when the divisor is the most-negative-value of a signed type (eg, -128 for signed-char for C6x) may produce the wrong answer. Defect occurs in C6000 Compiler versions: 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.8 - 6.0.28, 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.3, 7.3.0B1 - 7.3.0B3 Workaround: Using a wider type, for example int, should help. Compiling at -o0 may help. Negating the numerator instead of the denominator will avoid the problem. ------------------------------------------------------------------------------- FIXED SDSCM00040487 ------------------------------------------------------------------------------- Summary : packed attribute given before the member list of a CSU may produce bad code Fixed in : 7.3.0 Severity : S3 - Minor Affected Component : Parser Release Notes: A class/union/struct type declared with the packed attribute preceding its member list can result in the generation of incorrect code. Defect occurs in C6000 Compiler versions: 7.2.0 - 7.2.3, 7.3.0B1 - 7.3.0B3 Workaround: Declare the class/struct/union with the packed attribute following the member list. For example, instead of struct __attribute__((__packed__)) foo { int foo_int; ... } write struct foo { int foo_int; ... } __attribute__((__packed)); ------------------------------------------------------------------------------- FIXED SDSCM00040516 ------------------------------------------------------------------------------- Summary : Severe performance loss since 6.1.11 Fixed in : 7.3.0 Severity : S2 - Major Classification : Performance Affected Component : C/C++ Compiler (cl) Release Notes: Two codegen optimizations were incorrectly disabled with the switch --opt_for_speed=5 during a previous bug fix. Workaround: Removing the --opt_for_space option appears to restore the performance ------------------------------------------------------------------------------- FIXED SDSCM00040518 ------------------------------------------------------------------------------- Summary : Linker fails to impose alignment constraints of a segment's contents on the segment itself Fixed in : 7.3.0 Severity : S2 - Major Affected Component : ELF Linker Release Notes: None Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00040623 ------------------------------------------------------------------------------- Summary : Mixing direct and indirect accesses to same variable may give wrong answer Fixed in : 7.3.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00040794 Release Notes: Referring to the same variable both directly and indirectly -- eg, given p=&a, using both *p and a in the same function -- may produce the wrong answer when the alias between the two references is missed. Defect occurs in C6000 Compiler versions: 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.8 - 6.0.28, 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.4, 7.3.0B1 - 7.3.0B3 Workaround: Compile at -o1 or -o0, or avoid referring to same variable both directly or indirectly. ------------------------------------------------------------------------------- FIXED SDSCM00040651 ------------------------------------------------------------------------------- Summary : Return statement with embedded assignment from a post-increment or -decrement may return wrong value Fixed in : 7.3.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: A statement like "return j = i++" may return the value of i after it has been incremented, when it should return the value before the increment. It's possible that other cases exist, but all will involve an assignment of a post-increment or post-decrement embedded in another statement. Defect occurs in C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.8 - 6.0.28, 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.4, 7.3.0B1 - 7.3.0B3 Workaround: Do the assignment outside the return, as in "j = i; return i++;" or "j = i++; return j;" ------------------------------------------------------------------------------- FIXED SDSCM00040656 ------------------------------------------------------------------------------- Summary : An initialised local array, used in a loop, may be set up incorrectly Fixed in : 7.3.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00040775, SDSCM00040773 Release Notes: A local array variable that is initialised in its definition may be set up incorrectly if the array is used within a loop. Defect occurs in C6000 Compiler versions: 6.1.19, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.4, 7.3.0B1 - 7.3.0B3 Workaround: Make the array a global variable instead of a local, initialise it at runtime, or compile at -o0 or -o1. ------------------------------------------------------------------------------- FIXED SDSCM00040659 ------------------------------------------------------------------------------- Summary : Mixing direct and indirect accesses to same variable may give wrong answer Fixed in : 7.3.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Referring to the same variable both directly and indirectly -- eg, given p=&a, using both *p and a in the same function -- may produce the wrong answer when the alias between the two references is missed. Defect occurs in C6000 Compiler versions: 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.8 - 6.0.28, 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.4, 7.3.0B1 - 7.3.0B3 Workaround: Compile at -o1 or -o0, or avoid referring to same variable both directly or indirectly. ------------------------------------------------------------------------------- FIXED SDSCM00040698 ------------------------------------------------------------------------------- Summary : Optimiser may crash if given loop nest in which innermost loop unconditionally returns Fixed in : 7.3.0 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00041708 Release Notes: A loop nest with an inner loop that returns unconditionally may cause the optimiser to crash. Defect occurs in C6000 Compiler versions: 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.5, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.1B2, 6.1.20 - 6.1.19, 7.2.4, 7.3.0B3 Workaround: Don't return unconditionally from a loop; exit the loop and return outside. Or compile with -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00040730 ------------------------------------------------------------------------------- Summary : Optimizer terminates abnormally when vectorising _cmpyr1 Fixed in : 7.3.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: Optimiser will crash when vectorising _cmpyr1, because it fumbles an internal cast necessary to match the operands of the vector intrinsic, _dcmpyr1. Similar problems may exist with _maxu4 going to _dmaxu4 and _shru2 to _dshru2, but haven't been demonstrated. Defect occurs in C6000 Compiler versions: 7.2.2 - 7.2.4, 7.3.0B1 - 7.3.0B3 Workaround: Add "#pragma UNROLL(1)" to the loop to prevent vectorisation, or compile at -o0 or -o1. ------------------------------------------------------------------------------- FIXED SDSCM00040837 ------------------------------------------------------------------------------- Summary : Static initialization of packed double field for a C6X target causes seg fault Fixed in : 7.3.0 Severity : S2 - Major Affected Component : Code Generator Release Notes: For C6000 targets, static initialization of a packed double field will cause a segmentation fault in the assembly step (asm6x) of a compilation. For example the following code will cause the failure: typedef struct ps { char c; double d; } __attribute__((packed)) PS; PS v = { 'a', 1.0 }; . Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.4, 7.3.0B1 - 7.3.0B3 Workaround: Use dynamic initialization. ... v.c = 'a'; v.d = 1.0; ... ------------------------------------------------------------------------------- FIXED SDSCM00040870 ------------------------------------------------------------------------------- Summary : Compiler issues "invalid schedule generated" overly conservative non-fatal error Fixed in : 7.3.0 Severity : S2 - Major Affected Component : Code Generator Release Notes: In rare cases, the compiler may give a non-fatal error, "Invalid instruction schedule generated". This error message is usually conservative, meaning that there is actually no problem with the object file that was generated by the compiler. This code that can emit this error message has been altered so that it will be generated less often on c67+ and c674x parts. Defect occurs in C6000 Compiler versions: 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.28, 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.4, 7.3.0B1 - 7.3.0B3 Workaround: The error message emitted by the compiler is non-fatal and is often conservative. A possible workaround is to lower the optimization level. =============================================================================== 23. Defects fixed in C6000 Code Generation Tools release 7.3.0B3 =============================================================================== The following 6 defects were fixed in C6000 Code Generation Tools release 7.3.0B3, released June 2011. ------------------------------------------------------------------------------- FIXED SDSCM00039238 ------------------------------------------------------------------------------- Summary : Accessing variable as both scalar and array may give wrong answers Fixed in : 7.3.0B3 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: Accessing a local integer as both a scalar and an array, as in uint64_t val = 0; uint8_t *dest = (uint8_t *)&val; for ( ii = 0; ii < sizeof( uint64_t ); ++ii ) *dest++ = *src++; return val; which reads and writes val as a uint64_t and also writes to it byte-by-byte as a uint8_t, may produce the wrong answer. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.3, 7.3.0B1 - 7.3.0B2 Workaround: Compile at -o1 or -o0, or add "#pragma UNROLL(1)" to the loop to disable the vectorisation which leads to the problem. ------------------------------------------------------------------------------- FIXED SDSCM00039691 ------------------------------------------------------------------------------- Summary : The PC range for the lexical block in the debug info is incorrect Fixed in : 7.3.0B3 Severity : S2 - Major Affected Component : Code Generator Release Notes: The compiler under certain conditions generates incorrect debug information for local variables. The trigger condition for this bug is hard to describe. However, it usually happens to relative bug programs. Defect occurs in C6000 Compiler versions: 7.0.0 - 7.0.5, 7.2.0B1 - 7.2.3, 7.3.0B1 - 7.3.0B2 Workaround: Use --no_compress. Note that this might increase the code size. ------------------------------------------------------------------------------- FIXED SDSCM00040176 ------------------------------------------------------------------------------- Summary : Memory accesses may occur out of order Fixed in : 7.3.0B3 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Consecutive memory accesses like x[i++] x[i-1] may occur out of order, if i is not a loop index variable (ie, either the accesses are not in a loop or the loop has a different index) and the code is software-pipelined. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.3, 7.3.0B1 - 7.3.0B2 Workaround: Recasting the accesses to something like x[i] x[i] ++i will avoid the problem. The key is having the same index in both accesses. ------------------------------------------------------------------------------- FIXED SDSCM00040264 ------------------------------------------------------------------------------- Summary : optimizer reduces WRITE to volatile in a loop to a single WRITE to volatile after the loop Fixed in : 7.3.0B3 Severity : S2 - Major Affected Component : Optimizer Release Notes: A volatile access may not be properly handled if the volatile qualifier is only present on the field in the definition of a struct, as opposed to the struct type as a whole or the variable itself. Defect occurs in C6000 Compiler versions: 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.28, 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.3, 7.3.0B1 - 7.3.0B2 Workaround: Compile at -o1 or -o0, or try moving the volatile qualifier to the type or variable, or perhaps cast to volatile at the access itself. ------------------------------------------------------------------------------- FIXED SDSCM00040282 ------------------------------------------------------------------------------- Summary : Triangular loop nest may cause optimizer crash Fixed in : 7.3.0B3 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: A loop nest like for (i = 0; i < 7; i++) for (j = 0; j <= i; j++) x += k; where the inner loop's trip count depends on the outer loop's iteration (this is called a triangular loop nest) and the inner loop's body contains an increment of a variable that isn't a loop index, may cause the compiler to crash. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.3, 7.3.0B1 - 7.3.0B2 Workaround: Compile at -o1 or -o0, or add "#pragma UNROLL(1)" to the outer loop. Other unroll factors may also avoid the problem. ------------------------------------------------------------------------------- FIXED SDSCM00040377 ------------------------------------------------------------------------------- Summary : Error with va_end() as left operand of void expression Fixed in : 7.3.0B3 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The macro va_end should be legal in a void expression context such as the left hand operand of the comma operator. This means the macro needs to expand to a void expression rather than be an empty macro. Defect occurs in C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.28, 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.3, 7.3.0B1 - 7.3.0B2 Workaround: Rewrite the code so that calls to va_end are by themselves, not as part of a larger expression. =============================================================================== 24. Defects fixed in C6000 Code Generation Tools release 7.3.0B1 =============================================================================== The following 38 defects were fixed in C6000 Code Generation Tools release 7.3.0B1, released April 2011. ------------------------------------------------------------------------------- FIXED SDSCM00008525 ------------------------------------------------------------------------------- Summary : Float literal conversion to integers incorrectly saturates at 32 bits Fixed in : 7.3.0B1 Severity : S3 - Minor Affected Component : Parser Release Notes: When a floating point constant with a value of larger than pow(2,32) is converted (explicitly or implicitly) to a target integer type wider than 32 bits, the compiler will incorrectly saturate the value to 32 bits. Values larger than (pow(2,32)-1) will be saturated incorrectly when converting to a wide unsigned type, and values outside the range (-pow(2,31))..(pow(2,31)- 1) will be saturated incorrectly when converting to a wide signed type. For example: #include #define DVAL 500000000000.0 long long x() { return DVAL; } main() { if (x() == DVAL) puts('OK'); else printf('Error: %lld != %g\n', x(), DVAL); } Workaround: Use float expressions rather than float constants when they occur as the argument to an explicit or implicit conversion. A simple way to do this is with a function: float make_float(float x) { return x; } void fn() { long long y = make_float(5e11); [..] } ------------------------------------------------------------------------------- FIXED SDSCM00037551 ------------------------------------------------------------------------------- Summary : Incorrect schedule in a software pipelined loop that uses SPLOOPW Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: This bug is deep in our software pipelining and its related prolog and epilog scheduling. There is no obvious connection between the C/C++ source code to the trigger of this bug. This bug could cause hardware exception, wrong register allocation, and wrong instruction scheduling. Defect occurs in C6000 Compiler versions: 6.1.16 - 6.1.17, 7.0.0B1 - 7.0.4, 7.1.0B1 - 7.1.0B3, 7.2.0B1 Workaround: There is no work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00037756 ------------------------------------------------------------------------------- Summary : Legal combination of GROUP, UNION, uninitialized sections, and initialized sections leads to incorrect error messages Fixed in : 7.3.0B1 Severity : S3 - Minor Affected Component : Linker Release Notes: The test case in the detailed description combines GROUP, uninitialized and initialized output sections, and a UNION that contains only uninitialized sections. It works with older tools such as v6.0.8. With newer tools, such as v7.0.1 it gives error messages which indicate the linker is trying to place an initialized section within the UNION, even though that is not the case. The linker no longer issues a LOAD placement warning when a GROUP has UNIONs which all have only uninitialized sections. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00037878 ------------------------------------------------------------------------------- Summary : Linker generates relocation errors for symbols already in bss Fixed in : 7.3.0B1 Severity : S3 - Minor Affected Component : Linker Release Notes: If a partially linked out file does not include any bss variables the linker will still create a "$bss" symbol with a value of 0. This ensures that if this code is linked with boot code the DP is set to some known value. However, if this partially llinked file is later linked with code that includes bss variables, the linker may set $bss to an incorrect value. This will lead to relocation errors during the final link. NOTE: Use of several .bss output sections is not support by the current linkers. The following will generate relocation errors: .bss:subsect1 { f1.out (.bss:subsect1) } .bss:subsect2 { f2.out (.bss:subsect2) } .bss { . += 0x2100; *(.bss) } The global symbol $bss needs to be defined to the start of the .bss section to perform the relocations. The above would have to be written as: bss { . += 0x2100; f1.out (.bss:subsect1) f2.out (.bss:subsect2) *(.bss) } Workaround: None available. ------------------------------------------------------------------------------- FIXED SDSCM00037893 ------------------------------------------------------------------------------- Summary : RTS is not compliant with the --c64p_dma_l1d_workaround switch Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: When the --c64p_l1d_workaround=on switch is used this will define the macro __TI_NO_PARALLEL_LOADS = 1 for the parser and assembler. Without this switch this macro is set to __TI_NO_PARALLEL_LOADS = 0 in the assembler. The following rts assembly files have been updated: memcpy64.asm setjmp.asm tdeh_uwentry_c6000.asm Therefore if a rts library must be built with the --c64p_l1d_workaround=on switch, no rts assembly source changes are required and no parallel loads will be generated in the rts object files. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00038011 ------------------------------------------------------------------------------- Summary : Very large obj file size in 7.0.3 tools Fixed in : 7.3.0B1 Severity : S3 - Minor Affected Component : Parser Release Notes: Very large obj file size in 7.0.3 tools with COFF. --keep_unneeded_types=false did not work as expected is source files were C++. This is now fixed in the 7.0.4 Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00038264 ------------------------------------------------------------------------------- Summary : No match for ICALL with _dcmpgtu2 and others with signed return type Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: Internal codegen error with intrinsic. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00038299 ------------------------------------------------------------------------------- Summary : Silicon bug fixes for CQ35478 need to be disabled for C66 Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: On C66, the silicon bug of extra stall for SPLOOP is fixed. So we disable its compiler work around. Defect occurs in C6000 Compiler versions: 7.1.0B1 - 7.1.0B3, 7.2.0B1 Workaround: There is no work around. ------------------------------------------------------------------------------- FIXED SDSCM00038388 ------------------------------------------------------------------------------- Summary : Linker mishandling trampolines wastes lots of memory by creating many large needless holes Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : Linker Release Notes: No Information Available; please see defect details. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00038429 ------------------------------------------------------------------------------- Summary : Not able to compile a source file with codegen tools 7.2.0B1 on C64x+ Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: This bug is caused by incorrect modelling of the CSR registers. This bug could happen in software pipelining where there is a long distance between the first saturated instruction and the last saturated instruction in the loop. Defect occurs in C6000 Compiler versions: 7.2.0B1 Workaround: There is no work around for this bug. ------------------------------------------------------------------------------- FIXED SDSCM00038430 ------------------------------------------------------------------------------- Summary : dis6x crash Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : Disassembler (dis) Release Notes: The C6000 disassembler crashes on out file. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00038447 ------------------------------------------------------------------------------- Summary : Compiler generates aligned load for unaligned object Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: When compiled with optimization some accesses to unaligned data (created using the packed attribute) may be incorrectly compiled as an aligned load or store and thus result in a runtime error. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.0B2 Workaround: Turning off optimization completely will avoid the problem. Since turning off optimization for the entire program is likely to cause a large degradation in performance, try to isolate the code that has the problem and turn off optimization only for that code. Also, changing the optimization level _may_ be able to avoid the problem. ------------------------------------------------------------------------------- FIXED SDSCM00038456 ------------------------------------------------------------------------------- Summary : The assembler does not allow DETR as the source in a MVC instruction Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Updated the assembler to allow DETR to be read as a source operand for the MVC instruction. It was originally implemented as a write only register. Defect occurs in C6000 Compiler versions: 6.1.17 - 6.1.18, 7.1.0B1 - 7.1.0B3, 7.2.0B2 Workaround: Assembler implemented DETR as a write only register. No easy workaround. ------------------------------------------------------------------------------- FIXED SDSCM00038477 ------------------------------------------------------------------------------- Summary : The --gen_profile_info option in combination with -o0 generates incorrect code Fixed in : 7.3.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The --gen_profile_info option in combination with -o0 generates incorrect code for a unsigned long long constant which has a value larger than LLONG_MAX. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.18, 7.0.0B1 - 7.0.4, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 Workaround: Don't use --gen_profile_info ------------------------------------------------------------------------------- FIXED SDSCM00038490 ------------------------------------------------------------------------------- Summary : 7.2.0B1 cg6x.exe experienced a segmentation fault Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Defect occurs in C6000 Compiler versions: 7.2.0B1 Workaround: no workaround/problem fixed ------------------------------------------------------------------------------- FIXED SDSCM00038536 ------------------------------------------------------------------------------- Summary : _disable_interrupts and related intrinsics may be miscompiled in ELF Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The _disable_interrupts intrinsic, and similar barrier-type intrinsics, may be miscompiled if the intrinsic call is the only statement in a function, if it returns a value (and thus the statement is "return _disable_interrupts();"), and if compilation uses --abi=eabi. An optimisation intended for simple tail calls to functions mistakenly affects these barrier intrinsics as well, and may cause an undefined-symbol error in the linker. Defect occurs in C6000 Compiler versions: 7.2.0B1 Workaround: Don't use _disable_interrupts or the like in a function that does nothing more than return the result of the call. ------------------------------------------------------------------------------- FIXED SDSCM00038538 ------------------------------------------------------------------------------- Summary : Incorrect asm directives for function synonyms Fixed in : 7.3.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: Fixed issue resulting in invalid assembly output in rare cases. Defect occurs in C6000 Compiler versions: 7.2.0B1 Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00038600 ------------------------------------------------------------------------------- Summary : Missing DDEDGE in .opt file causes incorrect code to be generated Fixed in : 7.3.0B1 Severity : S3 - Minor Affected Component : Optimizer Release Notes: Given "long x" and "char *p = (char*) &x;", the optimiser may not recognise the dependence between p[i] and x. The situation only arises when making array-like accesses through a pointer to a scalar. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.18, 7.0.0B1 - 7.0.4, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 Workaround: Don't make array accesses through a pointer that was cast from the address of a scalar. ------------------------------------------------------------------------------- FIXED SDSCM00038757 ------------------------------------------------------------------------------- Summary : Portability aid --strip_coff_underscore should not strip underscores from helper functions generated from linear assembly Fixed in : 7.3.0B1 Severity : S3 - Minor Affected Component : Assembler Release Notes: Using the option --strip_coff_underscore on a linear assembly (.sa) file will mistakenly strip the underscore from compiler helper functions. The compiler will not usually generate calls to compiler helper functions from linear assembly code, but when also using the options -ms -mv6400+, the compiler is likely to generate calls to __c6xabi_push_rts and __c6xabi_pop_rts, and these symbols will be corrupted, leading to an unresolved symbol linker error. Defect occurs in C6000 Compiler versions: 7.0.0B1 - 7.0.4, 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.0B2 Workaround: Don't use -ms in combination with --strip_coff_underscore and -mv6400+ ------------------------------------------------------------------------------- FIXED SDSCM00038766 ------------------------------------------------------------------------------- Summary : Optimizer loses side effect in "expr % 1" - (codegen contains same bug SDSCM00038778) Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: Any expression modulo 1 -- "expr % 1" -- will be replaced by 0, because that's what it evaluates to. However, it is incorrect to completely remove "expr" if it has a side effect, such as incrementing a variable; the correct simplification is to "(expr, 0)". A similar problem exists for "((long)expr) / k" where the types int and long are distinct and k > INT_MAX. Defect occurs in C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.28, 6.1.0B1 - 6.1.18, 7.0.0B1 - 7.0.4, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.0B2 Workaround: Do the side effect before the modulo. ------------------------------------------------------------------------------- FIXED SDSCM00038778 ------------------------------------------------------------------------------- Summary : Codegen missing increment operation - (optimizer contains same bug SDSCM00038766) Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: For any value of x, the expression 'x % 1' results in 0. The compiler will perform this simplification but will incorrectly not evaluate x for side effects (eg. x++, x(), etc.). The compiler has been updated to evaluate x if there is a side effect. Defect occurs in C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.28, 6.1.0B1 - 6.1.18, 7.0.0B1 - 7.0.4, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.0B2 Workaround: Other than replacing 'x % 1' with 'x,0' no available compiler workarounds. ------------------------------------------------------------------------------- FIXED SDSCM00038841 ------------------------------------------------------------------------------- Summary : Runtime memory address out of range errors occur when using COFF linker and --dp_rel option Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : COFF Linker Release Notes: None Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00038853 ------------------------------------------------------------------------------- Summary : __builtin_expect is being ignored by the compiler Fixed in : 7.3.0B1 Severity : S3 - Minor Classification : Performance Affected Component : Code Generator Release Notes: The user assisted branch predictor results are no longer discarded. Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00038952 ------------------------------------------------------------------------------- Summary : Hex6x crashes in 7.0.4 release Fixed in : 7.3.0B1 Severity : S3 - Minor Affected Component : Hex Converter (hex) Release Notes: hex6x crashes starting with release 7.0.4: hex6x.exe coffToMot.cmd INTERNAL ERROR: hex6x.exe experienced a segmentation fault 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. There was a hex6x made for 7.0.4: SDSCM37480 that is the most likely cause. Workaround: Use hex6x from version 7.0.3. ------------------------------------------------------------------------------- FIXED SDSCM00039013 ------------------------------------------------------------------------------- Summary : Optimizer incorrectly optimizes ((x< typedef unsigned char U8; typedef unsigned short U16; typedef unsigned int U32; U16 parameter_mask; U32 mask; U8 parameters[6] = { 1, 1, 1, 1, 2, 0 }; main() { parameter_mask = (parameters[5] | (parameters[4] << 8U)); mask = 0; mask |= ( 0x00000001U ); if ((parameter_mask & 0x0200) == 0x0200) { mask |= 4; } printf("simple mask = 0x%d (should be 0x5)\n", mask); } Defect occurs in C6000 Compiler versions: 4.10 - 4.22, 4.37 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.28, 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.4, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.1 Workaround: Avoid constructing the (A|B)&C form when it fits the conditions. In this test case, controlling inlining (as with -o2) is enough. Using a global variable instead of a local variable for the OR subexpression also inhibits the necessary propagation. ------------------------------------------------------------------------------- FIXED SDSCM00039018 ------------------------------------------------------------------------------- Summary : Linker seems to hang on testcase Fixed in : 7.3.0B1 Severity : S3 - Minor Affected Component : ELF Linker Release Notes: None Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00039026 ------------------------------------------------------------------------------- Summary : Compiler emits "BNOP 8" illegal instruction Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: This bug could happen on any kind of C/C++ source code. It is caused by a internal clean up/minor optimization which fails to consider the constraints on the OP field size. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.19, 7.1.0B3, 7.2.0B1 - 7.2.1 Workaround: No obvious work around for this. ------------------------------------------------------------------------------- FIXED SDSCM00039046 ------------------------------------------------------------------------------- Summary : Cannot disable MISRA checking for rule 1.1 from the command line Fixed in : 7.3.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The MISRA rule 1.1 warning is no longer issued when using the --check_misra=- 1.1 option to disable it. Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00039176 ------------------------------------------------------------------------------- Summary : Linking fails if extra space is added to linker options Fixed in : 7.3.0B1 Severity : S3 - Minor Affected Component : ELF Linker Release Notes: Empty arguments that are processed as a result of adding extra space to linker options are now discarded. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00039244 ------------------------------------------------------------------------------- Summary : Compiler generates internal error "TP>> internal error: Bad kind: TYPE::type_pointed_to" Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: An expression like *(x ? (T*)0xc0000000 : (T*)0xc0404000) -- a dereference of a pointer that is selected by a quest/colon, for which one or both alternatives is a literal integer cast to a pointer type -- may cause the compiler to crash. During other manipulations of the expression, the compiler inadvertently discards the pointer casts and creates an invalid situation. The requirements are a pointer-cast of a literal integer and a quest/colon that is used as the pointer part of a memory reference. They don't need to be written directly that way: - The original test case used an if-then-else to choose between two pointer-cast integers; the compiler converted it to quest/colon. - The original test case used const variables that were initialised to the integers; the compiler propagated the constant values into the body of the function that used the variables. - The original test case used a combination of struct and array references -- p->x[i].f -- but it was reducible to a memory access based on p, which was the pointer quest/colon. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.4, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.1 Workaround: In this case, since the pointer-cast integers are defined as const global variables, the workaround is to remove the const qualifier. That will prevent the insertion of the integer values into the body of the function. (Since const globals cannot be modified, their values may be freely introduced in place of the variables.) In a case that does not depend on such insertion, create one or two globals to hold the integers, to break up the expression. ------------------------------------------------------------------------------- FIXED SDSCM00039321 ------------------------------------------------------------------------------- Summary : memcpy64.asm has incorrect code for no parallel loads silicon workaround Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: Added a switch --no_parallel_loads that will prevent the compiler from scheduling any loads in parallel. This will also automatically pass this option to the compiler and assembler: -D__TI_NO_PARALLEL_LOADS=1 This macro is available for use in the 3 rts assembly files that contain parallel loads: memcpy64.asm setjmp.asm tdeh_uwentry_c6000.asm Defect occurs in C6000 Compiler versions: 7.2.0 - 7.2.1 Workaround: Not applicable. ------------------------------------------------------------------------------- FIXED SDSCM00039397 ------------------------------------------------------------------------------- Summary : Compiler incorrectly moves SDIV instruction outside of if statement Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: Given a statement like if (X > 0) loc2 = (X - Y)*100 / X; the compiler may arrange to execute the division before the test for zero, causing incorrect behavior if the processor traps on divide-by-zero. (If there is no trap, the divide-by-zero result will be discarded and not affect the answer.) Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.4, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.2 Workaround: Compile at -o1 or -o0, or try declaring one of the affected variables "volatile" to inhibit optimisation. ------------------------------------------------------------------------------- FIXED SDSCM00039479 ------------------------------------------------------------------------------- Summary : Compiler issues warning "spanning execute packet at branch target" Fixed in : 7.3.0B1 Severity : S3 - Minor Affected Component : Assembler Release Notes: This bug is trigger only for C6400 target with debug on. Usually it happens to member function in a instantiated C++ class. The warning does no harm. User can just ignore it. What we have fixed here is that the assembler should not issue such a warning. It should be able to aligne such instantiated member function's entry label to FP boundary. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.4, 7.2.2 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00039506 ------------------------------------------------------------------------------- Summary : optimizer pulls the memory access out of a guard which causes hardware crash Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00039796 Release Notes: Given a statement like if (P != 0) loc2 = *P; the compiler may arrange to execute the load before the test for NULL pointer, causing incorrect behavior if the processor traps on the bad access. (If there is no trap, the load result will be discarded and not affect the answer.) Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.4, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.2 Workaround: Compile at -o1 or -o0, or try declaring one of the affected variables "volatile" to inhibit optimisation. ------------------------------------------------------------------------------- FIXED SDSCM00039551 ------------------------------------------------------------------------------- Summary : No Match for ICALL for dotp2 node Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00039693 Release Notes: This bug usually happens to __subvec internal intrinsic function. This intrinsic is generated by our optimizer. Should not happen without optimization. No work around available for this. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.4, 7.2.0B1 - 7.2.2 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00039569 ------------------------------------------------------------------------------- Summary : Optimizer removes compare in single iteration do-while loop Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: In the following code: var1 = 1; do { var1--; if (((var1 < 1U))==0) {(foo(((unsigned char) 0x02)));}; } while (var1 != 0); the optimizer removes the compare and unconditionally calls the routine "foo". The conditions for this bug to occur would be: 1. The loop must be a single iteration. 2. The loop induction variable must be initialized to 1. 3. The first reference to the induction variable must be an expression that decrements the loop counter to 0. 4. The loop is a single iteration loop because the loop must break when the induction variable is equal to 0. 5. The next reference to the loop counter must be in a compare expression that can be reduced at compile time to (1 == 0). Under these conditions the optimizer could remove the compare expression causing code within the if block to execute. Workaround: Possible workarounds: 1. Mark the induction variable volatile. 2. Change the loop induction range from 0 to 1 to any other integer range. 3. Change the compare expression to any other expression not equal to one. i.e. (1 == 2). ------------------------------------------------------------------------------- FIXED SDSCM00039671 ------------------------------------------------------------------------------- Summary : Assembler should give error on illegal assembly instruction ROTL .m2x b2,a3,a3 Fixed in : 7.3.0B1 Severity : S3 - Minor Affected Component : Assembler Release Notes: The assembler now detects illegal xpath operands in SRC2 for ROTL. Defect occurs in C6000 Compiler versions: 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.4, 7.2.2 Workaround: There is no workaround. ------------------------------------------------------------------------------- FIXED SDSCM00039735 ------------------------------------------------------------------------------- Summary : Optimizer does wrong constant folding for multiply of unsigned negative constants Fixed in : 7.3.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00040684 Release Notes: A sequence like "x -= 3; x = x * 3", where all the values are unsigned, may optimise incorrectly and produce a wrong constant. Requirements: unsigned values, an assignment equivalent to "x -= k" where k is a literal integer, a multiplication of x by a literal integer, and the two literal integers must both fit in 16 bits. Defect occurs in C6000 Compiler versions: 4.44 - 4.45, 5.0.0B1 - 5.0.1, 5.1.0B1 - 5.1.13, 5.3.0B1 - 5.3.0, 6.0.1B1 - 6.0.28, 6.1.0B1 - 6.1.19, 7.0.0B1 - 7.0.4, 7.1.0B1 - 7.1.0B3, 6.1.10.101, 7.2.0B1 - 7.2.2, 7.3.0B1 Workaround: Express the sequence directly as "x = (x - 3) * 3" instead of "x -= 3; x = x * 3". The separate assignment triggers one of the causes. =============================================================================== 25. Current Known Issues =============================================================================== The following 30 known issues exist for C6000 Code Generation Tools release 7.3.21 as of March 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 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 SDSCM00023977 ------------------------------------------------------------------------------- Summary : compiler is scheduling use of A8 too early causing an incorrect branch Affected Component : Code Generator Duplicate Defects : SDSCM00038899, SDSCM00033497, SDSCM00027812, SDSCM00026420, SDSCM00025367, SDSCM00024562 Description: The below code is generated by the compiler. The MVKL of _sqrt into A8 does not occur correctly which results in an incorrect branch. MVKH .S2 0x2de00d1b,B16 || OR .L2X A8,B7,B1 || MVKL .S1 _sqrt,A8 ; |80| || STW .D2T2 B29,*+SP(144) ; |88| There appears to some type of dependency with what happens several instructions above in: SUBDP .L1X A7:A6,B11:B10,A5:A4 ; |88| || ADDDP .S1 A11:A10,A11:A10,A7:A6 ; |81| If the NOPS between the instructions are increased, the error goes away. Increasing the NOP 1 to NOP 3 in line following the parallel SUBDP||ADDDP and the load works correctly. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00036152 ------------------------------------------------------------------------------- Summary : Compiler generates internal error from parser when compiling a source file containing gcc "labels as values" extension Affected Component : Parser Duplicate Defects : SDSCM00036148 Description: Use of GCC extension "labels as values" in a source file causes the compiler to generate an internal error and abort. Compiler needs to either properly support labels as values extension, or diagnose attempted use of "labels as values" and reject it as an unsupported feature. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00037445 ------------------------------------------------------------------------------- Summary : Linker crashes with .debug_info section exceeding formatted size Affected Component : Linker Description: TOOL_242 We have problems with CGT 7.0.3. We still use the COFF format. - Very bad performance of the linker. Total build time for some builds have increased by 30 times compared to CGT6, and it seems that the increase of time is during linking. - Very large files when compiled with debug symbols. One out-file is 160 MB when compiled with CGT6, and 555 MB when compiled with CGT7. - Internal error in cl6x when linking big files with debug symbols. tems/TdsRxm/libTdsRxm.lib components/TdsRxmComp/libTdsRxmComp_component.lib /vobs/rbs/bb/dp/subsystems/RacDrv/racfl/racoh/lib/assertOffTraceOff/c64pluse/- release/racoh.lib /vobs/rbs/bb/dp/subsystems/RacDrv/racfl/raccm/lib/assertOff- TraceOff/c64pluse/release/raccm.lib /vobs/rbs/bb/dp/subsystems/RacDrv/racfl/r- acfl_print/lib/assertOffTraceOff/c64pluse/release/racfl_print.lib /vobs/rbs/b- b/dp/subsystems/RacDrv/racfl/racpm/lib/assertOffTraceOff/c64pluse/release/rac- pm.lib CMakeFiles/TtbUldchLm.out.dir/verif/loadmodules/TtbUldchLm/src/UldchLM- .cpp.obj CMakeFiles/TtbUldchLm.out.dir/loadmodules/faraday/src/FaradayStreams- Setup.cpp.obj CMakeFiles/TtbUldchLm.out.dir/appcon_TtbUldchLm.out.c.obj CMakeFiles/TtbUldchLm.out.dir/appcon_TtbUldchLm.out_a.asm.obj /vobs/bts_common/dpp_c64xplus/delivery/dpp_tci6488.lib /vobs/rbs/bb/dp/subsystems/rts_ti/src/rts64pluse.lib /vobs/rbs/bb/dp/verif/loadmodules/TtbUldchLm/memory_ttb.cmd /vobs/rbs/bb/dp/verif/loadmodules/TtbUldchLm/sections_ttb_cmake.cmd /vobs/rbs/bb/dp/loadmodules/faraday/cpu0/cpu_memory.cmd /vobs/rbs/bb/dp/verif/tools/common_ttb.cmd /vobs/rbs/bb/dp/loadmodules/faraday/cpu_sections_cmake.cmd /vobs/rbs/bb/dp/subsystems/OseckHeap/src/OseckHeap.lib warning #10189-D: archive symbol directory is missing from archive "subsystems/Protocols/libProtocols.lib" "/vobs/rbs/bb/dp/verif/loadmodules/TtbUldchLm/sections_ttb_cmake.cmd", line 27: warning #10261-D: section specifier matches no sections; potential matches are consumed by section specifier at "/vobs/rbs/bb/dp/verif/loadmodules/TtbUldchLm/sections_ttb_cmake.cmd", line 6 *libTtbLdciStubComp_component.lib(.text) user_msg_api.c:178:internal fatal error #99926: (ofile_error_handler(): TtbUldchLm.out: illegal operation: writing 0x8ec30 bytes to offset 0x22bab979 in section ".debug_info" exceeds its formatted size (0x2c3a5a9)) INTERNAL ERROR: /vobs/wds/hwt2/tms320c6x_cgt_linux/tree/bin/lnk6x 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 *** Error code 1 The write address above is > 556 MB. Strange? Have you seen any of this, and is this something you are working on? I'll provide some more information later. Priority: high ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00037671 ------------------------------------------------------------------------------- Summary : XML output needs encoding specification Affected Component : Linker Description: Any tool that emits XML output (OFD or linker with --xml_info_file) needs to specify the encoding (e.g. encoding="ISO-8859-1") and be sure to handle "extended" characters correctly. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00039264 ------------------------------------------------------------------------------- Summary : When building with -o2, compiler sometimes fails to complete compilation Affected Component : Optimizer Description: Compiler fails to complete compilation of user-provided test case and eventually crashes. ------------------------------------------------------------------------------- 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 SDSCM00041192 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning for violation of Misra 9.2 Affected Component : C/C++ Compiler (cl) Description: With, CG tools: 7.2.4: I am getting Misra C warning 9.2 for the zero initialization of single dimention float arrays, like the one below: float array[ 10 ] = {0.0f}; --> Misra C Warning 9.2 (9.2: Braces shall be used to indicate and match the structure in the non-zero initialisation of arrays and structures) On verifying, this warning does not occur with PC Lint (other Misra C tool). My setup is: CCS 3.3, DM6437 CG Tools: v7.2.4 BIOS: 5.41.10.36 Attached test case where the issue is reproducible. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00041515 ------------------------------------------------------------------------------- Summary : Compiler book is paranoid when it says --interrupt_threshold=1 is needed when volatile is used Affected Component : Documentation Description: The compiler book (spru187t) in section 6.5.6, states that -- interrupt_threshold=1 is required when volatile is used. While not totally wrong, it is overkill. Higher values of --interrupt_threshold work as well. See the forum thread for a full discussion. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00042130 ------------------------------------------------------------------------------- Summary : C66x Codegen out of memory error Affected Component : C/C++ Compiler (cl) Description: The test case is shown by the two auto-generated header files plus a minimal C-file in the attachments - that still exhibits the problem when compiled by cl6x without any options: cl6x oom.c "searcher_prs_25rb_extended_cp_lut.h", line 339407: fatal error: out of memory 1 fatal error detected in the compilation of "oom.c". Compilation terminated. >> Compilation failure For reference, changing my path to bring in the old CG tools (6.0.x), acp6x.exe maxes out at ~313MB. I am running on Win7-64. Bug discovered by customer for full details please refer to attachments with test case included. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00042346 ------------------------------------------------------------------------------- Summary : Use of #include unexpectedly uses a file named "exception.hpp" Affected Component : C/C++ Compiler (cl) Description: For this combination of circumstances ... 1. A file named exception.hpp is in the directory /path/to/some_dir 2. #include is in the source 3. The command line includes -I=/path/to/some_dir before any -I for the standard include directory The compiler will include exception.hpp, and not the expected from the standard include directory. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00043586 ------------------------------------------------------------------------------- Summary : Add prototypes to c6x.h for _enable_interrupts, _disable_interrupts, _restore_interrupts Affected Component : Runtime Intrinsics Description: All other intrinsics have a prototype in c6x.h. Please add prototypes for these intrinsics. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00043622 ------------------------------------------------------------------------------- Summary : Use of align directive causes the .out file to be much larger, but affects nothing else. Affected Component : ELF Linker Description: The test case in the attachments has this line in the linker command file ... .my_data: ALIGN(0x01000000) That ALIGN directive causes the resulting .out file to be much, much, larger. But it affects nothing else. Remove that ALIGN directive, and the only difference is in the size of the .out file. Why? What extra stuff is being put in the .out file? ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00044199 ------------------------------------------------------------------------------- Summary : Linker removes sections that were included in link in previous versions Affected Component : Linker Description: The v7.3.x linker removes certain sections that were previously being included with 6.0.x linker. Those sections can still be retained with the -u linker option but it is not clear why the new linker removing those sections to begin with. The attached test case demonstrates the issue. Steps to reproduce it with CCS 5.1.1 are described below: 1) Start up CCS 5.1.1. Go into Project->Import Existing CCS/CCE Eclipse Project and browse to/select the lte33 project. 2) Check that the compiler version is set to a 7.3.x by looking at Project Properties->General 3) Build project and take a look at the lte.map file generated in the root folder. 4) Notice that there are no sections named .init_booting and .booting. These sections do exist in the object file booting.obj which is part of the link. 5) Go into Project Properties->General, and change the compiler version to a 6.0.x version. You can do this by clicking on More, then Select new build- tool from file-system and browse to the location of a 6.0.x CGT. 6) Clean Project, then Build Project 7) Check the lte.map file and notice that the .init_booting and .booting sections are now included in the link. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00044670 ------------------------------------------------------------------------------- Summary : Dwarf call information for CALLRET instruction does not include the name of the function called Affected Component : C/C++ Compiler (cl) Description: The Dwarf debug information for a CALLRET instruction does not include the name of the function called. The DW_AT_name attribute is not present. This error causes problems for the cg_xml script call_graph.pl. One, it appears a function is being called indirectly. Two, a normal direct function call is not recorded. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00045069 ------------------------------------------------------------------------------- Summary : internal fatal error #99926 Affected Component : Linker Description: I am developing project for C66x DSP using CCS 5.2.0 and Linux. 7.3.x linker fails when I try to build my RTSC project with the following error: DIAG/user_msg_api.c:211:internal fatal error #99926: (ofile_error_handler(): transcode.out: illegal operation: writing 0x1ffffeb8 bytes to offset 0x0 in section ".text" exceeds its formatted size (0x62fe0)) INTERNAL ERROR: /home/mrlika/ti/TI_CGT_C6000_7.3.7/bin/lnk6x 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 But I can successfully compile the project without changes using CGT 7.2.x. The error appears only when the project tries to link with MPEG2 Decoder 02.02.00.02 (mpeg2vdec_ti.le66). When project does not need linking with MPEG2 Decoder the build also succeeds. Is there any way to link with MPEG2 Decoder but still use latest CGT 7.3.x? ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00045205 ------------------------------------------------------------------------------- Summary : strip6x cannot handle very long filenames Affected Component : Strip Utility Description: This issue was originally reported as an aside in SDSCM00045197 - other annoying issue : strip6x has issues with long filenames : $ strip6x /data/wisap_jenkins/build_datas/111_2012-08-27_13-49-31/wcdma- nash/sc_wcdma_nash_src/packages/nash/config/core0/exe/nash_config_core0_rel- ease_dsp_arm_e66.xe66 -o toto.xe66 error: file access error: failed to open "/data/wisap_jenkins/build_datas/111_2012-08-27_13-49-31/wcdma-nash/sc_wcdma _nash_src/packages/nash/config/core0/exe/176272vapFJ" for writing error: no error ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00045612 ------------------------------------------------------------------------------- Summary : internal error: writing bytes exceeds its formatted size Affected Component : Linker Description: [ Possibly related to SDSCM00045069 ] My customer is making design of video conferencing system based on multiple C6678 MPUs. They are getting issue with code generation/compilation using CGT 7.3.x version and later. DIAG/user_msg_api.c:241:internal fatal error #99926: (ofile_error_handler(): codec.out: illegal operation: writing 0x1ffff6b0 bytes to offset 0x0 in section ".text" exceeds its formatted size (0xc96a0)) Several project details: Codec version: H264VDEC.version.02.04.00.03.wizardversion.0.5.3 Codec information: XDM_GETVERSION: H264VDEC_TI, 02.04.00.03, DEV.100.V.H264AVC.D.C66X.ELF.02.04.00.03_C6678_BP_MP_001 ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00045723 ------------------------------------------------------------------------------- Summary : The option -order on the hex utility for C6000 devices (hex6x) does not follow other device families Affected Component : Hex Converter (hex) Description: The option -order in the hex6x utility accepts the values L or M to set endianess. However, in all the other device families this same option uses LS or MS as values. Despite a nuisance, this issue affects all C6000 projects that use the post- build step configuration in the CCS IDE, as it assumes that all hex utilities use LS and MS values. The error message shown is: 'Create flash image: Intel-HEX' "C:/ti/ccsv5/tools/compiler/c6000/bin/hex6x" -i "C6455_SYSBIOS.out" -o "C6455_SYSBIOS.hex" -order MS -romwidth 16 error: bad argument to option -order: should be one of {L,M} gmake[1]: [post-build] Error 1 (ignored) ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00046565 ------------------------------------------------------------------------------- Summary : Quoted filenames are treated as filenames containing quotes in the hex command file Affected Component : Hex Converter (hex) Description: The hex utility will not properly handle quoted paths in a hex command file - the tool will add quotation marks, even if the path is already quoted. When a path is specified on the command line, this is not the case. Further, the compiler documentation states that behavior in a command file ought to match command line behavior: " Options and filenames. These are specified in a command file in exactly the same manner as on the command line." There are valid cases in which a user would want to quote path strings, such as if the path includes spaces. --- Analysis: the issue here is that quote characters are not special in the hex command file when specifying option arguments, and so a quoted filename will be created with quote characters in the filename. Changing this would require refactoring the lexer and the grammar, which is too extensive of a change to be added to branches. This issue should not be considered a defect, it should be considered an enhancement request, as the parsing works as designed. The documentation is not especially clear; obviously it cannot work exactly the same as on the command line, because the command line parser will interpret quotes and quote escapes, so the documentation should be updated. The magnitude of this change needs to be communicated to the customer so that it can be re-prioritized. [ See also SDSCM00046979 ] ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00046695 ------------------------------------------------------------------------------- Summary : FP rounding error, 1 ULP makes P70590.c fail Affected Component : Runtime Support Libraries (RTS) Description: IEEE-754 requires exact rounding for float addition. GCC gets 4056cf03 290a0f79 const folding gets 4056cf03 290a0f79 C6000 RTS gets 4056cf03 290a0f79 C6740 simulator gets 4056cf03 290a0f78 C6600 simulator gets 4056cf03 290a0f78 correct answer is ???? ------------------------------------------------------------------------------- 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 SDSCM00051607 ------------------------------------------------------------------------------- Summary : Compiler generates incorrect code under --opt_level=2 or higher Affected Component : C/C++ Compiler (cl) Description: For reasons still not understood, the compiler generates incorrect code for the attached test case. The code prints out the expected result when built with v6.1.23. Changing only the compiler version to 7.3.20 results in this output ... This value should be 0: 1 This value should be 0: 0 This value should be 0: 0 This value should be 0: 0