TI Arm Clang Compiler Tools - 3.2.0.LTS Release Notes

Table of Contents

Introduction

Version 3.2.0.LTS of the TI Arm Clang Compiler Tools, also known as the tiarmclang compiler, is derived from the open source LLVM/Clang source code base and the LLVM Compiler Infrastructure source base that can be found in GitHub (github.com).

The tiarmclang compiler can be used to compile and link C/C++ and assembly source files to build static executable application files that can be loaded and run on an Arm Cortex processor (m0, m0plus, m3, m4, m33, r4, and r5). Please see the Device Support section below for further information about which compiler options to use when building an application for a particular Arm Cortex processor configuration.

Long-Term Support Release

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

Documentation

The TI Arm Clang Compiler Tools User’s Guide is now available online at the following URL:

Since the tiarmclang compiler is derived from the LLVM project’s Clang compiler source base, much of the generic Clang online documentation is also applicable to the tiarmclang compiler. The latest version of the generic Clang documentation can be found here:

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.

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

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.

Defect Tracking Database

Compiler defect reports can be tracked at the new Development Tools bug database, SIR. SIR is a JIRA-based view into all public tools defects. The old SDOWP tracking database will be retired.

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

To find an old SDOWP issue, place the SDOWP ID in the search box and use double quotes around the SDOWP ID.

What’s New

Support for Call Coverage Information in tiarmcov Output (tiarmcov –show-call-region-summary option)

Call coverage indicates the coverage of regions with call sites in them. Previous versions of the code coverage report show statement and region coverage information in the tiarmcov output. The 3.2.0.LTS tiarmclang compiler and the updated tiarmcov utility will also display call coverage information in the tiarmcov output when the –show-call-region-summary option is specified on the tiarmcov command-line.

For example, given a source file, call_region.cpp:

int foo(int a, int b) { return a + b; }
int nop() { return 0; }
int bar(int a, int b) {
  nop();
  if (a < b)
    return a;
  return a == b ? foo(b, a) : b;
}

extern "C" { extern void __llvm_profile_write_file(void); }
int main(int argc, char *argv[])
{
  nop();
  if (true) {
    bar(5, 10);
    nop();
  }
  else
    nop();
    
  __llvm_profile_write_file();
  return 0;
}

The above source file uses a call to the runtime support function, __llvm_profile_write_file(), to extract the profile counter data from target memory and write data out to a raw profile counter file just prior to completing the main() routine. See Retrieving the Counters From Memory for more information.

The next steps for gathering call coverage information for the above application are:

1) Compile and link:

%> tiarmclang -fcoverage-mapping -fprofile-instr-generate call_region.cpp -o a.out -Wl,lnk.cmd

2) Load and run a.out

3) Process the raw profile counter file (default.profraw) using the tiarmprofdata utility:

%> tiarmprofdata merge -obj-file=a.out default.profraw -o call_region.profdata

4) Generate a coverage report that includes call coverage information with the tiarmcov utility:

%> tiarmcov report --summary-only --show-call-region-summary --object=a.out -instr-profile=call_region.profdata

Included in the tiarmcov generated report will be a call coverage summary:

Call Regions Missed Call Regions Cover
------------ ------------------- ------------
      5                   2      60.00%

Support for CSV Export Format in tiarmcov Utility (tiarmcov export –format=csv option)

The 3.2.0.LTS version of the tiarmcov utility, which is included with the TI Arm Clang Compiler Tools installation, supports a CSV export format that enables the tiarmcov export to be easily imported into a TI code coverage XLS template. The CSV format can be generated when tiarmcov is invoked with the following arguments: “tiarmcov export –format=csv”.

For example, consider an application that has been compiled and linked (app.out) and then loaded and run to produce a raw profile counter file (default.profraw), You can use the tiarmprofdata and tiarmcov utilities to create a CSV file that can be easily imported into an XLS worksheet:

1) Process the raw profile counter file (default.profraw) using tiarmprofdata:

%> tiarmprofdata merge -obj-file=app.out default.profraw -o app.profdata

2) Use “tiarmcov export” command to pipe CSV output to a file:

%> tiarmcov export --format=csv app.out -instr-profile=app.profdata >& app_cov.csv

Support for ELF Segment “Blocking” (Alignment and Padding)

