Arm Compiler 5 Downloads

This is the right place to find and download Arm Compiler 5 releases, the last generation based on the popular armcc compiler. Arm Compiler 5 provides stability and superb code size for legacy projects.

General update releases on the last branch, version 5.06, ended in H2 2017 with 5.06u6. After this, further support and maintenance will be available through Arm Compiler Long Term Maintenance releases with maintenance continuing until at least summer 2020. Arm Compiler 5.06 for Certification and Arm Compiler 5.06 Long Term Maintenance releases will each be supported by an Arm Compiler Qualification Kit.

Arm Compiler 5 can be used as a standalone tool (command line) or integrated into Arm Development Studio (installation instructions) or Keil MDK tool (installation instructions) suites, depending on your license. 

Haven’t got an Arm Compiler license?

Evaluate Arm Compiler in Development Studio
Buy Development Studio Buy Keil MDK

For the latest versions and legacy releases, visit Arm Compiler 6 Downloads and legacy compiler releases.

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

Downloads

Version 5.06 update 2

Released: January 27, 2016

Windows
File: DS500-PA-00002-r5p0-21rel0.zip (81.05 MB)
Linux
File: DS500-PA-00003-r5p0-21rel0.tgz (84.88 MB)

Release Note for Arm Compiler 5 Downloads 5.06 update 2

ARM Logo

Release notes for ARM Compiler 5.06 update 2 (build 183)

1. Introduction

ARM Compiler 5.06 is the final release series of ARM Compiler 5 and is succeeded by ARM Compiler 6.

For projects with safety certification requirements, specific releases will be available beginning with ARM Compiler 5.06 update 3 for Certification. After the normal ARM Compiler 5.06 maintenance period ends, further support and maintenance will be available through ARM Compiler Extended Maintenance. ARM Compiler 5.06 for Certification and ARM Compiler 5.06 Extended Maintenance releases will each be supported by an ARM Compiler Qualification Kit.

More information is available from the following links:

ARM Compiler 5.06 update 2 (build 183) is an update release to ARM Compiler 5.06 and is intended for use:

  • With DS-5 Professional Edition or DS-5 Ultimate Edition.
  • With Keil MDK-Standard, Keil MDK-Professional, or Keil MDK-Cortex-M.
  • As a standalone toolchain installation.

A suitable license from one of these products must be available. Contact your supplier or e-mail license.support@arm.com to enquire about a license.

If you are using a floating license, your license server must be running armlmd and lmgrd version 11.12.1.0 or later. In November 2015, Flexera published notification of security vulnerabilities that were discovered in the lmgrd and vendor daemon components of FlexNet Publisher. Flexera have no reason to believe that the vulnerabilities have been exploited but have nevertheless provided a security update in version 11.13.1.2. ARM recommends that you upgrade your license servers to the ltatest version of the license server software that is available from https://silver.arm.com/browse/BX002 (login/registration required).

2. Installation Instructions

If you received ARM Compiler 5.06 update 2 as part of a toolkit (DS-5 or Keil MDK), 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 5.06 update 2:

  • Integrated into DS-5 5.20 or later.
  • Integrated into Keil MDK 5.12 or later.
  • As a standalone product.

2.1. Integration into DS-5 5.20 or later

ARM Compiler 5.06 update 2 can be installed in any location, including the default location, providing this is outside of a DS-5 product installation.

After it is installed, you can integrate the toolchain with DS-5 5.20 or later by following the instructions in the tutorial available at https://developer.arm.com/products/software-development-tools/ds-5-development-studio/resources/tutorials/adding-new-compiler-toolchains-to-ds-5.

ARM recommends using ARM Compiler 5.06 update 2 from the DS-5 Eclipse IDE or DS-5 Command Prompt. When using the toolchain outside these environments, you might need to configure the following environment variables:

  • Set ARM_PRODUCT_PATH to the path to the sw/mappings directory within your DS-5 installation.
  • Set ARM_TOOL_VARIANT=ult if you are using the toolchain with DS-5 Ultimate Edition.

2.2. Integration into Keil MDK 5.12 or later

ARM Compiler 5.06 update 2 must be installed underneath the ARM subdirectory of the Keil MDK installation. For example, if your Keil MDK installation is in C:\Keil_v5 the recommended installation path is C:\Keil_v5\ARM\ARM_Compiler_5.06u2.

After it is installed, you can integrate the toolchain into an MDK project by following the instructions in the Application Note available at http://www.keil.com/appnotes/docs/apnt_267.asp.

2.3. Use as a standalone product

ARM Compiler 5.06 update 2 can be installed in any location, including the default location, providing this is outside of a DS-5 product installation and outside of a Keil MDK product installation.

Ensure that the ARMLMD_LICENSE_FILE environment variable is pointing to your license file or license server. Please note this path must not contain double quotes on Windows. A path that contains spaces will still work without the quotes.

2.4. Installation on Linux

ARM Compiler 5.06 update 2 has been tested on the following supported platforms:

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

Run Installer/setup.sh and follow the on-screen instructions.

Only a 32-bit installer is provided. The tools package includes a separate set of binaries that include a 64-bit version of armlink for use on 64-bit host platforms. See the documentation for details.

Some of the installed tools have dependencies on 32-bit system libraries. You must ensure that 32-bit compatibility libraries are installed when using ARM Compiler 5.06 update 2 on 64-bit Linux host platforms. ARM Compiler 5.06 update 2 tools might fail to run or report errors about missing libraries if 32-bit compatibility libraries are not installed. To install the required libraries, run the appropriate command for your platform with root privileges:

Red Hat
yum install glibc.i686
Ubuntu
apt-get install lib32stdc++6

2.5. Installation on Windows

ARM Compiler 5.06 update 2 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, 64-bit only.

Support for integration with Cygwin and translation of Cygwin paths is validated against the Cygwin distribution available at the time of each release.

Run Installer\setup.exe and follow the on-screen instructions.

Only a 32-bit installer is provided. The tools package includes a separate set of binaries that include a 64-bit version of armlink for use on 64-bit host platforms. See the documentation for details.

3. Uninstall

On Linux, delete the ARM Compiler 5.06 update 2 installation directory.

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

4. Documentation

