C6000 C/C++ CODE GENERATION TOOLS 7.4.12 December 2014 Defect History ------------------------------------------------------------------------------- Table of Contents ------------------------------------------------------------------------------- 1. Defects fixed in C6000 Code Generation Tools release 7.4.12 2. Defects fixed in C6000 Code Generation Tools release 7.4.11 3. Defects fixed in C6000 Code Generation Tools release 7.4.10 4. Defects fixed in C6000 Code Generation Tools release 7.4.9 5. Defects fixed in C6000 Code Generation Tools release 7.4.8 6. Defects fixed in C6000 Code Generation Tools release 7.4.7 7. Defects fixed in C6000 Code Generation Tools release 7.4.6 8. Defects fixed in C6000 Code Generation Tools release 7.4.5 9. Defects fixed in C6000 Code Generation Tools release 7.4.4 10. Defects fixed in C6000 Code Generation Tools release 7.4.3 11. Defects fixed in C6000 Code Generation Tools release 7.4.2 12. Defects fixed in C6000 Code Generation Tools release 7.4.1 13. Defects fixed in C6000 Code Generation Tools release 7.4.0 14. Defects fixed in C6000 Code Generation Tools release 7.4.0B2 15. Defects fixed in C6000 Code Generation Tools release 7.4.0B1 16. Current Known Issues =============================================================================== 1. Defects fixed in C6000 Code Generation Tools release 7.4.12 =============================================================================== The following 9 defects were fixed in C6000 Code Generation Tools release 7.4.12, released December 2014. ------------------------------------------------------------------------------- FIXED SDSCM00050051 ------------------------------------------------------------------------------- Summary : Table driven exception handling code does not check for malloc returning NULL Fixed in : 7.4.12 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 SDSCM00050505 ------------------------------------------------------------------------------- Summary : TDEH emergency buffer should be allocated on stack Fixed in : 7.4.12 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 SDSCM00050725 ------------------------------------------------------------------------------- Summary : Hang/crash in partitioning for C674x Fixed in : 7.4.12 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 SDSCM00050764 ------------------------------------------------------------------------------- Summary : Bound function has incorrect address in DWARF debug info Fixed in : 7.4.12 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00049433 Release Notes: The TI compiler allows a function to be bound to a specific address, usually with "#pragma location". There was a bug in the way the TI assembler recorded the DWARF debugging information for a bound function that corrupted the DWARF debugging information. This would cause CCS to report "no source available" when stepping attempting to step into such a function. Defect occurs in C6000 Compiler versions: 7.4.0B1 - 7.4.11, 7.6.0B1 - 7.6.0, 8.0.0B1 - 8.0.0 Workaround: Set a breakpoint at the bound function and run to it, rather than attempting to step into it. ------------------------------------------------------------------------------- FIXED SDSCM00050960 ------------------------------------------------------------------------------- Summary : Array memory allocated by new is not initialized to 0 Fixed in : 7.4.12 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.4.12 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. ------------------------------------------------------------------------------- FIXED SDSCM00050997 ------------------------------------------------------------------------------- Summary : lnk6x does not pad code sections properly when user specifies non-zero fill value Fixed in : 7.4.12 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. ------------------------------------------------------------------------------- FIXED SDSCM00051097 ------------------------------------------------------------------------------- Summary : Output section splitting creates a zero-length section Fixed in : 7.4.12 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 SDSCM00051241 ------------------------------------------------------------------------------- Summary : Output section splitting creates a zero-length section Fixed in : 7.4.12 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. =============================================================================== 2. Defects fixed in C6000 Code Generation Tools release 7.4.11 =============================================================================== The following 3 defects were fixed in C6000 Code Generation Tools release 7.4.11, released September 2014. ------------------------------------------------------------------------------- FIXED SDSCM00050597 ------------------------------------------------------------------------------- Summary : Backward reference to array-in-struct may miss an alias Fixed in : 7.4.11 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.4.11 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 SDSCM00050811 ------------------------------------------------------------------------------- Summary : Linker fails with INTERNAL ERROR: lnk2000 experienced an unhandled exception Fixed in : 7.4.11 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00050957, SDSCM00050799 Release Notes: This bug occurs in the C preprocessor used for reading linker command files, and results in an unhandled exception from the linker. If no C preprocessor directives are used, the bug should not occur. The --disable_pp option can be used to turn off the preprocessor if no directives are present. Defect occurs in C6000 Compiler versions: 7.4.9 - 7.4.10, 8.0.0B3 - 8.0.0 Workaround: Remove C preprocessor directives from linker command files. =============================================================================== 3. Defects fixed in C6000 Code Generation Tools release 7.4.10 =============================================================================== The following 0 defects were fixed in C6000 Code Generation Tools release 7.4.10, released August 2014. =============================================================================== 4. Defects fixed in C6000 Code Generation Tools release 7.4.9 =============================================================================== The following 8 defects were fixed in C6000 Code Generation Tools release 7.4.9, released August 2014. ------------------------------------------------------------------------------- FIXED SDSCM00049997 ------------------------------------------------------------------------------- Summary : Loop with volatile loop control expression removed Fixed in : 7.4.9 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 SDSCM00050194 ------------------------------------------------------------------------------- Summary : Compiler turns x+I*y into a complex multiplication and addition rather than just pack them Fixed in : 7.4.9 Severity : S3 - Minor Classification : Performance Affected Component : Runtime Support Libraries (RTS) Release Notes: The compiler failed to perform an intended optimization on an expression like x+I*y, where x and y are real floating-point values. This should be a simple structure packing, but the compiler turned it into a complex multiply and add Defect occurs in C6000 Compiler versions: 7.4.0B1 - 7.4.8, 7.5.0B1, 7.6.0B1 - 7.6.0 Workaround: Use __I__ instead of I ------------------------------------------------------------------------------- FIXED SDSCM00050202 ------------------------------------------------------------------------------- Summary : MISRA-C rule 19.11 false positive Fixed in : 7.4.9 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.4.9 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 SDSCM00050365 ------------------------------------------------------------------------------- Summary : openMP parser emit error message for #pragma omp critial (name) Fixed in : 7.4.9 Severity : S2 - Major Affected Component : Parser Release Notes: No Information Available; please see defect details. Workaround: pragma critical with a name is generating an error message when the name was not a variable declared in the compilation unit. Remove the name or use the name of a variable that is declared in the compilation unit. ------------------------------------------------------------------------------- FIXED SDSCM00050512 ------------------------------------------------------------------------------- Summary : Compiler does not handle control-C signal as expected Fixed in : 7.4.9 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: Added signal catchers for SIGINT and SIGBREAK on non-Unix hosts, so the tool exits cleanly instead of falling into the segfault report mechanism. Workaround: Later compiler releases (7.6.x and above) do not suffer from this problem. ------------------------------------------------------------------------------- FIXED SDSCM00050520 ------------------------------------------------------------------------------- Summary : strip crashes on files with more than 64k sections Fixed in : 7.4.9 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.4.9 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. =============================================================================== 5. Defects fixed in C6000 Code Generation Tools release 7.4.8 =============================================================================== The following 6 defects were fixed in C6000 Code Generation Tools release 7.4.8, released May 2014. ------------------------------------------------------------------------------- FIXED SDSCM00049421 ------------------------------------------------------------------------------- Summary : Auto-generated stress test terminate abnormally in optimizer Fixed in : 7.4.8 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 SDSCM00049539 ------------------------------------------------------------------------------- Summary : Vector code with variables of same name (as thru inlining) may produce wrong answers Fixed in : 7.4.8 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.4.8 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 ------------------------------------------------------------------------------- FIXED SDSCM00049832 ------------------------------------------------------------------------------- Summary : Using optimization causes incorrect result Fixed in : 7.4.8 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 SDSCM00050014 ------------------------------------------------------------------------------- Summary : Missing copyright notice on mklib.c source Fixed in : 7.4.8 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: The source code for mklib (mklib.c) is part of the product but lacks a proper copyright statement. This file should have the same copyright as the other TI-generated source files in the RTS library source code. Defect occurs in C6000 Compiler versions: 7.4.0B1 - 7.4.7, 7.5.0B1, 7.6.0B1 - 7.6.0 Workaround: Not applicable ------------------------------------------------------------------------------- FIXED SDSCM00050023 ------------------------------------------------------------------------------- Summary : SIGSEGV when using pragma on a template function Fixed in : 7.4.8 Severity : S2 - Major Affected Component : Parser Release Notes: The compiler may emit an internal error (SIGSEGV) when the user attempts to apply a pragma to a template class function. Defect occurs in 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.4.7 =============================================================================== The following 17 defects were fixed in C6000 Code Generation Tools release 7.4.7, released February 2014. ------------------------------------------------------------------------------- FIXED SDSCM00045207 ------------------------------------------------------------------------------- Summary : Option --advice:performance_file interface does not work well in CCS build environment Fixed in : 7.4.7 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: No Information Available; please see defect details. Workaround: This workaround is for CCS. In the text box for the option -- advice:performance_file enter ... $<.adv For the source file my_source.c, this causes the advice to be written to my_source.c.adv in the same directory. Feel free to use some extension other than "adv". ------------------------------------------------------------------------------- FIXED SDSCM00045417 ------------------------------------------------------------------------------- Summary : bool and _Bool are not defined correctly in strict ANSI C mode Fixed in : 7.4.7 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00048227, SDSCM00048226 Release Notes: The size and type of "bool" and "_Bool" must be the same in all modes so that declarations of the same object in different modules are compatible. However, in strict ANSI C89 mode, stdbool.h defines _Bool as "unsigned int," which means a C++ module using bool and a C module including stdbool.h and using bool are using incompatible types. _Bool and stdbool.h are C99 features, so a strictly-conforming C89 program does not use them, but the TI compiler provides them as an extension. This would cause a problem when attempting to mix C++ files and C files which both declare The ARM EABI Procedure Call Standard for the ARM Architecture (ARM IHI 0042D) section 7.1.1 ("Arithmetic Types") requires that both C++ bool and C99 _Bool be unsigned byte types. However, the TI toolset does not conform to that requirement. Defect occurs in 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 SDSCM00046180 ------------------------------------------------------------------------------- Summary : MISRA check 14.1 should not treat while(0) as potential infinte loop Fixed in : 7.4.7 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.4.7 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.4.7 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The definition of SIZE_MAX was incorrectly specified as the largest signed integer value. It is now defined as the largest unsigned integer value. Defect occurs in 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.4.7 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.4.7 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 SDSCM00048498 ------------------------------------------------------------------------------- Summary : MISRA-C rule 12.8 incorrectly reported for an expression like ((uint32_t)2U << 8U); Fixed in : 7.4.7 Severity : S2 - Major Affected Component : Parser Release Notes: A violation warning for the MISRA 12.8 rule was reported for the expression: ((uint32_t)2U << 8U); The MISRA 12.8 rule states that "The right-hand operand of a shift operator shall lie between zero and one less than the width in bits of the underlying type of the left-hand operand". The underlying type is determined by section 6.10 of the MISRA Guidelines. For a literal it is defined as being the smallest type of the same sign that can represent the literal, so for 2U the type is unsigned char. In that case the diagnostic is correct. However, the cast to uint32_t should make the underlying type unsigned int, making the operation legal. Defect occurs in 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 SDSCM00048712 ------------------------------------------------------------------------------- Summary : ARM assembler seg faults on certain input Fixed in : 7.4.7 Severity : S3 - Minor Affected Component : Assembler Duplicate Defects : SDSCM00049517 Release Notes: The problem is that the assembly instruction LDR r0,0x40004000 is not legal. The assembler believes 0x40004000 is a symbol because the user did not put a '#' in front of it. Adding the '#' produces the correct error: "Invalid addressing mode". This is still a defect because the assembler sshould not seg fault on a bad instruction. Workaround: Add the '#' in front of the 0x40004000 to produce the correct "Invalid addressing mode" error. ------------------------------------------------------------------------------- FIXED SDSCM00048747 ------------------------------------------------------------------------------- Summary : Using END(sym_name) or SIZE(sym_name) on .cinit can cause link to fail Fixed in : 7.4.7 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.4.7 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.4.7 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.4.7 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The CLINK pragma now works as expected for initialized data. Defect occurs in 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. ------------------------------------------------------------------------------- FIXED SDSCM00049229 ------------------------------------------------------------------------------- Summary : Symbols are missing in .debug_pubnames part of the Dwarf information Fixed in : 7.4.7 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.4.7 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 SDSCM00049407 ------------------------------------------------------------------------------- Summary : FAILURE in optimizer on local static variables with --opt_level=4 Fixed in : 7.4.7 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00049409 Release Notes: In rare cases, the optimizer may emit a spurious diagnostic message which says "FAILURE in mark_use_of_function_local_static." This message includes some symbol names, the first of which will be partially garbled. This message does not affect the generated code, so it may be ignored. Defect occurs in 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.4.7 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The test case attached has these lines ... #define PRAGMA(x) _Pragma(#x) PRAGMA(SET_DATA_SECTION("dsname")) This code compiles fine with several other TI compilers. However, for the C6000 compiler, this results in ... "file.c", line 5: error: this pragma cannot be used in a _Pragma operator (a #pragma directive must be used) "file.c", line 5: error: expected a "(" "file.c", line 5: error: expected a ")" Workaround: None. =============================================================================== 7. Defects fixed in C6000 Code Generation Tools release 7.4.6 =============================================================================== The following 6 defects were fixed in C6000 Code Generation Tools release 7.4.6, released October 2013. ------------------------------------------------------------------------------- FIXED SDSCM00037672 ------------------------------------------------------------------------------- Summary : GCC cast-to-union wrongly rejected in initialization constant Fixed in : 7.4.6 Severity : S2 - Major Affected Component : Parser Release Notes: union u { int i; int *p; }; struct s { int n; union u a; } v = {1, (union u) 2 }; Initialization will be flagged with "cast to type "union u" is not allowed". In GCC compatibility mode the cast should be allowed. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00045147 ------------------------------------------------------------------------------- Summary : Automatic RTS library build fails for C6713 (coff, LE). Fixed in : 7.4.6 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 SDSCM00047502 ------------------------------------------------------------------------------- Summary : linker fails with internal error if .cinit and .data are in the same GROUP Fixed in : 7.4.6 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 SDSCM00047564 ------------------------------------------------------------------------------- Summary : Valid regpair MV and NEG instructions rejected for C66x Fixed in : 7.4.6 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.4.6 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 SDSCM00047883 ------------------------------------------------------------------------------- Summary : bsearch failure when using -pr relaxed ANSI mode or --gcc mode from C++ Fixed in : 7.4.6 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00047268 Release Notes: In relaxed mode calling bsearch from C++ results in an infinite loop. Workaround: A workaround is to use --strict_ansi. =============================================================================== 8. Defects fixed in C6000 Code Generation Tools release 7.4.5 =============================================================================== The following 5 defects were fixed in C6000 Code Generation Tools release 7.4.5, released August 2013. ------------------------------------------------------------------------------- FIXED SDSCM00013456 ------------------------------------------------------------------------------- Summary : fgets in _IONBF mode does not respect size limit Fixed in : 7.4.5 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: The second argument to fgets() is the maximum number of chars to read. In _IONBF mode, fgets() reads until end-of-line, potentially overrunning the input buffer. For example: #include #include #include #include main() { FILE *f = fopen("tst.txt", "r"); char buffer[100]; int counter = 0; setvbuf(f, NULL, _IONBF, 0); while (fgets(buffer, 5, f) != NULL) { printf("[%s]\n", buffer); switch (counter++) { case 0: assert(!strcmp(buffer, "aaaa")); break; case 1: assert(!strcmp(buffer, "bbbb")); break; case 2: assert(!strcmp(buffer, "cccc")); break; } } assert(feof(f)); puts("PASS"); } With tst.txt having (with no trailing newline): aaaabbbbcccc Defect occurs in 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 SDSCM00043860 ------------------------------------------------------------------------------- Summary : Printf format %#06x prints zeros in the wrong place Fixed in : 7.4.5 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 SDSCM00046144 ------------------------------------------------------------------------------- Summary : Internal error during reporting OpenMP error 1510 Fixed in : 7.4.5 Severity : S3 - Minor Affected Component : Parser Release Notes: No Information Available; please see defect details. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00047563 ------------------------------------------------------------------------------- Summary : Disassembler applies X cross path to wrong operand of MPYSPDP Fixed in : 7.4.5 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. ------------------------------------------------------------------------------- FIXED SDSCM00047774 ------------------------------------------------------------------------------- Summary : In some cases, compiler fails to use unaligned load when reading members of a packed structure Fixed in : 7.4.5 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The compiler issues an unaligned load instruction LDNW when reading a member of a structure. Workaround: None. =============================================================================== 9. Defects fixed in C6000 Code Generation Tools release 7.4.4 =============================================================================== The following 17 defects were fixed in C6000 Code Generation Tools release 7.4.4, released June 2013. ------------------------------------------------------------------------------- FIXED SDSCM00042344 ------------------------------------------------------------------------------- Summary : Compiler generates internal error: illegal initialization or segmentation fault Fixed in : 7.4.4 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 SDSCM00044738 ------------------------------------------------------------------------------- Summary : EABI partial linking omits referenced library functions which refer to unresolved symbols Fixed in : 7.4.4 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 SDSCM00045373 ------------------------------------------------------------------------------- Summary : EXIDX section for alias function leads to INTERNAL ERROR unhandled exception Fixed in : 7.4.4 Severity : S2 - Major Affected Component : Linker Release Notes: If all of --exceptions, --unused_section_elimination=off, and --retain=.ARM.EXIDX are used, and the compiler turns a C++ function into an alias (this is a TI-specific optimization), it is possible for the linker to retain the EXIDX section for the alias function but not the alias function itself, which leads to an internal error. Defect occurs in 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.4.4 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.4.4 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.4.4 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.4.4 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.4.4 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.4.4 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.4.4 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: With the following program: #pragma DATA_SECTION(array, 4) int array[100]; Observe that the alignment of array is 32, should be 64. The DATA_ALIGN pragma should not cause an array to have an alignment that is less than the default array alignment. The DATA_ALIGN pragma is ignored if it attempts to do so. Workaround: Use the DATA_ALIGN pragma with an array alignment value of at least 8 for C64x+ ------------------------------------------------------------------------------- FIXED SDSCM00046812 ------------------------------------------------------------------------------- Summary : Instructions are placed in the wrong order Fixed in : 7.4.4 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: In rare cases, incorrect analysis by the compiler may indicate that two memory or stack accesses are unrelated when they actually refer to the same object. If this occurs, the compiler may schedule an access incorrectly. Defect occurs in 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.4.4 Severity : S2 - Major Classification : Performance Affected Component : Optimizer Release Notes: A program containing large structs containing many fields, especially if those fields are of type char, may require excessive time to compile. The compiler must check all those fields for potential aliases, and does so inefficiently. Defect occurs in 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 SDSCM00046848 ------------------------------------------------------------------------------- Summary : NOINIT keyword may be ignored Fixed in : 7.4.4 Severity : S2 - Major Affected Component : ELF Linker Duplicate Defects : SDSCM00047211 Release Notes: The linker command file keyword type(NOINIT) will be ignored in the ARM v5.0.4 and MSP430 v4.1.5 compilers. The changes made to fix SDSCM00045211 were incorrect, causing sections marked NOINIT in the linker command file to be initialized via the cinit mechanism for EABI. Defect occurs in C6000 Compiler versions: 7.4.3 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00046849 ------------------------------------------------------------------------------- Summary : stdin stdout stderr macros need to be usable without using namespace std for _ftable Fixed in : 7.4.4 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Duplicate Defects : SDSCM00045792, SDSCM00043348 Release Notes: stdin, stdout, and stderr are macros involving the identifier std::_ftable. As a macro, the namespace is not specified as you would for a type or variable (std::size_t). When cstdio is included, these macros are defined and should be usable without a using declaration putting std::_ftable in the global namespace. Defect occurs in 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.4.4 Severity : S2 - Major Affected Component : Hex Converter (hex) Release Notes: Using an invalid option with valid hex command file causes a segmentation fault. Defect occurs in 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. ------------------------------------------------------------------------------- FIXED SDSCM00046955 ------------------------------------------------------------------------------- Summary : INTERNAL ERROR: Decomposition error for C66x using packed struct Fixed in : 7.4.4 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The compiler no longer emits a decomposition error when using the packed pragma. Workaround: Remove packed pragma. ------------------------------------------------------------------------------- FIXED SDSCM00047263 ------------------------------------------------------------------------------- Summary : different binaries after compilation Fixed in : 7.4.4 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. =============================================================================== 10. Defects fixed in C6000 Code Generation Tools release 7.4.3 =============================================================================== The following 23 defects were fixed in C6000 Code Generation Tools release 7.4.3, released March 2013. ------------------------------------------------------------------------------- FIXED SDSCM00042332 ------------------------------------------------------------------------------- Summary : Don't generate typeinfo when not used Fixed in : 7.4.3 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.4.3 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.4.3 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The expression ... var_int16 = 4 * 256; contains no implicit conversions. However, MISRA rule 10.1 about no implicit conversions is still emitted for that expression. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00042581 ------------------------------------------------------------------------------- Summary : Linker fails with internal error: lnk6x failed to allocate memory Fixed in : 7.4.3 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 SDSCM00042600 ------------------------------------------------------------------------------- Summary : Ill advised enum scalar usage gets MISRA diagnostic, but similar usage of enum array does not Fixed in : 7.4.3 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The test case given assigned a integer to an enum scalar variable. MISRA checking correctly flags this with a diagnostic. The test case goes on to do the same thing with an enum array expression. It should get the same MISRA diagnostic, but does not. For example: typedef unsigned int uint16_t; uint16_t Func(void); typedef enum Error { OK, NO_DATA, BUFFER_FULL } Error_t; const Error_t errors[2] = {OK, OK}; uint16_t Func(void) { uint16_t myError; myError = OK; /* correctly flags as error (MISRA 10.1) */ myError = errors[0]; /* does not find error */ return myError; } Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00043229 ------------------------------------------------------------------------------- Summary : Instruction reordering alters logic Fixed in : 7.4.3 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 SDSCM00044183 ------------------------------------------------------------------------------- Summary : Compiler aborts with internal error "Corrupted IR detected during check_mve/spilling" with -o2 Fixed in : 7.4.3 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 SDSCM00044393 ------------------------------------------------------------------------------- Summary : Linker silently ignores an output section placement spec with missing ">" in the SECTIONS directive Fixed in : 7.4.3 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 SDSCM00045036 ------------------------------------------------------------------------------- Summary : Internal error when no suitable delete operator is present in destructor Fixed in : 7.4.3 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 SDSCM00045173 ------------------------------------------------------------------------------- Summary : Missing qsort and bsearch implementations for comparison functions with C++ linkage Fixed in : 7.4.3 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 SDSCM00045211 ------------------------------------------------------------------------------- Summary : Linker GROUP directive fails to allow NOINIT output sections and regular output sections to be together in the group Fixed in : 7.4.3 Severity : S2 - Major Affected Component : Linker Release Notes: An output section that includes NOINIT sections and regular sections is not allowed. The code to detect this error did not properly account for GROUPS, which can contain a mix of section types. However, this bug would only occur if a GROUP was declared to be type NOINIT in the linker command file. The type keyword should not be applied to GROUPs, as documented in SDSCM00032000, and this syntax will be disallowed when SDSCM00032000 is fixed. Defect occurs in C6000 Compiler versions: 7.4.0B1 - 7.4.2 Workaround: None. However, the type keyword should not be applied to GROUPs. ------------------------------------------------------------------------------- FIXED SDSCM00045381 ------------------------------------------------------------------------------- Summary : Read of array element, before memcpy() overwrites it, may be out of order Fixed in : 7.4.3 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 SDSCM00045550 ------------------------------------------------------------------------------- Summary : Truncated pointer created by cast from integer constant Fixed in : 7.4.3 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 SDSCM00045562 ------------------------------------------------------------------------------- Summary : Multiplication by power-of-2 wider than int may use wrong type Fixed in : 7.4.3 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.4.3 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 SDSCM00045894 ------------------------------------------------------------------------------- Summary : Use of option -pdse195 causes an incorrect error to be generated Fixed in : 7.4.3 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: An issue where diagnostics resulting from the evaluation of unused preprocessor tokens has been fixed. This issue only arose when error #195 was escalated to warning or error. For example, when compiling the following code with the option -pdse195: #define MY_CONCAT_DEFINE 1 #define MY_CONCAT_MACRO(a, b) a##b #if (MY_CONCAT_MACRO(MY_,CONCAT_DEFINE) == 0) #error ("Define is zero") #endif int x; The compiler generates the following incorrect error message: "test.c", line 5: error: zero used for undefined preprocessing identifier #if (MY_CONCAT_MACRO(MY_,CONCAT_DEFINE) == 0) ^ "test.c", line 5: error: zero used for undefined preprocessing identifier #if (MY_CONCAT_MACRO(MY_,CONCAT_DEFINE) == 0) ^ 2 errors detected in the compilation of "test.c". >> Compilation failure Defect occurs in 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.4.3 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 SDSCM00046075 ------------------------------------------------------------------------------- Summary : disassembler display wrong hex prefix for constant in compact instruction Fixed in : 7.4.3 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 SDSCM00046190 ------------------------------------------------------------------------------- Summary : Compiler may mishandle C symbols that resemble C++ mangled names (esp long sequences of underscores) Fixed in : 7.4.3 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 SDSCM00046346 ------------------------------------------------------------------------------- Summary : Linker takes too long to link after upgrade to 7.3.X Fixed in : 7.4.3 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 SDSCM00046400 ------------------------------------------------------------------------------- Summary : op-assign of float expression to bit-field results in corrupted code Fixed in : 7.4.3 Severity : S2 - Major Affected Component : Code Generator Release Notes: A bit-field may be assigned to with an op-assign (e.g. +=) operator. If the left hand side of the operator is a bit-field and right hand side is an expression with floating-point type, the compiler will in some cases write a corrupted value to the bit-field. Defect occurs in 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.4.3 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. ------------------------------------------------------------------------------- FIXED SDSCM00049284 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 10.1 Fixed in : 7.4.3 Severity : S3 - Minor Affected Component : Parser Release Notes: No Information Available; please see defect details. Workaround: None. =============================================================================== 11. Defects fixed in C6000 Code Generation Tools release 7.4.2 =============================================================================== The following 6 defects were fixed in C6000 Code Generation Tools release 7.4.2, released November 2012. ------------------------------------------------------------------------------- FIXED SDSCM00042974 ------------------------------------------------------------------------------- Summary : Resource conflict between instruction in SPLOOP and instruction in its epilog causing hardware exception Fixed in : 7.4.2 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 SDSCM00043174 ------------------------------------------------------------------------------- Summary : Linker fails to honor specific placement for function from RTS library Fixed in : 7.4.2 Severity : S2 - Major Affected Component : COFF Linker Release Notes: Linker now honors section placement specification. Workaround: Do not include libc.a option. ------------------------------------------------------------------------------- FIXED SDSCM00044285 ------------------------------------------------------------------------------- Summary : scanf %[^ mistakenly writes EOF to output Fixed in : 7.4.2 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: When using ^ to negate the scan set [ sscanf(in, "%[^abc]", out) ], scanf would incorrectly copy EOF to the output string. It should instead stop reading input and return as normal. Workaround: Negate the scan set manually; don't use the negation operator. ------------------------------------------------------------------------------- FIXED SDSCM00045105 ------------------------------------------------------------------------------- Summary : Empty struct as field of parent struct may cause optimizer abort Fixed in : 7.4.2 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.4.2 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.4.2 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. =============================================================================== 12. Defects fixed in C6000 Code Generation Tools release 7.4.1 =============================================================================== The following 9 defects were fixed in C6000 Code Generation Tools release 7.4.1, released August 2012. ------------------------------------------------------------------------------- FIXED SDSCM00043713 ------------------------------------------------------------------------------- Summary : Linker fails with internal error Fixed in : 7.4.1 Severity : S2 - Major Affected Component : Linker Duplicate Defects : SDSCM00043752 Release Notes: Linker sometimes fails with internal error: lnk.exe experienced an unhandled exception The linker no longer makes the assumption that the decompression routine's section can be automatically removed when the linker determines the decompression routine is not needed. Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00044048 ------------------------------------------------------------------------------- Summary : Enabling vectorization produces incorrect code Fixed in : 7.4.1 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00045426 Release Notes: In certain cases, enabling vectorization could result in incorrect code being generated. Defect occurs in 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.4.1 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 SDSCM00044450 ------------------------------------------------------------------------------- Summary : Parser allows virtual base classes that are too large Fixed in : 7.4.1 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 SDSCM00044463 ------------------------------------------------------------------------------- Summary : gcc packed attribute causes both codegen and optimizer error Fixed in : 7.4.1 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 SDSCM00044561 ------------------------------------------------------------------------------- Summary : ASG error in cg6x Fixed in : 7.4.1 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 SDSCM00044735 ------------------------------------------------------------------------------- Summary : EXIDX_CANTUNWIND yields invalid memory read Fixed in : 7.4.1 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.4.1 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.4.1 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. =============================================================================== 13. Defects fixed in C6000 Code Generation Tools release 7.4.0 =============================================================================== The following 12 defects were fixed in C6000 Code Generation Tools release 7.4.0, released July 2012. ------------------------------------------------------------------------------- FIXED SDSCM00041434 ------------------------------------------------------------------------------- Summary : Compiler optimizes away certain calls to assert() Fixed in : 7.4.0 Severity : S3 - Minor Affected Component : Absolute Lister Release Notes: Certain assert() statements, most notably "assert(x&1)" and the equivalent "assert(x%2==0)", may be removed by the compiler and thus will not do the run-time condition check that is desired. Defect occurs in 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 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.4.0 Severity : S2 - Major Classification : Performance Affected Component : Parser Release Notes: In EABI mode, the compiler was incorrectly creating static class member char arrays for string literals used in member functions instead of putting them in .const:.string. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00043770 ------------------------------------------------------------------------------- Summary : Intentional alias between two congruent IF tests may simplify incorrectly Fixed in : 7.4.0 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 SDSCM00043948 ------------------------------------------------------------------------------- Summary : IF predicate with negative integer factor simplifies incorrectly Fixed in : 7.4.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: An IF predicate with a negative integer factor -- eg, "if (x*(-3) == -9)" -- may be simplified incorrectly, for instance to "if (x == -3)" instead of the correct "if (x == 3)". Defect occurs in 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.4.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: If two three-operand expressions using the same associative operator and two of the same operands occur in the same function -- for example, x*x*x and 30*x*x -- the second expression may miscompile and be treated as identical to the first. Defect occurs in 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.4.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: Certain intrinsic operations are commutative -- their operands can occur in either order. Many of these are parallel versions of common commutative operations, like _add2, or specialised versions, like _smpy. Minimum and maximum operations also have commutative intrinsics, _min2 and _maxu4 for example. When one of these commutative intrinsics appears in a reduction -- an expression like x = _op(x, k); -- inside nested loops, the optimiser may crash. It is looking for similar kinds of expressions, but isn't handling intrinsics correctly. The compiler will either produce correct code here, or crash; it will not silently produce incorrect code. Some of these intrinsics can be introduced by the compiler itself, based on the original source code. The motivating case for this bug report looks like for (i = a; i < b; i++) for (j = c; j < d; j++) { t = ...; if (t < min) min = t; } and the compiler transformed the IF into _min2. For the problem to occur, the required ingredients are a commutative intrinsic or expressions that can be transformed into one, inside a nest of two loops that are simple enough that the outer loop may be unrolled. The workaround is to add "#pragma UNROLL(1)" to the outer loop, or to compile at -o1 or -o0, to prevent the transformation where the crash occurs. Defect occurs in 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.4.0 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.4.0 Severity : S2 - Major Affected Component : Parser Duplicate Defects : SDSCM00043437 Release Notes: In EABI mode, static variables in template functions and static data members of template classes may not be properly allocated and/or initialized. Templates are typically defined in header files, resulting in separate instances in each translation unit (source file). The tools must merge these multiple instances into unique instances, and ensure that static objects are allocated and initialized only once. There are three specific cases in which these mechanisms may fail, resulting in incorrect behavior of the program. They are: 1. A static variable in a template function, or a static variable in a member function of a template class, may not be allocated as a single unique object. This error occurs only when all of the following conditions occur: - the function is not declared inline, AND - the function is not implicity inline by virtue of having its body defined within the template class, AND - the function body is compiled in multiple translation units (i.e. the definition is in a header file). For example: template void f() { static int var; // ... } If this function definition is compiled into multiple translation units, the compiler may incorrectly create multiple instances of 'var'. Additionally, the compiler may incorrectly allocate 'var' into a section with other variables. This may cause unexpected behavior during linking, such as incorporating of unreferenced sections into the link, or changing the contents of the data section from link to link (depending on which copy of 'f()' arbitrarily gets linked in). A workaround for this defect is to declare the function f() as inline. 2. Under the same conditions described in case 1, if the static variable is initialized with a constructor, the constructor may incorrectly be called multiple times. For example: template void f() { static T var; // ... } The constructor T::T() may be called multiple times to initialize 'var'. Declaring f() as inline also works around this problem. 3. Similarly, if a static data member of a template class is initialized with a constructor, the constructor may incorrectly be called multiple times. This occurs only when all of the following conditions occur: - the definition (not the declaration) of the data member appears in multiple translation units, AND - the member is referenced in multiple translation units in which the definition occurs. For example: template class MyClass { static T var; // declaration }; // definition template T MyClass::var; // may call T::T() multiple times A workaround for case 3 is to move the definition from a header file to a .cpp file, so that it only occurs once. Workaround: 1. If a template function, or member function of a template class, has a static varaible, declare the function 'inline'. 2. If a template class has a static data member with initialization by constructor, put the definition of the data member in a .cpp file rather than a .h file. ------------------------------------------------------------------------------- FIXED SDSCM00044229 ------------------------------------------------------------------------------- Summary : including errno.h causes link-time failure when linked with thread safe RTS Fixed in : 7.4.0 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: An application that references 'errno' and links with a thread-safe version of the RTS library (rts6600_elf_mt.lib, for example), may experience a TLS symbol mismatch error during the link-step of the application build. Workaround: The problem can be avoided if: - RTS library's errno.h is #included by the file that references 'errno', AND - source file that references 'errno' is recompiled with - D__TI_USE_TLS option ------------------------------------------------------------------------------- FIXED SDSCM00044302 ------------------------------------------------------------------------------- Summary : opt6x emits an invalid symbol uid in the I-file as part of a load speculation advice record Fixed in : 7.4.0 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. ------------------------------------------------------------------------------- FIXED SDSCM00044618 ------------------------------------------------------------------------------- Summary : lnk6x runs out of memory when using --preferred_order in large application Fixed in : 7.4.0 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 SDSCM00045988 ------------------------------------------------------------------------------- Summary : Internal error: no match for ASG involving _mem2 Fixed in : 7.4.0 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. =============================================================================== 14. Defects fixed in C6000 Code Generation Tools release 7.4.0B2 =============================================================================== The following 23 defects were fixed in C6000 Code Generation Tools release 7.4.0B2, released May 2012. ------------------------------------------------------------------------------- FIXED SDSCM00037422 ------------------------------------------------------------------------------- Summary : Incorrect layout in .cdecls struct Fixed in : 7.4.0B2 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 SDSCM00042194 ------------------------------------------------------------------------------- Summary : Partial link drops weak function symbol Fixed in : 7.4.0B2 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 SDSCM00042362 ------------------------------------------------------------------------------- Summary : Disassembly shows valid instruction, but should reject illegal opcode Fixed in : 7.4.0B2 Severity : S2 - Major Affected Component : Disassembler (dis) Release Notes: Both the standalone disassembler and the disassembler view in CCS will mistakenly decode some instructions that actually contain encodings of illegal register pairs. This can mislead the user into thinking that corrupted or invalid encodings are legal instructions. 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.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: No practical workaround ------------------------------------------------------------------------------- FIXED SDSCM00042376 ------------------------------------------------------------------------------- Summary : C6000 compiler fails to preserve all the context for an interrupt function which contains an SPLOOP Fixed in : 7.4.0B2 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: This bug only happens for interrupt functions when the interrupt is in the middle of a SPLOOP and the interrupt function itself also has a SPLOOP. Defect occurs in C6000 Compiler versions: 6.0.1B1 - 6.0.30, 6.1.0B1 - 6.1.20, 7.2.0B1 - 7.2.8, 7.3.0 - 7.3.3, 7.4.0B1 Workaround: By adding lines similar to these, you can manually preserve ITSR. #include /* interrupt routine starts here */ unsigned int save_itsr = ITSR; /* loop code here */ ITSR = save_itsr; ------------------------------------------------------------------------------- FIXED SDSCM00042789 ------------------------------------------------------------------------------- Summary : Register allocation fails at ii=4, but succeeded in 7.3.0 compiler Fixed in : 7.4.0B2 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 SDSCM00042867 ------------------------------------------------------------------------------- Summary : ftell returns wrong error code in EABI Fixed in : 7.4.0B2 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" ------------------------------------------------------------------------------- FIXED SDSCM00042914 ------------------------------------------------------------------------------- Summary : Linker segfault using partial link output file of C++ source with ELF and exceptions enabled Fixed in : 7.4.0B2 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 SDSCM00043152 ------------------------------------------------------------------------------- Summary : Optimizer issues information advice using optimizer's temporary symbols instead of using symbols from user code Fixed in : 7.4.0B2 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 SDSCM00043207 ------------------------------------------------------------------------------- Summary : Compiler reads from stack frame after releasing it Fixed in : 7.4.0B2 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 SDSCM00043223 ------------------------------------------------------------------------------- Summary : Compiler may miss alias given struct-of-array-of-structs Fixed in : 7.4.0B2 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.4.0B2 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 SDSCM00043316 ------------------------------------------------------------------------------- Summary : Arithmetic fails in GROUP directive Fixed in : 7.4.0B2 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 SDSCM00043326 ------------------------------------------------------------------------------- Summary : Extremely long (templated) type names may overflow buffer, causing crash Fixed in : 7.4.0B2 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. ------------------------------------------------------------------------------- FIXED SDSCM00043376 ------------------------------------------------------------------------------- Summary : data array copy got wrong results after calling initTimer() Fixed in : 7.4.0B2 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.4.0B2 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.4.0B2 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< "./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 SDSCM00008525 ------------------------------------------------------------------------------- Summary : Float literal conversion to integers incorrectly saturates at 32 bits Fixed in : 7.4.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 SDSCM00031246 ------------------------------------------------------------------------------- Summary : Zero length Section allocation problem Fixed in : 7.4.0B1 Severity : S3 - Minor Affected Component : Linker Duplicate Defects : SDSCM00039877 Release Notes: A zero length output section in a linker command file that contains the dot expression . += 0x0 will cause a linker error: .trace: fill = 0x0 { _SYS_PUTCBEG = .; . += 0x0; _SYS_PUTCEND = . - 1; } > L1SARAM PAGE 1 placement fails for object ".trace", size 0x0 (page 1). Available ranges: L1SARAM size: 0x1000 unused: 0x22e max hole: 0x22c error: errors encountered during linking; Workaround: Comment out the . += 0x0 expression: .trace: fill = 0x0 { _SYS_PUTCBEG = .; /*. += 0x0;*/ _SYS_PUTCEND = . - 1; } > L1SARAM PAGE 1 ------------------------------------------------------------------------------- FIXED SDSCM00037170 ------------------------------------------------------------------------------- Summary : Embed does not handle cross-filesystem rename correctly Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : Embed Utility Release Notes: The embed utility needs to copy the file across file systems before renaming it. Workaround: No workaround ------------------------------------------------------------------------------- FIXED SDSCM00038452 ------------------------------------------------------------------------------- Summary : C6000 Compiler generates resource conflict in 64+ assembly output Fixed in : 7.4.0B1 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 SDSCM00039238 ------------------------------------------------------------------------------- Summary : Accessing variable as both scalar and array may give wrong answers Fixed in : 7.4.0B1 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 SDSCM00039422 ------------------------------------------------------------------------------- Summary : The intrinsic _ito128 is not handled properly Fixed in : 7.4.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The intrinsic _ito128 is not handled properly when optimization is enabled. This bug can be triggered when there is a paired register move, and the source register and the destination register are overlapped. The end result is one of the source register's content is propagated to several other destination registers. Defect occurs in C6000 Compiler versions: 7.1.0B1 - 7.1.0B3, 7.2.0 - 7.2.2, 7.3.0B1 Workaround: This is a bug. We will have it fixed. In the meantime, please refer to the attached test.c which I modifed to provide a work around. Wei ========Here comes the code ============= #include #include #define NUM_SAMPLE 16 short input[NUM_SAMPLE] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}; int main() { __x128_t input_128 = *(__x128_t*)input; __x128_t temp; /*WZ: added for work around */ int sample_index; int *input_32 = (int *) input; printf("Data before loop: %x, %x, %x, %x\n", _get32_128(input_128, 3), _get32_128(input_128, 2), _get32_128(input_128, 1), _get32_128(input_128, 0)); for (sample_index = 4; sample_index < 6; sample_index++) { printf("New input data: %x\n", input_32[sample_index]); temp = input_128; /*WZ: added for work around */ input_128 = _ito128(input_32[sample_index], _get32_128(temp, 3), _get32_128(temp, 2), _get32_128(temp, 1)); /*WZ: modifed for work around */ printf("Updated data: %x, %x, %x, %x\n", _get32_128(input_128, 3), _get32_128(input_128, 2), _get32_128(input_128, 1), _get32_128(input_128, 0)); } return 0; } ------------------------------------------------------------------------------- FIXED SDSCM00039691 ------------------------------------------------------------------------------- Summary : The PC range for the lexical block in the debug info is incorrect Fixed in : 7.4.0B1 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 SDSCM00039722 ------------------------------------------------------------------------------- Summary : __X128_t type not correct for early C6000 subtargets Fixed in : 7.4.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The __x128_t type is not intended for use on parts other than C66xx. The compiler was erroneously accepting the use of the __x128_t container type when -mv6600 was not used. In some cases (-mv6200), this could result in an assembler error. Defect occurs in C6000 Compiler versions: 7.2.3 Workaround: Do not use the __x128_t type in code that will be compiled for targets other than C6600. ------------------------------------------------------------------------------- FIXED SDSCM00039735 ------------------------------------------------------------------------------- Summary : Optimizer does wrong constant folding for multiply of unsigned negative constants Fixed in : 7.4.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. ------------------------------------------------------------------------------- FIXED SDSCM00039960 ------------------------------------------------------------------------------- Summary : Memory accesses may occur out of order in irreducible control-flow graph Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The problem appears to be the combination of a non-indexed memory access in a loop -- p->x as opposed to x[i] -- and an irreducible control-flow graph. The non-indexed memory access has a data dependence across iterations in both directions; the write must come after the current iteration's read, and it must also come before the next iteration's read. We get the write-after-read dependence but don't produce the read-after-write. Whether that causes a problem depends strongly on context. Only inner loops are pipelined, so outer-loop situations are probably safe. The inner loop has to pipeline in a particular way, so some will work and some won't. I will say that if your code does a lot of "p->x += y" expressions in loops, you'd be better off loading p->x into a temp, updating the temp in the loop, and writing it to p->x after the loop. The compiler won't always be able to do that for you automatically, and it'll improve your performance as well as avoiding this issue. An irreducible control-flow graph, loosely, is one which doesn't easily fit a loop-inside-loop-inside-loop model. Gotos that escape or enter a loop, for example, can cause the control-flow graph for a function to be irreducible. In this particular case, the problem is the "while(1)" loop with conditional returns in VC1VDEC_TI_Huff_WMV_fillEntry(). When ..._fillEntry() is inlined into VC1VDEC_TI_Huff_WMV_init(), it makes the whole function irreducible, which triggers the problem in the otherwise unrelated loop from VC1VDEC_TI_Huff_WMV_allocTables(). Avoiding irregular control flow like that will help, but again some cases will have trouble and some won't. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.2, 7.3.0B1 Workaround: 1. Replace non-indexed memory accesses (eg, p->x) that are updated inside a loop with a scalar temporary that is updated in the loop and then stored to the memory location after the loop. 2. Avoid irregular loops, like "while (1)" exited by "break" or "return" (the latter because the function might be inlined into a caller). Simple for-loops and while-loops without labels or exits will avoid the problem, will often produce faster code, and can be easier to read. 3. If such a loop must be used, isolate it in a function and prevent it from inlining, perhaps with a FUNC_CANNOT_INLINE pragma, so that it doesn't affect its caller. This case arose when one callee had an irregular loop and another callee's memory access was affected. ------------------------------------------------------------------------------- FIXED SDSCM00039973 ------------------------------------------------------------------------------- Summary : DCMPY or DCCMPY instrs incorrectly scheduled to write to M unit at same time as 2-cycle multiply instruction Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: In certain cases, the compiler may schedule code that causes a write port conflict on C6600 devices. In this particular case, the compiler may schedule the DCMPY or DCCMPY instruction such that a 2-cycle multiply instruction is trying to write to the register file at the same time. Since, on C6600, there are only two 64-bit write buses to the register file, one write will not be successful. Defect occurs in C6000 Compiler versions: 7.2.0B1 - 7.2.2, 7.3.0B1 Workaround: You can work around this problem by not using: - the _dcmpy instrinsic (C/C++) and the DCMPY instruction (linear assembly) - the _dccmpy intrinsic (C/C++) and the DCCMPY instruction (linear assembly) However, the compiler may also automatically generate these instructions if the _cmpy intrinsic is used within a loop. To prevent the compiler from using these instructions, use a #pragma UNROLL(1) on the line before any loop that contains the _cmpy intrinsic. ------------------------------------------------------------------------------- FIXED SDSCM00039981 ------------------------------------------------------------------------------- Summary : Compiler incorrectly generating LDDW when it should be generating LDNDW from a _mem8 Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: An unaligned access in a loop may be incorrectly vectorised in a way that creates an aligned access. So far this has only been observed for _mem8 and c66; it's theoretically possible also for _mem4, and for c674, c64p, and c64, but we haven't been able to create an example. Defect occurs in C6000 Compiler versions: 7.1.0B1 - 7.1.0B3, 7.2.0B1 - 7.2.2, 7.3.0B1 Workaround: Use a #pragma UNROLL(1) to prevent the optimizer from unrolling the loop. Alternatively, the user can call memcpy(), since the loop in this particular case is simply a block copy. ------------------------------------------------------------------------------- FIXED SDSCM00040101 ------------------------------------------------------------------------------- Summary : Compiler generates temporary files when compiling C++ files with templates and -pm that are not automatically deleted Fixed in : 7.4.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: When compiling C++ files which use templates with -pm option the compiler generates temporary files that are not automatically deleted. Defect occurs in 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 SDSCM00040151 ------------------------------------------------------------------------------- Summary : Getting compile time generated symbol re-definition error during linking C674x ELF target Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The linker may generate "duplicate symbol" errors for symbols named like _TI_DW_.debug_info. when linking object files. Using ofd, it can be seen that these symbols are signatures for COMDAT groups. This is an error in COMDAT generation in the assembler and linker. Defect occurs in C6000 Compiler versions: 7.2.0 - 7.2.5, 7.3.0B1 - 7.3.0 Workaround: No workaround exists. ------------------------------------------------------------------------------- FIXED SDSCM00040176 ------------------------------------------------------------------------------- Summary : Memory accesses may occur out of order Fixed in : 7.4.0B1 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.4.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: A volatile access may not be properly handled if the volatile qualifier is only present on the field in the definition of a struct, as opposed to the struct type as a whole or the variable itself. Defect occurs in 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.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: A loop nest like for (i = 0; i < 7; i++) for (j = 0; j <= i; j++) x += k; where the inner loop's trip count depends on the outer loop's iteration (this is called a triangular loop nest) and the inner loop's body contains an increment of a variable that isn't a loop index, may cause the compiler to crash. 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 SDSCM00040319 ------------------------------------------------------------------------------- Summary : OFD crashes while printing debug info from relocatable file Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : OFD Utility Release Notes: None Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00040365 ------------------------------------------------------------------------------- Summary : Mixing direct and indirect accesses to same variable may give wrong answer Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Fix is currently scheduled for 7.2.5 update planned 7/29/11 and 6.1.20 update planned for 8/5/11. Referring to the same variable both directly and indirectly -- eg, given p[0]=&a, using both *p[0] and a in the same function -- may produce the wrong answer when the alias between the two references is missed. Defect occurs in 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.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Given a struct type that contains a pointer to the same type, as in struct st { struct st *next; int val; } and a local variable X of that type, and an assignment to that variable like X = *(X.next); some fields of X may not be written correctly. (Because X.next is written before the read of *(X.next) has completed.) Fix is currently scheduled for 7.2.5 update planned 7/29/11 and 6.1.20 update planned for 8/5/11. Workaround: Change the local variable to a global, or declare it volatile, or make sure the pointer field ("next" in this example) is the last one listed in the type definition. ------------------------------------------------------------------------------- FIXED SDSCM00040372 ------------------------------------------------------------------------------- Summary : Variable with volatile inside loop resulted in codegen INTERNAL ERROR. Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Fix is currently scheduled for 7.2.5 update planned 7/29/11 and 6.1.20 update planned for 8/5/11. Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00040376 ------------------------------------------------------------------------------- Summary : Assignment to 2D-array, which has more than 20 items, resulted in INTERNAL ERROR. Fixed in : 7.4.0B1 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 SDSCM00040377 ------------------------------------------------------------------------------- Summary : Error with va_end() as left operand of void expression Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The macro va_end should be legal in a void expression context such as the left hand operand of the comma operator. This means the macro needs to expand to a void expression rather than be an empty macro. Defect occurs in 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. ------------------------------------------------------------------------------- FIXED SDSCM00040400 ------------------------------------------------------------------------------- Summary : Bitfield alias may be missed when struct is smaller than field type Fixed in : 7.4.0B1 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 SDSCM00040459 ------------------------------------------------------------------------------- Summary : Division or modulo by most-negative-value of type may produce incorrect answer Fixed in : 7.4.0B1 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.4.0B1 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 SDSCM00040497 ------------------------------------------------------------------------------- Summary : DSECT failure Fixed in : 7.4.0B1 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 SDSCM00040516 ------------------------------------------------------------------------------- Summary : Severe performance loss since 6.1.11 Fixed in : 7.4.0B1 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 SDSCM00040622 ------------------------------------------------------------------------------- Summary : Compiler may miss alias of struct returned from call if contains bitfield and fits in int Fixed in : 7.4.0B1 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 SDSCM00040623 ------------------------------------------------------------------------------- Summary : Mixing direct and indirect accesses to same variable may give wrong answer Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00040794 Release Notes: Referring to the same variable both directly and indirectly -- eg, given p=&a, using both *p and a in the same function -- may produce the wrong answer when the alias between the two references is missed. Defect occurs in 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 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.4.0B1 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.4.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The minimum max conversion (precision) printf size to be C89 compliant is 509. The conversion size is now C89 compliant. Workaround: Specify a printf precision of less than 400 ------------------------------------------------------------------------------- FIXED SDSCM00040651 ------------------------------------------------------------------------------- Summary : Return statement with embedded assignment from a post-increment or -decrement may return wrong value Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: A statement like "return j = i++" may return the value of i after it has been incremented, when it should return the value before the increment. It's possible that other cases exist, but all will involve an assignment of a post-increment or post-decrement embedded in another statement. Defect occurs in 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.4.0B1 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 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.4.0B1 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.4.0B1 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00040663 Release Notes: Accessing a static local variable both directly and indirectly, by taking its address, may miss an alias and produce incorrect behavior. Defect occurs in 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 SDSCM00040659 ------------------------------------------------------------------------------- Summary : Mixing direct and indirect accesses to same variable may give wrong answer Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Referring to the same variable both directly and indirectly -- eg, given p=&a, using both *p and a in the same function -- may produce the wrong answer when the alias between the two references is missed. Defect occurs in 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 SDSCM00040665 ------------------------------------------------------------------------------- Summary : Anonymous function call that can resolve to direct pure call may cause compiler crash Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: If an anonymous function call -- a call using a pointer-to-function variable rather than a direct function name -- can be resolved to a direct call to a known function with no side effects, in some cases the compiler may crash. Defect occurs in 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.4.0B1 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 SDSCM00040698 ------------------------------------------------------------------------------- Summary : Optimiser may crash if given loop nest in which innermost loop unconditionally returns Fixed in : 7.4.0B1 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.4.0B1 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 SDSCM00040777 ------------------------------------------------------------------------------- Summary : INTERNAL ERROR occurs. Usage of array variable of "unsigned long" type. Fixed in : 7.4.0B1 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.4.0B1 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.4.0B1 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 SDSCM00040837 ------------------------------------------------------------------------------- Summary : Static initialization of packed double field for a C6X target causes seg fault Fixed in : 7.4.0B1 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.4.0B1 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. ------------------------------------------------------------------------------- FIXED SDSCM00040908 ------------------------------------------------------------------------------- Summary : Hex converter crashes with segmentation fault Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : Hex Converter (hex) Release Notes: Hex converter crashes with segmentation fault if more than 15 --exclude options are used. Defect occurs in 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 SDSCM00041042 ------------------------------------------------------------------------------- Summary : Absolute difference of unsigned-char, accumulated in signed integer, may produce incorrect answer Fixed in : 7.4.0B1 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 SDSCM00041166 ------------------------------------------------------------------------------- Summary : C++ static consts are not optimized away and have space reserved in .bss Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: The parser now removes unreferenced static const variables. Workaround: Use -o3 ------------------------------------------------------------------------------- FIXED SDSCM00041192 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning for violation of Misra 9.2 Fixed in : 7.4.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: Compiler misreports Misra 9.2 warning for zero initialization of single dimension float arrays, like the one below: float array[ 10 ] = {0.0f}; Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00041224 ------------------------------------------------------------------------------- Summary : Compiler generating illegal cross path read in software pipelined loop Fixed in : 7.4.0B1 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.4.0B1 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 SDSCM00041308 ------------------------------------------------------------------------------- Summary : Demangler does not expose the --abi=eabi option through the help or compiler documentation Fixed in : 7.4.0B1 Severity : S3 - Minor Affected Component : Demangler (dem) Duplicate Defects : SDSCM00041780 Release Notes: The dem470 tool supports a --abi=eabi option that is needed to demangle C++ names when compiling for EABI. The option is not documented. Workaround: Use --abi=eabi when demangling name produced from and EABI project. ------------------------------------------------------------------------------- FIXED SDSCM00041312 ------------------------------------------------------------------------------- Summary : Register allocation in Software Pipelining is wrong because of errors in conflict graph Fixed in : 7.4.0B1 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.4.0B1 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.4.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: The scanf format %1f should stop after one character of input, but it ignores the field width and keeps parsing as long as the input looks like a floating-point number. Defect occurs in 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.4.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: When the scanf format %s is used, if there are no non-whitespace characters in the input, the conversion should fail and should not modify the argument. Defect occurs in 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.4.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: With a format string containing a %[ conversion specifier with field width, and input containing a sequence of characters that matches the scanset and has more characters than the field width, a call to vfscanf shall assign the number of characters equal to the field width to the corresponding pointer to character array leaving characters after the input item unread. 7.19.6.9;2a (161) The bug here is that, while _scanfi assigns the correct number of characters, it fails to unget the following character, which belongs to the next conversion. Defect occurs in 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.4.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: When a conversion fails, scanf should return immediately. In these test cases, scanf erroneously keeps going. scanf eventually reports a return value that is too large. Defect occurs in 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.4.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: When using the # printf format flag, printf should only add an extra "0" at the beginning of the number if it isn't already "0". Defect occurs in 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.4.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: For *printf functions, the C standard requires that if the value is 0, the precision is 0, and the # flag is used, a single "0" will be printed. Defect occurs in 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 SDSCM00041468 ------------------------------------------------------------------------------- Summary : When linker is invoked with --abi=ebai and the linker opens a COFF library, it should issue a diagnostic Fixed in : 7.4.0B1 Severity : S3 - Minor Affected Component : Linker Release Notes: None Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00041470 ------------------------------------------------------------------------------- Summary : cmp6x takes more than 1 hour during template instantiation Fixed in : 7.4.0B1 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 SDSCM00041471 ------------------------------------------------------------------------------- Summary : dis6x crash with very long identifier names Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : Disassembler (dis) Release Notes: dis6x crash Workaround: None ------------------------------------------------------------------------------- FIXED SDSCM00041550 ------------------------------------------------------------------------------- Summary : sscanf %% failure not handled correctly Fixed in : 7.4.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: scanf fails in these ways when the %% conversion specifier fails: When any sort of error occurs with %%, scanf immediately returns EOF. It should instead return EOF only if there were 0 previous successful conversions and there was an input failure. If the failure was either a matching failure, or there were any previous successful conversions, it should return the number of previous successful conversions. When the failure is a matching failure, scanf should unget the character that didn't match. It fails to do so. Defect occurs in 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.4.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: scanf should immediately return when an input failure occurs, even if ordinary characters in the format were already successfully matched. This bug affects all of the integer and float conversions. Defect occurs in 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.4.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: It should be possible for sscanf to return EOF on a string if an input error occurs (the end of the input string is reached before the format string is exhausted), but it does not return EOF as appropriate. Defect occurs in 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.4.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: When matching ordinary characters in the format string, if there is an input failure, scanf should return EOF only if there were no previous successful conversions. If there were any, it should return the number of previous successful conversions. Defect occurs in 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.4.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: When using %f (or other floating-point conversion specifier) or %[, if a matching failure occurs before even one character is matched, scanf will return EOF instead of 0 as the standard requires. Defect occurs in 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 SDSCM00041565 ------------------------------------------------------------------------------- Summary : Optimizer error, 2-dimensional array, 2 multiplications Fixed in : 7.4.0B1 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.4.0B1 Severity : S3 - Minor Affected Component : Optimizer Release Notes: The optimiser believed that UAND-of-NAME was always non-NULL. That's not true for weak symbols. Defect occurs in 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.4.0B1 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.4.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: Under certain specific circumstances, the compiler may replace an assignment to a bitfield with a temporary variable whose value has not been properly truncated as the original assignment did. To cause the bug, several passes that do the right thing must be inhibited; one known way is to use -o1 and a packed struct. Workaround: Compile at -o0 or -o2, or avoid packed bitfields. ------------------------------------------------------------------------------- FIXED SDSCM00041786 ------------------------------------------------------------------------------- Summary : Certain oversized vectorisation cases cause optimiser crash Fixed in : 7.4.0B1 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. ------------------------------------------------------------------------------- FIXED SDSCM00041828 ------------------------------------------------------------------------------- Summary : Internal error when compiling c++ code Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) 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.4.0B1 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.4.0B1 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 SDSCM00041909 ------------------------------------------------------------------------------- Summary : strtoimax definition does not match prototype Fixed in : 7.4.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: The definition of strtoimax in strtoimax.c, and strtoumax in strtoumax.c, lack the restrict qualifiers found in the prototypes in inttypes.h Defect occurs in 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.100 - 6.1.10.101, 7.2.0B1 - 7.2.6, 7.3.0B1 - 7.3.1 Workaround: no workaround ------------------------------------------------------------------------------- FIXED SDSCM00041925 ------------------------------------------------------------------------------- Summary : C++ name mangling for global string object causes linker conflict if project contains files with same filename Fixed in : 7.4.0B1 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.4.0B1 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 SDSCM00041971 ------------------------------------------------------------------------------- Summary : Spurious remark generated from __STDC_VERSION__ ref in stddef.h in C++ mode Fixed in : 7.4.0B1 Severity : S3 - Minor Affected Component : Runtime Support Libraries (RTS) Release Notes: #include int main(void) { return 2; } Then compile with the following flags: cl6x a.cpp -pdv -pdr include/stddef.h", line 87: remark #195-D: zero used for undefined preprocessing identifier (__STDC_VERSION__ >= 199901L || !__TI_STRICT_ANSI_MODE__) This happens because __STDC_VERSION__ is not defined in C++ mode Workaround: Use the -pds=195 switch to avoid the remark. ------------------------------------------------------------------------------- FIXED SDSCM00042028 ------------------------------------------------------------------------------- Summary : Assembly listing file output doesn't agree with .map file output. Fixed in : 7.4.0B1 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.4.0B1 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 SDSCM00042053 ------------------------------------------------------------------------------- Summary : Near a software pipelined loop that comes from an include file, the .dwpsn directives have the wrong file name Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Fixed a bug where debug information near an inlined loop could contain the incorrect file name. Defect occurs in 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 SDSCM00042061 ------------------------------------------------------------------------------- Summary : Library building fails when TEMP is moderately long (50+ characters) Fixed in : 7.4.0B1 Severity : S1 - Critical / PS Affected Component : Runtime Support Libraries (RTS) Release Notes: The ar470 command line is over 32k characters, which runs afoul of the insurmountable upper limit of the Win32 API CreateProcess. When this happens, the user will see a mysterious error which looks something like this: process_begin: CreateProcess(c:\progra~1\texasi~1\tms470~2.1\bin\ar470.exe, c:/progra~1/texasi~1/tms470~2.1/bin/ar470 -qa d:/docume~1/user.name/locals~1/temp/ti5b2e~1/rtsv7a8_a_le_eabi.lib e:/docume~1/user.name/locals~1/temp/ti5b2e~1/obj/decode.obj f:/docume~1/user.name/locals~1/temp/ti5b2e~1/obj/xatexit.obj, ...) failed. make (e=87): The parameter is incorrect. Defect occurs in 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.4.0B1 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.4.0B1 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.4.0B1 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.4.0B1 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: If the PATH environment variable has quotes in it, mklib will crash with a mysterious error like "CreateProcess(NULL, cl470 atexit.c ...) failed. The system cannot find the file specified." It is not legal to have literal quotes in PATH, but as an enhancement, mklib will attempt to remove quotes from PATH and try again. Defect occurs in 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.4.0B1 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.4.0B1 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.4.0B1 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 SDSCM00042202 ------------------------------------------------------------------------------- Summary : 7.2.6 compiler does not inline constructors in some instances in EABI Fixed in : 7.4.0B1 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 SDSCM00042217 ------------------------------------------------------------------------------- Summary : Compiler may miss alias involving union within struct Fixed in : 7.4.0B1 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 SDSCM00042256 ------------------------------------------------------------------------------- Summary : Parser generates illegal EH table on modified cpp_peren_eh testcase Fixed in : 7.4.0B1 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 SDSCM00042309 ------------------------------------------------------------------------------- Summary : v7.3 compiler doesn't generate string literals in the .const:.string section and this breaks compatibility Fixed in : 7.4.0B1 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.4.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The no virtual base class destructor diagnostic will no longer be emitted when the base class has a virtual destructor. Workaround: Do not use the -pdr option. ------------------------------------------------------------------------------- FIXED SDSCM00042368 ------------------------------------------------------------------------------- Summary : Parser generates segmentation fault Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Parser generates segmentation fault when compiling the following source file: static const int a[1]; int main(void) { (void)a[0]; return 0; } static const int a[1] = { 0 }; Workaround: Move the second static const int declaration above the reference. ------------------------------------------------------------------------------- FIXED SDSCM00042395 ------------------------------------------------------------------------------- Summary : linker sorts input section specifications incorrectly Fixed in : 7.4.0B1 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.4.0B1 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.4.0B1 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 SDSCM00042556 ------------------------------------------------------------------------------- Summary : The location pragma incorrectly treats addresses of 0x80000000 or greater as 0x7fffffff Fixed in : 7.4.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The bug only affects addresses larger than 0x8000000. If a variable or function needs to be placed at that address, the pragma cannot be used. The object can still be placed by putting it in its own section and specifying the placement in the linker command file. Workaround: If a variable or function needs to be placed at that address, the pragma cannot be used. The object can still be placed by putting it in its own section and specifying the placement in the linker command file. ------------------------------------------------------------------------------- FIXED SDSCM00042561 ------------------------------------------------------------------------------- Summary : CGTools 6.0.29 generates wrong code with o3 Fixed in : 7.4.0B1 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.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Certain loop structures, which we are not able to describe concisely, can cause the optimiser to crash when compiling at -o2 or higher. The one known example involves C++ code and a lot of inlining; adjusting the inlining avoids the problem. Workaround: Compile at -o1. In this particular example, removing an "inline" keyword from a function avoids the problem, because it changes the complexity of the function causing the crash. ------------------------------------------------------------------------------- FIXED SDSCM00042619 ------------------------------------------------------------------------------- Summary : Optimizer crashes given unrolled nested loops and lots of aliasing Fixed in : 7.4.0B1 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.4.0B1 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.4.0B1 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.4.0B1 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.4.0B1 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.4.0B1 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 SDSCM00042811 ------------------------------------------------------------------------------- Summary : printf("%d") with negative values incorrect for printf_support=minimal Fixed in : 7.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: printf("%d") is treated as printf("%u") for --printf_support=minimal, which means negative values will be printed incorrectly. Defect occurs in C6000 Compiler versions: 7.4.0B1 Workaround: Use printf_support=nofloat =============================================================================== 16. Current Known Issues =============================================================================== The following 46 known issues exist for C6000 Code Generation Tools release 7.4.12 as of December 2014. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008248 ------------------------------------------------------------------------------- Summary : Compilers on PC will not work without TMP set Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00034609 Description: When compiling on the PC, the code generator cannot find the icode file produced by the parser if the environment variable TMP is no set. If TMP is set, then all appears well. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008465 ------------------------------------------------------------------------------- Summary : Language Conformance: crash because of void pointer dereference Affected Component : Parser Description: Compiler generates multiple INTERNAL ERRORs when code like the following is compiled: void dr106_1(void *pv, int i) { *pv; i ? *pv : *pv; *pv, *pv; } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008534 ------------------------------------------------------------------------------- Summary : Linker -xml_link_info option doesn't work when in a command file Affected Component : Linker Description: The option --xml_link_info=file.xml does not work when it is placed inside a linker command file. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008537 ------------------------------------------------------------------------------- Summary : assembler expression ~(0x80000000) evaulates as 0x80000000 Affected Component : Assembler Description: The following expression is evaluating incorrectly in the assembler: .eval ~(0x80000000), mask mask ends up getting assigned 0x80000000, whereas I expect it to be 0x7FFFFFFF. It seems that any constant with bit 31 set will incorrectly return 0x80000000 ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008543 ------------------------------------------------------------------------------- Summary : Forward reference in .space generates an internal error Affected Component : Assembler Description: If you attempt to assemble: .space 0+a b a .set 1 the assembler will generate an internal error. This happens with v3.83 and v4.1.0B1 on Solaris. If you change the code to: .space a b b .set 1 the correct error message is generated, 'Absolute, well-defined integer value expected'. ------------------------------------------------------------------------------- KNOWN ISSUE 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 SDSCM00042559 ------------------------------------------------------------------------------- Summary : modf(-Inf, 1.0) with -mv6740 enters infinite loop Affected Component : C/C++ Compiler (cl) Description: Attempting to call modf(-Inf, 1.0) will result in an infinite loop. C6000 doesn't guarantee to handle Inf values correctly, but this should at least not be an infinite loop. Also calling modf(x, NaN) where x is negative will also result in an infinite loop. Not sure if this is the same bug. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00043877 ------------------------------------------------------------------------------- Summary : Emit warning message when objects of size 256MB or larger truncated Affected Component : C/C++ Compiler (cl) Description: Data objects of size 256MB or larger are silently truncated to a much smaller size. This is most easily seen for an object of size 512MB. The compiler should emit a warning message that indicates we don't support objects of size 256MB or larger. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00044351 ------------------------------------------------------------------------------- Summary : A functionality bug in Nyquist Cycle Approximate Simulator when SPLOOP buffer is enabled Affected Component : C/C++ Compiler (cl) Description: [ Could this be related to SDSCM00046638? ] I'm transferring this incident to the compiler team since the test case of interest is passing the Functionality Test on Turbo Nyquist Cycle Approximate Simulator when compiled with the Experimental Tools v7.4.01X13058 with the compiler option --use_g3 and SPLOOP buffer enabled by default. The loop related to the failing test is in the source file at line 804. I've also tried some of 7.2.x and 7.3.x tools, and the issue is present. I've attached pp, source and out files. I have attached C66x code of MRC benchmark with the corresponding tests. The problem I've noticed is with Nyquist Cycle Approximate simulator and CGTools 7.3.0.B3 I have observed the following: 1) all tests passing if Debug mode, 2) 1st and 2nd test passing, the rest of the tests are failing if Release mode (by default, SPLOOP buffer is enabled), 3) all tests passing if Release mode with SPLOOP buffer is disabled. If the same test is run on the board (EVM), all tests are passing if Release mode (by default, SPLOOP buffer is enabled). ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00044972 ------------------------------------------------------------------------------- Summary : openMP default clause is ignored Affected Component : C/C++ Compiler (cl) Description: See Details. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00046391 ------------------------------------------------------------------------------- Summary : When failing to place a section, include size of trampolines in error message Affected Component : Linker Description: The C6000 linker generates a strange error: lnk6x -mv=6600 _tsk.obj debug\single\_linker.cmd "_linker.cmd", line 5: error: program will not fit into available memory. placement with alignment fails for section ".text" size 0x1220 . Available memory ranges: MEM_18 size: 0x1220 unused: 0x1220 max hole: 0x1220 error: errors encountered during linking; "$kernel.out" not built The alignment of the .text section is 32 (from ofd6x): 18 .text 0x00000000 0x00000000 0x1220 32 Y The relevant part of the command file is: MEMORY { MEM_18: o=0x00800420 l=0x00001220 } SECTIONS { .text > MEM_18 } The error indicates that the linker can't fit 0x1220 bytes into a properly- aligned hole at 0x00800420 that is 0x1220 bytes long! There are no other .text sections or subsections. [ response: The error message is a bit misleading about the size of .text. The reported size is the total size of the input sections named .text, but doesn't account for the trampolines that the linker had to add. If you look at the linker map file (the linker option --map_file), you'll see that the actual size of .text after trampolines are added is 0x14e0. Certainly that error message needs to be made clearer ] ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00046659 ------------------------------------------------------------------------------- Summary : global labels defined in .cproc region are discarded Affected Component : Code Generator Description: The linear assembler accepts global label definitions inside a .cproc region, and even puts them in the I-file, but the codegen discards them. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00046690 ------------------------------------------------------------------------------- Summary : pow(min, max) and pow(max, max) incorrect Affected Component : Runtime Support Libraries (RTS) Description: pow(DBL_MIN, DBL_MAX) should be 0, but RTS routine returns ??? pow(DBL_MAX, DBL_MAX) should be +Inf, but RTS routine returns ??? ------------------------------------------------------------------------------- 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 SDSCM00046784 ------------------------------------------------------------------------------- Summary : extract_h should return a signed 16-bit value Affected Component : Runtime Support Libraries (RTS) Description: [ Customer argues that extract_h is intended to return a 16-bit value. We will need to refer to the ETSI GSM standard to verify this. This affects both C6000 and C5500, any others? ] The C6X version [of extract_h] will cast a signed 32-bit integer to unsigned and then right shift; so, the sign is lost. To my understanding, the intent is to "extract" the signed upper 16-bit value. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00046929 ------------------------------------------------------------------------------- Summary : Hex converter fails to process RAM model .cinit records for initialized sections Affected Component : Hex Converter (hex) Description: For a COFF RAM-model (-cr) program, hex converter fails to process the .cinit records for any initialized section. This is the same as SDSCM00036443, except that that covers the case when we are creating a boot table, and this request represents the case when we are not creating a boot table. Note that it's difficult to legitimately create an initialized section with .cinit records. The only way I was able to accomplish it was to create a distinct initialized section and combine them in the linker command file output section specification for .bss ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00046931 ------------------------------------------------------------------------------- Summary : Hex converter map file does not list all sections for RAM model program with initialized sections with .cinit records Affected Component : Hex Converter (hex) Description: For a COFF RAM-model (-cr) program, when creating a boot table, the hex converter will process the .cinit records for any initialized section. However, the hex converter infrastructure gets confused because it keeps track of the end of a section's data in the boot table, and there might now be two parts: the initialized data and the converted .cinit records. This ultimately leads to almost no sections appearing in the hex converter map file. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00047204 ------------------------------------------------------------------------------- Summary : C6000 CGT: bit field updated incorrectly when optimizer is turned on and volatile attribute is used. Affected Component : C/C++ Compiler (cl) Description: The compiler fails to update the some bitfields if the volatile attibute is used, with -O2 and "for speed 5". I can replicate it with cgtools 6.1.23 and 7.4.2. The customer is using 6.1.23. Attached a test case for CCS 5.3. It looks similar to what was reported recently on: https://e2e.ti.com/support/development_tools/compiler/int- compiler/f/85/t/247170.aspx What happens is that after executing: TestRegAudio.TestStepPCIE = 454372; TestRegAudio.TestStartProc = 0; TestRegAudio.SelectRegSet = 1; // line 15 uData = *(unsigned int *)&TestRegAudio; // line 16 the write operations in line 15 and 16 are executed in parallel. So in uData we find at the end the content that TestRegAudio had at like 14. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00047237 ------------------------------------------------------------------------------- Summary : Openmp build does not honor C6600 intrinsic Affected Component : C/C++ Compiler (cl) Description: Under some circumstances, use of the intrinsic _cmatmpy does not result in use of the CMATMPY instruction, but a call to a function named _cmatmpy. This problem presents itself when the program fails to link, and a diagnostic is issued which says _cmatmpy is an undefined symbol. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00047243 ------------------------------------------------------------------------------- Summary : isunordered not supported Affected Component : Runtime Support Libraries (RTS) Description: C6x does not support C99 function isunordered ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00047244 ------------------------------------------------------------------------------- Summary : C99 header file fenv.h not supported Affected Component : Runtime Support Libraries (RTS) Description: C6x does not provide fenv.h ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00047245 ------------------------------------------------------------------------------- Summary : C99 math.h macros not supported Affected Component : Runtime Support Libraries (RTS) Description: C99 math.h does not provide support for several macros (i.e. FLT_EVAL_METHOD, MATH_ERRNO, MATH_ERREXCEPT, FP_ILOGB0, FP_ILOGBNAN). ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00047403 ------------------------------------------------------------------------------- Summary : Compiler generates segmentation fault when double-quotes are used within C6X_C_OPTION Affected Component : C/C++ Compiler (cl) Description: The below compiles ok (even if some characters are not recognized): C:\TI\ccsv5\tools\compiler\c6000_7.4.1\bin>cl6x.exe hello.c --abi=eabi -- gcc -I="..\" while this one generates a segmentation error (probably because of the unrecognized quotes): D:\TI\ccsv5\tools\compiler\c6000_7.4.1\bin> set C6X_C_OPTION=--abi=eabi -- gcc -I="..\" E:\TI\ccsv5\tools\compiler\c6000_7.4.1\bin>cl6x.exe hello.c INTERNAL ERROR> cl6x.e experienced a segmentation fault while processing ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00047840 ------------------------------------------------------------------------------- Summary : omp for loop with unsigned short loop counter generates error message Affected Component : Parser Description: cl6x -mv6600 --abi=elfabi t.c --omp "t.c", line 8: error: syntax error in OpenMP pragma "t.c", line 8: error: syntax error in OpenMP pragma 2 errors detected in the compilation of "t.c". ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00047907 ------------------------------------------------------------------------------- Summary : Compiler not generating error message when #pragma omp parallel is placed before a variable declaration Affected Component : Parser Description: Using internal tools build. Production tools silently ignore the omp parallel pragma. cl6x -mv6600 --omp -o3 t.c "t.c", line 24: internal error: assertion failed: create_il_entry_for_pragma: invalid next_construct call (ANSI/pragma.c, line 1298) 1 catastrophic error detected in the compilation of "t.c". Compilation aborted. INTERNAL ERROR: acpia6x aborted while processing function foo1 file t.c line 25 ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049238 ------------------------------------------------------------------------------- Summary : Use of -mh=auto can cause link to fail Affected Component : C/C++ Compiler (cl) Description: Use of -mh=auto can, all on its own, cause the link to fail with a message similar to ... "link.cmd", line 76: error: program will not fit into available memory. placement with alignment fails for section ".stack" size 0x1000 . Available memory ranges: STACK size: 0x1000 unused: 0x1000 max hole: 0x1000 In this case, the --stack=0x1000 option is used to set the size of the stack. And it is allocated into a memory range named STACK that is exactly the same length. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049545 ------------------------------------------------------------------------------- Summary : Compiler mishandles near address operation under EABI Affected Component : C/C++ Compiler (cl) Description: The test case given includes ... near int Value; unsigned int test() { unsigned int addr = (unsigned int)&Value; addr += (1 << 28); return addr; } When compiled this sees an unexpected diagnostic from the assembler ... "C:\tmp\file.asm", WARNING! at line 80: [W0001] Value out of range; converted to 0 MVK .S1 $DPR_byte(Value)+268435456,A3 ; |6| No Assembly Errors, 1 Assembly Warning The compiler should never generate code which causes assembler diagnostics. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049680 ------------------------------------------------------------------------------- Summary : Need to add a _lldotp2 intrinsic to the compiler to avoid EXT instruction when using DOTP2 that writes a register pair Affected Component : Code Generator Description: The _ldotp2 intrinsic's return type is int40_t. Currently, there is no _lldotp2 intrinsic (that would return long long). When using the _ldotp2 intrinsic in order to use the DOTP2 instruction that writes a 64-bit register pair, if you want a long long result (rather than an int40_t result), the compiler will add an EXT x,24,24,y instruction after the DOTP2. It is legal for the compiler to add this EXT instruction, but unnecessary and could slightly affect performance. The compiler does this because the compiler only models _ldotp2 and not a hypothetical _lldotp2 intrinsic. To prevent this EXT instruction and to improve the programming model, the compiler should have a "long long _lldotp2(int a, int b) intrinsic (where a and b are signed packed 16-bit values). See the attached file. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049993 ------------------------------------------------------------------------------- Summary : MISRA diagnostic 12.2 does not show the source line number Affected Component : C/C++ Compiler (cl) Description: The attached test case contains this line ... while ((*d++ = *s++) && --n); This line causes MISRA diagnostic 12.2 to be issued. The problem is that the diagnostic does not show the source line number. % cl6x --check_misra=12.2 file.c Warning: (MISRA-C:2004 12.2/R) The value of an expression shall be the same under any order of evaluation that the standard permits ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050003 ------------------------------------------------------------------------------- Summary : Compiler mistakenly issues MISRA diagnostic 16.7, related to pointer function parameters Affected Component : C/C++ Compiler (cl) Description: The attached test case contains this function ... static void f(compound_t * a) { a[0].member = 1; a[1].member = 1; a[2].member = 1; a[3].member = 1; } The parameter a is a pointer to an array of structures. It is used to modify members within those structures. Nonetheless, the compiler issues the MISRA diagnostic ... "file.c", line 12: warning: (MISRA-C:2004 16.7/A) A pointer parameter in a function prototype should be declared as pointer to const if the pointer is not used to modify the addressed object ("a: const compound_t *") ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050004 ------------------------------------------------------------------------------- Summary : Compiler mistakenly issues MISRA diagnostic 9.1 regarding local variables being initialized Affected Component : C/C++ Compiler (cl) Description: The attached test case contains this function ... void a(void) { compound_t array[4]; f (array); } The type compound_t is a structure. The compiler issues this diagnostic ... "file.c", line 18: warning: (MISRA-C:2004 9.1/R) All automatic variables shall have been assigned a value before being used (variable "array") Well, it is possible the purpose of the function f() is to initialize the array. Based on what is here, there is no way to tell. ------------------------------------------------------------------------------- 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 SDSCM00050135 ------------------------------------------------------------------------------- Summary : wchar.h should not include stdio.h Affected Component : Runtime Support Libraries (RTS) Description: It is a bug for any C header file that the user includes directly to include any other file that the user might include directly, because the identifiers for the second header file are not necessarily supposed to be defined. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050657 ------------------------------------------------------------------------------- Summary : Unused label causes compiler to fail with INTERNAL ERROR: cg6x experienced a segmentation fault Affected Component : C/C++ Compiler (cl) Description: The source of the attached test case has label OUT which is never used. The compiler fails with this diagnostic ... "file.c", line 11: warning #179-D: label "OUT" was declared but never referenced INTERNAL ERROR: cg6x experienced a segmentation fault while processing function test file file.c line 8 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 ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050703 ------------------------------------------------------------------------------- Summary : Compiler auto-generates identical global symbol definition in different modules, which causes link to fail Affected Component : Parser Description: The attached test case combines together several unusual circumstances. A source file has the same name in two different directories. Each file has a line similar to ... static int var = the_user_function("argument"); This variable must be initialized before main starts running. The compiler auto- generates a function which calls the_user_function and assigns the result to the static variable. The name of this function is something like __sti___12_mysource_cpp_1b42d16c, and it is a global symbol. The exact same name is generated for both source files. Because this symbol is defined twice, the link fails. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051125 ------------------------------------------------------------------------------- Summary : Linker should emit warning that .c6xabi.exidx cannot be split across output sections Affected Component : C/C++ Compiler (cl) Description: The linker command file contains these lines ... rts_exidx { -l rts6600_elf_eh.lib(.c6xabi.exidx) } > EXT1 rts_extab { -l rts6600_elf_eh.lib(.c6xabi.extab) } > EXT1 The section rts_extab is created as expected. The section rts_exidx, however, ends up empty. The output section c6xabi.exidx ends up containing all the c6xabi.exidx input sections from both user code and the RTS library. The user is attempting to split the .c6xabi.exidx section. This index entries should be contiguous. There should be warning to inform the user that this output section cannot be split. Also, the rts_exidx is empty if the line above is modified to: rts_exidx { *(.c6xabi.exidx) } > EXT1 rts_exidx should be non-empty in this case. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051143 ------------------------------------------------------------------------------- Summary : Need compiler fix for SPLOOP-SPKERNEL-interrupt bug Affected Component : Code Generator Duplicate Defects : SDSCM00051127 Description: A compiler workaround is needed for a hardware bug involving an interrupt during SPLOOP. See details. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051234 ------------------------------------------------------------------------------- Summary : asm(" nop 5") changes position with another asm statement Affected Component : C/C++ Compiler (cl) Description: A function contains these statements ... /* Execute B NRP to re-start the whole application. */ asm(" B NRP"); asm(" NOP 5"); But the assembly output for these lines is ... NOP 5 B NRP Note how the NOP instruction moved.