Release notes for Arm Compiler 6.10.1

Release notes for Arm Compiler 6.10.1

1. Introduction

Arm Compiler 6.10.1 is an update release to Arm Compiler 6.10 and is intended for use:

  • In conjunction with DS-5.
  • In conjunction with Keil MDK.
  • As a standalone toolchain installation.

A suitable license from one of these products must be available. Contact your sales representative or visit https://developer.arm.com/products/buy-arm-products to enquire about a license.

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

1.1 Arm Compiler 6 Configuration

Arm Compiler 6 is the successor to Arm Compiler 5 and includes the components listed below. See the Migration and Compatibility Guide in the product documentation for more information on migrating projects from previous versions.

  • armclang
    • armclang is the successor to armcc and is based on LLVM and Clang technology.
  • armlink, armasm, fromelf, armar
    • armlinkarmasmfromelf, and armar have been extended to support Armv8 and behave similarly to Arm Compiler 5.
  • Arm C and C++ libraries for embedded systems
    • The standard Arm Compiler embedded libraries have been extended to support Armv8 and behave similarly to those found in Arm Compiler 5.
    • Arm Compiler 6 includes the libc++ library as the C++ Standard Template Library.

Note regarding assemblers:

  • Arm Compiler 6 adopts the LLVM integrated assembler as default because it aligns more closely with GNU assembler syntax, improving portability between the GNU and Arm Compiler toolchains. The LLVM integrated assembler is called by default by armclang. A side effect is that Arm Compiler 6 will not compile C/C++ source files which contain legacy armccinline or embedded assembler.
  • The legacy assembler (armasm) is not called by default, but is included in Arm Compiler 6 for assembling source code written in armasm syntax. The legacy assembler is included to help with migration of existing projects from Arm Compiler 5 or earlier. Although the legacy assembler has been extended to support Armv8, this assembler does not include all the features of the latest Armv8 updates, and Arm has no plans to add further architectural support to armasm. For new projects, Arm recommends the armclang inline assembler and integrated assembler.

1.2 What’s Supported in Arm Compiler 6.10.1?

The following table describes the level of support for the most common toolkits:

Architectures and Processors Support Level License / Configuration
MDK-Lite MDK-Essential MDK-Plus MDK-Professional DS-5 Professional DS-5 Ultimate
Armv8-A Cortex-A76/75/73/72/57/55/53/35/32 Product feature Yes
Armv7-A Cortex-A17/15/12/9/8/7/5 Product feature Yes Yes Yes
Armv8-R Cortex-R52 Product feature Yes
Armv7-R Cortex-R8/7/5 Product feature Yes Yes
Cortex-R4F/4 Product feature Yes Yes Yes Yes
Armv8-M Cortex-M35P/33/23 Product feature Non-secure only Yes Yes Yes Yes
Armv7-M SC300 Product feature Yes Yes Yes Yes
Cortex-M7/4/3 Product feature 32 Kbyte code limit Yes Yes Yes Yes Yes
Armv6-M SC000 Product feature Yes Yes Yes Yes
Cortex-M0/M0+ Product feature 32 Kbyte code limit Yes Yes Yes Yes Yes
Arm architectures earlier than Armv6-M Unsupported
Non Arm architectures Unsupported
Support Level Description
Product features Production quality. Highest support priority.
Beta product features Implementation complete, but not thoroughly tested. User experimentation and feedback is welcomed.
Alpha product features Implementation is not complete and not thoroughly tested. User experimentation and feedback is welcomed.
Community features Additional features that are available in the open-source technology Arm Compiler 6 is built on. Arm makes no claims about the quality level or the degree of functionality of these features. User experimentation and feedback is welcomed.
Unsupported features Features that are either not present in the toolchain or have been deprecated. These features are completely untested. Use entirely at your own risk.

Check with your supplier for information about which architectures and processors are supported by other toolkits.

For more information on the supported features and level of support for features, see the product documentation.

2. Installation Instructions

If you received Arm Compiler 6.10.1 as part of a toolkit, for example DS-5, the toolkit installer takes care of the installation process. Please refer to the installation instructions for the toolkit in such cases.

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

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

2.1. Integration into DS-5 5.20 or later

