C6000 C/C++ CODE GENERATION TOOLS 8.1.1 May 2016 Defect History ------------------------------------------------------------------------------- Table of Contents ------------------------------------------------------------------------------- 1. Defects fixed in C6000 Code Generation Tools release 8.1.1 2. Current Known Issues =============================================================================== 1. Defects fixed in C6000 Code Generation Tools release 8.1.1 =============================================================================== The following 7 defects were fixed in C6000 Code Generation Tools release 8.1.1, released May 2016. ------------------------------------------------------------------------------- FIXED SDSCM00052529 ------------------------------------------------------------------------------- Summary : Optimizer assumes enum variable can only have value of enumeration constants Fixed in : 8.1.1 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00048886 Release Notes: If an enumerated type is defined to have only two constants that evaluate to 0 and 1, then the compiler will assume that only those two values are possible. However, the C++ and C standards allow variables of enumerated types to hold other values as well; if other values are used, the compiler may produce incorrect code. Workaround: Don't make enumerated types with constants only for 0 and 1 if other values may be used. Either add a third value, or use values different than 0 and 1, or avoid using values that aren't the enumeration constants. ------------------------------------------------------------------------------- FIXED SDSCM00052699 ------------------------------------------------------------------------------- Summary : Compiler discards write to a volatile local struct member Fixed in : 8.1.1 Severity : S2 - Major Affected Component : Optimizer Release Notes: When volatile appears in a struct definition ... struct device { volatile unsigned tcc; } dev; The compiler doesn't honor it. References to dev.tcc still get optimized away. Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00052721 ------------------------------------------------------------------------------- Summary : lnk6x automatic RTS selection does not work when thread-safe version of RTS is needed Fixed in : 8.1.1 Severity : S2 - Major Affected Component : ELF Linker Release Notes: The autoselection of a thread-safe RTS library was coupled to the use of OpenMP. If the --openmp compiler option is specified on one of the source files, this will insert the appropriate advisory build attribute into the compiler generated object file so that the linker will resolve a reference to libc.a using a thread-safe version of the RTS library. Workaround: Explicitly specify the thread-safe version of the RTS library that is to be included in the link instead of using libc.a on the link command line or in the linker command file. ------------------------------------------------------------------------------- FIXED SDSCM00052805 ------------------------------------------------------------------------------- Summary : Decomposition error on while(*ptr++) where ptr points to volatile Fixed in : 8.1.1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The while(*ptr++) loop where ptr points to volatile is handled incorrectly by the code generation tool. Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00052833 ------------------------------------------------------------------------------- Summary : Linker INTERNAL ERROR with object files with DWARF information compiled by IAR compiler Fixed in : 8.1.1 Severity : S2 - Major Affected Component : Linker Release Notes: The IAR compiler generates some DWARF debugging entries that the TI linker does not handle correctly. In some cases, the TI linker may crash with a segmentation fault or other internal error. Workaround: Add option --compress_dwarf=off ------------------------------------------------------------------------------- FIXED SDSCM00052887 ------------------------------------------------------------------------------- Summary : Compiler produces incorrect code for C674x at -O2 Fixed in : 8.1.1 Severity : S2 - Major Affected Component : Optimizer Release Notes: No Information Available; please see defect details. Workaround: Place #pragma UNROLL(1) immediately before the loop ------------------------------------------------------------------------------- FIXED SDSCM00052889 ------------------------------------------------------------------------------- Summary : uint16_t value not truncated as it ought to be in if test using -O2 Fixed in : 8.1.1 Severity : S2 - Major Affected Component : Code Generator Release Notes: No Information Available; please see defect details. Workaround: None. =============================================================================== 2. Current Known Issues =============================================================================== The following 33 known issues exist for C6000 Code Generation Tools release 8.1.1 as of May 2016. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008248 ------------------------------------------------------------------------------- Summary : Compilers on PC will not work without TMP set Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00034609 Description: When compiling on the PC, the code generator cannot find the icode file produced by the parser if the environment variable TMP is no set. If TMP is set, then all appears well. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008465 ------------------------------------------------------------------------------- Summary : Language Conformance: crash because of void pointer dereference Affected Component : Parser Description: Compiler generates multiple INTERNAL ERRORs when code like the following is compiled: void dr106_1(void *pv, int i) { *pv; i ? *pv : *pv; *pv, *pv; } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008534 ------------------------------------------------------------------------------- Summary : Linker -xml_link_info option doesn't work when in a command file Affected Component : Linker Description: The option --xml_link_info=file.xml does not work when it is placed inside a linker command file. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008537 ------------------------------------------------------------------------------- Summary : assembler expression ~(0x80000000) evaulates as 0x80000000 Affected Component : Assembler Description: The following expression is evaluating incorrectly in the assembler: .eval ~(0x80000000), mask mask ends up getting assigned 0x80000000, whereas I expect it to be 0x7FFFFFFF. It seems that any constant with bit 31 set will incorrectly return 0x80000000 ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008543 ------------------------------------------------------------------------------- Summary : Forward reference in .space generates an internal error Affected Component : Assembler Description: If you attempt to assemble: .space 0+a b a .set 1 the assembler will generate an internal error. This happens with v3.83 and v4.1.0B1 on Solaris. If you change the code to: .space a b b .set 1 the correct error message is generated, 'Absolute, well-defined integer value expected'. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008685 ------------------------------------------------------------------------------- Summary : DWARF does not correctly represent variables stored in register pairs Affected Component : Code Generator Description: In the attached example, variables 'var1' and 'var2' are both long long types, and are stored in A7:A6 and B5:B4. However, the DWARF information shows var1 only to be in A6, and var2 only to be in B4: [000000e8] DW_TAG_variable DW_AT_name var1 DW_AT_symbol_name _var1 DW_AT_type [00000113] DW_AT_location { DW_OP_reg6 } [000000fa] DW_TAG_variable DW_AT_name var2 DW_AT_symbol_name _var2 DW_AT_type [00000113] DW_AT_location { DW_OP_reg20 } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008928 ------------------------------------------------------------------------------- Summary : Extern inline functions are not supported in the C/C++ Compiler Affected Component : Parser Duplicate Defects : SDSCM00018364 Description: Users cannot create global accessible code with INLINE functions. The V3.00 compiler/code generator does not create globally accessible code for functions which are declared inline. A simple example is: inline int x() { return 1; } int y() {return 2;} When compiled with 'cl6x -k -c test.c', a warning is produced: 'test.c', line 1: warning: function 'x' was declared but never referenced and the resulting assembler file (test.asm) does not contain any code for x(). The documentation states that code declared inline will be inlined in that module but global code will also be generated (section 2.10.3.2 in v3.00 C Compiler manual). The new compiler is overly aggressive in its optimizations. If y() is modified to call x() then code is generated for x() unless the optimizer is also invoked (by using -x2). ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00014430 ------------------------------------------------------------------------------- Summary : calloc doesn't check arguments to make sure the requested size is reasonable Affected Component : Runtime Support Libraries (RTS) Description: The function calloc() is required to return a pointer to memory representing "nelem" copies of "size" bytes, or NULL if the request cannot be satisfied. However, for some values of "nelem" and "size" (specifically when the result of nelem*size wraps around), calloc can return a pointer to an object that is not large enough, rather than NULL. For example, on a 32-bit target, if the user calls calloc(0x00010001, 0x00010001), even though each argument by itself is reasonable, the request cannot be satisfied because the product is 0x000100020001, which exceeds size_t. (Note that we cannot check for overflow by checking if the product is less than either argument, which is commonly done for unsigned addition.) Arguably, we can try to claim that it is undefined behavior to make a call to calloc where the product would exceed size_t, but there doesn't seem to be anything in the standard which says so. The problem is worse on 16-bit targets, where calloc(0x0101, 0x0101) is enough to overflow size_t. It may not be obvious to the user that this overflows. Another concern is that it is hard to figure out whether a multiplication will overflow without having a double-width multiply available. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00018691 ------------------------------------------------------------------------------- Summary : Linker gives misleading warning when dot expressions used in SECTION directive for .stack section Affected Component : Linker Description: Linker gives the warning: warning: creating ".stack" section with default size of 0x800; use the -stack option to change the default size even when the application does not link in boot code from RTS lib. A linker command file is used that contains a specialized SECTION directive for the ".stack" section. Because of a series of ". += " assignments in the section spec, the linker is forced to increase the size of the .stack section to 0xc00. The linker is doing the correct thing by making a .stack section large enough to accommodate the dot expressions, but the diagnostic is misleading, as 0x800 isn't the final size of the .stack section. ------------------------------------------------------------------------------- KNOWN ISSUE 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 SDSCM00031374 ------------------------------------------------------------------------------- Summary : C6x 6.1.6 performance degradation compared with 6.0.14 Affected Component : C/C++ Compiler (cl) Description: Details of performace drop can be found the attached Email ------------------------------------------------------------------------------- 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. 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 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 SDSCM00049284 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 10.1 Affected Component : Parser Description: Compiler misreports MISRA warning 10.1/R for the following code. typedef enum _MyEnum { One, Two } MyEnum; MyEnum MyVariable; int foo(void) { int result = 1; if (One == MyVariable) // fails here with MISRA-C:2004 10.1/R { result = 2; } return result; } ------------------------------------------------------------------------------- KNOWN ISSUE 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 SDSCM00051300 ------------------------------------------------------------------------------- Summary : Array with many dimensions hangs parser Affected Component : Parser Description: Trying to declare an array with many dimensions, but still of legal size, apparently hangs the parser. This appears to be exponential growth and not necessarily indefinite runtime. This happens in TYPE::qual_kind() when pushing the qualifiers on arrays down to the array element. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051481 ------------------------------------------------------------------------------- Summary : MISRA 10.1/10.2 don't understand pointers to float types Affected Component : Parser Description: The parser incorrectly gives both a MISRA 10.1 and 10.2 warning for code that passes a pointer to a float to a function which expects the same type.