The following documentation is available for the ARM Compiler 5.06 release series:

  • armar User Guide.
  • armasm User Guide.
  • armcc User Guide.
  • armlink User Guide.
  • fromelf User Guide.
  • ARM C and C++ Libraries and Floating-Point Support User Guide.
  • Errors and Warnings Reference Guide.
  • Getting Stated Guide.
  • Migration and Compatibility Guide.
  • Software Development Guide.

For more information, please see the ARM Compiler 5 documentation on developer.arm.com.

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 e-mail support-sw@arm.com with feedback or support issues. Where appropriate, please provide the --vsn output from the tool, and include any source code, other files, and command-lines necessary to reproduce the issue. The overall build number for ARM Compiler 5.06 update 2 can also be found in the title at the top of this document.

5. Release History and Changes

The following are the releases to date of the ARM Compiler 5.06 series:

  • 5.06 update 2 (released January 2016)
  • 5.06 update 1 (released September 2015)
  • 5.06 (released July 2015)

Below is a summary of the changes in each release, including new features and defect fixes. Changes are listed since the previous release in each case unless otherwise specified. Each itemized change is accompanied by a unique SDCOMP-<NNNNN> identifier. If you need to contact ARM about a specific issue within these release notes, please quote the appropriate identifier.

Changes in ARM Compiler 5.06 update 2

Enhancements in ARM Compiler 5.06 update 2

Linker (armlink)
  • [SDCOMP-30794]  Support has been added for the --no_unaligned_access linker option. This option prevents the linker from selecting objects from the ARM C library that permit unaligned accesses, and causes the linker to report one or more of the following downgradeable errors if any input object permits unaligned accesses:

    • Error: L6366E: <object> attributes<attr> are not compatible with the provided cpu and fpu attributes.
    • Error: L6367E: <object>(<section>) attributes<attr> are not compatible with the provided cpu and fpu attributes.
    • Error: L6368E: <symbol> defined in <object>(<section>) attributes<attr> are not compatible with the provided cpu and fpu attributes.

Defect fixes in ARM Compiler 5.06 update 2

Compiler (armcc)
  • [SDCOMP-30645]  In rare circumstances, when compiling expressions that only need to be evaluated due to side-effects such as volatile accesses or function calls, the compiler could report Internal fault: [0xcddbd6:<ver>]. This has been fixed.

  • [SDCOMP-30601]  In rare circumstances, when compiling with -Otime --vectorize at -O2 or above, the compiler could incorrectly report "no source": Warning: #68-D: integer conversion resulted in a change of sign. This has been fixed.

  • [SDCOMP-30568]  In rare circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate incorrect code for a multiplication that may overflow and involves integers of different types or widths. This has been fixed.

  • [SDCOMP-30556]  In certain circumstances, when compiling C++ code containing an expression of the form <condition> ? <expression1> : <expression2> where <condition> is a constant known at compile time and both <expression1> and <expression2> return class rvalues, the compiler could report Internal fault: [0x87ecef:<ver>] or a Windows APPCRASH error. This has been fixed.

  • [SDCOMP-30412]  In rare circumstances, when compiling at -O2 or above, the compiler could report Internal fault: [0x691cf6:<ver>]. This has been fixed.

  • [SDCOMP-30374]  When compiling C++11 code containing the type std::nullptr_t with --omf_browse, the compiler would incorrectly report KB: Unexpected type: 16 std::nullptr_t. This has been fixed.

  • [SDCOMP-30302]  In certain circumstances, when compiling with --use_frame_pointer at -O1 or above, the compiler could generate incorrect code for a tail call optimization that results in corruption of the frame pointer register. This has been fixed.

  • [SDCOMP-30286]  In certain circumstances, when compiling floating-point code with --cpu=7-M --fpu=FPv5_D16 at -O1 or above, the compiler could generate a sequence of code in which a VSEL instruction incorrectly appeared before the associated flag-setting instruction. This has been fixed.

  • [SDCOMP-30253]  When compiling C++ code without --gnu, the __sync_* family of GNU built-in functions were incorrectly specified to return void instead of the required type. This has been fixed.

  • [SDCOMP-30109]  In certain circumstances, when compiling with -Otime --vectorize at -O2 or above, the compiler could generate incorrect code when vectorizing expressions involving explicit type conversion from unsigned char and short to long. This has been fixed.

  • [SDCOMP-30027]  Previously, when compiling with --cpu=7, the compiler would incorrectly allow function definitions to be qualified with the __irq keyword. This is invalid because interrupt handler entry and exit sequences are not common across ARMv7-A, ARMv7-R, and ARMv7-M. This has been fixed. The compiler now reports Error: #3733: __irq functions cannot be generated for this architecture. To compile __irq functions to have the correct entry and exit sequences, replace --cpu=7 with --cpu=name where name is the name of a processor or architecture variant.

  • [SDCOMP-30013]  In rare circumstances, when compiling for Thumb state for a target that supports Thumb-2 technology, the compiler could generate incorrect code when a bitwise AND is involved in a conditional expression or in the controlling expression of a selection statement. This has been fixed.

  • [SDCOMP-30010]  In rare circumstances, when compiling for Thumb state for a target that supports Thumb-2 technology, at -O2 or above, the compiler could generate incorrect code for conditional expressions or statements. This has been fixed.

  • [SDCOMP-30003]  In certain circumstances, when compiling at -O1 or above, the compiler could generate an incorrect result when sign-extending an expression involving a variable whose address has previously been taken. This has been fixed.

  • [SDCOMP-30002]  In certain circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could incorrectly generate code that does not update the iteration variable of a for loop that contains a continue statement and is known at compile time to have one iteration. This has been fixed.

  • [SDCOMP-30001]  In certain circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate code that unconditionally executes statements contained in the body of a loop even though that loop may never be executed. This has been fixed.

  • [SDCOMP-30000]  In certain circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could incorrectly treat the result of an equality or relational operator as unsigned int instead of int. This has been fixed.

  • [SDCOMP-29993]  In certain circumstances, when compiling C++11 code containing a virtual method with a noexcept specifier that overrides a method from a template base class, the compiler could incorrectly report Error: #766-D: exception specification for virtual <entity> is incompatible with that of overridden <entity>. This has been fixed.

  • [SDCOMP-29947]  In certain circumstances, when compiling at -O1 or above, the compiler could generate incorrect code when an unsigned int is cast to a double and that double is then cast to a long long. This has been fixed.

  • [SDCOMP-29854]  In certain circumstances, when compiling C++11 code containing a constructor that is declared as a constexpr, the compiler could report Internal fault: [0x87ecef:<ver>] or a Windows APPCRASH error. This has been fixed.

  • [SDCOMP-29758]  In rare circumstances, when compiling NEON intrinsics at -O1 or above, or compiling with -Otime --vectorize at -O2 or above, the compiler could report Internal fault: [0xb36758:<ver>]. This has been fixed.

  • [SDCOMP-29388]  In certain circumstances, when compiling C++11 code that contains a braced literal struct initializer as an argument to a constructor, the compiler could report Internal fault: [0x87ecef:<ver>] or a Windows APPCRASH error. This has been fixed.

  • [SDCOMP-29386]  When compiling C++11 code containing an enum class type with --omf_browse, the compiler would report Internal fault: [0x87ecef:<ver>] or a Windows APPCRASH error. This has been fixed.

  • [SDCOMP-29384]  In certain circumstances, when compiling with --multifile, if the same variable is declared in multiple translation units and at least one of the declarations has an alignment attribute, the compiler could report Internal fault: [0x87ecef:<ver>] or a Windows APPCRASH error. This has been fixed.

  • [SDCOMP-29003]  In certain circumstances, when compiling C++11 code containing a variadic template T1 that is used in an alias template definition AT1, and AT1 is instantiated in another variadic template T2, when T2 is instantiated the compiler could incorrectly report Error: #304: no instance of <entity> matches the argument list. This has been fixed.

  • [SDCOMP-28973]  In certain circumstances, when compiling C++11 code containing variadic templates, the compiler could fail to properly substitute a variadic template argument when a given template has already been instantiated using similar expressions that should be considered distinct, and then incorrectly report Error: #871: template instantiation resulted in unexpected function type of <type>. This has been fixed.

  • [SDCOMP-26533]  In rare circumstances, when compiling with -Otime at -O2 or above, the compiler could incorrectly report "no source": Warning: #68-D: integer conversion resulted in a change of sign. This has been fixed.

  • [SDCOMP-26059]  In certain circumstances, when compiling source that contains an embedded assembler function on a Japanese Windows machine, and the username or TMP environment variable contain non-ASCII characters, the compiler could incorrectly report Fatal error: A1023E: File "<filename>" could not be opened: No such file or directory. This has been fixed.

  • [SDCOMP-26058]  In rare circumstances, when compiling source that contains an embedded assembler function on a Japanese Windows machine, the compiler could incorrectly report a Windows BEX error. This has been fixed.

  • [SDCOMP-25631]  In certain circumstances, when compiling with --vectorize at an inappropriate optimization level or for a target that does not support NEON, the compiler could incorrectly report Warning: C4361W: Loop optimizations can only be enabled at -O3 -Otime or --vectorize or fail to report a warning. This has been fixed. The compiler now reports either one or both of Warning: C4366W: Vectorization can only be enabled for targets with NEON capability and Warning: C4367W: Vectorization can only be enabled at -O3 -Otime or -O2 -Otime.

  • [SDCOMP-23625]  In rare circumstances, when compiling an inline assembler instruction involving a shift other than RRX, the compiler could incorrectly report Warning: C4007E: Uninitialised or corrupted use of PSR. This code may not work correctly. This has been fixed.

  • [SDCOMP-15500]  In certain circumstances, when an expression addressing an unsigned bitfield appears on the right-hand side of a comma operator and the other operand is of signed integer type, the compiler could incorrectly promote the result of the operator to unsigned type. This has been fixed.

