Updating Arm Compiler with an existing toolchain:

Installing Arm Compiler using a development suite:

 

The latest release of Arm Compiler is 6.13

For license server management software visit the FlexNet Publisher downloads page.

Download Arm Compiler

Version 6.13

Released: October 10, 2019

Windows 64-bit
File: DS500-BN-00024-r5p0-15rel0.zip (205.58 MB)
Windows 32-bit
File: DS500-BN-00025-r5p0-15rel0.zip (196.15 MB)
Linux 64-bit
File: DS500-BN-00026-r5p0-15rel0.gz (276.98 MB)

Release Note for Arm Compiler 6 Downloads 6.13

Arm Logo

Release notes for Arm Compiler 6.13

1. Introduction

Arm Compiler 6.13 adds:

  • Support for Cortex-A65, Cortex-A77, and Star processors.
  • Early support for Future Architecture Technologies in the A architecture profile:
    • Assembly for the Embedded Trace Extension (ETE).
    • Assembly for the Scalable Vector Extension 2 (SVE2).
    • Assembly for the Trace Buffer Extension (TRBE).
    • Assembly and intrinsics for the Transactional Memory Extension (TME).
  • Armv8.6-A:
    • Alpha support for assembly.
    • Alpha support for intrinsics for the BFloat16 Extension.
    • Alpha support for intrinsics for the Matrix Multiply Extension.
  • Armv8.5-A:
    • Support for intrinsics for the optional Memory Tagging Extension.
  • Armv8.1-M:
    • Support for assembly and intrinsics.
    • Beta support for automatic vectorization for the optional M-profile Vector Extension (MVE).

Arm Compiler 6.13 is intended for use:

  • In conjunction with an Arm Development Studio toolkit.
  • In conjunction with a Keil MDK toolkit.
  • As a standalone toolchain installation, provided you have a license for a suitable toolkit.

Contact your sales representative or visit https://developer.arm.com/buy-arm-products to enquire about a license. Visit https://developer.arm.com/support/licensing to manage your licenses or access troubleshooting resources.

If you are using a floating license, your license server must be running armlmd and lmgrd version 11.14.1.0 or later. Arm recommends that you always use the latest version of the license server software that is available from https://developer.arm.com/products/software-development-tools/license-management/downloads.

1.1 Arm Compiler 6 Configuration

The Arm Compiler 6.13 toolchain includes the following:

  • armclang: Compiler and integrated assembler based on LLVM and Clang technology.
  • armasm: Legacy assembler for armasm-syntax assembly code. Use the armclang integrated assembler for all new assembly files.
  • armar: Archiver which enables sets of ELF object files to be collected together.
  • armlink: Linker that combines objects and libraries to produce an executable.
  • fromelf: Image conversion utility and dissembler.
  • Arm C++ libraries: Libraries based on the LLVM libc++ project.
  • Arm C libraries: Runtime support libraries for embedded systems.

1.2 What's Supported in Arm Compiler 6.13?

The following table lists the target Arm Architectures and Processors supported in Arm Compiler 6.13. The exact set of targets depends on which license and toolkit you are using. The table is correct at the time of the Arm Compiler 6.13 release but may change in the future. Check with your supplier for more information.

Target License
Keil MDK
(Windows Only)
Arm Development Studio
(Linux and Windows)
Lite Essential PlusProfessional Bronze Silver Gold Platinum
Future Arch - - - - - - - -Yes
Armv8.6-A - - - - - - - - Yes
Armv8-A up to 8.5-A Neoverse N1/E1 - - - - - - -Yes
Cortex-A77/76AE/76/65AE/65 - - - - - - -Yes
Cortex-A75/73/72/57/55/53/35/32 - - - - - - YesYes
Armv7-A Cortex-A17/15/12/9/8/7/5 - - - Yes - Yes YesYes
Armv8-R Cortex-R52 - - - - - - YesYes
Armv7-R Cortex-R8/7/5 - - - - - Yes YesYes
Cortex-R4F/4 - - Yes Yes - Yes YesYes
Armv8.1-M - - - - - - - -Yes
Armv8-M Star - --- - - -Yes
Cortex-M35P/33/23 - Non-secure only Yes Yes Yes Yes YesYes
Armv7-M SC300 - - Yes Yes Yes Yes YesYes
Cortex-M7/4/3 32 Kbyte code limit Yes Yes Yes Yes Yes YesYes
Armv6-M SC000 - - Yes Yes Yes Yes YesYes
Cortex-M1/0/0+ 32 Kbyte code limit Yes Yes Yes Yes Yes YesYes