Users may tell the linker to align and pad initialized ELF segments (aka program headers, collections of sections) based on a power-of-two byte boundary using the “–block_init_segments=” linker option.

For example, using “–block_init_segments=16” would force these segments to be aligned and padded on a 16-byte boundary. This is useful for when an entire segment has to be encrypted with 128bit-aligned blocks.

OpTI-Flash Smart Placement and Smart Layout

The tiarmclang compiler release includes features to support OpTI-Flash. OpTI-Flash enables users to more easily place heavily accessed functions and data objects and also utilize new hardware features available on the AM263P device. The OpTI-Flash tooling support provided by the LTS toolchain provide a set of building blocks and can be understood as three categories of functionality:

C/C++ Source-level function attributes:

Smart Placement:

```
__attribute__(({local,onchip,offchip}(priority))) (Corresponding to TCMx, SRAM, FLASH)
```

Smart Layout:

```
__attribute__((fast_local_copy(flcregionid))) (present region limit: 4)
```

Example:

```
__attribute__((local(1))) void func0(void) { .. } // Place in TCM with priority 1
__attribute__((local(2))) void func1(void) { .. } // Place in TCM with priority 2
__attribute__((onchip))   void func2(void) { .. } // Place in SRAM with implied priority 1
__attribute__((fast_local_copy(1))) void func3(void) { .. } // Place in FLC Region 1
```

The attributes can be added to a function definition or a function declaration (if that function is called/referenced in the same compilation unit).

Assembly metainfo directives

Functions can also be annotated by adding an assembly metainfo directive in an assembly file that is compiled and linked with the project using the following format. This would allow users to avoid having to compile other source code.

Smart Placement

```
  .global <global function symbol>
  .sym_meta_info <global function symbol>, "of_placement", {"local","onchip","offchip"}, <priority>
```

Smart Layout

```
  .global <global function symbol>
  .sym_meta_info <global function symbol>, "of_placement", "fast_local_copy", <regionid>
```

e.g.

```
  .global strcmp
  .sym_meta_info strcmp, "of_placement", "local", 1
  .global memcpy
  .sym_meta_info strcmp, "of_placement", "memcpy", 1
```

A simple node.js script called “generate_syms.js” is also included that generates an assembly file based on a CSV text file of the following format:

```
  strcmp,local,1
  main,onchip,3
  memcpy,fast_local_copy,1
```

Smart Placement Linker Aggregation

With the placement described above, the TI link-step will aggregate function and data input sections into documented output sections while also sorting the input sections. For Smart Placement, the input sections are sorted based on the designated priority. The documented output sections for Smart Placement are:

Note: that data objects placed in .TI.local or .TI.onchip are always directly initialized according to RAM-model initialization. This means that whatever is responsible for loading that code and data into RAM or TCM will also initialize the data, even if ROM-model auto-initialization is used. This means that in ROM-model, CINIT records are not created for this data.

When ROM-model auto-initialization is enabled, zero-initialization CINIT records will be created for the uninitialized memory regions .TI.bss.local and .TI.bss.onchip. When RAM-model initialization is used, it is up to the user to zero-initialized these sections. The linker will export symbols that an initialization routine can link against designated the start and end of these sections:

Note that because symbols are defined for these sections, they cannot be split between multiple memory regions.

A default linker command file needs to place the documented output sections in the corresponding memory regions in both development and deployment flows. This could be autogenerated by sysconfig based on the memory partition or linked using generic macros. For a development flow, this is pretty straightforward, as in the following example.

```
/* Partitioned memory map */
MEMORY
{
    R5F_VECS : ORIGIN = 0x00000000 , LENGTH = 0x00000040
    R5F_TCMA : ORIGIN = 0x00000040 , LENGTH = 0x00007FC0
    R5F_TCMB : ORIGIN = 0x41010000 , LENGTH = 0x00008000
    MSRAM    : ORIGIN = 0x70080000 , LENGTH = 0x40000
    FLASH    : ORIGIN = 0x60100000 , LENGTH = 0x80000
}

SECTIONS
{
    /* "local"   --> split between TCMs and SRAM                   */
    /* "onchip"  --> split between SRAM and FLASH                  */
    /* "offchip" --> FLASH                                         */

    .TI.local   : {} >> R5F_TCMA | R5F_TCMB | MSRAM
    .TI.onchip  : {} >> MSRAM | FLASH
    .TI.offchip : {} > FLASH
    .TI.local.bss : {} > R5F_TCMB; /* Exports symbols __start___TI.bss.local, __stop___TI.bss.local */
    .TI.onchip.bss: {} > MSRAM;    /* Exports symbols __start___TI.bss.onchip, __stop___TI.bss.onchip */
}
```

