Release notes for Arm Compiler 5.06 update 7

# Release notes for Arm Compiler 5.06 update 7 (build 960)

## Table of Contents

## 1. Introduction

This is the initial set of release notes provided at the time of the release. For the latest copy of the release notes, please visit https://developer.arm.com.

Arm Compiler 5.06 update 7 is the final planned maintenance update to Arm Compiler 5.06. For projects with safety certification requirements, Arm Compiler 5.06 update 7 has a safety certified variant which is accompanied by a Qualification Kit and TÜV Certification Pack. More information is available at https://developer.arm.com/tools-and-software/embedded/arm-compiler/safety.

Arm Compiler 5 is a proven and mature toolchain for the Arm targets that it supports. With this release, Arm Compiler 5 becomes a legacy product and has reached the end of Mainstream Support. If this causes concern to your projects, please contact your supplier or visit https://developer.arm.com/support and open a case. It can still be used for:

- Existing projects.
- New projects for legacy Armv4, Armv5, or Armv6 targets.

For all other new projects, Arm strongly recommends that you upgrade to the latest release of Arm Compiler 6 (or later). More information is available at https://developer.arm.com/tools-and-software/embedded/arm-compiler.

Arm Compiler 5.06 update 7 is intended for use:

- In conjunction with an Arm Development Studio toolkit.
- In conjunction with a Keil MDK toolkit (Windows only).
- In conjunction with a legacy DS-5 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/tools-and-software/embedded/arm-compiler/buy 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.

## 2. Installation Instructions

If you received Arm Compiler 5.06 update 7 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 5.06 update 7:

- Integrated into Arm Development Studio 2019.1 or later
- Integrated into Keil MDK 5.12 or later.
- Integrated into the legacy DS-5 5.20 or later.
- As a standalone product.

Unless you are using Keil MDK, Arm Compiler 5.06 update 7 can be installed in any location, including the default location, providing this is outside of an Arm Development Studio or DS-5 product installation directory.

Please refer to the important 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 2019.1 or later

You can integrate the toolchain with Arm Development Studio by following the instructions available at https://developer.arm.com/documentation/101470/2000/Configure-Arm-Development-Studio/Register-a-compiler-toolchain.

### 2.2. Integration into Keil MDK 5.12 or later

Arm Compiler 5.06 update 7 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.06u7`.

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.

With an MDK license, Arm Compiler 5.06 update 7 is supported on Windows only.

### 2.3. Integration into DS-5 5.20 or later

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/tools-and-software/embedded/legacy-tools/ds-5-development-studio/resources/tutorials/adding-new-compiler-toolchains-to-ds-5.

### 2.4. Use as a standalone product

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.5. Installation on Linux

Arm Compiler 5.06 update 7 has been tested on the following supported platforms:

- Red Hat Enterprise Linux 6 Workstation.
- Red Hat Enterprise Linux 7 Workstation.
- Ubuntu Desktop Edition 14.04 LTS, 64-bit only.
- Ubuntu Desktop Edition 16.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 7 on 64-bit Linux host platforms. Arm Compiler 5.06 update 7 tools may fail to run or report errors about missing libraries if 32-bit compatibility libraries are not installed.

For example, the tools may report one of the following errors:

- `/path/to/armcc: No such file or directory`.
- `Internal fault: [0x87ecef:<ver>]`.

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 lib32z1`

On Ubuntu 16.04 LTS systems, an additional 32-bit library is required. To install the required library, run the following command with root privileges:

  `apt-get install libc6:i386`

The commands for Ubuntu have been tested on a clean installation based on the default configuration of Ubuntu Desktop Edition 16.04 LTS, 64-bit only. You may need to run additional commands if you have a custom configuration of Ubuntu 16.04 LTS.

### 2.6. Installation on Windows

Arm Compiler 5.06 update 7 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.
- Windows 10, 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 7 installation directory.

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

## 4. Documentation

Documentation for the Arm Compiler 5.06 release series is available on https://developer.arm.com and comprises:

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

## 5. Feedback and Support

Your feedback is important to us, and you are welcome to send us defect reports 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 5.06 series:

- 5.06 update 7 (released September 2020)
- 5.06 update 6 (released September 2017)
- 5.06 update 5 (released February 2017)
- 5.06 update 4 (released September 2016)
- 5.06 update 3 (released May 2016)
- 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 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 5.06 update 7

#### Defect fixes in Arm Compiler 5.06 update 7