For more information about the level of support for these targets and the toolchain features, refer to the product documentation.

Arm Development Studio Platinum Edition is reserved for Arm partners developing the latest IP before it becomes available in devices. It includes all the features of Gold, and additionally has support for the latest announced IP from Arm. Please contact Arm for more information.

2. Installation Instructions

If you received Arm Compiler 6.13 as part of a toolkit, for example Arm Development Studio, the toolkit installer takes care of the installation process. Please refer to the installation instructions for the toolkit in such cases.

For all other cases, you must select an appropriate installation location depending on how you intend to use Arm Compiler 6.13:

  • Integrated into Arm Development Studio 2018.0 or later.
  • Integrated into Keil MDK 5.22 or later.
  • As a standalone toolchain installation.

Unless you are using Keil MDK, Arm Compiler 6.13 can be installed in any location, including the default location, providing this is outside of an Arm Development Studio product installation directory.

Please refer to the configuration instructions at https://developer.arm.com/tools-and-software/software-development-tools/license-management/resources/product-and-toolkit-configuration and also the relevant sections below.

2.1. Integration into Arm Development Studio 2018.0 or later

You can integrate the toolchain with Arm Development Studio 2018.0 or later by following the instructions available at https://developer.arm.com/docs/101470/latest/configure-arm-development-studio/register-a-compiler-toolchain.

2.2. Integration into Keil MDK 5.22 or later

Arm Compiler 6.13 must be installed underneath the ARM subdirectory of the Keil MDK installation directory. For example, if your Keil MDK installation directory is in C:\Keil_v5, the recommended installation path is C:\Keil_v5\ARM\ARMCompiler6.13.

After it is installed, you can integrate the toolchain into a Keil MDK project by following the instructions in the tutorial available at http://www.keil.com/support/man/docs/uv4/uv4_armcompilers.htm.

Only the 32-bit Windows variant of Arm Compiler 6.13 can be used with a Keil Single-User License or Keil Floating-User License.

2.3. Use as a standalone toolchain installation

Ensure that the ARMLMD_LICENSE_FILE environment variable is pointing to your license file or license server.

2.4. Installation on Linux

Arm Compiler 6.13 has been tested on the following supported platforms:

  • Red Hat Enterprise Linux 6 Workstation, 64-bit only.
  • Red Hat Enterprise Linux 7 Workstation, 64-bit only.
  • Ubuntu Desktop Edition 16.04 LTS, 64-bit only.
  • Ubuntu Desktop Edition 18.04 LTS, 64-bit only.

Arm Compiler 6.13 is not expected to work on older platforms.

To install Arm Compiler 6.13, run (not source) install_x86_64.sh and follow the on-screen instructions. The installer unpacks Arm Compiler 6.13 into your chosen directory.

The armclang binary is dynamically linked to a copy of libstdc++ installed under your chosen directory as part of Arm Compiler 6.13.

2.5. Installation on Windows

Arm Compiler 6.13 has been tested on the following supported platforms:

  • Windows Server 2012, 64-bit only.
  • Windows 7 Enterprise SP1.
  • Windows 7 Professional SP1.
  • Windows 8.1 Enterprise, 64-bit only.
  • Windows 8.1 Professional, 64-bit only.
  • Windows 10 Enterprise, 64-bit only.
  • Windows 10 Professional, 64-bit only.