Assembler (armasm)
  • [SDCOMP-25912]  When assembling MRS or MSR instructions that access the system registers PAR, TTBR0, or TTBR1 for a target that implements the Large Physical Address Extension (LPAE), the assembler would incorrectly report Error: A1902E: Specified special register not supported on target architecture. This has been fixed.

Linker (armlink)
  • [SDCOMP-24039]  In certain circumstances, the linker could report incorrect load addresses in messages of the form Error: L6788E: Scatter-loading of execution region <er1name> to [<base1>,<limit1>) will cause the contents of execution region <er2name> at [<base2>,<limit2>) to be corrupted at run-time. This has been fixed.

Libraries
  • [SDCOMP-30835]  The standard header stdint.h incorrectly defined the standard C macro UINTPTR_MAX as (2^31)-1 instead of (2^32)-1. This has been fixed.

  • [SDCOMP-30831]  The standard C library implementations of the printf() family of functions, when formatting a floating-point number in hexadecimal format using %a or %A, would incorrectly omit the hexadecimal-point character from the formatted output when the # flag is specified and the value after the hexadecimal point is zero. This has been fixed.

  • [SDCOMP-29760]  The standard C library implementations of the strtod() and scanf() families of functions would return incorrect results when parsing a string in C99 hexadecimal floating-point syntax, when all the digits before the hexadecimal point and at least one digit following the hexadecimal point are zero, for example "0x0.00E". This has been fixed.

Changes in ARM Compiler 5.06 update 1

General changes in ARM Compiler 5.06 update 1

  • [SDCOMP-29957]  The __sync_* family of GNU built-in functions were previously only available when compiling with --gnu. These functions are now available in all source language modes.

Defect fixes in ARM Compiler 5.06 update 1