##### Compiler (armcc)

- [SDCOMP-54083] In certain circumstances, when compiling with `--protect_stack` or `--protect_stack_all`, the compiler could generate code that incorrectly failed to mitigate against certain stack underflow attacks. This has been fixed.

- [SDCOMP-53915] In certain circumstances, when compiling at `-O1` or above, the compiler could incorrectly ignore the left-hand operand of a comma operator that is used in the controlling expression of a `do-while` loop. This has been fixed.

- [SDCOMP-53352] In certain circumstances, when compiling with `--vectorize`, the compiler could generate incorrect code for a loop that contains a call to the Arm C library implementation of the `abs()` function. This has been fixed.

- [SDCOMP-52907] In certain circumstances, when compiling at `-O1` or above, and for a target that supports the `SMULWB` and `SMULWT` instructions, the compiler could generate incorrect code for a multiplication operation that is followed by a right shift operation. This has been fixed.

- [SDCOMP-52619] In certain circumstances, when compiling code that contains a function `F` which does not return and is annotated with `__attribute__((weak))` or `__weak`, the compiler could generate code which incorrectly assumed that the final image does not contain a non-weak definition of `F` that does return. This has been fixed.

- [SDCOMP-52460] In certain circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code for a `break` statement within a loop that is within a `switch` statement. This has been fixed.

- [SDCOMP-52449] In certain circumstances, when compiling for T32 state and for a target that supports Thumb-2 technology, and at `-O2` or above, the compiler could incorrectly generate an `UNPREDICTABLE` `STM` instruction that contains `SP` in the list of registers to be stored. This has been fixed.

- [SDCOMP-51646] In certain circumstances, when the program contains a global named register variable that uses a register `R` in the range `R0` - `R3`, the compiler could generate incorrect code for a call to a function that modifies `R`. This has been fixed.

- [SDCOMP-50871] In certain circumstances, when compiling at `-O2` or above, and the program uses a combination of load, shift, and bitwise OR operations to construct a value from 3 consecutive bytes of memory, the compiler could generate code that incorrectly performs an out-of-bounds memory access. This has been fixed.

- [SDCOMP-50692] In rare circumstances, the compiler could generate incorrect code that overwrites a value before it has been used. This has been fixed.

- [SDCOMP-50661] In certain circumstances, when a 64-bit integer constant is added to or subtracted from an address that has been cast to a 64-bit integer type, the compiler could generate code that incorrectly ignores the upper 32 bits of the constant value. This has been fixed.

- [SDCOMP-50641] In certain circumstances, when compiling with `--vectorize`, and the program contains an array `A` of integer type and an array `B` of `char` type, the compiler could generate incorrect code for a loop that conditionally updates the elements of `A` based on a comparison that involves elements from `A` and `B` at the same index. This has been fixed.

- [SDCOMP-49474] In certain circumstances, when compiling with `--vectorize`, and the program contains an array `A` of `unsigned` `short` type and an array `B` of `unsigned` `char` type, the compiler could generate incorrect code for a loop that conditionally updates the elements of `A` based on a comparison that involves elements from `A` and `B` at the same index. This has been fixed.

- [SDCOMP-49286] In certain circumstances, when compiling for an Armv6T2, Armv7-A, Armv7-M, or Armv7-R target, the compiler could generate code that incorrectly fails to perform sign extension for accesses to `signed` `long` `long` bitfield members of a `struct`. This has been fixed.

- [SDCOMP-46997] When compiling with `--use_frame_pointer` for T32 state, the compiler could generate code that incorrectly assigns a temporary value to the stack pointer register. This has been fixed.

##### Assembler (armasm)

- [SDCOMP-49312] When assembling a source file that contains a data block `B` followed by an exported symbol `S` that is associated with an instruction `I`, and padding must be added after `B` to ensure that `I` is correctly aligned, the assembler would associate `S` with an incorrect address. This has been fixed.

##### Linker (armlink)

- [SDCOMP-47265] In certain circumstances, when linking with `--paged` `--no_legacyalign` and using a scatter file where a `ZI` section has a higher alignment requirement than an `RW` section in the same execution region, the linker could incorrectly generate an image containing overlapping output sections. This could result in data being initialized to an incorrect value. This has been fixed.

##### Libraries

- [SDCOMP-54710] The microlib implementations of the `snprintf()` and `vsnprintf()` functions incorrectly always returned zero instead of the number of characters to be written to the buffer (not counting the terminating null character) when called with a buffer size of zero. This has been fixed.