Arm Compiler 6.13 is not expected to work on older platforms.

Arm Compiler 6.13 has been tested on the latest feature update of Windows 10 available as of October 2019. It is expected to work well on later updates.

To install Arm Compiler 6.13, run win-x86_64\setup.exe on a supported 64-bit Windows platform or win-x86_32\setup.exe on a supported 32-bit Windows platform and follow the on-screen instructions. If you have an earlier version of Arm Compiler 6 installed and you wish to perform an upgrade, it is recommended that you uninstall the previous version before installing the new version of Arm Compiler 6.

Arm Compiler 6.13 is built with Microsoft Visual Studio 2017 and requires the Universal C Runtime in Windows to be installed. For further information see https://support.microsoft.com/en-gb/help/2999226/update-for-universal-c-runtime-in-windows.

3. Uninstall

On Linux, delete the Arm Compiler 6.13 installation directory.

On Windows, use Programs and Features in Control Panel, select ARM Compiler 6.13, and click the Uninstall button.

4. Documentation

Arm Compiler 6.13 documentation is available on https://developer.arm.com and comprises:

  • User Guide.
  • Reference Guide.
  • Arm C and C++ Libraries and Floating-Point Support User Guide.
  • Migration and Compatibility Guide.
  • Errors and Warnings Reference Guide.

From this release, the Reference Guide has been extended to incorporate reference information for all the Arm Compiler tools. This includes reference information that was provided in separate User Guide documents in previous releases.

In January 2018, Arm published information about the Variant 1: bounds check bypass (CVE-2017-5753) vulnerability. Refer to https://developer.arm.com/support/security-update/compiler-support-for-mitigations and use the Migration path recommendations with this Arm Compiler release to help mitigate against the vulnerability. Note that the API of the mitigation is subject to change.

5. Feedback and Support

Your feedback is important to us, and you are welcome to send us defect reports and suggestions for improvement on any aspect of the product. Contact your supplier or visit https://developer.arm.com/support and open a case with feedback or support issues. Where appropriate, please provide the --vsn output from the tool, the complete content of any error message that the tools produce, and include any source code, other files, and command-lines necessary to reproduce the issue.

6. Release History and Changes

The following are the releases to date of the Arm Compiler 6.13 series:

  • 6.13 (released October 2019)

Below is a summary of the enhancements and defect fixes when compared to the previous release. The information may include technical inaccuracies or typographical errors, and may change in future editions of the Release notes. Each itemized change is accompanied by a unique SDCOMP-<n> identifier. If you need to contact Arm about a specific issue within these release notes, please quote the appropriate identifier.

Changes in Arm Compiler 6.13

Changes are listed since the previous feature release, Arm Compiler 6.12.