Compiler (armcc)
  • [SDCOMP-29910]  When compiling for any processor except for Cortex-M processors, ARM Compiler 5.06 (build 20) would generate incorrect code for functions that are qualified with the __irq keyword. The generated code preserved only the registers that are required to be preserved by the AAPCS rather than preserving all processor registers. This has been fixed.

  • [SDCOMP-29862]  In certain circumstances, the compiler could incorrectly generate code that fails to load the top half of a 64-bit volatile value when only the bottom 32 bits are used by subsequent code. This has been fixed.

  • [SDCOMP-29767]  In rare circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate incorrect code when C99 designated initializers are used. This has been fixed. 

  • [SDCOMP-29633]  When compiling C++ code containing a static variable that is declared with __attribute__((section("name"))) in an inline function or an inline class member function, the compiler would incorrectly ignore the attribute. In certain circumstances, the compiler could also report Internal fault: [0x58a8aa:<ver>]. This has been fixed.

  • [SDCOMP-29585]  In rare circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate incorrect code when processing a nested loop where loop counters are used as part of an assignment statement within the innermost loop. This has been fixed.

  • [SDCOMP-29544]  In rare circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could incorrectly assume that the values of elements in a multi-dimensional array would not change from their initial values. This could result in the compiler generating incorrect code. This has been fixed.

  • [SDCOMP-29543]  In certain circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could incorrectly fail to sign extend the return value for a function that returns a signed integer when the expression receiving the returned value is of a wider integer type. This has been fixed.

  • [SDCOMP-29542]  In certain circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could incorrectly treat the result of an equality operator or a relational operator as unsigned int instead of int. This has been fixed.

  • [SDCOMP-29487]  In rare circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate incorrect code for loops that increment pointers and perform memory accesses. This has been fixed.

  • [SDCOMP-29464]  In rare circumstances, when compiling at -O1 or above, the compiler could generate a sequence of code that incorrectly used a flag-setting instruction, corrupting the flags required by a subsequent flag-reading instruction. This has been fixed.

  • [SDCOMP-29431]  In certain circumstances, the compiler could ignore a #pragma arm section directive related to read-only data for initialization constants when partially initializing a struct. This has been fixed.

  • [SDCOMP-29383]  In certain circumstances, when compiling C++11 code containing braced initialization lists for class members, with exceptions disabled, the compiler could report Internal fault: [0x87ecef:<ver>] or a Windows APPCRASH error. This has been fixed.

Libraries
  • [SDCOMP-29102]  The standard C library implementation of the strftime() function would generate incorrect results when using the %C or %h format specifiers. This has been fixed.

Other issues
  • [SDCOMP-29337]  In certain circumstances, the compiler could incorrectly report Error: C9558E: System clock tampering detected. License checkout will fail when files with very old timestamps are present in the file system. This has been fixed.

Changes in ARM Compiler 5.06

Changes are listed since the previous feature release, ARM Compiler 5.05.

General changes in ARM Compiler 5.06

  • [SDCOMP-22253]  The following changes have been made to supported host platforms:

    • Support for Windows 8 moves to Windows 8.1, 64-bit only.
    • Support has been deprecated for Windows XP Professional SP3.
    • Support has been deprecated for Windows Server 2008 R2.
    • Support has been deprecated for Ubuntu Desktop Edition 12.04 LTS.
    • Support has been deprecated for Red Hat Enterprise Linux 5 Desktop with Workstation option.

    From ARM Compiler 5.06 update 2, the deprecated host platforms are no longer supported.

  • [SDCOMP-29393]  Previously the installer did not support coexisting installations of different ARM Compiler 5 releases. Any existing installation was automatically removed or upgraded irrespective of the destination folder. This behavior has been changed. The installer will no longer automatically remove or upgrade an existing installation:

    • To create a coexisting installation, select a destination folder that does not contain an existing installation.
    • To replace or upgrade an existing installation, uninstall the existing version before installing the replacement.

  • [SDCOMP-24529]  Support for the following processors has been deprecated in ARM Compiler 5.06:

    • 88FR101.
    • 88FR101.hw_divide.
    • 88FR111.
    • 88FR111.no_hw_divide.
    • 88FR121.
    • 88FR121.hw_divide.
    • 88FR131.
    • 88FR131.hw_divide.
    • 88FR301.
    • 88FR301.hw_divide.
    • 88FR321.
    • 88FR321.hw_divide.
    • 88FR331.
    • 88FR331.hw_divide.
    • ARM710T.
    • ARM740T.
    • ARM7TDM.
    • ARM7TM.
    • ARM7TM-S.
    • ARM810.
    • ARM940T.
    • ARM968E-S.
    • ARM9EJ-S.
    • ARM1022E.
    • ARM1026EJ-S.
    • ARM1156T2F-S.
    • SA-110.
    • SA-1100.

    Replace affected --cpu=name options as follows:

    • Use --cpu=4 instead of --cpu=ARM810, --cpu=SA-110, or --cpu=SA-1100.
    • Use --cpu=ARM7TDMI instead of --cpu=ARM710T, --cpu=ARM740T, --cpu=ARM7TDM, --cpu=ARM7TM, or --cpu=ARM7TM-S.
    • Use --cpu=ARM9TDMI instead of --cpu=ARM940T.
    • Use --cpu=5TE instead of --cpu=88FR101, --cpu=88FR101.hw_divide, --cpu=88FR111, --cpu=88FR111.no_hw_divide, --cpu=88FR121, --cpu=88FR121.hw_divide, --cpu=88FR131, --cpu=88FR131.hw_divide, --cpu=88FR301, --cpu=88FR301.hw_divide, --cpu=88FR321, --cpu=88FR321.hw_divide, --cpu=88FR331, --cpu=88FR331.hw_divide, or --cpu=ARM968E-S.
    • Use --cpu=5TEJ instead of --cpu=ARM9EJ-S.
    • Use --cpu=ARM1020E instead of --cpu=ARM1022E or --cpu=ARM1026EJ-S.
    • Use --cpu=ARM1156T2-S --fpu=VFPv2 instead of --cpu=ARM1156T2F-S.

    From ARM Compiler 5.06 update 3, support for the deprecated processors has been removed.

  • [SDCOMP-13769]  The compiler now fully supports the following memory barrier instruction intrinsics:

    • __isb()
    • __dsb()
    • __dmb()

    Support has also been added for an additional optimization barrier intrinsic:

    • __force_loads()

    These intrinsics are described in the armcc User Guide.

  • [SDCOMP-25014]  The behavior of __declspec(noreturn) and __attribute__((noreturn)) has changed. If a function decorated with either extension implicitly or explicitly returns, the compiler now ignores the __attribute__((noreturn)) or __declspec(noreturn) and reports Warning: #1461-D: function declared with "noreturn" does return. This warning can be optionally downgraded or suppressed. The armcc User Guide provides more information about these extensions.

  • [SDCOMP-29571]  In certain circumstances, when compiling functions that are declared as deleted using the C++11 keyword delete, the compiler could report Warning #177-D: <entity> was declared but never referenced. This behavior has been changed. The warning is no longer reported in these cases.

  • [SDCOMP-25883]  In ARM Compiler 5.05, the behavior in --gnu mode was changed to not allow an lvalue reference to a const volatile argument type to be accepted as a match for an rvalue reference in overload resolution. This is strictly compliant with the C++ standard. In certain circumstances, this causes ARM Compiler 5.05 to report errors for C++ source that can be successfully compiled by previous releases of ARM Compiler. The behavior prior to ARM Compiler 5.05 has been restored for --gnu mode only.

  • [SDCOMP-25881]  In ARM Compiler 5.05, the behavior in --gnu mode was changed to always check that a copy constructor was callable and could be successfully instantiated even if it was being optimized out at a particular call. This is strictly compliant with the C++ standard. In certain circumstances, for example when a copy constructor that uses incomplete types is instantiated without the full type declarations being available, this causes ARM Compiler 5.05 to report errors for C++ source that can be successfully compiled by previous releases of ARM Compiler. The behavior prior to ARM Compiler 5.05 has been restored for --gnu mode only.

  • [SDCOMP-29787]  The compiler previously ignored #pragma arm section [section_type_list] for out-of-line copies of inline functions. This behavior has been changed. The pragma now also affects out-of-line copies of inline functions. To restore the previous behavior, use the following option:

    • --no_ool_section_name

  • [SDCOMP-29788]  When linking using --partial, the linker previously generated an SHT_ARM_ATTRIBUTES section containing file-scope build attributes set to Tag_nodefaults. All build attribute tags were described in each individual SHF_ALLOC section. This behavior has been changed. The linker now generates file-scope build attributes that describe the most restrictive compatibility requirements of the SHF_ALLOC sections. This change in behavior increases compatibility with other toolchains. Both the previous and new behavior conform to the Application Binary Interface for the ARM Architecture.

  • [SDCOMP-29592]  The default --gnu_version has been changed from 40200 to 40700. Unless a different --gnu_version=version is specified, the compiler now emulates the behavior of GCC version 4.7.0 as closely as possible when the --gnu option is used.

  • [SDCOMP-28484]  The control of license management warnings has been improved:

    • The --diag_remark and --diag_suppress options can now be used to downgrade or suppress all license management warnings.
    • The --diag_error=warning option now upgrades all warnings except for license management warnings to error severity.

  • [SDCOMP-17855]  The __ldrex and __strex family of intrinsics have been deprecated, and use of the LDREX and STREX family of instructions in inline assembly code has also been deprecated. Use one of the following alternatives:

    • Write code that uses these instructions in an embedded assembler function.
    • Use an appropriate member of the __sync_* family of GNU built-in functions, for example __sync_lock_test_and_set().

  • [SDCOMP-28842]  The --fpu option has been extended to support the FPv5 architecture:

    • --fpu=FPv5_D16 selects a hardware floating-point unit conforming to the FPv5-D16 architecture.
    • --fpu=FPv5-SP selects a hardware floating-point unit conforming to the single-precision variant of the FPv5 architecture.
    • --fpu=SoftVFP+FPv5_D16 selects a hardware floating-point unit conforming to FPv5-D16, with software floating-point linkage.
    • --fpu=SoftVFP+FPv5-SP selects a hardware floating-point unit conforming to FPv5-SP, with software floating-point linkage.

  • [SDCOMP-30343]  Support has been added for a workaround for the ARM Cortex-M3 erratum 838469. To enable the workaround, use the following compiler option:

    • --branchpatch=cortex-m3-838469

  • [SDCOMP-30400]  Support has been added for a workaround for the ARM Cortex-M4 erratum 838869. To enable the workaround, use the following compiler option:

    • --branchpatch=cortex-m4-838869