- [SDCOMP-54131] When a program contains a function that is annotated with `__attribute__((destructor[(priority)]))`, the function was incorrectly not called automatically after `main()` completes or after `exit()` is called. This has been fixed.

- [SDCOMP-52050] The Arm C library implementation of the `atan2f()` function could incorrectly return positive zero instead of negative zero. This has been fixed.

- [SDCOMP-49975] The Arm C library implementations of the `atan2()`, `atan2f()`, and `erfc()` functions could incorrectly fail to set `errno` to `ERANGE` when the return value underflows to zero. This has been fixed.

- [SDCOMP-49764] The microlib implementation of the `strrchr()` function incorrectly returned a null pointer when used to locate the terminating null character `'\0'` of a string. This has been fixed.

- [SDCOMP-29999] In certain Arm C library header files, the character sequence `*/*` was used where a pointer is followed by a comment. `*/*` can be reported as a fault by third party static analysis tools. This has been fixed.

##### Fromelf

- [SDCOMP-49313] When disassembling an ELF file that contains a PC-relative load instruction modified by a relocation that has an addend, the `fromelf` utility would produce disassembly that contained an incorrect load value for the instruction. This has been fixed.

### Changes in Arm Compiler 5.06 update 6

#### Defect fixes in Arm Compiler 5.06 update 6

##### Compiler (armcc)

- [SDCOMP-48383] In certain circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code for a `do-while` loop with a controlling expression that contains a postfix decrement operator with an operand of `unsigned` type. This has been fixed.

- [SDCOMP-48226] In rare circumstances, when compiling with `--vectorize`, the compiler could generate incorrect code for a `for` or `while` loop that conditionally negates a value depending on the result of a bitwise AND operation. This has been fixed.

- [SDCOMP-48050] When compiling C++11 code containing aggregate initialisation of a temporary object and that object has a non-trivial destructor, the compiler would report `Internal` `fault:` `[0x87ecef:<ver>]` or a Windows `APPCRASH` error. This has been fixed.

- [SDCOMP-47432] In certain circumstances, when compiling for an Armv6T2, Armv7-A, Armv7-M, or Armv7-R target, the compiler could generate code that performs sign extension incorrectly for accesses to `signed` `long` `long` bitfield members of a `struct`. This has been fixed.

- [SDCOMP-47401] In rare circumstances, when compiling with `--cpp11` at `-O3` `-Otime` or with `--vectorize`, the compiler could report `Internal` `fault:` `[0x50bce4:<ver>]`. This has been fixed.

- [SDCOMP-47393] In rare circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code for a `for` loop that dereferences a pointer which aliases the loop index. This can result in incorrect behavior when the loop index is indirectly referenced. This has been fixed.

- [SDCOMP-47388] In rare circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code for a loop that contains an `if` statement where one or more substatements at the start of both the `if` and `else` blocks each contain one of:

  - A bitwise shift compound assignment operator, `>>=`.
  - A division compound assignment operator, `/=`.

  This has been fixed.

- [SDCOMP-47142] In rare circumstances, when compiling at `-O1` or above, the compiler could generate incorrect code for a function that twice loads an 8-bit or 16-bit value from the same location into a wider integer type, and treats the loaded value as signed for one load and unsigned for the other load. The compiler could incorrectly always treat the loaded value as signed or unsigned. This has been fixed.

- [SDCOMP-46962] In certain circumstances, when compiling at `-O2` or above, the compiler could incorrectly fail to generate code for an inline assembly statement that contains only `CPSID` or `CPSIE` instructions. This has been fixed.

- [SDCOMP-29406] In certain circumstances, when reporting a diagnostic at the expansion point of a macro, the compiler could incorrectly print a newline character instead of the first character of the name of the macro. This has been fixed.

##### Linker (armlink)

- [SDCOMP-48776] When linking a program that contains an A32 function that calls a small T32 function, the function inlining feature of the linker could incorrectly replace the call to the small T32 function with an invalid instruction that is `UNPREDICTABLE` in A32 state. This has been fixed.

- [SDCOMP-47276] The unused section elimination feature of the linker could incorrectly remove a section that is only referred to using a linker-defined input section symbol. This has been fixed.

- [SDCOMP-47224] In certain circumstances, the linker could resolve references to symbols incorrectly when the program contains `__at` sections. This could result in an affected program accessing an incorrect memory location, or executing code at an unexpected address. This has been fixed.