General changes in Arm Compiler 6.13

  • [SDCOMP-54460]  Beta support has been added for automatic vectorization for the optional M-profile Vector Extension (MVE) in Armv8.1-M.

  • [SDCOMP-54459]  Alpha support has been added for intrinsics for the Matrix Multiply Extension in Armv8.6-A. To target the Matrix Multiply Extension, select from the following armclang options where <ext> is 2 or later:

    • --target=aarch64-arm-none-eabi -march=armv8.<ext>-a+i8mm to enable matrix multiplication instructions for 8-bit integer operations for AArch64 state.
    • --target=aarch64-arm-none-eabi -march=armv8.<ext>-a+f32mm to enable matrix multiplication instructions for 32-bit single-precision floating-point operations for AArch64 state.
    • --target=aarch64-arm-none-eabi -march=armv8.<ext>-a+f64mm to enable matrix multiplication instructions for 64-bit double-precision floating-point operations for AArch64 state.
    • --target=arm-arm-none-eabi -march=armv8.<ext>-a+i8mm to enable matrix multiplication instructions for 8-bit integer operations for AArch32 state.

  • [SDCOMP-54458]  Early support has been added for assembly for the Trace Buffer Extension (TRBE) for Future Architecture Technologies in the A architecture profile. To target TRBE, select the following armclang options:

    • --target=aarch64-arm-none-eabi -march=armv8-a

  • [SDCOMP-54457]  Early support has been added for assembly for the Embedded Trace Extension (ETE) for Future Architecture Technologies in the A architecture profile. To target ETE, select the following armclang options:

    • --target=aarch64-arm-none-eabi -march=armv8-a

  • [SDCOMP-54456]  Early support has been added for assembly and intrinsics for the Transactional Memory Extension (TME) for Future Architecture Technologies in the A architecture profile. To target TME, select the following armclang options:

    • --target=aarch64-arm-none-eabi -march=armv8-a+tme

  • [SDCOMP-54455]  Alpha support has been added for assembly for the Armv8.6-A architecture. To target Armv8.6-A, select from the following armclang options:

    • --target=aarch64-arm-none-eabi -march=armv8.6-a for AArch64 state.
    • --target=arm-arm-none-eabi -march=armv8.6-a for AArch32 state.

  • [SDCOMP-54454]  Alpha support has been added for intrinsics for the BFloat16 Extension in Armv8.6-A. To target BFloat16, select from the following armclang options where <ext> is 2 or later:

    • --target=aarch64-arm-none-eabi -march=armv8.<ext>-a+bf16 for AArch64 state.
    • --target=arm-arm-none-eabi -march=armv8.<ext>-a+bf16 for AArch32 state.

  • [SDCOMP-53664]  Support has been added for the Star processor. To target Star, select from the following armclang options:

    • --target=arm-arm-none-eabi -mcpu=star for a variant with DSP and FP.
    • --target=arm-arm-none-eabi -mcpu=star+nodsp for a variant without DSP but with FP.
    • --target=arm-arm-none-eabi -mcpu=star -mfloat-abi=soft for a variant with DSP but without FP.
    • --target=arm-arm-none-eabi -mcpu=star+nodsp -mfloat-abi=soft for a variant without DSP and FP.

  • [SDCOMP-53663]  Support has been added for the Cortex-A65 processor. To target Cortex-A65, select the following armclang options:

    • --target=aarch64-arm-none-eabi -mcpu=cortex-a65

  • [SDCOMP-53662]  Support has been added for the Cortex-A77 processor. To target Cortex-A77, select from the following armclang options:

    • --target=aarch64-arm-none-eabi -mcpu=cortex-a77 for AArch64 state.
    • --target=arm-arm-none-eabi -mcpu=cortex-a77 for AArch32 state.

  • [SDCOMP-53600]  Early support has been added for assembly for the Scalar Vector Extension 2 (SVE2) for Future Architecture Technologies in the A architecture profile. To target SVE2, select from the following armclang options:

    • --target=aarch64-arm-none-eabi -march=armv8-a+sve2
    • --target=aarch64-arm-none-eabi -march=armv8-a+sve2-aes
    • --target=aarch64-arm-none-eabi -march=armv8-a+sve2-bitperm
    • --target=aarch64-arm-none-eabi -march=armv8-a+sve2-sha3
    • --target=aarch64-arm-none-eabi -march=armv8-a+sve2-sm4

  • [SDCOMP-53277]  Support has been added for the SysV dynamic linking model. Use the following options to enable this model:

    • armclang:
      • -fsysv to enable the generation of code suitable for the SysV linking model.
    • armlink:
      • --sysv to create a System V (SysV) formatted ELF executable file.

    For more information about these options, refer to the -fsysv, -fno-sysv and --sysv sections of the Reference Guide.

  • [SDCOMP-53102]  Support has been added for Arm C Language Extensions (ACLE) intrinsics for the optional Memory Tagging Extension in Armv8.5-A.

  • [SDCOMP-52927]  Support has been added for the memory tagging stack protection (stack tagging) feature for the optional Memory Tagging Extension in Armv8.5-A. The memory tagging stack protection feature can be used with the following options:

    • armclang:
      • -fsanitize=memtag to enable the generation of memory tagging code for protecting the memory allocations on the stack.
    • armlink:
      • --library_security=protection to override the automatic selection of protected libraries for branch protection and memory tagging stack protection.

    For more information about these options, refer to the -fsanitize and --library_security=protection sections of the Reference Guide.

  • [SDCOMP-51237]  In the C++ Thread Porting API, the name of the timespec structure has been changed to __ARM_TPL_timespec_t to avoid a namespace violation. Additionally, the type of the tv_nsec member of this structure has been changed from unsigned long to long.

    For more information about the C++ Thread Porting API, refer to the Multithreaded support in Arm C++ libraries [ALPHA] section of the Arm C and C++ Libraries and Floating-Point Support User Guide.

  • [SDCOMP-49562]  Support has been added for assembly and intrinsics for the Armv8.1-M architecture, including the optional M-profile Vector Extension (MVE). To target Armv8.1-M, select from the following armclang options:

    • --target=arm-arm-none-eabi -march=armv8.1-m.main for a variant without MVE.
    • --target=arm-arm-none-eabi -march=armv8.1-m.main+mve to enable MVE instructions for integer operations.
    • --target=arm-arm-none-eabi -march=armv8.1-m.main+mve.fp to enable MVE instructions for integer and single-precision floating-point operations.
    • --target=arm-arm-none-eabi -march=armv8.1-m.main+mve.fp+fp.dp to enable MVE instructions for integer, single-precision, and double-precision floating-point operations.