Defect fixes in ARM Compiler 5.06

Compiler (armcc)
  • [SDCOMP-29640]  In certain circumstances, when compiling for a hardware floating-point unit conforming to the single-precision variant of the FPv5 architecture, the compiler could report Internal fault: [0xd82ad8:<ver>] when processing an expression that uses the conditional operator ? : with a floating-point value or variable. This has been fixed.

  • [SDCOMP-29304]  In rare circumstances, when compiling at -O2 or above, the compiler could generate incorrect code when the result of an arithmetic expression containing a bitwise Exclusive OR and a bitwise OR operator is assigned to a variable of integer type that is smaller than a 32-bit integer. This has been fixed.

  • [SDCOMP-29280]  In rare circumstances, when compiling at -O1 or above, the compiler could generate incorrect code when a location in memory is written to without using volatile followed by another write to the same location that does use volatile. This has been fixed.

  • [SDCOMP-29267]  In rare circumstances, when compiling at -O2 or above, the compiler could incorrectly optimize an expression involving two operators that are either:

    • Both bitwise OR.
    • Both bitwise Exclusive OR.
    • A combination of bitwise OR and bitwise Exclusive OR.

    This has been fixed.

  • [SDCOMP-29261]  In rare circumstances, when compiling for Thumb state, the compiler could generate incorrect code for a program that reads from a number of contiguous memory locations where it can be determined that some of the reads can be eliminated. This could result in a failure to load some of the required data. This has been fixed.

  • [SDCOMP-29257]  In certain circumstances, when compiling with --debug or -g, the compiler could produce incomplete debug information for data that is allocated to registers rather than memory. This has been fixed.

  • [SDCOMP-29252]  In rare circumstances, when compiling at -O2 or above, the compiler could incorrectly allocate variables local to a block of code to the same memory locations as variables outside of the block of code. This has been fixed.

  • [SDCOMP-29222]  In rare circumstances, when compiling for ARM state, the compiler could generate incorrect code for calculating addresses for loads and stores. This has been fixed.

  • [SDCOMP-29191]  In rare circumstances, when compiling with -Otime --vectorize at -O2 or above, the compiler could generate incorrect code when vectorizing a loop that writes to an array. This has been fixed.

  • [SDCOMP-29189]  In rare circumstances, when compiling with -Otime --vectorize at -O2 or above, the compiler could generate incorrect code for a loop that casts the elements of an array of integer type to float to perform a floating-point calculation, and the result is cast back to an integer type for further calculations. This has been fixed.

  • [SDCOMP-29160]  In certain circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate incorrect code for a for loop that modifies a pointer which aliases the loop index. This could result in an incorrect number of iterations of the loop. This has been fixed.

  • [SDCOMP-29158]  In rare circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate incorrect code for a program containing nested for loops, resulting in an inner loop body incorrectly being executed. This has been fixed.

  • [SDCOMP-29157]  In rare circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate incorrect code for expressions of the form A & B when one of A or B can be evaluated at compile time to zero and the other expression contains an increment or decrement operator. This has been fixed.

  • [SDCOMP-29155]  In rare circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate incorrect code when a parameter of a function is always passed the same value, and the value is not in range of the type of the parameter. This has been fixed.

  • [SDCOMP-29151]  In rare circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate incorrect code for a control statement having a controlling expression of the form A <= B or A > B, where expression A can be evaluated at compile time to zero and B is of an unsigned type. This has been fixed.

  • [SDCOMP-29117]  In rare circumstances, when compiling at -O2 or above, the compiler could generate code containing execution paths that do not have correctly balanced PUSH and POP instructions. This could corrupt the stack, resulting in incorrect behavior. This has been fixed.

  • [SDCOMP-29030]  In rare circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate incorrect code for expressions of the form A relational-operator B when both A and B are of integer type and have known values at compile time. This has been fixed.

  • [SDCOMP-29029]  In rare circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate incorrect code for a for loop that has an iteration variable, X, where X is of signed integer type, has an initial value that is not known at compile time, and that may overflow or underflow the range of values for its type. This could result in the loop body not being entered for all the expected initial values of X. This has been fixed.

  • [SDCOMP-29028]  In rare circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could incorrectly fail to generate code for an if statement where the value of the controlling expression, except for any side-effects, can be evaluated at compile time. This has been fixed.

  • [SDCOMP-29026]  In rare circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate incorrect code for a for loop that has an iteration variable, X, that must overflow or underflow in order to reach the loop termination condition, and X is of signed char or signed short type. This could result in a failure to enter the loop body. This has been fixed.

  • [SDCOMP-29025]  In certain circumstances, when compiling at -O3 -Otime or --vectorize, the compiler could generate incorrect code for accesses to members of structures declared under #pragma pack(4). This has been fixed.

  • [SDCOMP-28950]  In rare circumstances, when compiling for Thumb state at -O2 or above, the compiler could generate a sequence of code that incorrectly contains a flag-setting MULS instruction rather than the non-flag-setting MUL instruction. This has been fixed.

  • [SDCOMP-28790]  In rare circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could incorrectly pass only the first character when a string literal is used as the argument for a C++ function parameter that is a reference to an array of characters. This has been fixed.

  • [SDCOMP-28788]  In rare circumstances, when inlining a function into the main() function at -O3 -Otime or with --vectorize, the compiler could incorrectly remove a write to a global variable by the function being inlined. This has been fixed.

  • [SDCOMP-28753]  In certain circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate incorrect code when unrolling a loop. This has been fixed.

  • [SDCOMP-28700]  When compiling code that contains lvalue casts with --gnu --gnu_version=30400, the compiler would report Internal fault: [0x87ecef:<ver>] or a Windows APPCRASH error. This has been fixed.

  • [SDCOMP-28669]  In rare circumstances, when compiling conditional expressions for ARM state at -O2 or above, the compiler could report Internal fault: [0xe4ffdb:<ver>]. This has been fixed.

  • [SDCOMP-28666]  When compiling C++11 code containing an expression of the form (void)v or static_cast<void>(v) where v is a volatile variable, the compiler would incorrectly fail to generate a read from v. This has been fixed.

  • [SDCOMP-28651]  In certain circumstances, the compiler could generate incorrect code for a chained struct or class assignment x = y = z, resulting in the rvalue expression z being evaluated more than once. This has been fixed.

  • [SDCOMP-28552]  In rare circumstances, when compiling at -O2 or above, the compiler could generate incorrect code for assignment expressions involving nested conditionals when the assigned value is never used. The assignment could be written to the wrong variable, resulting in incorrect behavior. This has been fixed.

  • [SDCOMP-28423]  When compiling with --cpp11 -g or --cpp11 --debug, use of the type std::nullptr_t would cause the compiler to report Internal fault: [0x6983ab:<ver>], Internal fault: [0xd1dee6:<ver>], or Internal fault: [0xe66931:<ver>]. This has been fixed.

  • [SDCOMP-28421]  When compiling with --cpp11, an expression involving an assignment to an rvalue reference of type std::nullptr_t would cause the compiler to report Internal fault: [0x44784c:<ver>]. This has been fixed.

  • [SDCOMP-28420]  In certain circumstances, when compiling with --cpp11, the compiler could incorrectly ignore a constexpr specifier resulting in one or more reports of Error: #28: expression must have a constant value or Error: #3673: function call must have a constant value in a constant expression. This has been fixed.

  • [SDCOMP-28391]  When compiling a virtual destructor that has an exception specification with --cpp11 --exceptions, the compiler would incorrectly report Error: #766-D: exception specification for virtual <entity> is incompatible with that of overridden <entity>. This has been fixed.

  • [SDCOMP-28328]  When compiling with --cpp11 --omf_browse=filename.crf, a scoped enumeration declared with enum class or enum struct would cause the compiler to report Internal fault: [0x87ecef:<ver>] or a Windows APPCRASH error. This has been fixed.

  • [SDCOMP-28288]  In certain circumstances, when compiling with --cpp11 at -O3 -Otime, the compiler could report Internal fault: [0x6bca8b:<ver>]. This has been fixed.

  • [SDCOMP-28272]  In certain circumstances, when preprocessing a source file that uses a multibyte encoding in which ordinary ASCII characters can appear as consecutive bytes of a multibyte character, the compiler could incorrectly expand macros containing the # operator. This could result in error messages such as Error: #8: missing closing quote or Error: #54-D: too few arguments in invocation of macro <macro>. This has been fixed.

  • [SDCOMP-27405]  In rare circumstances, when compiling for Thumb state, the compiler could generate incorrect code when explicitly or implicitly adding, subtracting, or comparing to an integer constant and that constant cannot be directly encoded in the immediate field of an ADD or ADDS instruction. This has been fixed.

  • [SDCOMP-26522]  When compiling C++ code that stores the address of a member function in a class or struct member, the compiler would place the address of that member function in a read-write data section instead of a read-only data section. This has been fixed.

  • [SDCOMP-26133]  When compiling a union containing a class type that indirectly includes a volatile class-type field, the compiler would incorrectly report Error: #294: invalid union member -- <entity> has a disallowed member function. This has been fixed.

  • [SDCOMP-26055]  The compiler incorrectly failed to issue any warning when an __attribute__((at(address))) is overwritten by an __attribute__((section("name"))) or a different __attribute__((at(address))). This has been fixed. The compiler now reports Warning: #3730-D: section name conflicts with previous declaration .ARM.__AT_<address>.

  • [SDCOMP-26023]  In rare circumstances, when compiling code containing NEON intrinsics, the compiler could report Internal fault: [0x48c94b:<ver>] or Internal fault: [0x7b3e71:<ver>]. This has been fixed.

  • [SDCOMP-26015]  When compiling code that contains __attribute__((bitband)) with --cpu=SC300, the compiler would incorrectly report Error: #1114: this feature not supported on target architecture/processor. This has been fixed.

  • [SDCOMP-25946]  In rare circumstances, when compiling at -O2 or above, the compiler could generate a sequence of code that incorrectly contains a flag-setting variant of an instruction rather than the non-flag-setting variant. This has been fixed.

  • [SDCOMP-25900]  In certain circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate incorrect code for a loop that contains only if statements with bodies that are never executed and are either empty or contain only a break or continue statement. This has been fixed.

  • [SDCOMP-25894]  In certain circumstances, when compiling at -O1 or above, when reading a bitfield of type long long or unsigned long long from a struct that has been declared packed using any of __attribute__((packed)), #pragma pack(n), or the __packed qualifier, and the code is not compiled for unaligned accesses, the compiler could generate code that loaded data from memory beyond the end of the struct. This has been fixed.

  • [SDCOMP-25885]  In certain circumstances, when compiling code that contains preprocessor macros, ARM Compiler 5.05 (build 41) and 5.05 update 1 (build 106) could take significantly longer than previous releases of ARM Compiler 5. This has been fixed.

  • [SDCOMP-25845]  The compiler would generate incorrect code for a chained struct assignment if the left-hand side of the assignment is a volatile struct and the right-hand side is another assignment expression that does not involve an assignment to or from a volatile struct. This has been fixed.

  • [SDCOMP-25839]  When __attribute__((const)) or __attribute__((noreturn)) is specified for both a virtual method and an overriding method, the compiler would incorrectly report Error: #1510: function "__attribute__((__<entity>__))" present on overridden virtual function <entity> must be present on overridding function. This has been fixed.

  • [SDCOMP-25836]  In rare circumstances, when compiling at -O3 -Otime, a combination of optimizations could result in an incorrect transformation, causing the compiler to report Internal fault: [0x2732f5:<ver>]. This has been fixed.

  • [SDCOMP-25830]  In certain circumstances, the compiler could generate incorrect code for a copy assignment of a struct that contains both non-volatile and volatile bitfields. This has been fixed.

  • [SDCOMP-25811]  In certain circumstances, when compiling with --diag_warning=error to downgrade error messages to warning severity, the compiler could incorrectly fail to generate an object file even though it returned a zero exit code. This has been fixed.

  • [SDCOMP-25767]  When compiling a main() function that is declared __declspec(noreturn) void, the compiler would incorrectly report Warning: #951-D: return type of function "main" must be "int". This has been fixed.

  • [SDCOMP-25761]  In certain circumstances, when compiling at -O2 or above, the compiler could generate incorrect code when integer constant values with the same binary representation are used in two different expressions, and the first of these expressions includes a bitwise Exclusive OR. This has been fixed.

  • [SDCOMP-25725]  In rare circumstances, when compiling for Thumb state at -O3, the compiler could report Internal fault: [0xe4ffdb:<ver>]. This has been fixed.

  • [SDCOMP-25720]  When compiling an __ldrex or __strex intrinsic and the pointer argument is not of pointer-to-integer or pointer-to-pointer type, the compiler would incorrectly report Error: #31: expression must have integral type. This has been fixed.

  • [SDCOMP-25575]  In certain circumstances, the compiler could generate incorrect code for accesses to a volatile bitfield member of a struct where the bitfield container is narrower than the bitfield container type but wider than one byte. This has been fixed.

  • [SDCOMP-25496]  In rare circumstances, when compiling with --cpp11 at -O3 -Otime, the compiler could report Internal fault: [0x518125:<ver>], Internal fault: [0x66a710:<ver>], or Internal fault: [0xab8feb:<ver>]. This has been fixed.

  • [SDCOMP-25485]  In certain circumstances, when compiling with -Otime --vectorize at -O2 or above, a loop that copies an array of structures in decreasing address order could be incorrectly transformed by the compiler into a copy by increasing address order. When the source and destination memory areas overlap, this could result in incorrect behavior. This has been fixed.

  • [SDCOMP-25465]  In certain circumstances, when compiling for Thumb state with -Otime at -O2 or above, code containing a comparison with a number that cannot be used as an immediate with the ADDS instruction could cause the compiler to report Internal fault: [0xcbb629:<ver>]. This has been fixed.

  • [SDCOMP-24118]  When compiling with --debug or -g, the compiler would generate incomplete .debug_loc section information for function parameters held in registers. This has been fixed.

  • [SDCOMP-23730]  When compiling code that accesses an array member of a temporary instance of a non-POD class or struct, the compiler would report Internal fault: [0x05ced5:<ver>]. This has been fixed.

  • [SDCOMP-23712]  In certain circumstances, when compiling code that accesses the CPSR, the compiler could report Internal fault: [0x674afd:<ver>], Internal fault: [0xc43ed8:<ver>], or Internal fault: [0xe40a12:<ver>]. This has been fixed.

  • [SDCOMP-22697]  In rare circumstances, when compiling at -O3 -Otime, the compiler could fail to apply certain optimizations to loops that include one or more empty statements. This has been fixed.

  • [SDCOMP-21864]  When compiling code that contains a #pragma pack(n) followed by a #pragma pop, with no declarations between them, the compiler would incorrectly ignore the #pragma pop. This has been fixed.

  • [SDCOMP-11575]  In rare circumstances, when compiling a C++ constructor for a derived class, and the complete constructors of the object and subobject are not combined, the compiler could generate code that is not fully compliant with the Itanium C++ ABI. When linked with code built using a different C++ compiler, this could result in a run-time error. This has been fixed. This change does not affect compatibility with code generated by earlier versions of ARM Compiler.