- [SDCOMP-29653] When linking with `--edit` and a steering file that contains the command `HIDE` `__scatterload_rt_thumb_only`, the linker incorrectly failed to hide the symbol `__scatterload_rt_thumb_only`. This has been fixed.

- [SDCOMP-22630] When two or more `__at` sections containing read-write data are placed within an execution region that also contains at least one read-only section, the linker could incorrectly report one of the following:

  - `Internal` `fault:` `[0xc0fbf2:<ver>]`.
  - `Internal` `fault:` `[0xd6a969:<ver>]`.

  This has been fixed.

##### Libraries

- [SDCOMP-45990] The Arm C library incorrectly did not contain an implementation of the `__0vsscanf()` function. This could result in the linker reporting `Error:` `L6218E:` `Undefined` `symbol` `__0vsscanf`. This has been fixed.

##### Fromelf

- [SDCOMP-48404] When decoding exception table information for executable images with `-c` `-e`, or `--text` `-c` `-e`, the `fromelf` utility would report incorrect symbol name and address information for `ARM_EXIDX` table entries that refer to a symbol in a different ELF section than the ELF section containing the `ARM_EXIDX` table. This has been fixed.

- [SDCOMP-48381] When disassembling an ELF file that contains a PC-relative load instruction modified by a relocation, the `fromelf` utility would produce disassembly that contained an incorrect load value for the instruction. This has been fixed.

##### Other issues

- [SDCOMP-49019] In certain circumstances, when an assembler, compiler, or linker process invoked another of the tools as a sub-process but all suitable licenses were already in use, the processes could deadlock. This has been fixed.

- [SDCOMP-48808] When using 32-bit binaries on a Linux host platform and a filesystem that has 64-bit inodes enabled, the tools could incorrectly report the following error:

  - `Unable` `to` `determine` `the` `current` `toolkit.` `Check` `that` `ARM_TOOL_VARIANT` `is` `set` `correctly.` `ARM` `Compiler` `could` `not` `determine` `the` `product` `installation` `it` `is` `part` `of`.

  This has been fixed.

### Changes in Arm Compiler 5.06 update 5

#### General changes in Arm Compiler 5.06 update 5

- [SDCOMP-46762] Arm Compiler 5.06 update 5 includes FlexNet Publisher 11.14.1.0 client libraries. This version of the license client is not compatible with previous versions of the FlexNet Publisher license server software. When used with a license server running an `armlmd` or `lmgrd` version earlier than 11.14.1.0, Arm Compiler 5.06 update 5 can report either of the following:

  - `Failed` `to` `check` `out` `a` `license.Bad` `message` `command`.
  - `Failed` `to` `check` `out` `a` `license.Version` `of` `vendor` `daemon` `is` `too` `old`.
  - `Flex` `error` `code:` `-83`.
  - `Flex` `error` `code:` `-140`.

  A license server running `armlmd` and `lmgrd` version 11.14.1.0 (or later) is compatible with Arm Compiler 5.06 update 5 and all previous releases of Arm tools.

  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.

#### Defect fixes in Arm Compiler 5.06 update 5

##### Compiler (armcc)

- [SDCOMP-46912] In rare circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code when a loop dereferences a pointer that aliases a variable used in the controlling expression of that loop. This has been fixed.

- [SDCOMP-46817] In rare circumstances, when compiling at `-O1` or above, the compiler could generate incorrect code when inlining a function that returns a `long` `long` or `unsigned` `long` `long` into a function that uses a large amount of stack space. This has been fixed.

- [SDCOMP-46807] In certain circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code when a loop contains an assignment to a variable of `struct` type, and the last member of that `struct` type is an unnamed bitfield of width `0`. This has been fixed.

- [SDCOMP-46795] The compiler would incorrectly accept floating-point literals that are greater than `DBL_MAX` (`1.79769313486231571e+308`) but less than `1.0e+309`, and then represent them as the floating-point value `-0.0`. This has been fixed. The compiler now reports `Error:` `#30:` `floating` `constant` `is` `out` `of` `range`.

- [SDCOMP-46767] When compiling a constructor that initializes an array using a C++11 braced-init-list, the compiler would report `Internal` `fault:` `[0x87ecef:<ver>]` or a Windows `APPCRASH` error. This has been fixed.

