Test Readme for C6000 Code Generation Tools v8.3.12

Table of Contents

1 Support Information

1.1 List of Resolved and Known Defects

Resolved defects

ID Summary
CODEGEN-9599 Some compiler diagnostic ID numbers changed in releases after 2019
CODEGEN-9399 Temp file name collision causes compilation failure at –opt_level=4
CODEGEN-9082 Optimizer drops part of a compound conditional expression controlling a loop

Known defects

The up-to-date known defects in v8.3.12 can be found here (dynamically generated):

Known defects in v8.3.12

1.2 Compiler Documentation

The “TMS320C6000 Optimizing Compiler User’s Guide” and the “TMS320C6000 Assembly Language Tools User’s Guide” can be downloaded from:

https://www.ti.com/tool/C6000-CGT

1.3 TI E2E Community

Questions concerning TI Code Generation Tools can be posted to the TI E2E Community forums: https://e2e.ti.com/

1.4 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.

10 MISRA-C 2004 Support Deprecation

Starting with C6000 CGT v8.3.9, MISRA-C 2004 checking support has been deprecated. The existing MISRA checking functionality will remain in further patch versions of this compiler stream as is, but no further issues will be addressed.

11 New command-line option to suppress specific kind of speculation

Starting with C6000 CGT v8.3.12, a new command-line compiler option has been added to this patch release of the compiler. --assume_control_regs_read will tell the compiler that the control registers that contain floating-point status bits and saturation status bits may be read by the program. This tells the compiler not to speculate instructions that may set any one of these status bits.

Under normal operation (when this option is not specified), the compiler is allowed to speculate instructions that may set control status bits if those status bits are not explicitly read by the program in the enclosing function. See the C6000 C/C++ Compiler User’s Guide (sprui04), section 8.6.15 for more information on default behavior of the compiler.

12 Diagnostic number changes

v8.3.12 change:

In July 2019, a change to the compiler inadvertently caused some existing diagnostic numbers to change. Starting with C6000 CGT v8.3.12, the compiler uses the previous (pre July 2019) diagnostic numbering. If you are working with a compiler released after July 2019, and you are using compiler options that control compiler diagnostics (for example, the compiler option –diag_suppress), you may need to adjust the compiler diagnostic number parameter by lowering the diagnostic number by 1 to match the corrected numbering. This change will not be necessary for most diagnostic numbers.

For example, –diag_suppress 2681 should now be written as –diag_suppress 2680.