Assembler (armasm)
  • [SDCOMP-25862]  When assembling the MSR instruction for an ARMv7-M processor, the assembler would not recognize the _<bits> qualifier for the IAPSR, EAPSR, and XPSR registers. This has been fixed.

  • [SDCOMP-23084]  In rare circumstances, the assembler could generate incorrect output for the --list option. This has been fixed.

Linker (armlink)
  • [SDCOMP-29055]  In certain circumstances, when linking using the --cpp_compat option, the linker could report Error: L6173E: Unmangled symbol name <symbol> does not have a unique mangled name as a result of incorrectly processing unnamed namespaces. This has been fixed.

  • [SDCOMP-28957]  In certain circumstances, when resolving an Image$$region_name$$Length symbol for an empty execution region, the linker could report Error: L6286E: ARM Linker: Execution interrupted due to an illegal storage access or a Segmentation fault. This has been fixed.

  • [SDCOMP-28370]  In rare circumstances, when linking a program using the --veneer_inject_type=pool option, the linker could report Internal fault: [0xeb14f5:<ver>]. This has been fixed.

  • [SDCOMP-26071]  In certain circumstances, when resolving a relocation to a linker-generated Load$$ symbol, and read-write data in one or more preceding execution regions is compressed, the linker could incorrectly calculate that value of the symbol. This has been fixed.

  • [SDCOMP-24767]  When generating veneers, a data section that includes a symbol with type STT_FUNC would cause the linker to report ARM Linker: Execution interrupted due to an illegal storage access. This has been fixed. The linker now reports Warning: L6171W: Code symbol <symname> defined in non executable section <secname> and Error: L6169E: Relocation #REL:<rel_number> in <secname> with respect to <symname>. Branch to code symbol defined in non executable section <secname>.

  • [SDCOMP-17870]  When linking a program using --list=filename, if filename could not be opened for writing the linker would report a Segmentation fault. This has been fixed.

  • [SDCOMP-12939]  In certain circumstances, the linker could report Error: L6286E: ARM Linker: Execution interrupted due to an illegal storage access instead of Error: L6286E: Relocation #<rel_class>:<rel_number> in <objname>(<secname>) with respect to <symname>. Value(<val>) out of range(<range>) for (<rtype>). This has been fixed.

