C6000 C/C++ Code Generation Tools v8.3.7 Release Notes

Table of Contents

1 Support Information

1.1 List of Resolved and Known Defects

Resolved defects

ID Summary
CODEGEN-7227 Compiler incorrectly optimizes unsigned loop counter which wraps around
CODEGEN-7146 Compiler loses conversion to size_t in length argument to memcpy
CODEGEN-7011 Compiler intermittently fails with INTERNAL ERROR: optimizer experienced a segmentation fault
CODEGEN-6914 Enum type with no enumerators fails to emit DW_AT_byte_size, crashes CCS
CODEGEN-6866 Compiler computes wrong offset for structure member, causing CCS to display it incorrectly
CODEGEN-6810 Parser failure with nested lambdas
CODEGEN-6783 Ensure C std headers do not issue MISRA warnings
CODEGEN-6757 Use of C++ lambda causes Dwarf debug information to be incorrect, and prevents debugging the code
CODEGEN-6581 Optimizer fails with segmentation fault
CODEGEN-6476 switch statement where controlling expression is C++ scoped enum with underlying type smaller than int crashes compiler unless optimization is used
CODEGEN-6452 Initializing function objects causes compilation to take much longer
CODEGEN-6419 Compiler may crash if two thread-local accesses in one function are separated by a function call
CODEGEN-6289 Pointer to VLA 2D array computation in IF condition is double-adjusted and garbled
CODEGEN-6132 pdd tool fails when program includes unused file
CODEGEN-6130 deque push_back of structure larger than 64-bytes tries to write to invalid memory location
CODEGEN-6004 OFD erroneously prints 0x<decimal> where hex was intended
CODEGEN-5986 Compiler may crash when auto as return type of uninstantiated member function in template class resolves to template parameter
CODEGEN-5943 Compiler may lose volatile qualifier in A->B->C when B and C are both volatile
CODEGEN-5905 Linker command file option –define with pathname with many directory components leads to error: “source line too long”
CODEGEN-5903 Using –openmp:device and an improperly-declared target variable causes C6000 compiler to fail with INTERNAL ERROR: acpia6x experienced a segmentation fault
CODEGEN-5843 Use of –check_misra=14.10 causes non-MISRA related warning to be emitted
CODEGEN-5791 C++ enum class with explicit type has some problems
CODEGEN-5778 Duplicate definitions of ldexp and ldexpl
CODEGEN-5777 Compiler schedules an M-unit instruction too soon after MPYSP2DP or MPYSPDP
CODEGEN-5623 Makefile dependence generation (–preproc_dependency) should quote spaces in filenames
CODEGEN-5574 Loop controlled by unsigned char counter iterates more than 255 times
CODEGEN-5569 C++ constructor which uses volatile causes compiler to crash
CODEGEN-5563 Checking for MISRA rule 20.1 causes macro redefinition to be ignored
CODEGEN-5533 Loop with Cortex-R, -mf3, and DWARF debug leads to assembler error “defined differently in each pass”
CODEGEN-5527 Local structure initialization is incorrectly optimized away
CODEGEN-5486 Global constexpr class errors out when assigning to member data
CODEGEN-5450 Compiler mistakenly parallelizes MPYSPDP with single-cycle write of its SP input
CODEGEN-5236 Register allocation failure
CODEGEN-5164 Under –speculate_loads=auto, linker creates zero-filled fill sections instead of reducing the size of the corresponding memory range
CODEGEN-5119 Using #pragma RETAIN does not keep a static file level variable
CODEGEN-5040 –c64p_dma_l1d_workaround is missing from 8.x compilers
CODEGEN-5033 Functions in <string> incorrectly return NULL
CODEGEN-4931 Applying attribute((used)) to static variable does not work
CODEGEN-4885 See MISRA diagnostics when compiling stdio.h
CODEGEN-4700 Incorrect diagnostic when using macro that comes from macro library
CODEGEN-4668 Macro with temp label causes assembler to crash
CODEGEN-4634 Use of stdarg.h va_start macro causes a write to the wrong local variable
CODEGEN-4621 Remove COFF global linker symbols from documentation for ELF-only targets
CODEGEN-4600 Warning when using pragma RETAIN with attribute((noinit))
CODEGEN-4548 Compiler manual incorrectly spells option –disable_software_pipelining. It is spelled –disable_software_pipeline.
CODEGEN-4525 Unreachable code in linear assembly may lead to crash
CODEGEN-4113 Assembler computes wrong result for expression 0x232800 % 0x10000
CODEGEN-4078 Linker takes over 5 minutes to finish
CODEGEN-3931 Compiler crashes while handling 0 length array in zero sized struct
CODEGEN-3918 Writing multiple input sections in one line unexpectedly changes how input sections are combined into output sections
CODEGEN-3797 Documentation should state that users must use far keyword when declaring C/C++ data symbols defined by the linker
CODEGEN-3613 Some vector types computations are not carried out
CODEGEN-2346 Compiler produces incorrect code at -o2 optimization
CODEGEN-2286 palign(8) of .init_array messes up __TI_INITARRAY_Limit address
CODEGEN-2113 Hex utility mishandles space in directory name of output file
CODEGEN-1979 Statements before declarations with no white space (aggravated by macros) may cause incorrect parser error
CODEGEN-1154 ltoa definition conflicts with quasi-standard ltoa
CODEGEN-848 Local struct with non-constant initializer treated as static scope variable
CODEGEN-260 XML output needs encoding specification