- [SDCOMP-46700] In certain circumstances, when compiling at `-O1` or above, the compiler could generate incorrect code for a compound-assignment statement that modifies two members of the same `struct`, a memory location contains both those members, and at least one of those members is a bitfield. This has been fixed.

- [SDCOMP-46535] When compiling C++11 code containing a lambda, where the lambda capture list includes an object passed by value and that object has a non-trivial destructor, the compiler would report `Internal` `fault:` `[0x21315f:<ver>]` or a Windows `APPCRASH` error. This has been fixed.

- [SDCOMP-45940] The compiler would incorrectly accept code which passes a `__packed` pointer as an argument to a function that has been declared implicitly, or declared without argument types. This has been fixed. The compiler now reports `Error:` `#3734:` `__packed` `qualifier` `dropped` `when` `passing` `argument` `to` `unprototyped` `function`.

- [SDCOMP-45899] In rare circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code for a loop containing a conditional statement that causes a subsequent conditional `break` statement within the same loop to be unreachable. This has been fixed.

- [SDCOMP-45880] In certain circumstances, when compiling at `-O2` or above, the compiler could generate incorrect code when an assignment expression and a bitwise AND expression are conditionally executed, and the result of the bitwise AND expression is used to conditionally evaluate another expression. This has been fixed.

- [SDCOMP-45854] In certain circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code for a loop that refers to the address of a `static` pointer, modifies the pointer, and then updates memory by dereferencing the pointer. This has been fixed.

- [SDCOMP-45833] In certain circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code when the controlling expression of a loop contains a variable of type `char` that must overflow in order to reach the loop termination condition. This has been fixed.

- [SDCOMP-45824] In rare circumstances, when compiling at `-O2` or above, the compiler could generate incorrect code when the assignment to, and subsequent use of, a 64-bit integer object both involve a bitwise OR or Exclusive OR with a 64-bit integer constant. This has been fixed.

- [SDCOMP-45820] In rare circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code for a loop which calls a function that initializes a local array using the address of a global variable, and subsequently uses the value returned by that function. This has been fixed.

- [SDCOMP-45688] When compiling an inline assembler statement in which a destination operand expression is cast to a type with a size smaller than 32 bits, the compiler would incorrectly generate code that performs a 32-bit memory access. This has been fixed.

##### Assembler (armasm)

- [SDCOMP-47141] The assembler would incorrectly fail to report an error for a floating-point literal that is greater than `1.79769313486231571e+308` and less than `1.0e+309`. Instead, it would incorrectly represent the literal as negative zero. This has been fixed. The assembler now reports the following error:

  - `A1407E:` `Overlarge` `floating` `point` `value`.

- [SDCOMP-46908] When assembling a `VMOV` instruction that has a `.32`, `.I32`, `.S32`, or `.U32` suffix, the assembler could incorrectly report the following error:

  - `A1887E:` `Specified` `source` `data` `type` `not` `allowed;` `must` `be` `one` `of:` `F32`.

  This has been fixed.

- [SDCOMP-45076] In certain circumstances, when assembling code containing a conditional instruction with `--unsafe`, the assembler could report `Internal` `fault:` `[0x364f5c:<ver>]`. This has been fixed.

##### Libraries

- [SDCOMP-47150] The Arm C library implementations of `strtod()` and `wcstod()` could incorrectly return negative zero instead of infinity when the input string specifies a number in the range `(1.79769313486231571e+308,` `1.0e+309)`. This has been fixed.

- [SDCOMP-47048] The Arm C library implementation of `expm1f()` could return an incorrect result when the input argument is between `0.8110728` and `0.8231074`. Fewer than 1 in 2,500 numbers in this range were affected. The result would be incorrectly separated by more than one unit in the last place (ULP) from the exact result. This has been fixed.

- [SDCOMP-46050] When the program is built for full IEEE 754 floating-point standard conformance, the Arm C library implementations of the following string to floating-point conversion functions could behave incorrectly:

  - `atof()`.
  - `strtod()`.
  - `strtof()`.
  - `strtold()`.
  - The `scanf()` family of functions when using a floating-point conversion specifier.

  The affected functions could:

  - Incorrectly fail to set the IEEE inexact, overflow, or underflow exception flags.
  - Incorrectly round the result to `-0`, `0`, `-inf`, or `inf`.
  - Set `errno` to `0` when `ERANGE` is expected.

  This has been fixed.