Arm Compiler 6.10.1 can be installed in any location, including the default location, providing this is outside of a DS-5 product installation.

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

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

  • Set ARM_PRODUCT_PATH to the path to the sw/mappings directory within your DS-5 installation. Please note this path must not contain double quotes on Windows. A path that contains spaces will still work without the quotes.
  • Set ARM_TOOL_VARIANT appropriately if you are not using a DS-5 Professional Edition license.

For further information see https://developer.arm.com/products/software-development-tools/license-management/resources/product-and-toolkit-configuration.

2.2. Integration into Keil MDK 5.22 or later

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

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.

2.3. Use as a standalone product

Arm Compiler 6.10.1 can be installed in any location, including the default location, providing this is outside of a DS-5 product installation.

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

Set ARM_TOOL_VARIANT appropriately if you are not using a DS-5 Professional Edition license.

For further information see https://developer.arm.com/products/software-development-tools/license-management/resources/product-and-toolkit-configuration.

2.4. Installation on Linux

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

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

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

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

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

2.5. Installation on Windows

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

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

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

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

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

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

3. Uninstall

On Linux, delete the Arm Compiler 6.10.1 installation directory.

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

4. Documentation

The following documentation is available for Arm Compiler 6.10.1:

  • User Guide.
  • armar User Guide.
  • armasm User Guide.
  • armclang Reference Guide.
  • armlink User Guide.
  • fromelf User Guide.
  • Arm C and C++ Libraries and Floating-Point Support User Guide.
  • Migration and Compatibility Guide.
  • Software Development Guide.
  • Errors and Warnings Reference Guide.
  • Scalable Vector Extension User Guide.

For more information, please see Arm Compiler 6 documentation in developer.arm.com.

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

5. Feedback and Support

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

6. Release History and Changes

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

  • 6.10.1 (released June 2018)
  • 6.10 (released March 2018)

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

Changes in Arm Compiler 6.10.1

General changes in Arm Compiler 6.10.1

  • [SDCOMP-51014]  Support has been added for the Cortex-A76 processor. To target Cortex-A76, select from the following options:armclang:
    • --target=aarch64-arm-none-eabi -mcpu=cortex-a76 for AArch64 state.
    • --target=arm-arm-none-eabi -mcpu=cortex-a76 for AArch32 state.

    armasmarmlink, and fromelf:

    • --cpu=8.2-A.64 for AArch64 state.
    • --cpu=8.2-A.32 for AArch32 state.
  • [SDCOMP-51015]  Support has been added for the Cortex-M35P processor. To target Cortex-M35P, select from the following options:armclang:
    • --target=arm-arm-none-eabi -mcpu=cortex-m35p for a variant with DSP and FP.
    • --target=arm-arm-none-eabi -mcpu=cortex-m35p+nodsp for a variant without DSP but with FP.
    • --target=arm-arm-none-eabi -mcpu=cortex-m35p -mfloat-abi=soft for a variant with DSP but without FP.
    • --target=arm-arm-none-eabi -mcpu=cortex-m35p+nodsp -mfloat-abi=soft for a variant without DSP and FP.

    armasmarmlink, and fromelf:

    • --cpu=Cortex-M35P for a variant with DSP and FP.
    • --cpu=Cortex-M35P.no_dsp for a variant without DSP but with FP.
    • --cpu=Cortex-M35P --fpu=SoftVFP for a variant with DSP but without FP.
    • --cpu=Cortex-M35P.no_dsp --fpu=SoftVFP for a variant without DSP and FP.

Defect fixes in Arm Compiler 6.10.1

Other issues
  • [SDCOMP-50941]  When Arm Compiler was used on Windows 10 version 1803 (April 2018 Update) with an MDK-ARM installation and a Keil Single-User or Keil Floating license, the tools would incorrectly report error: Failed to check out a license.Keil Licensingerror: No TOOLS.ini file found. This has been fixed.

Known issues in Arm Compiler 6.10.1

  • [SDCOMP-50507]  Compiler support for the AArch64 Armv8.2-A half-precision floating-point intrinsics has the following limitations:
    • The compiler incorrectly reports fatal error: error in backend or error: cannot compile this builtin function yet for the floating-point absolute compare intrinsics and a subset of the floating-point integer conversion intrinsics.
    • The floating-point multiply extended (by element) intrinsics, vmulxh_lane_f16() and vmulxh_laneq_f16(), are not supported.
  • [SDCOMP-50470]  The compiler incorrectly fails to report an error for a function call that involves invalid default argument promotion for the _Float16 data type.