By default, section splitting should be used as shown above between memory regions to get the full effect of function prioritization.

Enable Smart Data Collection for Smart Placement

When the “–smart_data_collect” linker option is enabled, the TI link-step will not only include explicitly annotated function and data objects into the appropriate documented output sections, it will also pull in referenced initialized data sections and assign them the same priority as the object that references them. For objects placed in .TI.local, referenced read-write and read-only (constant) data sections are pulled in. For objects placed in .TI.onchip, only referenced read-only (constant) data sections are pulled in. Nothing happens for objects placed in .TI.offchip.

Smart Layout Linker Aggregation

For Smart Layout, the input sections are sorted based on linear execution order (function PREORDER) based on a call graph.

The documented output sections for Smart Placement are:

A default linker command file needs to be provided for the customer that will place the output sections in FLASH.

```
SECTIONS
{
    .TI.flc.region1 : { } > FLASH
    .TI.flc.region2 : { } > FLASH
    .TI.flc.region3 : { } > FLASH
    .TI.flc.region4 : { } > FLASH
}
```

The linker will automatically generate start/stop symbols for each region so that the FLC can be programmed:

```
__start___TI_flc_region1, __stop___TI_flc_region1
__start___TI_flc_region2, __stop___TI_flc_region2
__start___TI_flc_region3, __stop___TI_flc_region3
__start___TI_flc_region4, __stop___TI_flc_region4
```

Users are responsible for ensuring that FLC regions are programmed according to the hardware interface based on the region symbols above.

Users may also create their own output sections in a linker command file with manually specified input sections and sort them based on execution order using the PREORDERED() operator:

```
SECTIONS
{
    .outputSection: { 
        foo.o(.text)
        bar.o(.text.myfunc) 
    } > FLASH, PREORDERED()
}
```

Support for C++17

The 3.2.0.LTS version of the tiarmclang compiler supports C++17 language extensions.

The tiarmclang compiler supports gnu17 language extensions for C programs, and now c++17 language extensions for C++ programs by default.

To choose a different C or C++ language dialect when compiling your program, you can use the tiarmclang -std option to choose your desired dialect. Please see C/C++ Language Standard Options (-std) for a full list of available C and C++ language dialects supported by the tiarmclang compiler.

Support for Generating TI-TXT Hex Format from tiarmobjcopy

The 3.2.0.LTS version of the tiarmobjcopy utility supports generating ti-txt hex format.

In addition to the already supported formats like ihex (Intel) and binary, the tiarmobjcopy utility can be used to generate ti-txt format from an ELF object file.

For example, given an ELF executable file, app.out, you can use tiarmobjcopy to generate an output file containing the raw data content of the app.out file in ti-txt format:

```
%> tiarmobjcopy --input-target=elf32-littlearm --output-target=ti-txt app.out app.hex
```

For further information about using the tiarmobjcopy utility, please see tiarmobjcopy - Object Copying and Editing Tool.

For further information about the TI_TXT format, please see TI-TXT Hex Format.

Support for C++ Exceptions (-fexceptions)

By default, C++ exceptions are disabled.

In version 3.2.0.LTS of the tiarmclang compiler tools, the -fexceptions compiler option can be specified when the compiler is invoked to enable support for C++ exceptions.

If the -fexceptions compiler option is used to compile an application’s source code, then the linker will be instructed to link with runtime support libraries that support C++ exceptions during the link-step of an application build.

Example

Consider the following simple example of utilizing C++ exceptions:

```
#include <iostream>

int main() {
  int age;

  std::cout << "How old are you? ";
  std::cin >> age;
  try {
    if (age >= 18) {
      std::cout << "Please proceed to an open booth to vote ... Thank you!\n";    
}
else {
  throw (age);
}
  }
  catch (int input_age) {
    std::cout << "I'd like to help you, but you're too young to vote (" << input_age << ")\n";
  }

  return 0;
}
```

Compile the above C++ source file as follows:

```
%> tiarmclang -mcpu=cortex-m4 -fexceptions check_age.cpp -o check_age.out -Wl,-llnk.cmd
```