- [SDCOMP-45329] The microlib implementation of the `printf()` family of functions could incorrectly write `%%` instead of `%` when processing the format conversion specification `%%`. This has been fixed.

- [SDCOMP-30369] The Arm C library implementation of the `strtof()` function incorrectly failed to set `errno` to `ERANGE` when called with an input byte string that specifies a floating-point value which is outside the range of the `float` type but within the range of the `double` type. This has been fixed.

- [SDCOMP-29945] The Arm C library implementation of `setlocale()` incorrectly failed to return a null pointer for a locale string that begins with the `*` character but has an invalid format. Instead, it incorrectly updated the internal locale state of the C library to contain invalid pointers. Subsequently, this could result in unexpected run-time behavior. This has been fixed.

##### Other issues

- [SDCOMP-29403] When using the tools on a Linux platform and a filesystem that has 64-bit inodes enabled, the tools could incorrectly report one of the following errors:

  - `#5:` `cannot` `open` `<entity>` `input` `file` `"<filename>":` `Value` `too` `large` `for` `defined` `data` `type`.
  - `#2918:` `cannot` `open` `<entity>` `file` `"<entity>":` `not` `a` `regular` `file`.

  This has been fixed.

### Changes in Arm Compiler 5.06 update 4

#### General changes in Arm Compiler 5.06 update 4

- [SDCOMP-22192] The ABI conformance of the tools has been updated to release 2.09 of the 32-bit Application Binary Interface for the Arm Architecture.

#### Defect fixes in Arm Compiler 5.06 update 4

##### Compiler (armcc)

- [SDCOMP-45708] When compiling C++11 code with exceptions disabled, the compiler would incorrectly generate code that fails to call the destructors when deleting objects of type `class` or `struct` that have been initialized using brace initializers. This has been fixed.

- [SDCOMP-45545] In rare circumstances, when compiling at `-O1` or above, the compiler could generate incorrect code when a constant value is written to a variable in a compound expression. This would result in an incorrect value being written to the variable. This has been fixed.

- [SDCOMP-45522] In rare circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code for a `for` loop that dereferences a pointer which aliases the loop index. This could result in incorrect behavior when the loop index is indirectly referenced. This has been fixed.

- [SDCOMP-45519] In certain circumstances, when compiling an expression that modifies at least two bitfield members of the same `struct`, at `-O1` or above, the compiler could incorrectly generate code that does not update all of the modified bitfield members. This has been fixed.

- [SDCOMP-45508] In certain circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code for a `for` loop that calls a function where one of the arguments involves a comma operator with a right-hand operand that requires an implicit integer conversion. This has been fixed.

- [SDCOMP-45489] In certain circumstances, when compiling at `-O2` or above, the compiler could generate incorrect code when both the operands of a logical OR expression access the same non-volatile variable and at least one of the operands is an expression that has side-effects. This has been fixed.

- [SDCOMP-45484] In rare circumstances, when compiling at `-O1` or above, the compiler could generate incorrect code when integer constants that have the same binary representation appear in at least two expressions, and the constant can be implicitly converted to a narrower integer type in a subset of those expressions without changing the behavior. The compiler could incorrectly use a narrower version of the constant in expressions that require the full value, resulting in incorrect behavior. This has been fixed.

- [SDCOMP-45478] In rare circumstances, when compiling at `-O2` or above, the compiler could incorrectly generate a sequence of code containing conditional and flag-setting instructions that does not conform to the source code. This has been fixed.

- [SDCOMP-44744] In rare circumstances, when compiling code which passes an argument that is an element of a multi-dimensional array to a function parameter of `union` type, at `-O3` `-Otime` or with `--vectorize`, the compiler could incorrectly report `Error:` `#167:` `argument` `of` `type` `<type>` `is` `incompatible` `with` `parameter` `of` `type` `<type>`. This has been fixed.

- [SDCOMP-29087] In rare circumstances, when compiling with `--cpp11` at `-O3` `-Otime`, the compiler could report `Internal` `fault:` `[0x50bce4:<ver>]`. This has been fixed.

- [SDCOMP-25441] In certain circumstances, when the language was other than English, and the source locale was not set to UTF-8, the compiler could report incorrect error messages. This has been fixed.

##### Linker (armlink)

- [SDCOMP-30572] When linking a program without the `--cpu` option and the input-file-list only specifies members of libraries, the linker would incorrectly report one of the following:

  - `Internal` `fault:` `[0x4b0af3:<ver>]`.
  - `Internal` `fault:` `[0xec6eb7:<ver>]`.

  This has been fixed.