Libraries
  • [SDCOMP-28709]  The ARM C library function _fisatty() would incorrectly return 0 instead of 1 when stdout is attached to a terminal device. This has been fixed.

  • [SDCOMP-28672]  In certain circumstances, the std::deque::operator++() and std::deque::operator+=() methods implemented in deque and deque.cc could incorrectly load data from memory beyond the area allocated for the deque. This could result in a run-time error. This has been fixed.

  • [SDCOMP-28636]  The std::vector::operator=() method implemented in vector.cc contained an error that would corrupt the internal information of the destination vector when the size of the source vector is smaller than the size of the destination vector. This has been fixed.

  • [SDCOMP-25856]  The standard C library and microlib implementations of the casin(), casinf(), and casinl() functions would incorrectly return the imaginary part of the result as NaN instead of 0 when computing the complex inverse sine of a real number greater than -1.0 and less than +1.0. This has been fixed.

Other issues
  • [SDCOMP-28980]  In certain circumstances, when preprocessing a scatter-file, the link step could require two compiler licenses concurrently. This has been fixed.

  • [SDCOMP-26076]  In certain circumstances, the tools could unintentionally report licensing error 9558E: System clock tampering detected. This has been fixed.

  • [SDCOMP-24626]  In rare circumstances, the --cpu=list option could incorrectly fail to list the supported processors and architectures. This has been fixed.

  • [SDCOMP-17536]  In certain circumstances, the tools could fail to find an input file when given a relative path of the form ./../dir/input_file resulting in an Error. This has been fixed.

