C6000 C/C++ CODE GENERATION TOOLS 8.0.0 September 2014 Defect History ------------------------------------------------------------------------------- Table of Contents ------------------------------------------------------------------------------- 1. Defects fixed in C6000 Code Generation Tools release 8.0.0 2. Defects fixed in C6000 Code Generation Tools release 8.0.0B4 3. Defects fixed in C6000 Code Generation Tools release 8.0.0B3 4. Defects fixed in C6000 Code Generation Tools release 8.0.0B2 5. Defects fixed in C6000 Code Generation Tools release 8.0.0B1 6. Current Known Issues =============================================================================== 1. Defects fixed in C6000 Code Generation Tools release 8.0.0 =============================================================================== The following 3 defects were fixed in C6000 Code Generation Tools release 8.0.0, released September 2014. ------------------------------------------------------------------------------- FIXED SDSCM00050597 ------------------------------------------------------------------------------- Summary : Backward reference to array-in-struct may miss an alias Fixed in : 8.0.0 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 SDSCM00050713 ------------------------------------------------------------------------------- Summary : Optimization level -o3 inlines weak function body Fixed in : 8.0.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: A function declared as weak may be inlined, which is incorrect because the linker may override the weak definition later. Defect occurs in C6000 Compiler versions: 7.6.0B1 - 7.6.0, 8.0.0B1 - 8.0.0B4 Workaround: Use the FUNC_CANNOT_INLINE pragma to directly inhibit inlining. ------------------------------------------------------------------------------- FIXED SDSCM00050763 ------------------------------------------------------------------------------- Summary : Only the C6000 compiler accepts the GCC builtin function __builtin_constant_p Fixed in : 8.0.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Error emitted that GNU __builtin_constant_p function not supported. Workaround: None. =============================================================================== 2. Defects fixed in C6000 Code Generation Tools release 8.0.0B4 =============================================================================== The following defect was fixed in C6000 Code Generation Tools release 8.0.0B4, released September 2014. ------------------------------------------------------------------------------- FIXED SDSCM00050677 ------------------------------------------------------------------------------- Summary : Using --opt_level=1 or higher causes compiler to fail with INTERNAL ERROR: >>>Register allocation failed Fixed in : 8.0.0B4 Severity : S2 - Major Affected Component : Code Generator Release Notes: Floating point registers are causing INTERNAL ERROR: register allocation failure. Workaround: Use _itof and _ftoi intrinsics =============================================================================== 3. Defects fixed in C6000 Code Generation Tools release 8.0.0B3 =============================================================================== The following defect was fixed in C6000 Code Generation Tools release 8.0.0B3, released August 2014. ------------------------------------------------------------------------------- FIXED SDSCM00050365 ------------------------------------------------------------------------------- Summary : openMP parser emit error message for #pragma omp critial (name) Fixed in : 8.0.0B3 Severity : S2 - Major Affected Component : Parser Release Notes: Parser does not process OpenMP critical pragma properly. 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. =============================================================================== 4. Defects fixed in C6000 Code Generation Tools release 8.0.0B2 =============================================================================== The following 3 defects were fixed in C6000 Code Generation Tools release 8.0.0B2, released July 2014. ------------------------------------------------------------------------------- FIXED SDSCM00050243 ------------------------------------------------------------------------------- Summary : Scary but harmless warning: FAILURE in mark_use_of_function_local_static() Fixed in : 8.0.0B2 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 SDSCM00050520 ------------------------------------------------------------------------------- Summary : strip crashes on files with more than 64k sections Fixed in : 8.0.0B2 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 : 8.0.0B2 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 8.0.0B1 =============================================================================== The following 3 defects were fixed in C6000 Code Generation Tools release 8.0.0B1, released July 2014. ------------------------------------------------------------------------------- FIXED SDSCM00047517 ------------------------------------------------------------------------------- Summary : Complex math operations are inefficient Fixed in : 8.0.0B1 Severity : S2 - Major Classification : Performance Affected Component : C/C++ Compiler (cl) Release Notes: Improvements to the speed of C99 float complex will be appearing in v8.0 of the C6000 compiler. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00050405 ------------------------------------------------------------------------------- Summary : Incorrect error message when combining #pragma PERSISTENT and DATA_SECTION Fixed in : 8.0.0B1 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: The error message mentions noinit when it should say persistent instead. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00050535 ------------------------------------------------------------------------------- Summary : Compiler does not accept documented option --c++03 Fixed in : 8.0.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Compiler emits a fatal error when --c++03 option is encountered on the command line. The --c++03 option is deprecated and will be interpreted as an alias for the --c++ option. Workaround: Use the --c++ option instead. =============================================================================== 6. Current Known Issues =============================================================================== The following 21 known issues exist for C6000 Code Generation Tools release 8.0.0 as of September 2014. ------------------------------------------------------------------------------- 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 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 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 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. The C6000 RTS function rounds differently than the hardware. ------------------------------------------------------------------------------- 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 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 SDSCM00047568 ------------------------------------------------------------------------------- Summary : Disassembler fails to disassemble DPINT DPTRUNC DPSP Affected Component : Disassembler (dis) Description: The disassembler disassembles valid DPINT, DPTRUNC, and DPSP instructions as .word ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00048083 ------------------------------------------------------------------------------- Summary : %#x should not prefix 0x to a zero value Affected Component : Runtime Support Libraries (RTS) Description: C99 7.19.6.1 ("fprintf") says that with '#', "For x (or X) conversion, a nonzero result has 0x (or 0X) prefixed to it." However, we prefix the 0x even for zero values. Most other compilers do not prefix the 0x for a zero value. Strictly speaking, what we do could be argued to be conforming, but we really should just do what other compilers do. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00048582 ------------------------------------------------------------------------------- Summary : Use of short form of options in C_OPTION may cause spurious warning Affected Component : ELF Linker Description: If the C_OPTION environment variable is set with the short form of an option, the compiler will sometimes emit a warning that the option is invalid for the linker and will be ignored. To recreate: setenv C_OPTION -pden bugslayer --t C6000 CQ10569 You will see: cl6x -mv6400 --abi=coffabi ... >> WARNING: invalid linker option -pden (ignored) ------------------------------------------------------------------------------- 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.