When loaded and run, the above application will generate the following output:

```
How old are you? 21
Please proceed to an open booth to vote ... Thank you!

How old are you? 5
I'd like to help you, but you're too young to vote (5)
```

Enable Compiler Generation of Execute-Only Code for Cortex-M0/M0+ Functions (-mexecute-only)

The -mexecute-only compiler option can be used in version 3.2.0.LTS of the tiarmclang compiler tools to generate “execute-only” code for Cortex-M0/M0+. Use of the -mexecute-only compiler option on the compiler invocation will prevent constant data from being embedded in the code section that the compiler generates for a function.

When an application’s source files are compiled with the -mexecute-only option, the linker will be instructed to link with execute-only versions of the runtime support libraries during the link-step of an application build.

Example

Consider a simple example with a function that contains a switch statement:

```
#include <stdio.h>

void mySwitch(int n) {

  switch (n) {
    case 1:
      printf("Input value is 1\n");
      break;
    case 2:
      printf("Input value is 2\n");
      break;
    case 3:
      printf("Input value is 3\n");
      break;
    default:
      printf("Invalid input\n");
      break;
  }
}
```

Compile the above C source file as follows, using the -S to emit compiler-generated assembly:

```
%> tiarmclang -mcpu=cortex-m0plus -mexecute-only -S ex_switch.c
```

The compiler generated assembly file contains the following:

```
%> cat ex_switch.s
...
        .section        .text.mySwitch,"axy",%progbits,unique,0
        .globl  mySwitch
        .p2align        1
        .code   16                              @ @mySwitch
        .thumb_func
mySwitch:
...
.LBB0_5:                                @ %sw.bb3
        movs    r0, :upper8_15:.L.str.2
        lsls    r0, r0, #8
        adds    r0, :upper0_7:.L.str.2
        lsls    r0, r0, #8
        adds    r0, :lower8_15:.L.str.2
        lsls    r0, r0, #8
        adds    r0, :lower0_7:.L.str.2
        bl      printf
...
        .section        .rodata.str1.1,"aMS",%progbits,1
.L.str:
        .asciz  "Input value is 1\n"
        .size   .L.str, 18
...
.L.str.2:
        .asciz  "Input value is 3\n"
        .size   .L.str.2, 18
...
```

Note that in the above compiler-generated code, the address where each string constant resides in the .rodata.str1.1 section is loaded via direct addressing. This requires four 8-bit loads to load each part of the address into a register before the call to printf can be made.

If we then compare this to the code that is generated when execute-only is disabled:

```
%> tiarmclang -mcpu=cortex-m0plus -S ex_switch.c
%> cat ex_switch.s
...
        .section        .text.mySwitch,"ax",%progbits
        .globl  mySwitch
        .p2align        1
        .code   16                              @ @mySwitch
        .thumb_func
mySwitch:
...
.LBB0_5:                                @ %sw.bb3
        ldr     r0, .LCPI0_0
        bl      printf
...
        pop     {r7, pc}
    .p2align        2
.LCPI0_0:
        .long   .L.str.2
...
        .section        .rodata.str1.1,"aMS",%progbits,1
.L.str:
        .asciz  "Input value is 1\n"
        .size   .L.str, 18
...
.L.str.2:
        .asciz  "Input value is 3\n"
        .size   .L.str.2, 18
...
```

Observe that in the non-execute-only generated code the address of the location where the string constant resides is in a table of constants that is included in the .text section that contains the definition of the mySwitch function. This allows the address to be loaded via PC-relative addressing.

While the non-execute-only compiler-generated code is smaller and more efficient, the execute-only code may reside in special execute-only memory. This can be useful when code security is a concern in your application.

Enable Use of Custom Datapath Extension (CDE) Intrinsics on Cortex-M33

Support for using Custom Datapath Extension (CDE) intrinsics in source code to be compiled for the TI Arm Cortex-M33 processor is available in version 3.2.0.LTS of the tiarmclang compiler tools.

CDE Intrinsics

The CDE intrinsics are defined in the arm_cde.h header file that is included in the tiarmclang compiler tools installation.

The arm_cde.h header file must be included in any compilation unit that references a CDE intrinsic. For example,

```
#include <arm_cde.h>

void foo(void) {
  ...
  uint32 my_u32 = __arm_cx2a(10, 20, 30, 40);
  ...
}
```