Changes in Arm Compiler 6.10

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

General changes in Arm Compiler 6.10

  • [SDCOMP-50185]  Previously, when assembling for AArch32 state and for a target that supports the A32 and T32 instruction sets, the legacy assembler option --apcs=/nointerwork was selected by default. This behavior has been changed. In these circumstances, --apcs=/interwork is now selected by default.For more information about these options, refer to the armasm User Guide.
  • [SDCOMP-49700]  In certain circumstances, when a legacy assembler or linker process invoked the compiler as a sub-process to preprocess a file but all suitable licenses were already in use, the processes could deadlock. This has been fixed.
  • [SDCOMP-47596]  The default C++ source language mode has changed from gnu++98 to gnu++14.gnu++14 language and library features are a [BETA] product feature. Arm recommends compiling with -std=c++11 to restrict Arm Compiler to using only C++11 language and library features, which are fully supported.For more information, refer to the -std section of the armclang Reference Guide.
  • [SDCOMP-30915]  Previously, functions or variables annotated with __attribute__((used)) could be removed by the unused section elimination feature of the linker, unless they were retained using the --keep=section_id or --no_remove linker options. This behavior has been changed. Functions or variables annotated with __attribute__((used)) are no longer removed by the unused section elimination feature of the linker.

Enhancements in Arm Compiler 6.10

Compiler and integrated assembler (armclang)
  • [SDCOMP-49242]  Support has been added to the compiler for targeting the Armv8.1-A atomics architecture extension. This includes generating the CASP instruction for C++11 std::atomic compare and swap operations on 128-bit types.
  • [SDCOMP-49008]  Support has been added to the inline assembler, integrated assembler, legacy assembler, and the fromelf utility for the CSDB barrier instruction that can be used to mitigate the Variant 1: bounds check bypass (CVE-2017-5753) vulnerability.
  • [SDCOMP-48997]  Support has been added for the -fno-builtin option that can be used to prevent the compiler from optimizing calls to certain standard C library functions, such as printf(). When compiling without -fno-builtin, the compiler can replace such calls with inline code or with calls to other library functions.For more information about this option, refer to the armclang Reference Guide.
  • [SDCOMP-45236]  Support has been added for the _Float16 data type in all C and C++ source language modes.The _Float16 data type is defined in ISO/IEC TS 18661.

Defect fixes in Arm Compiler 6.10