##### Libraries

- [SDCOMP-25153] The Arm Compiler library implementations of the following functions for Armv6-M targets would return an incorrect result when the input string specifies a number that is too large to represent as a `double`, including when the output type is `float`:

  - `atof()`.
  - `strtod()`.
  - `strtof()`.
  - `strtold()`.
  - The `scanf()` family of functions when using a floating-point conversion specifier.

  In these circumstances, the following functions would also incorrectly fail to set `errno` to `ERANGE`:

  - `strtod()`.
  - `strtof()`.
  - `strtold()`.
  - The `scanf()` family of functions when using a floating-point conversion specifier.

  This has been fixed.

##### Other issues

- [SDCOMP-45568] When integrating Arm Compiler into Keil MDK with a 7-day evaluation license, the tools would incorrectly report `FLEX_USE` `is` `set` `to` `1` `in` `C:\Keil\tools.ini` `but` `no` `FLEX=port@host` `is` `defined`. This has been fixed.

- [SDCOMP-45297] The tools would generate objects that incorrectly claimed conformance to release 2.10 rather than release 2.09 of the 32-bit Application Binary Interface for the Arm Architecture. This has been fixed.

### Changes in Arm Compiler 5.06 update 3

#### General changes in Arm Compiler 5.06 update 3

- [SDCOMP-45000] Support for the following processors has been removed:

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

- [SDCOMP-45022] Support has been added for the Cortex-R8 processor. To target Cortex-R8, use the following option:

  - `--cpu=Cortex-R8`

#### Defect fixes in Arm Compiler 5.06 update 3

##### Compiler (armcc)

- [SDCOMP-45004] In certain circumstances, when compiling with `--vectorize`, the compiler could generate incorrect code for a repeated and necessary statement. This has been fixed.

- [SDCOMP-44793] In certain circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code for a loop as a result of ignoring a loop-carried dependency on the iteration variable. This has been fixed.

- [SDCOMP-44774] In certain circumstances, when compiling at `-O3` `-Otime`, the compiler could generate incorrect code which fails to update the value of a global variable that is modified within a nested loop. This has been fixed.

- [SDCOMP-44765] In rare circumstances, when compiling for T32 state for a target that supports Thumb-2 technology, the compiler could generate a sequence of code in which a `CMP` instruction incorrectly appeared before another flag-setting instruction. This has been fixed.

- [SDCOMP-44757] In certain circumstances, when compiling with `--bi` or `--bigend` at `-O1` or above, the compiler could generate an incorrect result when sign-extending an expression involving a bitfield member of a `struct`. This has been fixed.

- [SDCOMP-44753] When compiling for a target that does not support bit-banding, the compiler would incorrectly accept the `--bitband` option. This has been fixed. The compiler now reports `Error:` `C4368W:` `Selected` `target` `does` `not` `support` `bit-banding`.

- [SDCOMP-44696] In rare circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code that resulted in a failure to enter a loop body. This has been fixed.

- [SDCOMP-44676] In rare circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code for a nested loop. This has been fixed.

- [SDCOMP-44669] The compiler would generate incorrect code for C++11 abstract classes that use delegated constructors. This has been fixed.

- [SDCOMP-44621] In rare circumstances, when compiling at `-O1` or above, the compiler could generate incorrect code for accesses to a function argument that is aliased by a pointer. This has been fixed.

- [SDCOMP-44618] In rare circumstances, the compiler could generate incorrect code after emitting an `LDRD` or `STRD` instruction with writeback. This has been fixed.

- [SDCOMP-44601] In rare circumstances, when compiling for T32 state, the compiler could generate incorrect code for a relational expression that involves an increment operator or decrement operator. This has been fixed.

- [SDCOMP-44594] In rare circumstances, when compiling at `-O2` or above, the compiler could generate incorrect code for functions that are passed a `struct` by value containing at least one bitfield narrower than 32 bits. This has been fixed.

- [SDCOMP-44583] In certain circumstances, when compiling at `-O3` `-Otime`, the compiler could generate incorrect code that unconditionally assigns a value to a variable that should have been assigned conditionally. This has been fixed.

- [SDCOMP-44581] In certain circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code when evaluating a parameter to a function call that is contained in the controlling expression of an `if` statement. This has been fixed.