Open defects

ID Summary
CODEGEN-7337 Compiler incorrectly issues remark: value copied to temporary, reference to temporary used
CODEGEN-6929 Compiler generates many more single cycle NOP instructions
CODEGEN-6662 C6000: callstack replicates caller function indefinitely when Step Into/Over
CODEGEN-6509 Compiler error: no instance of function template matches the argument list
CODEGEN-6296 Unexpectedly large loop-carried dependence bound in loop that touches struct containing array
CODEGEN-4942 Conditional clause function call with GCC statement argument causes compiler crash
CODEGEN-1489 lnk6x emits warnings about .tdata and .tbss when .TI.tls specification is present in a linker command file
CODEGEN-1013 Array with many dimensions hangs parser
CODEGEN-793 Ill advised enum scalar usage gets MISRA diagnostic, but similar usage of enum array does not
CODEGEN-792 Array that is correctly initialized erroneously gets a MISRA diagnostic about size not being specified
CODEGEN-766 Use of short form of options in C_OPTION may cause spurious warning
CODEGEN-750 %#x should not prefix 0x to a zero value
CODEGEN-747 Should reject certain unitless instructions in parallel with certain other instructions
CODEGEN-696 Disassembler fails to disassemble DPINT DPTRUNC DPSP
CODEGEN-676 C99 math.h macros not supported
CODEGEN-675 C99 header file fenv.h not supported
CODEGEN-674 isunordered not supported
CODEGEN-651 Hex converter map file does not list all sections for RAM model program with initialized sections with .cinit records
CODEGEN-650 Hex converter fails to process RAM model .cinit records for initialized sections
CODEGEN-633 Floating point addition rounding error
CODEGEN-631 pow(min, max) and pow(max, max) incorrect
CODEGEN-630 global labels defined in .cproc region are discarded
CODEGEN-606 When failing to place a section, include size of trampolines in error message
CODEGEN-581 RTS float arithmetic functions rounding error
CODEGEN-367 modf(-Inf, 1.0) with -mv6740 enters infinite loop
CODEGEN-322 Structure is not initialized correctly when using -o2 or -o3 optimization
CODEGEN-292 When building with -o2, compiler sometimes fails to complete compilation
CODEGEN-115 compiler is scheduling use of A8 too early causing an incorrect branch
CODEGEN-104 Linker gives misleading warning when dot expressions used in SECTION directive for .stack section
CODEGEN-63 DWARF does not correctly represent variables stored in register pairs
CODEGEN-56 Forward reference in .space generates an internal error
CODEGEN-30 Compilers on PC will not work without TMP set

1.2 Compiler Wiki

A Wiki has been established to assist developers in using TI Embedded Processor Software and Tools. Developers are encouraged to read and contribute to the articles. Registered users can update missing or incorrect information. There is a large section of compiler-related material. Please visit:

https://processors.wiki.ti.com/index.php?title=Category:Compiler

1.3 Compiler Documentation

The “TMS320C6000 Optimizing Compiler User’s Guide” can be downloaded from:

https://www.ti.com/tools-software/compilers/download.html

Navigate to the C6000 Code Generation Tools section to view the user guide in HTML or PDF format.

1.4 TI E2E Community

Questions concerning TI Code Generation Tools can be posted to the TI E2E Community forums. The Code Composer Studio support forum can be found at:

https://e2e.ti.com/support/tools/ccs/f/81

1.5 Defect Tracking Database

Issues filed against the TI compilers can be searched in the Code Generation Tools Defect Database.

2 C++ 2014 support

As of v8.3, the compiler supports the C++14 version of the C++ standard. C++03 is no longer supported. See the C++14 Standard ISO/IEC 14882:2014. For a description of unsupported C++ features, see Section 7.2 of the “TMS320C6000 Optimizing Compiler User’s Guide”.

The move to C++14 will break ABI compatibility with previous C++ RTS releases. Attempting to link old C++ object code with the new RTS will result in a link-time error. Suppressing this error will likely result in undefined symbols or undefined behavior during execution.