Compiler and integrated assembler (armclang)
  • [SDCOMP-50315]  In certain circumstances, when compiling C++ code containing a lambda with a parameter of array type, the compiler could incorrectly report Segmentation fault(core dumped). This has been fixed.
  • [SDCOMP-50226]  When compiling with -S or --save-temps, and the program contains an inline assembly statement with a .type directive that specifies a %notype or STT_NOTYPEtype, the assembly output incorrectly contained an invalid type. This has been fixed.
  • [SDCOMP-49972]  In certain circumstances, when compiling for an Armv7-M target or an Armv8-M target without the DSP Extension, the compiler could generate code that incorrectly contained the architecturally UNDEFINED instruction SMMLS. This has been fixed.
  • [SDCOMP-49927]  When assembling for AArch32 state, the inline assembler and integrated assembler incorrectly failed to report an error for a memory access instruction that specifies an invalid shift operator for the shifted second register operand. Instead, the inline assembler and integrated assembler incorrectly ignored the instruction. This has been fixed. The inline assembler and integrated assembler now report error: illegal shiftoperator.
  • [SDCOMP-49843]  When assembling for a big-endian target and T32 state, and the program contains an inst.w directive that specifies an instruction I, the inline assembler and integrated assembler would encode I with the bytes in an incorrect order. This has been fixed.
  • [SDCOMP-49817]  In certain circumstances, when compiling at -O3-Ofast, or -Omax, the compiler could generate code that incorrectly fails to pass pointer arguments to a function that is annotated with __attribute__((naked)). This has been fixed.
  • [SDCOMP-49718]  When compiling for an Armv6-M target or an Armv8-M target without the Main Extension, and the code contains a function that has a parameter P and a local variable that has an alignment requirement of more than 8 bytes, where P is a variable argument list or must be passed using the stack, the compiler would generate code that accessed P incorrectly. This has been fixed.
  • [SDCOMP-49707]  In certain circumstances, when compiling at -Oz, and the program contains functions that throw and catch C++ exceptions, the compiler could generate an incorrect ARM_EXIDX table entry for a function F that catches C++ exceptions. Subsequently, when a C++ exception was thrown, the variables in F could be corrupted. This has been fixed.
  • [SDCOMP-49698]  When compiling in a C++ source language mode, the compiler incorrectly failed to report an error for an invalid declaration specifier in a template non-type parameter. Instead, it incorrectly ignored the invalid declaration specifier. This has been fixed. The compiler now reports error: invalid declaration specifier intemplate non-type parameter.
  • [SDCOMP-49645]  In certain circumstances, when compiling for a target that supports the Advanced SIMD Extension (NEON) and AArch32 state, and the program contains a comparison operation that is promoted to an integral type, the compiler could generate incorrect code. This has been fixed.
  • [SDCOMP-49456]  In certain circumstances, when compiling at any optimization level except -O0 and -O1 for a big-endian target and AArch32 state, the compiler could incorrectly reorder memory accesses. This has been fixed.
  • [SDCOMP-49246]  In certain circumstances, when compiling for AArch32 state with -mfloat-abi=soft and without -mfpu=none, the compiler could generate an object that incorrectly contained the build attribute Tag_FP_arch. Subsequently, the linker could incorrectly select implementations of library functions containing hardware floating-point instructions. This has been fixed.
  • [SDCOMP-49132]  In certain circumstances, when compiling for an Armv8-M target without the Main Extension, and the code contains a call through a function pointer, the compiler could incorrectly report fatal error: error in backend: ran out of registersduring register allocation. This has been fixed.
  • [SDCOMP-48979]  In certain circumstances, when compiling at any optimization level except -O0 and -O1 for a big-endian target and AArch64 state, the compiler could generate incorrect code for vectorizable memory access operations. This has been fixed.
  • [SDCOMP-48864]  In certain circumstances, when assembling for an Armv6-M, Armv7, or Armv8-M target and T32 state, the inline assembler and integrated assembler could incorrectly fail to report an error for a VMRS or VMSR instruction that specifies SP as the general-purpose register operand. Instead, the inline assembler and integrated assembler could generate a VMRS or VMSR instruction with the UNPREDICTABLE general-purpose register encoding value 13. This has been fixed. The inline assembler and integrated assembler now report error: invalid operand for instruction.
  • [SDCOMP-48429]  When assembling for AArch32 state, the inline assembler and integrated assembler would incorrectly fail to report an error for an instruction that specifies an invalid register for the base register operand or the optionally shifted second register operand. Instead, the inline assembler and integrated assembler would generate an instruction that incorrectly has a different but valid general-purpose register as the specified operand. This has been fixed. The inline assembler and integrated assembler now report error: invalid operand for instruction.
  • [SDCOMP-47542]  In certain circumstances, when compiling with -g or -gdwarf-version, the compiler could generate incorrect debug information for enumerator values. This has been fixed.
  • [SDCOMP-46968]  In certain circumstances, when compiling a static variable that is annotated with __attribute__((used)), the compiler could generate code that incorrectly used global linkage instead of local linkage for the variable. This has been fixed.
  • [SDCOMP-25212]  When compiling C or C++ language source code, the compiler is required to define the __GNUC__ preprocessor macro, but incorrectly failed to do so for source language modes that do not support additional GNU extensions. This has been fixed.
Legacy 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.
Libraries and system headers
  • [SDCOMP-49975]  In certain circumstances, the Arm Compiler library implementations of the following functions could incorrectly fail to set errno to ERANGE when the return value underflows to zero:
    • atan2().
    • atan2f().
    • erfc().

    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-49759]  The default constructor of the Arm C++ library implementation of the class template std::basic_stringbuf incorrectly failed to initialize all its sequence pointers to null pointers. This has been fixed.
  • [SDCOMP-49721]  When compiling code that contains an == or != operator that involves std::istream_iterator, and the operator is referenced using its qualified name, the compiler would incorrectly report error: no matching function for call to'operator'. This has been fixed.
  • [SDCOMP-49323]  The arm_compat.h system header incorrectly failed to include the arm_acle.h system header when the macro __ARM_ACLE was defined. This has been fixed.