- [SDCOMP-44559] In rare circumstances, when compiling for T32 state, the compiler could generate incorrect code for a function that contains two conditional expressions with the same condition. This has been fixed.

- [SDCOMP-44523] 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-44469] In rare circumstances, when compiling at `-O1` or above, the compiler could generate incorrect code for functions that access the CPSR. This has been fixed.

- [SDCOMP-30951] In certain circumstances, when compiling at `-O1` or above, the compiler could generate incorrect code for a program that writes a negative value to a structure using `memset()` and then accesses that structure. This has been fixed.

- [SDCOMP-30950] In rare circumstances, when compiling at `-O1` or above, the compiler could incorrectly generate a tail call to `memcpy()` with a pointer argument that pointed below the stack pointer. This has been fixed.

- [SDCOMP-30854] In rare circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code for a loop that has an iteration variable of unsigned integer type. This has been fixed.

- [SDCOMP-30847] In certain circumstances, when compiling at `-O3` `-Otime` or with `--vectorize`, the compiler could generate incorrect code for a loop that accesses a `volatile` member of a `struct`. This has been fixed.

- [SDCOMP-30818] In certain circumstances, when compiling for T32 state for a target that does not support Thumb-2 technology, use of the `alloca()` function could cause the compiler to report `Internal` `fault:` `[0xcbb629:<ver>]`. This has been fixed.

- [SDCOMP-29863] In certain circumstances, when compiling with `--multifile`, the compiler could incorrectly report `Error:` `#3167:` `attribute` `"at"` `is` `missing` `in` `another` `translation` `unit` if the same variable is declared in multiple translation units and `__attribute__((at(address)))` is used in at least one but not all of the declarations. This has been fixed.

- [SDCOMP-29651] In certain circumstances, when compiling C++ code containing a function template that uses a non-type template parameter in a call to an intrinsic, the compiler could incorrectly report `Error:` `#2529:` `expression` `must` `be` `an` `integral` `constant` `in` `range` `<entity>` `to` `<entity>` for valid values of the parameter. This has been fixed.

- [SDCOMP-29350] When compiling C++11 code containing a range-based `for` loop where the iteration variable is not used in the loop body, the compiler would report `Internal` `fault:` `[0x6bca8b:<ver>]`. This has been fixed.

- [SDCOMP-11935] When compiling with `--fpu=vfpv2` or `--fpu=softvfp+vfpv2` for an Armv7-A target that supports NEON, the compiler would generate code that could incorrectly contain VFPv3 or later instructions. This has been fixed.

##### Assembler (armasm)

- [SDCOMP-44881] When assembling `VMRS` or `VMSR` instructions for an Armv7E-M target that supports a hardware floating-point unit, the assembler would incorrectly accept system registers other than `FPSCR`. This has been fixed. The assembler now reports `Error:` `A1477E:` `This` `register` `combination` `results` `in` `UNPREDICTABLE` `behaviour`.

- [SDCOMP-22681] When assembling with `--fpu=vfpv2` or `--fpu=softvfp+vfpv2` for an Armv7-A target that supports NEON, the assembler would incorrectly fail to report an error for the usage of VFPv3 or later instructions in the source code. This has been fixed. The assembler now reports `Error:` `A1797E:` `Specified` `FPU` `is` `not` `compatible` `with` `CPU` `architecture`.

##### Linker (armlink)

- [SDCOMP-30022] When preprocessing a scatter file on Windows, the linker would incorrectly fail to expand any environment variables specified using `%<NAME>%` syntax in the `#!` line before invoking the selected preprocessor. This has been fixed.

##### Libraries

- [SDCOMP-32959] In rare circumstances, printing a `long` `double` value using the microlib implementation of the `printf()` function could result in an infinite loop. This has been fixed.

- [SDCOMP-30944] The microlib implementations of the `snprintf()` and `vsnprintf()` functions would incorrectly attempt to write to their output pointer when passed a length of zero. This has been fixed.

- [SDCOMP-30381] In rare circumstances, the standard C library and microlib implementations of the `expm1f()` function could return an incorrect result. This has been fixed.

- [SDCOMP-23349] The microlib implementation of the `fclose()` function selected by `#pragma` `import` `(__use_full_stdio)` would incorrectly fail to free the memory allocated for the `FILE` structure by `fopen()`. This could result in a memory leak. This has been fixed.

### 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 T32 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 T32 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.06.

#### 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 T32 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 A32 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 T32 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 A32 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 T32 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 T32 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 T32 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.