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:
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:
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.
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:
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.
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.
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.
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.
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.
Arm Compiler 5.06 update 7 has been tested on the following supported platforms:
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:
To install the required libraries, run the appropriate command for your platform with root privileges:
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:
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.
Arm Compiler 5.06 update 7 has been tested on the following supported platforms:
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.
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.
Documentation for the Arm Compiler 5.06 release series is available on https://developer.arm.com and comprises:
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.
The following are the releases to date of the Arm Compiler 5.06 series:
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.
[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.
[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.
[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.
[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.
[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.
[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:
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.
[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:
This has been fixed.
[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.
[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.
[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:
This has been fixed.
[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:
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.
[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.
[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:
[SDCOMP-46908] When assembling a VMOV instruction that has a .32, .I32, .S32, or .U32 suffix, the assembler could incorrectly report the following error:
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.
[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:
The affected functions could:
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.
[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:
This has been fixed.
[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.
[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.
[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:
This has been fixed.
[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:
In these circumstances, the following functions would also incorrectly fail to set errno to ERANGE:
This has been fixed.
[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.
[SDCOMP-45000] Support for the following processors has been removed:
Replace affected --cpu=name options as follows:
[SDCOMP-45022] Support has been added for the Cortex-R8 processor. To target Cortex-R8, use the following option:
[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.
[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.
[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.
[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.
[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:
[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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 are listed since the previous feature release, Arm Compiler 5.06.
[SDCOMP-22253] The following changes have been made to supported host platforms:
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:
[SDCOMP-24529] Support for the following processors has been deprecated in Arm Compiler 5.06:
Replace affected --cpu=name options as follows:
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:
Support has also been added for an additional optimization barrier intrinsic:
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:
[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:
[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:
[SDCOMP-28842] The --fpu option has been extended to support the FPv5 architecture:
[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:
[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:
[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:
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.
[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.
[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.
[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.
[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.
[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.