The available CDE instrinsics include the following:

Each of the CDE intrinsics is defined in arm_cde.h as a static inline function and implemented via a compiler runtime built-in function that is defined in the relevant version of the libclang_rt.builtins.a runtime library, which is included in the tiarmclang 3.2.0.LTS compiler tools installation.

Specify -march Option to Enable Use of CDE Intrinsics on Cortex-M33

To enable the use of CDE intrinsics during a compilation of a source file, one of the following -march compiler options must be specified when the compiler is invoked:

Cortex-M4 and Cortex-R5 Performance Improvements

The 3.2.0.LTS version of the tiarmclang compiler tools are capable of generating slightly higher performance Cortex-M4 and Cortex-R5 code versus the tiarmclang 2.1.3.LTS release due to the following improvements:

tiarmclang 2.1.3.LTS v. tiarmclang 3.0.0.STS Benchmark Scores

The Coremark and Dhrystone performance benchmarks were built and run with both the tiarmclang 2.1.3.LTS and tiarmclang 3.0.0.STS releases. The following tables provide a sense of the performance improvements that can be anticipated when moving an application build from the 2.1.3.LTS compiler tools to the 3.2.0.LTS compiler tools.

Cortex-M4:

Benchmark 2.1.3.LTS Score 3.0.0.STS Score
Coremark (inlining off) 2.42 2.69
Coremark (inlining on) 3.12 3.51
Dhrystone (inlining off) 1.00 1.13
Dhrystone (inlining on) 1.25 1.56

Cortex-R5:

Benchmark 2.1.3.LTS Score 3.0.0.STS Score
Coremark (inlining off) 2.87 2.87
Coremark (inlining on) 3.58 3.60
Dhrystone (inlining off) 1.25 1.55
Dhrystone (inlining on) 1.61 2.05

Host Support / Dependencies

The following host-specific versions of the 3.2.0.LTS tiarmclang compiler tools are available:

Device Support

The tiarmclang compiler tools support development of applications that are to be loaded and run on one of the following Arm Cortex processor and runtime environment configurations:

Cortex-M0:

Runtime Environment Configuration Options
Cortex-M0 “-mcpu=cortex-m0”
exceptions on “-mcpu=cortex-m0 -fexceptions”
execute-only on “-mcpu=cortex-m0 -mexecute-only”
execute-only and exceptions on “-mcpu=cortex-m0 -mexecute-only -fexceptions”

Cortex-M0+:

Runtime Environment Configuration Options
Cortex-M0+ “-mcpu=cortex-m0plus”
exceptions on “-mcpu=cortex-m0plus -fexceptions”
execute-only on “-mcpu=cortex-m0plus -mexecute-only”
execute-only on, exceptions on “-mcpu=cortex-m0plus -mexecute-only -fexceptions”

Cortex-M3:

Runtime Environment Configuration Options
Cortex-M3 “-mcpu=cortex-m3”
exceptions on “-mcpu=cortex-m3 -fexceptions”

Cortex-M4:

Runtime Environment Configuration Options
Cortex-M4 (FPv4SPD16 on by default) “-mcpu=cortex-m4”
FPv4SPD16 on “-mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16”
FPv4SPD16 on, exceptions on “-mcpu=cortex-m4 -fexceptions”
FPv4SPD16 on, exceptions on “-mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fexceptions”
FPv4SPD16 off “-mcpu=cortex-m4 -mfloat-abi=soft”
FPv4SPD16 off, exceptions on “-mcpu=cortex-m4 -mfloat-abi=soft -fexceptions”

Cortex-M33:

Runtime Environment Configuration Options
Cortex-M33 (FPv5SPD16 on by default) “-mcpu=cortex-m33”
FPv5SPD16 on “-mcpu=cortex-m33 -mfloat-abi=hard -mfpu=fpv5-sp-d16”
FPv5SPD16 on, exceptions on “-mcpu=cortex-m33 -fexceptions”
FPv5SPD16 on, exceptions on “-mcpu=cortex-m33 -mfloat-abi=hard -mfpu=fpv5-sp-d16 -fexceptions”
FPv5SPD16 off “-mcpu=cortex-m33 -mfloat-abi=soft”
FPv5SPD16 off, exceptions on “-mcpu=cortex-m33 -mfloat-abi=soft -fexceptions”
CDE CP0 on, FPv5SPD16 on “-mcpu=cortex-m33 -march=armv8.1-m.main+cdecp0”
CDE CP0 on, FPv5SPD16 on “-mcpu=cortex-m33 -march=thumbv81-m.main+cdecp0”
CDE CP0 on, FPv5SPD16 on “-mcpu=cortex-m33 -march=armv8.1-m.main+cdecp0 -mfloat-abi=hard -mfpu=fpv5-sp-d16”
CDE CP0 on, FPv5SPD16 on “-mcpu=cortex-m33 -mfloat-abi=hard -march=thumbv81-m.main+cdecp0 -mfpu=fpv5-sp-d16”
CDE CP0 on, FPv5SPD16 on, exceptions on “-mcpu=cortex-m33 -march=armv8.1-m.main+cdecp0 -fexceptions”
CDE CP0 on, FPv5SPD16 on, exceptions on “-mcpu=cortex-m33 -march=thumbv81-m.main+cdecp0 -fexceptions”
CDE CP0 on, FPv5SPD16 on, exceptions on “-mcpu=cortex-m33 -march=armv8.1-m.main+cdecp0 -mfloat-abi=hard -mfpu=fpv5-sp-d16 -fexceptions”
CDE CP0 on, FPv5SPD16 on, exceptions on “-mcpu=cortex-m33 -march=thumbv81-m.main+cdecp0 -mfloat-abi=hard -mfpu=fpv5-sp-d16 -fexceptions”
CDE CP0 on, FPv5SPD16 off “-mcpu=cortex-m33 -march=armv8.1-m.main+cdecp0 -mfloat-abi=soft”
CDE CP0 on, FPv5SPD16 off “-mcpu=cortex-m33 -march=thumbv81-m.main+cdecp0 -mfloat-abi=soft”
CDE CP0 on, FPv5SPD16 off, exceptions on “-mcpu=cortex-m33 -march=armv8.1-m.main+cdecp0 -mfloat-abi=soft -fexceptions”
CDE CP0 on, FPv5SPD16 off, exceptions on “-mcpu=cortex-m33 -march=thumbv81-m.main+cdecp0 -mfloat-abi=soft -fexceptions”

Please Note:

Cortex-R4:

Runtime Environment Configuration Options
Cortex-R4 (default Arm mode, VFPv3D16 off) “-mcpu=cortex-r4”
Arm mode, VFPv3D16 off “-mcpu=cortex-r4 -mfloat-abi=soft”
Arm mode, VFPv3D16 off, exceptions on “-mcpu=cortex-r4 -fexceptions”
Arm mode, VFPv3D16 off, exceptions on “-mcpu=cortex-r4 -mfloat-abi=soft -fexceptions”
Arm mode, VFPv3D16 on “-mcpu=cortex-r4 -mfloat-abi=hard -mfpu=vfpv3-d16”
Arm mode, VFPv3D16 on, exceptions on “-mcpu=cortex-r4 -mfloat-abi=hard -mfpu=vfpv3-d16”
Thumb mode, VFPv3D16 off “-mcpu=cortex-r4 -mthumb”
Thumb mode, VFPv3D16 off “-mcpu=cortex-r4 -mthumb -mfloat-abi=soft”
Thumb mode, VFPv3D16 off, exceptions on “-mcpu=cortex-r4 -mthumb -fexceptions”
Thumb mode, VFPv3D16 off, exceptions on “-mcpu=cortex-r4 -mthumb -mfloat-abi=soft -fexceptions”
Thumb mode, VFPv3D16 on “-mcpu=cortex-r4 -mthumb -mfloat-abi=hard -mfpu=vfpv3-d16”
Thumb mode, VFPv3D16 on, exceptions on “-mcpu=cortex-r4 -mthumb -mfloat-abi=hard -mfpu=vfpv3-d16 -fexceptions”

Cortex-R5:

Runtime Environment Configuration Options
Cortex-R5 (default Arm mode, VFPv3D16 on “-mcpu=cortex-r5”
Arm mode, VFPv3D16 on “-mcpu=cortex-r5 -mfloat-abi=hard -mfpu=vfpv3-d16”
Arm mode, VFPv3D16 on, exceptions on “-mcpu=cortex-r5 -fexceptions”
Arm mode, VFPv3D16 on, exceptions on “-mcpu=cortex-r5 -mfloat-abi=hard -mfpu=vfpv3-d16 -fexceptions”
Arm mode, VFPv3D16 off “-mcpu=cortex-r5 -mfloat-abi=soft”
Arm mode, VFPv3D16 off, exceptions on “-mcpu=cortex-r5 -mfloat-abi=soft -fexceptions”
Thumb mode, VFPv3D16 on “-mcpu=cortex-r5 -mthumb”
Thumb mode, VFPv3D16 on “-mcpu=cortex-r5 -mthumb -mfloat-abi=hard -mfpu=vfpv3-d16”
Thumb mode, VFPv3D16 on, exceptions on “-mcpu=cortex-r5 -mthumb -fexceptions”
Thumb mode, VFPv3D16 on, exceptions on “-mcpu=cortex-r5 -mthumb -mfloat-abi=hard -mfpu=vfpv3-d16 -fexceptions”
Thumb mode, VFPv3D16 off “-mcpu=cortex-r5 -mthumb -mfloat-abi=soft”
Thumb mode, VFPv3D16 off, exceptions on “-mcpu=cortex-r5 -mthumb -mfloat-abi=soft -fexceptions”

Resolved Defects

ID Summary
CODEGEN-11433 Use of _disable_interrupts intrinsic causes compiler to emit call to function _get_CPSR, which does not exist
CODEGEN-11158 Do not emit the diagnostic: warning: call to function without interrupt attribute could clobber interruptee's VFP registers; consider using the interrupt_save_fp attribute to prevent this behavior
CODEGEN-11092 QKIT ToolDefinition.pdf for tiarmclang 1.3.x.LTS and 2.1.x.LTS has inaccurate Tool Version information
CODEGEN-10988 tiarmclang documentation fails to clarify that #pragma pack never increases the default alignment
CODEGEN-10591 Optimization of Logical NOT on condition yields incorrect MC/DC test vector tracking
CODEGEN-10444 Enabling Code Coverage and LTO results in missing profile data section
CODEGEN-10383 Document ‘#pragma clang section bss’ to be used for uninitialized variables
CODEGEN-10251 Initialization of array of structures is mistakenly filled with 0
CODEGEN-10229 Crash can occur when loading symbols due to self-referencing DIE
CODEGEN-10067 LTO: linker should include undefined symbols that are referenced from a static function in the IR symbol table that is passed to the LTO recompile
CODEGEN-10000 LTO: Compiling a source file with cortex-r4/r5 with -mthumb and linking with ARM mode cortex-r4/r5 runtime libraries improperly resolves an R_ARM_CALL relocation
CODEGEN-9997 tiarmclang: LTO behaves differently than non-LTO with regards to how zero-initialized variables are defined
CODEGEN-9850 Unresolved reference to runtime library function when that function is referenced from asm statement
CODEGEN-9838 Update tiarmclang documentation to explain that C++ library does not support features related to threads and concurrency
CODEGEN-9834 Compiler ignores attribute((used))
CODEGEN-9779 Function local static array allocated to .data section, and not .bss
CODEGEN-9669 TI Arm Clang mismatch between source code and debugger view with function subsections
CODEGEN-9415 Compiler inappropriately generates non-empty ARM.exidx sections
CODEGEN-9092 tiarmclang mistakenly documents support for -fpic position independent code
CODEGEN-8914 _enable_IRQ in ti_compatibility.h only supports Cortex-M devices
CODEGEN-8899 tiarmlnk generates cinit record for tiny .init_array section
CODEGEN-8887 Compiler does not support linking code that uses C++ exceptions
CODEGEN-8639 tiarmar.exe is denied permission to create an archive file on Windows 7
CODEGEN-8533 Use of virtual functions causes many RTS print functions to be linked into the program
CODEGEN-8471 Hex utility, when splitting a section as required by the bootloader, ignores the section alignment for the second part of the split
CODEGEN-8255 tiarmclang: zero-initialized static and global variables are being defined in .bss
CODEGEN-8216 Code coverage symbols not defined when profile counter section manually placed
CODEGEN-8177 Change documentation of –symbol_map
CODEGEN-6288 tiarmclang: optimizer removes empty loops that don't have side effects

Known Defects

The up-to-date known defects in v3.2.0.LTS can be found here (dynamically generated):

known defects in v3.2.0.LTS

End of File