TI Arm Clang Compiler Tools - 5.0.0.STS Release Notes
Table of Contents
Introduction
Version 5.0.0.STS 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, m55, m85, r4, r5, r52, and r52plus). 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.
Short-Term Support Release
This is a Short-Term Support 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 available online at the following URL:
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 - Features Added in the 5.0.0.STS Release
Position Independent Code (PIC) / Dynamic Linking
The tiarmclang 5.0.0.STS compiler tools now provide support for generating position independent code (PIC) via the -fPIC compiler option and support for dynamic linking.
Position Independent Code (PIC) - -fPIC Compiler Option
Position independent code is a contiguous block of executable code that is comprised of one or more function definitions and read-only (RO) data objects that are gathered into a RO segment.
Using the -fPIC compiler option instructs the compiler to generate code that is, as far as possible, independent of what target memory address it is loaded to. In most cases, it is not possible to eliminate all assumptions about the location of the code, and the compiler needs assistance from an external tool to make code fully “position independent”.
The tiarmclang compiler tools employ dynamic linking to facilitate full “position independence”.
Dynamic Linking
A dynamically linked application is comprised of two primary object file components: dynamic link libraries (DLLs) and dynamic executables. Each of these components can be loaded to a target memory address of the dynamic loader’s choosing.
Dynamic link libraries (DLLs) are individual ELF object files that contain functions and data objects meant to be used by other ELF files. In a dynamic application, this means they may be used by dynamic executables or other DLLs. A DLL is not intended to be executable on its own.
Dynamic executables are very much like a static executable, except that they are not typically tied to a specific target memory address and they may depend on one or more DLLs to resolve references to symbols that are not defined in the dynamic executable ELF object file itself.
When building a dynamic application, one must start with building the DLLs that do not depend on other DLLs, then build the DLLs that have dependencies on other DLLs, then finally build the dynamic executable that may depend on one or more DLLs.
Once the dynamic application is built, a dynamic loader with special capabilities is needed to load and run the application. These special capabilities are described in more detail below in the Support Responsibilities of the Dynamic Loader section.
PIC / Dynamic Linking - Building and Running a Dynamic Application
In order to explain how to use the tiarmclang PIC and Dynamic Linking capabilities, lets examine a simple representational dynamic application example …
A Representational Example
In the following discussions about how position independent function calls and data accesses work, we’ll refer to the following source code …
a.c is the C source file for a DLL, a.dll:
a.c
---
volatile int a = 42;
int foo(void) {
return a;
}b.c is the C source file for a DLL, b.dll, that depends on a.dll:
b.c
---
extern volatile int a;
int foo(void);
int bar() {
return a + foo();
}c.c is the C source file for dynamic executable, c.exe, that depends on b.dll and defines an entry point function symbol, start:
c.c
---
int start(void) {
return bar();
}A Closer Look at Compiler Generated PIC
To begin this discussion, we’ll first build the a.dll and b.dll object files using the following commands:
%> tiarmclang -mcpu=cortex-r4 -fPIC -nostdlib a.c -o a.dll \
-Wl,--dynamic=lib,--export=foo,--export=a
%> tiarmclang -mcpu=cortex-r4 -fPIC -nostdlib b.c -o b.dll \
-Wl,--dynamic=lib,a.dll,--export=barSince b.c contains both an external data access and a call to an externally defined function, lets examine the disassembly of the linked b.dll object file:
%> tiarmobjdump -S -d b.dll
b.dll: file format elf32-littlearm
Disassembly of section .text:
00000010 <bar>:
10: e92d4800 push {r11, lr}
14: e24dd008 sub sp, sp, #8
18: e59f0020 ldr r0, [pc, #0x20] @ 0x40 <bar+0x30>
1c: e79f0000 ldr r0, [pc, r0]
20: e5900000 ldr r0, [r0]
24: e58d0004 str r0, [sp, #0x4]
28: ebfffff4 bl 0x0 <.plt.foo> @ imm = #-0x30
2c: e1a01000 mov r1, r0
30: e59d0004 ldr r0, [sp, #0x4]
34: e0800001 add r0, r0, r1
38: e28dd008 add sp, sp, #8
3c: e8bd8800 pop {r11, pc}
40: e4 ff ff ff .word 0xffffffe4
Disassembly of section .plt:
00000000 <.plt.foo>:
0: e51ff004 ldr pc, [pc, #-0x4] @ 0x4 <.plt.foo+0x4>
4: 00 00 00 00 .word 0x00000000Accessing Data with PIC - Global Offset Tables (GOT)
There are three components involved in the access to the global variable ‘a’ that is defined in the a.dll object file that is specified as input to the tiarmclang command that is used to build b.dll:
Offset from PC to GOT Entry
The constant value stored at address 0x40 in the above code/data block represents the distance from the instruction that accesses the constant to the starting address of the GOT plus 8 (a PC-relative load assumes a PC value associated with the second instruction immediately following the load instruction that accesses the offset constant).
Three ldr Instructions
Loading the value of the global variable ‘a’ is accomplished at run-time via the following three load instructions:
18: e59f0020 ldr r0, [pc, #0x20] @ 0x40 <bar+0x30> 1c: e79f0000 ldr r0, [pc, r0] 20: e5900000 ldr r0, [r0]The first of these load instructions is a PC-relative load that loads an offset constant from address 0x40 into register r0. The value of that offset constant is -28.
The second PC-relative load subtracts the offset constant in r0 from the value of the PC register (the address of the second instruction following the second PC-relative load), 0x24 or 36. This instruction is actually accessing the GOT entry that, at run-time, contains the address of the variable ‘a’. At load-time, the dynamic loader will have patched the GOT entry at address 0x8 with the address of the variable ‘a’ as it has been assigned when a.dll was loaded.
Finally, the third load instruction in this sequence loads the value of ‘a’ from the address where ‘a’ has been placed in target memory by the dynamic loader.
Global Offset Table (GOT)
The GOT in b.dll is defined in an uninitialized section named .got. The linker creates a GOT entry for each externally defined global symbol that is referenced from b.dll. Though it is not listed in the above disassembly of b.dll, we can calculate the location of the .got section in the b.dll block of code and data using the information relevant to the second PC-relative load. That is, a PC value == 36 plus the value in r0 == -28
PC + r0 = 36 + (-28) = 0x8
Calling Functions with PIC - Procedure Link Tables (PLTs)
There are two components involved in the calling of function foo() in a position independent manner:
Procedure Linkage Table (PLT) Entry
For every externally defined function that is called from a dynamic executable or a DLL, the linker creates a PLT entry. All PLT entries created on behalf of a dynamic executable or DLL object file are collected into a .plt section. In b.dll, the PLT entry for foo() is located at the start of the code/data segment that contains both the PLT and the definition of foo()’s caller:
Disassembly of section .plt: 00000000 <.plt.foo>: 0: e51ff004 ldr pc, [pc, #-0x4] @ 0x4 <.plt.foo+0x4> 4: 00 00 00 00 .word 0x00000000When b.dll is being loaded by the dynamic loader, it first loads a.dll, thus resolving the location in target memory of the definition of foo(), then the dynamic loader can process the dynamic relocation attached to the .word directive in the above PLT entry and patch the address of foo() into the appropriate location in the PLT entry for foo().
At run-time, the call to foo()’s PLT entry performs a PC-relative load of foo()’s address directly into the PC, effecting a branch to the definition of foo(). When foo() returns, rather than landing back in the PLT entry, the return from foo() lands at the instruction following the call to foo()’s PLT entry.
Call to PLT Entry
During the build of b.dll, the linker replaces a normal call to foo(), “bl foo”, with a call to the PLT entry associated with foo(). Since the linker knows the address of the PLT within the code/data segment that contains both the PLT and the definition of foo()’s caller, the linker can resolve the call to the PLT entry for foo() to a call with a PC-relative offset that lands the call at the correct PLT entry. In this case, the PLT entry for foo() resides at the beginning of the code/data segment:
28: ebfffff4 bl 0x0 <.plt.foo> @ imm = #-0x30
Building Dynamic Link Libraries (DLLs)
As mentioned above, building DLLs is reasonably straightforward and utilizes a few key compiler and linker options:
%> tiarmclang -mcpu=cortex-r4 -fPIC -nostdlib a.c -o a.dll \
-Wl,--dynamic=lib,--export=foo,--export=a
%> tiarmclang -mcpu=cortex-r4 -fPIC -nostdlib b.c -o b.dll \
-Wl,--dynamic=lib,a.dll,--export=bar-fPIC
Instruct compiler to generate PIC that depends on dynamic linking and loading mechanisms.
-nostdlib
Exclude code or data from runtime libraries from the DLL link.
- -Wl,–export=a
-Wl,–export=foo
Make the global symbols ‘a’ and ‘foo’, defined in a.dll, available to any dynamic executables or DLLs that depend on a.dll.
-Wl,–export=bar
Make the global symbol ‘bar’, defined in b.dll, available to any dynamic executable or DLLs that depend on b.dll.
a.dll
Indicate that the build of b.dll depends on a.dll.
-Wl,–dynamic=lib
Instruct the linker to create a DLL.
Building a Dynamic Executable
Like DLLs, building a dynamic executable is also straighforward and utilizes compiler and linker options related to dynamic linking:
%> tiarmclang -mcpu=cortex-r4 -fPIC -nostdlib c.c -o c.exe \
-Wl,--dynamic=exe,b.dll,-estart-Wl,-estart
Indicates that execution of the dynamic executable starts at the definition of the start() function.
b.dll
Indicate that the build of c.exe depends on b.dll. Note that only b.dll needs to be mentioned in the tiarmclang command that builds c.exe even though c.exe is indirectly dependent on a.dll via b.dll.
-Wl,–dynamic=exe
Instructs the linker to build a dynamic executable.
Loading and Running a Dynamic Executable
Loading and running a dynamic application requires the use of a dynamic loader that is not provided as part of the tiarmclang 5.0.0.STS compiler tools installation.
When building a dynamic executable or DLL, the linker generates the information needed by the dynamic loader to successfully carry out its support responsibilities. This information can be found in the linker-generated dynamic sections.
After a dynamic executable and any needed DLLs have been loaded, the dynamic loader must provide some means of initiating execution of the dynamic application.
Linker Generated Dynamic Sections
The dynamic loader depends on information contained in dynamic sections that are created by the linker while building a dynamic executable or DLL. This section provides a general overview of the content of the dynamic sections, with some more detailed descriptions of the more commonly used elements.
.dynamic
The .dynamic section contains an array of the following structure:
typedef struct { Elf32_Sword d_tag; Union { Elf32_Word d_val; Elf32_Word d_ptr; } d_un; } Elf32_Dyn;where:
- d_tag - identifies the type of information represented
- d_val - is an integer value relevant to the information type
- d_ptr - is a reference to a piece of information within the file; for a d_tag == DT_SYMTAB, the d_ptr value refers to the file offset where the .dynsym section is located in the dynamic object file
Using the tiarmofd object file display utility, we can examine the content of the .dynamic section in the b.dll object file:
%> tiarmofd -v -o b_dll.ofd b.dll %> cat b_dll.ofd ... Dynamic Information in ".dynamic" id tag value -- --- ----- 0 DT_NEEDED a.dll 1 DT_PLTRELSZ 8 2 DT_HASH 0x00000404 3 DT_STRTAB 0x000003ec 4 DT_SYMTAB 0x000003ac 5 DT_STRSZ 23 6 DT_SYMENT 16 7 DT_SONAME b.dll 8 DT_REL 0x0000012c 9 DT_RELSZ 16 10 DT_RELENT 8 11 DT_PLTREL 17 12 DT_TEXTREL (null) 13 DT_JMPREL 0x00000134 14 DT_ARM_SYMTABSZ 4Lets walk through the .dynamic section content and examine what is represented in each array element:
- DT_NEEDED - the DT_NEEDED tag value identifies a DLL that the current dynamic object file depends on. If the dynamic object file depends on multiple DLLs, then there will be a DT_NEEDED entry for each one.
- DT_PLTRELSZ - the DT_PLTRELSZ tag value is the total size of the rel.plt section
- DT_HASH - the DT_HASH tag value is a file offset to the location of the symbol hash table (.hash section)
- DT_STRTAB - the DT_STRTAB tag value is a file offset to the .dynstr section
- DT_SYMTAB - the DT_SYMTAB tag value is a file offset to the .dynsym section
- DT_STRSZ - the DT_STRSZ tag value is the number of bytes in the .dynstr section
- DT_SYMENT - the DT_SYMENT tag value indicates the size of a single symbol table entry in the .dynsym section
- DT_SONAME - the DT_SONAME tag value identifies the name of the current dynamic object file
- DT_REL - the DT_REL tag value is the file offset to the .rel.dyn section that contains the list of dynamic relocations that need to be processed by the dynamic loader to patch GOT table entries associated with the current dynamic object file
- DT_RELSZ - the DT_RELSZ tag value is the total size in bytes of the .rel.dyn section
- DT_RELENT - the DT_RELENT tag value indicates the size of a single relocation entry in the .rel.dyn section
- DT_PLTREL - the DT_PLTREL tag value indicates the kind of relocation (either DT_REL or DT_RELA) that is used for all relocations in the .rel.plt section
- DT_TEXTREL - the DT_TEXTREL tag value is itself a flag. If it is present in the .dynamic section, then one or more relocation entries may modify the content of a non-writable segment. This is applicable in the tiarmclang support for dynamic linking since the linker puts both the .plt and .got sections in the same RO segment as .text and .rodata. The dynamic loader processes dynamic relocations that are applicable to the .plt and .got sections before the RO segment containing .plt and .got is actually loaded into target memory.
- DT_JMPREL - the DT_JMPREL tag value is the file offset to the .rel.plt section that contains the list of dynamic relocation entries that must be processed when the current object file is loaded in order to patch the addresses of externally defined functions into the PLT entries attached to the current dynnamic object file
- DT_ARM_SYMTABSZ - the DT_ARM_SYMTABSZ tag is Arm-specific and its value indicates the number of symbol table entries in the .dynsym section
.dynsym
The .dynsym section contains an array of symbol table entries, each of which contains information about the dynamic symbol’s name, value, binding, type, etc.
.dynstr
The .dynstr section contains the dynamic string table. In raw form, the .dynstr section contains a stream of bytes that are null-terminated strings butted up against one another. A string in the dynamic string table can be accessed using the location of the string table plus the byte offset where the beginning of the desired string resides.
.rel.dyn and .rela.dyn
The .rel.dyn or .rela.dyn section contains a list of dynamic relocation entries used by the dynamic loader to patch GOT entries during the loading of a dynamic object file.
.hash
The .hash section contains a hash table that can be used to assist with symbol table lookup. Please see an ELF specification for more detailed information about how the hash table is organized.
.rel.plt
The .rel.plt section contains a list of dynamic relocation entries used by the dynamic loader to patch PLT entries during the loading of a dynamic object file.
For more detailed information about the content of the dynamic sections used by the dynamic loader, please refer to the latest available ELF specification. The following link points to the github site that maintains the official repository for the ELF Object File Format specification:
Support Responsibilities of the Dynamic Loader
Ability to Read and Comprehend ELF Dynamic Object Files
A core requirement of the dynamic loader is the ability to read and comprehend all aspects of an ELF dynamic object file. Please refer to the latest ELF Object File specification for details about the parts of a given ELF object file.
Target Memory Management
When presented with a dynamic executable or a DLL that is to be loaded into target memory, the dynamic loader allocates space in target memory in which to load the code and data segments from the dynamic executable or DLL, loads the code and data segments into the allocated space, then updates its target memory database to accurately reflect which target memory regions are still available, and which are occupied or otherwise unavailable.
File Dependency Management
When loading a dynamic executable or DLL object file, the dynamic loader must read the object file’s .dynamic section. Any DLLs that the object file depends on are listed in one or more DT_NEEDED entries in the .dynamic section. The dynamic loader must maintain a data base of DLLs that have already been loaded so that the dynamic loader can determine whether a DLL refered to by a DT_NEEDED entry is already loaded or not.
Process GOT and PLT Relocations
Before processing any dynamic relocations in a dynamic executable or DLL object file that is being loaded, the dynamic loader must ensure that any DLLs that the object file depends on has been loaded and relocated with global symbols that are defined in the dependent DLLs having been entered into the dynamic loader’s dynamic symbol table.
Once these steps have been completed, the dynamic loader can then process the dynamic relocations in the object file currently being loaded. For a reference to an externally defined function or data symbol, the dynamic loader can find the address where the symbol is defined via a global symbol table lookup, then patch the address of the symbol’s definition into the appropriate entry in the object file’s PLT (for function symbols) or GOT (for data symbols).
Maintain Global Symbol Table
As discussed above, before processing dynamic relocations in a dynamic executable or DLL object file that is in the process of being loaded. the dynamic loader ensures that any DLLs that the object file depends on are completely loaded first. The same is true when reading the dynamic symbol table from the object file.
After loading the DLLs that the currently loading object file is dependent on, the dynamic loader reads the dynamic symbols from the object file’s .dynsym section. For each defined symbol in the .dynsym section, the dynamic loader first checks that the symbol has not already been defined by another object file, then enters the symbol into the dynamic loader’s global symbol table.
Similarly, for each undefined symbol in the .dynsym section, the dynamic loader checks that the symbol has been defined by one of the DLLs that it depends on.
Summary of Compiler and Linker Options Relevant to PIC and Dynamic Linking
The compiler and linker options used in the building of the example dynamic application discussed above are listed below for quick reference.
Compiler Options
-fPIC
Instruct compiler to generate code to facilitate position independence and utilize dynamic linking and loading mechanisms.
-nostdlib
No code or data from runtime libraries is linked into the application under construction.
Linker Options
-Wl,–export=
Make specified function or data symbol available to users of the DLL that includes the definition of the symbol.
-Wl,–dynamic=lib
Instruct the linker to create a DLL.
-Wl,–dynamic=exe
Instruct the linker to create a dynamic executable.
Full Support for Cortex-M55, Cortex-M85 and Cortex-R52+
The tiarmclang compiler tools now support generating code for the Arm Cortex-M55, Cortex-M85 and Cortex-R52+ processor variants.
Cortex-M55
Support for generating Cortex-M55 code is enabled using the -mcpu=cortex-m55 compiler option. If the -mcpu=cortex-m55 option is specified, then the compiler assumes that support for the fp-armv8-fullfp16-d16 FPU is also enabled by default.
When the -mcpu=cortex-m55 option is specified, the default enabling of the fp-armv8-fullfp16-d16 FPU can be overridden by specifying the -mfloat-abi=soft or the -mfpu=none option on the compiler command line. This indicates that the compiler is to generate instructions to perform floating-point operations without using the FPU instruction set.
For more information about optionsets available for generating Cortex-M55 code with and without fp-armv8-fullfp16-d16 instructions, please see the Device Support section below.
Performance Note
As development efforts to support generation of Cortex-M55 code continue, we have been measuring the performance of tiarmclang generated code for the Cortex-M55 processor over the industry Coremark and Dhrystone benchmarks. The latest scores for these benchmarks are listed below along with the Arm Limited published scores for the Cortex-M55 processor:
| Benchmark | tiarmclang 5.0.0.STS | Arm Ltd Score |
|---|---|---|
| Coremark | 4.71 | 4.4 |
| Dhrystone (inlining) | 1.93 (2.19*) | 2.16 |
| Dhrystone (no inlining) | 1.60 (1.78*) | 1.69 |
NOTE: re: tiarmclang 5.0.0.STS Dhrystone scores - The scores annotated with an asterisk (*) were run using the Arm Ltd. compiler’s strcmp() routine. The gap between the published Arm Ltd. scores and the tiarmclang 5.0.0.STS scores for Dhrystone are entirely due to the faster Arm Ltd. strcmp() runtime library implementation.
Cortex-M85
Support for generating Cortex-M85 code is enabled using the -mcpu=cortex-m85 compiler option. If the -mcpu=cortex-m85 option is specified, then the compiler assumes that support for the fp-armv8-fullfp16-d16 FPU is also enabled by default.
When the -mcpu=cortex-m85 option is specified, the default enabling of the fp-armv8-fullfp16-d16 FPU can be overridden by specifying the -mfloat-abi=soft or the -mfpu=none option on the compiler command line. This indicates that the compiler is to generate instructions to perform floating-point operations without using the FPU instruction set.
For more information about optionsets available for generating Cortex-M85 code with and without fp-armv8-fullfp16-d16 instructions, please see the Device Support section below.
Cortex-R52+
Support for generating Cortex-R52+ code is enabled using the -mcpu=cortex-r52plus compiler option. If the -mcpu=cortex-r52plus option is specified, then the compiler assumes that support for the neon-fp-armv8 FPU is also enabled by default.
When the -mcpu=cortex-r52plus option is specified, the default enabling of the neon-fp-armv8 FPU can be overridden by specifying the -mfloat-abi=soft or the -mfpu=none option on the compiler command line. This indicates that the compiler is to generate instructions to perform floating-point operations without using the FPU instruction set.
For more information about optionsets available for generating Cortex-R52+ code with and without neon-fp-armv8 instructions, please see the Device Support section below.
Performance Note
As development efforts to support generation of Cortex-R52+ code continue, we have been measuring the performance of tiarmclang generated code for the Cortex-R52+ processor over the industry Coremark and Dhrystone benchmarks. The latest scores for these benchmarks are listed below along with the Arm Limited published scores for the Cortex-R52+ processor:
| Benchmark | tiarmclang 5.0.0.STS | Arm Ltd Score |
|---|---|---|
| Coremark | 4.39 | 4.3 |
| Dhrystone (inlining) | 2.72 | 2.70 |
| Dhrystone (no inlining) | 2.24 | 2.09 |
Performance and Code Size Improvements
Development efforts on the tiarmclang compiler tools since the last major release (4.0.x.LTS) have led to improvements in the performance of code generated by the tiarmclang 5.0.0.STS compiler tools.
The tables below compare the performance of code generated by the tiarmclang 5.0.0.STS compiler tools versus the tiarmclang 4.0.4.LTS compiler tools over the industry Coremark and Dhrystone performance benchmarks.
Cortex-M4
| Benchmark | tiarmclang 4.0.4.LTS | tiarmclang 5.0.0.STS | Arm Ltd Score |
|---|---|---|---|
| Coremark | 3.51 | 3.88 | 3.54 |
| Dhrystone (inlining) | 1.56 | 1.56 | 1.67 |
| Dhrystone (no inlining) | 1.19 | 1.19 | 1.27 |
Cortex-M33
| Benchmark | tiarmclang 4.0.4.LTS | tiarmclang 5.0.0.STS | Arm Ltd Score |
|---|---|---|---|
| Coremark | 3.95 | 4.44 | 4.1 |
| Dhrystone (inlining) | 1.80 | 1.82 | 2.05 |
| Dhrystone (no inlining) | 1.31 | 1.31 | 1.52 |
Cortex-R5
| Benchmark | tiarmclang 4.0.4.LTS | tiarmclang 5.0.0.STS | Arm Ltd Score |
|---|---|---|---|
| Coremark (THUMB) | 3.72 | 4.1 | 3.47 |
| Coremark (ARM) | 3.61 | 3.88 | 3.47 |
| Dhrystone (THUMB inlining) | 2.03 | 1.96 | 2.02 |
| Dhrystone (ARM inlining) | 2.04 | 2.04 | 2.02 |
| Dhrystone (THUMB no inlining) | 1.56 | 1.58 | 1.67 |
| Dhrystone (ARM no inlining) | 1.56 | 1.56 | 1.67 |
Issues Fixed in tiarmclang 5.0.0.STS
CODEGEN-13751 - Optimization goal for LTO does not match compiler
When link-time optimization (LTO) is enabled and multiple optimization flags are specified in the compiler command, the expectation is that the last optimization flag seen in the compiler command indicates the level of optimization to be in effect during the LTO recompile.
However, in prior versions of the tiarmclang compiler tools, the LTO recompile would adopt the optimization level indicated by the first optimization flag specified in the compiler command. For example, in the following command:
%> tiarmclang -O3 -O0 -flto project.c -o project.out -Wl,lnk.cmdthe optimization level in effect during the compilation of project.c was -O0, while the optimization level in effect during the LTO recompile was -O3.
This defect has been addressed in version 5.0.0.STS of the tiarmclang compiler tools so that the last optimization flag specified in the compiler command is in effect both during the initial compile of input C/C++ source files and during the LTO recompile.
Host Support / Dependencies
The following host-specific versions of the 4.0.1.LTS tiarmclang compiler tools are available:
- Linux: Ubuntu, RHEL 7
- Windows: 7, 8, 10
- Mac: OSX
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:
- CDE CP0 refers to support for Custom Datapath Extension intrinsics on Coprocessor 0
One of the following -march options must be specified in the tiarmclang command to enable support for the CDE intrinsics on Coprocessor 0;
- -march=armv8.1-m.main+cdecp0
- -march=thumbv8.1-m.main+cdecp0
You should only enable CDE intrinsics on Coprorcessor 0 if the target device is known to have a coprocessor unit on board
Cortex-M55:
| Runtime Environment Configuration | Options |
|---|---|
| Cortex-M55 (ARMv8FULLFP16 on by default) | “-mcpu=cortex-m55” |
| ARMv8FULLFP16 on | “-mcpu=cortex-m55 -mfloat-abi=hard -mfpu=fp-armv8-fullfp16-d16” |
| ARMv8FULLFP16 on, exceptions on | “-mcpu=cortex-m55 -fexceptions” |
| ARMv8FULLFP16 on, exceptions on | “-mcpu=cortex-m55 -mfloat-abi=hard -mfpu=fp-armv8-fullfp16-d16 -fexceptions” |
| ARMv8FULLFP16 off | “-mcpu=cortex-m55 -mfloat-abi=soft” |
| ARMv8FULLFP16 off, exceptions on | “-mcpu=cortex-m55 -mfloat-abi=soft -fexceptions” |
| CDE CP0 on, ARMv8FULLFP16 on | “-mcpu=cortex-m55 -march=armv8.1-m.main+cdecp0” |
| CDE CP0 on, ARMv8FULLFP16 on | “-mcpu=cortex-m55 -march=thumbv81-m.main+cdecp0” |
| CDE CP0 on, ARMv8FULLFP16 on | “-mcpu=cortex-m55 -march=armv8.1-m.main+cdecp0 -mfloat-abi=hard -mfpu=fp-armv8-fullfp16-d16” |
| CDE CP0 on, ARMv8FULLFP16 on | “-mcpu=cortex-m55 -mfloat-abi=hard -march=thumbv81-m.main+cdecp0 -mfpu=fp-armv8-fullfp16-d16” |
| CDE CP0 on, ARMv8FULLFP16 on, exceptions on | “-mcpu=cortex-m55 -march=armv8.1-m.main+cdecp0 -fexceptions” |
| CDE CP0 on, ARMv8FULLFP16 on, exceptions on | “-mcpu=cortex-m55 -march=thumbv81-m.main+cdecp0 -fexceptions” |
| CDE CP0 on, ARMv8FULLFP16 on, exceptions on | “-mcpu=cortex-m55 -march=armv8.1-m.main+cdecp0 -mfloat-abi=hard -mfpu=fp-armv8-fullfp16-d16 -fexceptions” |
| CDE CP0 on, ARMv8FULLFP16 on, exceptions on | “-mcpu=cortex-m55 -march=thumbv81-m.main+cdecp0 -mfloat-abi=hard -mfpu=fp-armv8-fullfp16-d16 -fexceptions” |
| CDE CP0 on, ARMv8FULLFP16 off | “-mcpu=cortex-m55 -march=armv8.1-m.main+cdecp0 -mfloat-abi=soft” |
| CDE CP0 on, ARMv8FULLFP16 off | “-mcpu=cortex-m55 -march=thumbv81-m.main+cdecp0 -mfloat-abi=soft” |
| CDE CP0 on, ARMv8FULLFP16 off, exceptions on | “-mcpu=cortex-m55 -march=armv8.1-m.main+cdecp0 -mfloat-abi=soft -fexceptions” |
| CDE CP0 on, ARMv8FULLFP16 off, exceptions on | “-mcpu=cortex-m55 -march=thumbv81-m.main+cdecp0 -mfloat-abi=soft -fexceptions” |
Please Note:
- CDE CP0 refers to support for Custom Datapath Extension intrinsics on Coprocessor 0
One of the following -march options must be specified in the tiarmclang command to enable support for the CDE intrinsics on Coprocessor 0;
- -march=armv8.1-m.main+cdecp0
- -march=thumbv8.1-m.main+cdecp0
You should only enable CDE intrinsics on Coprorcessor 0 if the target device is known to have a coprocessor unit on board
Cortex-M85:
| Runtime Environment Configuration | Options |
|---|---|
| Cortex-M85 (ARMv8FULLFP16 on by default) | “-mcpu=cortex-m85” |
| ARMv8FULLFP16 on | “-mcpu=cortex-m85 -mfloat-abi=hard -mfpu=fp-armv8-fullfp16-d16” |
| ARMv8FULLFP16 on, exceptions on | “-mcpu=cortex-m85 -fexceptions” |
| ARMv8FULLFP16 on, exceptions on | “-mcpu=cortex-m85 -mfloat-abi=hard -mfpu=fp-armv8-fullfp16-d16 -fexceptions” |
| ARMv8FULLFP16 off | “-mcpu=cortex-m85 -mfloat-abi=soft” |
| ARMv8FULLFP16 off, exceptions on | “-mcpu=cortex-m85 -mfloat-abi=soft -fexceptions” |
| CDE CP0 on, ARMv8FULLFP16 on | “-mcpu=cortex-m85 -march=armv8.1-m.main+cdecp0” |
| CDE CP0 on, ARMv8FULLFP16 on | “-mcpu=cortex-m85 -march=thumbv81-m.main+cdecp0” |
| CDE CP0 on, ARMv8FULLFP16 on | “-mcpu=cortex-m85 -march=armv8.1-m.main+cdecp0 -mfloat-abi=hard -mfpu=fp-armv8-fullfp16-d16” |
| CDE CP0 on, ARMv8FULLFP16 on | “-mcpu=cortex-m85 -mfloat-abi=hard -march=thumbv81-m.main+cdecp0 -mfpu=fp-armv8-fullfp16-d16” |
| CDE CP0 on, ARMv8FULLFP16 on, exceptions on | “-mcpu=cortex-m85 -march=armv8.1-m.main+cdecp0 -fexceptions” |
| CDE CP0 on, ARMv8FULLFP16 on, exceptions on | “-mcpu=cortex-m85 -march=thumbv81-m.main+cdecp0 -fexceptions” |
| CDE CP0 on, ARMv8FULLFP16 on, exceptions on | “-mcpu=cortex-m85 -march=armv8.1-m.main+cdecp0 -mfloat-abi=hard -mfpu=fp-armv8-fullfp16-d16 -fexceptions” |
| CDE CP0 on, ARMv8FULLFP16 on, exceptions on | “-mcpu=cortex-m85 -march=thumbv81-m.main+cdecp0 -mfloat-abi=hard -mfpu=fp-armv8-fullfp16-d16 -fexceptions” |
| CDE CP0 on, ARMv8FULLFP16 off | “-mcpu=cortex-m85 -march=armv8.1-m.main+cdecp0 -mfloat-abi=soft” |
| CDE CP0 on, ARMv8FULLFP16 off | “-mcpu=cortex-m85 -march=thumbv81-m.main+cdecp0 -mfloat-abi=soft” |
| CDE CP0 on, ARMv8FULLFP16 off, exceptions on | “-mcpu=cortex-m85 -march=armv8.1-m.main+cdecp0 -mfloat-abi=soft -fexceptions” |
| CDE CP0 on, ARMv8FULLFP16 off, exceptions on | “-mcpu=cortex-m85 -march=thumbv81-m.main+cdecp0 -mfloat-abi=soft -fexceptions” |
Please Note:
- CDE CP0 refers to support for Custom Datapath Extension intrinsics on Coprocessor 0
One of the following -march options must be specified in the tiarmclang command to enable support for the CDE intrinsics on Coprocessor 0;
- -march=armv8.1-m.main+cdecp0
- -march=thumbv8.1-m.main+cdecp0
You should only enable CDE intrinsics on Coprorcessor 0 if the target device is known to have a coprocessor unit on board
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” |
Cortex-R52:
| Runtime Environment Configuration | Options |
|---|---|
| Cortex-R52 (default Arm mode, FPARMv8+NEON on) | “-mcpu=cortex-r52” |
| Arm mode, FPARMv8+NEON on | “-mcpu=cortex-r52 -mfloat-abi=hard -mfpu=neon-fp-armv8” |
| Arm mode, FPARMv8+NEON on, exceptions on | “-mcpu=cortex-r52 -fexceptions” |
| Arm mode, FPARMv8+NEON on, exceptions on | “-mcpu=cortex-r52 -mfloat-abi=hard -mfpu=neon-fp-armv8 -fexceptions” |
| Arm mode, FPARMv8+NEON off | “-mcpu=cortex-r52 -mfloat-abi=soft” |
| Arm mode, FPARMv8+NEON off, exceptions on | “-mcpu=cortex-r52 -mfloat-abi=soft -fexceptions” |
| Thumb mode, FPARMv8+NEON on | “-mcpu=cortex-r52 -mthumb” |
| Thumb mode, FPARMv8+NEON on | “-mcpu=cortex-r52 -mthumb -mfloat-abi=hard -mfpu=neon-fp-armv8” |
| Thumb mode, FPARMv8+NEON on, exceptions on | “-mcpu=cortex-r52 -mthumb -fexceptions” |
| Thumb mode, FPARMv8+NEON on, exceptions on | “-mcpu=cortex-r52 -mthumb -mfloat-abi=hard -mfpu=neon-fp-armv8 -fexceptions” |
| Thumb mode, FPARMv8+NEON off | “-mcpu=cortex-r52 -mthumb -mfloat-abi=soft” |
| Thumb mode, FPARMv8+NEON off, exceptions on | “-mcpu=cortex-r52 -mthumb -mfloat-abi=soft -fexceptions” |
Cortex-R52+:
| Runtime Environment Configuration | Options |
|---|---|
| Cortex-R52+ (default Arm mode, FPARMv8+NEON on) | “-mcpu=cortex-r52plus” |
| Arm mode, FPARMv8+NEON on | “-mcpu=cortex-r52plus -mfloat-abi=hard -mfpu=neon-fp-armv8” |
| Arm mode, FPARMv8+NEON on, exceptions on | “-mcpu=cortex-r52plus -fexceptions” |
| Arm mode, FPARMv8+NEON on, exceptions on | “-mcpu=cortex-r52plus -mfloat-abi=hard -mfpu=neon-fp-armv8 -fexceptions” |
| Arm mode, FPARMv8+NEON off | “-mcpu=cortex-r52 -mfloat-abi=soft” |
| Arm mode, FPARMv8+NEON off, exceptions on | “-mcpu=cortex-r52plus -mfloat-abi=soft -fexceptions” |
| Thumb mode, FPARMv8+NEON on | “-mcpu=cortex-r52plus -mthumb” |
| Thumb mode, FPARMv8+NEON on | “-mcpu=cortex-r52plus -mthumb -mfloat-abi=hard -mfpu=neon-fp-armv8” |
| Thumb mode, FPARMv8+NEON on, exceptions on | “-mcpu=cortex-r52plus -mthumb -fexceptions” |
| Thumb mode, FPARMv8+NEON on, exceptions on | “-mcpu=cortex-r52plus -mthumb -mfloat-abi=hard -mfpu=neon-fp-armv8 -fexceptions” |
| Thumb mode, FPARMv8+NEON off | “-mcpu=cortex-r52plus -mthumb -mfloat-abi=soft” |
| Thumb mode, FPARMv8+NEON off, exceptions on | “-mcpu=cortex-r52plus -mthumb -mfloat-abi=soft -fexceptions” |
Resolved Defects
| ID | Summary |
|---|---|
| CODEGEN-14342 | Dwarf call frame information contains frame description entries with instructions with the wrong address |
| CODEGEN-14327 | Global instance of structure is unexpectedly allocated into an initialized section |
| CODEGEN-14277 | Use of -Werror fails to change warning diagnostic into an error |
| CODEGEN-14222 | The function attribute((destructor)) is silently ignored |
| CODEGEN-14115 | Disassembly fails in VS Code and GNU Arm objdump due to presence of .TI.phattrs section |
| CODEGEN-13751 | Optimization goal for LTO does not match compiler |
| CODEGEN-13642 | MacOS: missing symbol frmo Mac libc++.1.dylib may cause link to fail |
| CODEGEN-13377 | Building with link time optimization leaves behind temporary file |
| CODEGEN-13361 | tiarmclang silently ignores #pragma FUNCTION_OPTIONS, when a diagnostic is expected |
| CODEGEN-13308 | “padding” section created with a dot expression is not being initialized if a fill operator is applied to it |
| CODEGEN-13041 | Code coverage breaks naked functions |
| CODEGEN-13028 | Code built with -flto causes linker to fail with segmentation fault |
| CODEGEN-13015 | QKitUserGuide.pdf lists incorrect compiler user manual in section 7 references. correct user manual listed in ToolDefinition.pdf |
| CODEGEN-13002 | Loop optimization at -O3 leads to segmentation fault on auto-generated Simulink code |
| CODEGEN-12833 | Compiler incorrectly optimizes control flow code in the presence of an empty infinite loop |
| CODEGEN-12795 | STDC_NO_THREADS is not defined even though compiler doesn't support C threads |
| CODEGEN-12763 | tiarmstrip documentation is wrong |
| CODEGEN-12700 | For a float if statement followed by divide, compiler generated code performs divide first |
| CODEGEN-12689 | Compiler does not support characters in the ISO 8859 extended character set |
| CODEGEN-12684 | Linker option –scan_libraries mistakenly complains about duplicate symbols when a library is supplied multiple times |
| CODEGEN-12682 | Document that tiarmclang and c29clang compilers do not support C11 threads |
| CODEGEN-12625 | Assembler error when ISR built with interrupt_save_fp dumped and compiled as assembly. |
| CODEGEN-12535 | tiarmclang ti_compatibility.h gets build errors with -mcpu=cortex-m33 |
| CODEGEN-12533 | Using tiarmclang -S -flto does not create an assembly file |
| CODEGEN-11966 | Changing the directory of the source files can cause the contents of the .rodata section to be ordered differently |
| CODEGEN-11890 | Using 32bit counters sometimes results in counter size mismatch around increment.step |
| CODEGEN-11631 | tiarmcov should not include instrumented runtime data by default or report errors |
| CODEGEN-11527 | Wrong source for main is referenced during source stepping |
| CODEGEN-11466 | QKIT: tiarmclang 2.1.0.LTS QKIT has typo's for c17 and c++17 support |
| 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-10691 | assembler/linker incorrectly handles REL relocations if user specifies a CODE_SECTION that starts with ‘a’ |
| 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-10306 | For EABI cinit copy “compression”, the linker incorrectly sets the number of bytes to copy for smaller copy initialization sizes |
| 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-9576 | Using –symbol_map with LTO results in incorrect optimizations across functions |
| 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 v5.0.0.STS can be found here (dynamically generated):
End of File