Fromelf
  • [SDCOMP-49646]  When processing an ELF file with --elf--localize=option[,option,…], the fromelf utility would incorrectly localize external references identified by the arguments to --localize, resulting in an output object file that could result in the linker reporting Error: L6283E: Object  contains illegallocal reference to symbol . This has been fixed. The --localize option now only localizes definitions, and not references.
  • [SDCOMP-49582]  In certain circumstances, when disassembling an ELF file that contains an instruction modified by a relocation, the fromelf utility could produce disassembly that incorrectly failed to indicate the presence of the relocation. 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-48274]  In certain circumstances, when disassembling an ELF file that contains an A64 load or store instruction modified by a relocation, the fromelf utility could produce disassembly that incorrectly contained AArch32 registers instead of AArch64 registers. This has been fixed.
  • [SDCOMP-30908]  In certain circumstances, when processing an AArch64 ELF file with --text -g, the fromelf utility would report offsets that were incorrectly 8 bytes greater than their actual values for entries in the .debug_loc section. This has been fixed.

Known issues in Arm Compiler 6.10

  • [SDCOMP-50941]  When Arm Compiler is used on Windows 10 version 1803 (April 2018 Update) with an MDK-ARM installation and a Keil Single-User or Keil Floating license, the tools would incorrectly report error: Failed to check out a license.Keil Licensingerror: No TOOLS.ini file found. For further information, see http://www.keil.com/support/docs/4043.htm.
  • [SDCOMP-50507]  Compiler support for the AArch64 Armv8.2-A half-precision floating-point intrinsics has the following limitations:
    • The compiler incorrectly reports fatal error: error in backend or error: cannot compile this builtin function yet for the floating-point absolute compare intrinsics and a subset of the floating-point integer conversion intrinsics.
    • The floating-point multiply extended (by element) intrinsics, vmulxh_lane_f16() and vmulxh_laneq_f16(), are not supported.
  • [SDCOMP-50470]  The compiler incorrectly fails to report an error for a function call that involves invalid default argument promotion for the _Float16 data type.

Changes in Future Releases

  • The legacy R-type dynamic linking model, which does not conform to the 32-bit Application Binary Interface for the Arm Architecture, will be deprecated in a future release of Arm Compiler 6.The following will be deprecated:
    • Linking with --reloc.
    • Linking without --base_platform with a scatter file that contains the RELOC load region attribute.

    Use the Base Platform and Base Platform Application Binary Interface (BPABI) linking models to generate relocatable executable files instead of using the legacy R-type dynamic linking model.

    For information about the Base Platform and BPABI linking models, refer to the armlink User Guide.

  • Support for ELF sections that contain the legacy SHF_COMDEF ELF section flag will be deprecated in a future release of Arm Compiler 6.The following will be deprecated:
    • The COMDEF section attribute of the legacy armasm syntax AREA directive.
    • Linking with legacy objects that contain ELF sections with the legacy SHF_COMDEF ELF section flag.

    Use the GRP_COMDAT ELF section flag instead of the legacy SHF_COMDEF ELF section flag by:

    • Replacing the COMDEF section attribute of the legacy armasm syntax AREA directive with the COMGROUP=symbol_name section attribute.
    • Rebuilding incompatible legacy objects that were built using Arm Compiler 5 or earlier using one of the following:
      • The same version of the compiler as before, but with --dwarf3.
      • Arm Compiler 6.

    For more information about the COMGROUP=symbol_name section attribute of the legacy armasm syntax AREA directive, refer to the armasm User Guide.

    For more information about COMDAT groups and the GRP_COMDAT ELF section flag, refer to the Itanium C++ ABI.

  • __declspec will be deprecated in a future release of Arm Compiler 6.For information on replacing uses of __declspec, refer to the Migration and Compatibility Guide.
2018-06-19T15:43:06+00:00