Enhancements in Arm Compiler 6.13

Compiler and integrated assembler (armclang)
  • [SDCOMP-51844]  Support has been added for the small and tiny code model types when compiling for AArch64 state. Use one of the following options to compile for these memory models:

    • -mcmodel=small to generate code for the small code model. The program and its statically defined symbols must be within 4GB of each other. This is the default code model.
    • -mcmodel=tiny to generate code for the tiny code model. The program and its statically defined symbols must be within 1MB of each other.

    Alpha support has been added for the large code model when compiling for AArch64 state. Use the following option to compile for the large memory model:

    • -mcmodel=large to generate code for the large code model. The compiler makes no assumptions about addresses and sizes of sections.

    For more information, refer to the -mcmodel section of the Reference Guide.

Defect fixes in Arm Compiler 6.13

Compiler and integrated assembler (armclang)
  • [SDCOMP-54132]  In certain circumstances, when compiling with -fstack-protector, -fstack-protector-all, or -fstack-protector-strong, the compiler could generate code that incorrectly failed to properly protect against buffer overflow. This has been fixed.

    In July 2019, cert.org published information about this vulnerability as LLVMs Arm stack protection feature can be rendered ineffective (VU#129209). Arm Compiler 6.12 is affected by this vulnerability. Versions before Arm Compiler 6.12 are not affected because the stack protection feature was not supported until Arm Compiler 6.12.

  • [SDCOMP-53862]  In certain circumstances, when compiling with C++ exceptions enabled for an Armv6-M target or an Armv8-M target without the Main Extension, the compiler could generate incorrect exception unwinding information for an inline assembly statement that contains one of the following registers in its clobber list:

    • R8.
    • R9.
    • R10.
    • R11.
    • R12.
    • R13 (SP).
    • R14 (LR).

    Subsequently, when an exception is thrown, the variables of the function could be corrupted. This has been fixed.

  • [SDCOMP-53783]  In certain circumstances, when compiling at any optimization level except -O0 for AArch32 state, the compiler could generate incorrect code for a variadic function arguments list that contains a struct that has a member of double type and is annotated with __attribute__((packed)). This has been fixed.

  • [SDCOMP-53771]  In certain circumstances, when compiling for AArch64 state, the compiler could generate incorrect code for a call to a vsqadd*() or vuqadd*() Neon intrinsic that passes a value of floating-point type as the second argument. This has been fixed.

  • [SDCOMP-53728]  In certain circumstances, when compiling with -MD or -MMD, and not with -MF, and the output filename does not contain a dot, the dependency information could be written to a file with an incorrect name. This has been fixed.

  • [SDCOMP-53569]  In certain circumstances, when compiling at any optimization level except -O0 for AArch32 state, the compiler could generate incorrect code for an expression that casts an integer type with a size smaller than 32 bits to a floating-point type. This has been fixed.

  • [SDCOMP-53506]  In certain circumstances, when compiling a program that uses a variadic function arguments list that contains an overaligned or underaligned parameter P, the compiler could generate code that incorrectly misaligned P. Such code did not confirm to the Parameter Passing section of the Procedure Call for the Arm Architecture ABI release 2.09 for AArch32 state, or the Parameter Passing section of the Procedure Call Standard for the Arm 64-bit Architecture ABI release 1.0 for AArch64 state. This has been fixed.

  • [SDCOMP-53434]  In certain circumstances, when compiling at any optimization level except -O0, the compiler could generate incorrect code for a function F that contains conditional accesses to the stack. Such incorrect code prematurely released stack memory that must remain reserved throughout the execution of F. This has been fixed.

  • [SDCOMP-53407]  In certain circumstances, when assembling for AArch32 state, the inline assembler and integrated assembler could incorrectly report error: invalid instruction or error: invalid operand for instruction for a CDP, CDP2, LDC, LDC2, MCR, MCR2, MCRR, MCRR2, MRC, MRC2, MRRC, MRRC2, STP, or STP2 instruction that specifies a coprocessor name (P<n>) or coprocessor register (C<n>) using an uppercase letter. This has been fixed.

  • [SDCOMP-53279]  In rare circumstances, when compiling at any optimization level except -O0 for T32 state, the compiler could incorrectly generate an invalid IT block. This has been fixed.

  • [SDCOMP-53271]  The inline assembler and integrated assembler incorrectly failed to report an error for a VFMAL or VFMSL instruction with a second source register operand that is not in the range D0-D7 or S0-S15. This has been fixed. The inline assembler and integrated assembler now report error: invalid instruction and either note: operand must be a register in range [d0, d7] or note: operand must be a register in range [s0, s15].

  • [SDCOMP-53213]  In certain circumstances, when assembling for AArch64 state, the inline assembler and integrated assembler could incorrectly report:

    • error: expected readable system register for an MRS instruction that specifies TTBR0_EL2 as the special register to be accessed.
    • error: expected writable system register or pstate for an MSR instruction that specifies TTBR0_EL2 as the special register to be accessed.

    This has been fixed.

  • [SDCOMP-53007]  In certain circumstances, when compiling at -Os or -Oz for AArch32 state, the compiler could incorrectly report fatal error: error in backend: ran out of registers during register allocation. This has been fixed.

  • [SDCOMP-52959]  In certain circumstances, when compiling at -Oz and with a -mbranch-protection option that enables branch protection using Branch Target Identification, the compiler could generate code containing a BTI instruction in an incorrect location. This has been fixed.

  • [SDCOMP-52933]  In certain circumstances, when compiling at any optimization level except -O0 for AArch32 state, the compiler could incorrectly fail to truncate a 16-bit integer to an 8-bit integer when required to do so. This has been fixed.

  • [SDCOMP-52918]  In certain circumstances, when compiling for AArch32 state and a target that supports a hardware floating-point unit but not the half-precision floating-point (FP16) extension, the compiler could generate incorrect code for a call to function which has a parameter of struct type that has a member of half-precision floating-point vector type. This has been fixed.

  • [SDCOMP-52910]  In certain circumstances, when compiling at any optimization level except -O0 for AArch32 state and a target that supports the half-precision floating-point (FP16) extension, the compiler could incorrectly report fatal error: error in backend: Cannot select: <value>. This has been fixed.

  • [SDCOMP-52828]  In certain circumstances, when compiling for T32 state and an Armv8-A target that supports a hardware floating-point unit, the compiler could generate an IT block that incorrectly contains a floating-point instruction. This has been fixed.

  • [SDCOMP-52632]  In certain circumstances, when compiling with -mfloat-abi=value, the code contains a function F with a homogenous aggregate parameter, and F is annotated with __attribute__((pcs("calling_convention"))), the compiler could generate code that incorrectly does not conform to the Procedure Call Standard for the Arm Architecture ABI release 2.09. This has been fixed.

  • [SDCOMP-51612]  In certain circumstances, when compiling at any optimization level except -O0 for AArch32 state and a target that supports a hardware floating-point unit, the compiler could generate incorrect code for throw statements that specify an exception object of a vector type that has an alignment requirement of 8 bytes. This has been fixed.

  • [SDCOMP-51181]  In certain circumstances, the compiler could generate incorrect code for a function which throws a C++ exception E when it can be proven that code following E is unreachable. This has been fixed.

  • [SDCOMP-51026]  In certain circumstances, when compiling at any optimization level except -O0 for AArch32 state, the compiler could generate incorrect code for a function that has a parameter of struct type that is more than 80 bytes in size, and performs multiple operations involving a variable that is 8 bytes in size. This has been fixed.

  • [SDCOMP-50736]  In certain circumstances, when compiling at -O0 for AArch32 state and a target that supports the half-precision floating-point (FP16) extension, the compiler could generate incorrect code for a struct that has a member of half-precision floating-point type. This has been fixed.

  • [SDCOMP-50723]  In certain circumstances, when compiling for AArch32 state and a target that supports the half-precision floating-point (FP16) extension, the compiler could generate a VLDR{<c>}{<q>}.16 or VSTR{<c>}{<q>}.16 instruction with an incorrect immediate offset. This has been fixed.

  • [SDCOMP-50722]  In certain circumstances, when compiling code at any optimization level except -O0 for AArch32 state and a big-endian target that supports the half-precision floating-point (FP16) extension, the compiler could incorrectly report error: clang frontend command failed due to signal. This has been fixed.

  • [SDCOMP-50507]  In certain circumstances, when compiling for a target that supports the half-precision floating-point (FP16) extension, the compiler could incorrectly report fatal error: error in backend or error: cannot compile this builtin function yet for a program that contains a call to a floating-point absolute compare intrinsic or a floating-point integer conversion intrinsic. This has been fixed.

    Additionally, support has been added for the floating-point multiply extended (by element) intrinsics, vmulxh_lane_f16() and vmulxh_laneq_f16().

  • [SDCOMP-50396]  In certain circumstances, when compiling for an Armv6-M target or an Armv8-M target without the Main Extension, the compiler could generate code that incorrectly corrupts a register by overwriting it with the value from R12. This has been fixed.

Linker (armlink)
  • [SDCOMP-53507]  In certain circumstances, when linking without --no_merge_litpools for T32 state, the linker could generate an output file containing symbol information that incorrectly failed to account for a function that changes in size as a result of the merging of identical constants. This has been fixed.

  • [SDCOMP-53500]  In certain circumstances, when linking with --paged, the linker could calculate the number of load segments incorrectly and subsequently generate a corrupted image. This has been fixed.

  • [SDCOMP-52081]  In certain circumstances, when linking a program with RW data compression enabled for AArch32 state, and the program contains a compressible execution region which references a symbol in a compressible execution region, the linker could generate an image that incorrectly does not contain a required function. This has been fixed.

  • [SDCOMP-51704]  In certain circumstances, when linking with a scatter file that contains a .ANY selector, the linker could incorrectly report Internal fault: [0xb3b91b:<ver>] or a Windows APPCRASH error. This has been fixed.

  • [SDCOMP-51507]  The linker incorrectly failed to report an error when the input objects contain conflicting stack or heap setup methods. Subsequently, this could result in unexpected run time behavior. This has been fixed. The linker now reports Error: 6915E: Library reports error: Conflicting stack/heap set up methods in use. __user_setup_stackheap, __user_initial_stackheap cannot be used with __initial_sp, __heap_base and __heap_limit.

  • [SDCOMP-51114]  In certain circumstances, the linker could incorrectly report Warning: L6412W: Disabling merging for <objname>(<secname>), unsupported relocation <type> from <srcobj>(<srcsec>). This has been fixed.

  • [SDCOMP-30573]  In certain circumstances, when linking with --partial, and an input object that has been compiled in a C++ source language mode contains a COMDAT group and either debug information or a .eh_frame section, the linker could incorrectly report Internal fault: [0x13429b:<ver>], Internal fault: [0x67fec6:<ver>], or Internal fault: [0xe81a5a:<ver>]. This has been fixed.

Libraries and system headers
  • [SDCOMP-54483]  The arm_neon.h system header incorrectly failed to define the poly64_t, poly64x1_t, and poly64x2_t types when compiling for AArch32 state. This has been fixed.

  • [SDCOMP-53777]  In certain circumstances, when the program is built for a target that supports a hardware floating-point unit, the Arm C++ library implementation of the std::binomial_distribution::operator() function could return an incorrect result. This has been fixed.

  • [SDCOMP-53677]  In certain circumstances, when using microlib and the program contains a call to the scanf() function with a non-constant format string, an issue in microlib could incorrectly cause the linker to report Error: L6218E: Undefined symbol. This has been fixed.

  • [SDCOMP-52285]  The Arm C library implementations of certain functions specified parameters that incorrectly did not conform to the Application Binary Interface (ABI) for the Arm Architecture for calls to the __aeabi_idiv0() or __aeabi_ldiv0() functions. This has been fixed.

  • [SDCOMP-52050]  In certain circumstances, the Arm C library implementation of the atan2f() function could incorrectly return positive zero instead of negative zero. This has been fixed.

  • [SDCOMP-51695]  The Arm C library implementation of the freopen() function incorrectly failed to return a null pointer when called with a null pointer as the filename parameter. This has been fixed.

  • [SDCOMP-50456]  The Arm C++ library variant built with C++ exception handling, for AArch32 state and a big-endian target, incorrectly failed to catch C++ exceptions. This has been fixed.

  • [SDCOMP-30358]  In certain circumstances, the Arm C++ library implementation of regex_traits::isctype() could return an incorrect result when the character class is the word character class. This has been fixed.

  • [SDCOMP-30357]  The Arm C++ library implementation of std::regex_traits<T>::lookup_classname() returned an incorrect value when its argument is equal to punct. This has been fixed.

Known issues in Arm Compiler 6.13

  • [SDCOMP-54453]  When disassembling an ELF file that contains a BFCSEL instruction and a relocation of type R_ARM_THM_BF12, the fromelf utility incorrectly reports the type of the relocation as R_ARM_THM_BF13.

  • [SDCOMP-54427]  In rare circumstances, when compiling with -fsanitize=memtag, the compiler can generate incorrect memory tagging code. Subsequently, this can result in spurious memory tagging exceptions against addresses in the stack area.

  • [SDCOMP-54391]  When compiling with -fstack-protector-strong at -O0, the compiler incorrectly fails to enable stack protection for functions containing certain kinds of address-taking of non-array local variables. To avoid this issue, compile with -fstack-protector-all instead of -fstack-protector-strong.

  • [SDCOMP-50470]  The compiler incorrectly fails to report an error for a function call that involves invalid default argument promotion for the _Float16 data type.