Readme for C6000 Code Generation Tools v.8.5.0

Table of Contents

0 Introduction to the C7000 Code Generation Tools v8.5.x LTS

This C6000 compiler release is a “Long-Term Support” (LTS) release.

For definitions and explanations of STS, LTS, and the versioning number scheme, please see SDTO Compiler Version Numbers

The previous release stream, v8.3.x, will remain active for two additional years after the release of v8.5.0.LTS. In July 2027, the v8.3.x release stream will become inactive.

1 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

2 TI E2E Community - Where to get help

Post compiler related questions to the TI E2E design community forum and select the TI device being used.

If submitting a defect report, please attach a scaled-down test case with command-line options and the compiler version number to allow us to reproduce the issue easily.

The following is the top-level webpage for all of TI’s Code Generation Tools.

3 Defect Tracking Database

Compiler defect reports can be tracked at the Development Tools bug database, SIR. SIR is a JIRA-based view into all public tools defects.

A my.ti.com account is required to access this page. To find an issue in SIR, enter your defect id in the top right search box once logged in. Alternatively from the top red navigation bar, select “Issues” then “Search for Issues”.

4 2014 version of the C++ language (C++14)

As of v8.3, the compiler supports ISO/IEC 14882:2014, the 2014 version of the C++ language standard, known as C++14. C++03 is no longer supported. 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 the run-time support library provided with older versions; you should recompile C++ object files compiled with a version of the C6000 compiler before 8.3.0. 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.

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

6 New Function Inlining Control Pragmas

Three new pragmas to control function inlining were added in v8.3:

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

7 2011 version of the C language (C11)

As of v8.5, the compiler supports ISO/IEC 9889:2011, the 2011 version of the C language standard, known as C11. Compiling with the –c11 option causes the compiler to conform to C11. The compiler supports some features of C11 in the default relaxed ANSI mode. C ABI compatibility will not be affected by this change.

C11 _Atomic, stdatomic.h and threads.h are not supported.

For a description of unsupported C features, see Section 7.2 of the “TMS320C6000 Optimizing Compiler User’s Guide”.

8 Floating-point status flags and SAT status flag changes

Starting with C6000 CGT v8.5.0, the compiler and run-time support library support checking the FAUCR DIV0 flags (FAUCR.S1.DIV0 and FAUCR.S2.DIV0) to detect floating-point division by zero. To use this feature, you must compile your entire application with the --assume_control_regs_read command-line option. Then you may read these flags at any point, even after the run-time library division function has returned.

The --assume_control_regs_read command-line option was introduced in v8.3.12. This option tells the compiler that the control/status registers that contain floating-point status flags and saturation status flags may be read sometime later in the program after the current function returns. This means that the compiler is only allowed to perform transformations which don’t change when and where status flags are raised. For example, consider an RCPSP instruction inside an if statement which checks if the argument is equal to zero, avoiding the RCPSP. Without this option, the compiler could arrange the RCPSP instruction to execute unconditionally earlier in the function if doing so makes the function faster, intending to just discard the result if the condition ends up being false. However, RCPSP has the side effect of raising DIV0 if its operand is equal to zero, which is undesirable if DIV0 is going to be read later.

The default behavior is that the compiler may perform such transformations unless the control/status registers are explicitly read in the same function invocation in which they are set. Using the the --assume_control_regs_read option option lets you examine the flags after the function has returned. See the C6000 C/C++ Compiler User’s Guide (sprui04), section 8.6.15 for more information on default behavior of the compiler.

Before v8.5.0, these flags would have an indeterminate value and could not be relied upon if not read before the function returns. These flags were not raised when floating-point division by zero occurred, and could be raised in library function where they should not have been, specifically sqrt and sqrtf.

This only applies to versions of the hardware that have hardware floating-point instructions such as C6740 and C6600. For versions of the hardware that do not support floating-point hardware, the compiler does not provide any way to detect division by zero.

Even versions of the hardware that have hardware floating-point instructions do not have a hardware instruction for floating-point division, so it has to be emulated with a library helper function. Starting with v8.5.0, these helper functions have been modified to raise one or both of the status flags FAUCR.S1.DIV0 and FAUCR.S2.DIV0 when the program attempts to divide any floating-point number by a value equal to zero. It is not specified which of these two flags is raised; a program which needs to check for floating-point division by zero must check both. Both the float and double versions of the helper function now support DIV0. Note that DIV0 is actually raised by the RCPSP, RCPDP, RSQRSP, and RSQRDP instructions when used with an operand equal to zero, so if you use any of these instructions or the corresponding intrinsics, you must lower both DIV0 flags manually before performing division in order to be able to rely on the flags.

The run-time support library is now compiled with the --assume_control_regs_read command-line option. This prevents sqrt and sqrtf, which use RSQRDP and RSQRSP respectively, from inadvertently raising either DIV0 flag when the argument to sqrt or sqrtf is equal to zero.

This support for detecting floating-point division-by-zero can help you detect other floating-point exceptions such as overflow, overflow, and invalid operations, assuming you use the --assume_control_regs_read command-line option. However, the TI compiler does not support a “strict” floating-point exceptions mode, so the compiler may still perform transformations like constant folding that may introduce or eliminate other floating-point exceptions, especially underflow and inexact. The compiler will not perform transformations which would introduce a division-by-zero. The compiler does have an –fp_mode=strict option, but it does not include strict floating-point exceptions.

9 Resolved defects

Resolved defects in v8.5.0:

ID Summary
CODEGEN-13454 Compiler generates bad code for logical or expression containing two uses of the same boolean value
CODEGEN-13324 symbol table entry for the compiled file should indicate source file name but instead has either a temp file name or the file's assembly file name
CODEGEN-12663 Compiler may generate incorrect code for ternary max idiom with integers
CODEGEN-12282 Missing warning for C89 with integer literal too large for long
CODEGEN-12112 attribute constructor does not support optional priority input but silently accepts it
CODEGEN-10306 For EABI cinit copy “compression”, the linker incorrectly sets the number of bytes to copy for smaller copy initialization sizes
CODEGEN-9407 Flexible array of structs does not correctly initialize last element with implicitly initialized struct members.
CODEGEN-8880 Vector accesses in for loops may generate incorrect results
CODEGEN-8580 Documentation of intrinsic _dmvd shows incorrect arguments, both should be int
CODEGEN-8440 Compiler does not account for wraparound when different increment type added to signed int
CODEGEN-8177 Change documentation of –symbol_map
CODEGEN-7536 C6000: Compiler manual incorrectly states the arguments to _ssub2 intrinsic are unsigned
CODEGEN-6501 memory allocation functions do not robustly handle case of –heap_size=0

10 Known defects

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

Known defects in v8.5.0

End Of File