Known issues in ARM Compiler 5.06

  • [SDCOMP-29910]  When compiling for any processor except for Cortex-M processors, ARM Compiler 5.06 (build 20) generates incorrect code for functions that are qualified with the __irq keyword. The generated code preserves only the registers that are required to be preserved by the AAPCS rather than preserving all processor registers. For example:

    extern unsigned int x, y;
    __irq void foo(void) { x = y; }
    

    Compiled with --asm -O0 using ARM Compiler 5.05 update 2 (build 169):

    ||foo|| PROC
            PUSH     {r0,r1}
            LDR      r0,|L1.28|
            LDR      r0,[r0,#0]  ; y
            LDR      r1,|L1.32|
            STR      r0,[r1,#0]  ; x
            POP      {r0,r1}
            SUBS     pc,lr,#4
            ENDP
    

    Compiled with --asm -O0 using ARM Compiler 5.06 (build 20):

    ||foo|| PROC
            LDR      r0,|L1.20|
            LDR      r0,[r0,#0]  ; y
            LDR      r1,|L1.24|
            STR      r0,[r1,#0]  ; x
            SUBS     pc,lr,#4
            ENDP
    

    A workaround is to wrap affected interrupt handler functions with assembly language functions that save and restore the additional registers, and remove the __irq keyword from the original functions. For example:

            AREA     |.irq_workaround|, CODE, READONLY
            EXPORT   |$Sub$$irq_handler|
            IMPORT   |$Super$$irq_handler|
    |$Sub$$irq_handler| PROC
            PUSH     {r0-r3,r12,lr}      ; save registers
            BL       |$Super$$irq_handler|
            POP      {r0-r3,r12,lr}      ; restore registers
            SUBS     pc,lr,#4
            ENDP
            END
    

    ARM Compiler 5.06 (build 20) is the only release affected by this issue. All previous releases of the ARM Compiler are not affected. This issue has been fixed in ARM Compiler 5.06 update 1 (build 61) under change identifier SDCOMP-29910.