C ABI compatibility will not be affected by this change.

In most cases, recompiling old source code with the new RTS should be safe. However, due to the changes made in the language, some constructs will result in syntax errors. Some common issues include:

A full list can be found in Appendix C, section 2 of the C++14 standard.

3 Printf Support for Vector Data Types

As of v8.3, the printf() function included it the RTS supports vector data types. The convention set by OpenCL 1.2 as documented in Section 6.12.13 of the OpenCL 1.2 standard is followed with one exception. This exception is to do with use of ll instead of l in the format string for longlong vector conversions.

Example:

float4 f = (float4)(1.0f, 2.0f, 3.0f, 4.0f); uchar4 uc = (uchar4)(0xFA, 0xFB, 0xFC, 0xFD);

printf(“f4 = %2.2v4hlf\n”, f); printf(“uc = %#v4hhx\n”, uc);

/* Output: */ f4 = 1.00,2.00,3.00,4.00 uc = 0xfa,0xfb,0xfc,0xfd

4 Use of Vector Data Types no longer requires optimizer

Usage of vector data types previously required the optimizer. As of v8.3, use of the optimizer is no longer required i.e. the –vectypes option can be used without specifying a -o[0-3] option.

5 Compiler Option –legacy

As of the 8.2.2 release, a compiler option, –legacy, has been added. When legacy code bases tuned for C6000 CGT v7.4.x or older exhibit performance degradations (cycles or code size) with later compiler versions, this option may help. Do not use this option in new applications. Any new features added to newer tool chains will not be available when the –legacy option is used.

6 New Linker Feature: Using memory for multiple purposes

As of v8.3, this feature enables overlaying an initialized section with the same load and run address with other sections that have separate load and run addresses.

One way to reduce memory required is to use the same range of memory for multiple purposes. It is possible to use a range of memory at first for system initialization and startup. Once that phase is complete, the same memory can then be repurposed as a collection of uninitialized data variables, or a heap. To implement this scheme, use the variation of UNION which allows one section to be initialized, and the remaining sections to be uninitialized.

Generally, an initialized section (one with raw data, such as .text) in a union must have its load allocation separately specified. However, one and only one initialized section in a union can be allocated at the union’s run address. By listing it in the union with no load allocation at all, it will use the union’s run address as its own load address.

For example:

UNION run = FAST_MEM

{ .cinit .bss }

.cinit is an initialized section. It will be loaded into FAST_MEM at the run address of the union. .bss is an uninitialized section. Its run address will also be that of the union.

7 New Linker Option –ecc

In previous versions, linker generated ECC has been enabled via an ECC specifier on memory ranges in the linker command file. This makes it difficult for TI to provide linker command files with ECC specified because users need the ability to enable/disable the support.

Starting with v8.3, users can enable/disable ecc support via the –ecc=[on|off] linker option. Existing users of ECC will need to specify –ecc=on

8 New Function Inlining Control Pragmas

Three new pragmas to control function inlining were added in this version:

a) The FORCEINLINE pragma will force functions to be inlined in the annotated statement i.e., it has no effect on those functions in general, only on function calls in a single statement.

b) The FORCEINLINE_RECURSIVE pragma will force inlining not only of calls visible in the statement, but also in the inlined bodies of calls from that statement.

c) The NOINLINE pragma prevents calls within a single statement from being inlined. (NOINLINE is the inverse of the FORCEINLINE pragma.)

9 Bug related to restrict pointers fixed

A bug that could propagate a restrict pointer into a disjoint scope (e.g., an inlined function) and make a wrong decision about memory disambiguation was fixed.

The fix may cause performance degradations when a restrict pointer is passed into an inlined function.

Based on the definition of ‘restrict’, ‘restrict’ means within the scope of the declaration of a pointer P. Only P or expressions based on P will be used to access the object or sub-object pointed to by P. A pointer copy of another restrict pointer can inherit the restrictness only when they are in the same scope or nested scopes.

For example:

int x[100]; void test() { int restrict p1; int restrict p2;

p1 = x; p2 = x+1;

foo(p1); bar(p2); }

void foo(int* r1) { *(r1+1) = 0; return; }

void bar(int* r2) { *r2 = 1; return; }

After inlining foo() and bar(), we have:

void test() { int restrict p1; int restrict p2;

p1 = x; p2 = x+1;

{// inlined function f00() int r1 = p1; (r1+1) = 0; }

{// inlined function bar() int r2=p2; r2 = 1; } }

Previous versions of the compiler might propagate p1 and p2 for r1 and r2, and incorrectly determine that (r1+1) and r2 do not alias.

This fix may cause performance degradations when pointers in disjoint scopes actually do not access the same memory locations, because the compiler has to assume that alias exists.