Skip to Main Content Skip to Footer Navigation

Sorry, your browser is not supported. We recommend upgrading your browser. We have done our best to make all the documentation and resources available on old versions of Internet Explorer, but vector image support and the layout may not be optimal. Technical documentation is available as a PDF Download.

You copied the Doc URL to your clipboard.

Feature test macros

Introduction

The feature test macros allow programmers to determine the availability of ACLE or subsets of it, or of target architectural features. This may indicate the availability of some source language extensions (for example intrinsics) or the likely level of performance of some standard C features, such as integer division and floating-point.

Several macros are defined as numeric values to indicate the level of support for particular features. These macros are undefined if the feature is not present. (Aside: in Standard C/C++, references to undefined macros expand to 0 in preprocessor expressions, so a comparison such as:

#if __ARM_ARCH >= 7

will have the expected effect of evaluating to false if the macro is not defined.)

All ACLE macros begin with the prefix __ARM_. All ACLE macros expand to integral constant expressions suitable for use in an #if directive, unless otherwise specified. Syntactically, they must be primary-expressions generally this means an implementation should enclose them in parentheses if they are not simple constants.

Testing for Arm C Language Extensions

__ARM_ACLE is defined to the version of this specification implemented, as 100 * major_version + minor_version. An implementation implementing version 2.1 of the ACLE specification will define __ARM_ACLE as 201.

Endianness

__ARM_BIG_ENDIAN is defined as 1 if data is stored by default in big-endian format. If the macro is not set, data is stored in little-endian format. (Aside: the “mixed-endian” format for double-precision numbers, used on some very old Arm FPU implementations, is not supported by ACLE or the Arm ABI.)

A32 and T32 instruction set architecture and features

References to the target architecture refer to the target as configured in the tools, for example by appropriate command-line options. This may be a subset or intersection of actual targets, in order to produce a binary that runs on more than one real architecture. For example, use of specific features may be disabled.

In some cases, hardware features may be accessible from only one or other of A32 or T32 state. For example, in the v5TE and v6 architectures, DSP instructions and (where available) VFP instructions, are only accessible in A32 state, while in the v7-R architecture, hardware divide is only accessible from T32 state. Where both states are available, the implementation should set feature test macros indicating that the hardware feature is accessible. To provide access to the hardware feature, an implementation might override the programmer’s preference for target instruction set, or generate an interworking call to a helper function. This mechanism is outside the scope of ACLE. In cases where the implementation is given a hard requirement to use only one state (for example to support validation, or post-processing) then it should set feature test macros only for the hardware features available in that state as if compiling for a core where the other instruction set was not present.

An implementation that allows a user to indicate which functions go into which state (either as a hard requirement or a preference) is not required to change the settings of architectural feature test macros.

A32/T32 instruction set architecture

__ARM_ARCH is defined as an integer value indicating the current Arm instruction set architecture (for example 7 for the Arm v7-A architecture implemented by Cortex-A8 or the Armv7-M architecture implemented by Cortex-M3 or 8 for the Armv8-A architecture implemented by Cortex-A57). Armv8.1-A [ARMARMv81] onwards, the value of __ARM_ARCH is scaled up to include minor versions. The formula to calculate the value of __ARM_ARCH from Armv8.1-A [ARMARMv81] onwards is given by the following formula:

For an Arm architecture ArmvX.Y, __ARM_ARCH = X * 100 + Y. E.g.
for Armv8.1 __ARM_ARCH = 801.

Since ACLE only supports the Arm architecture, this macro would always be defined in an ACLE implementation.

Note that the __ARM_ARCH macro is defined even for cores which only support the T32 instruction set.

__ARM_ARCH_ISA_ARM is defined to 1 if the core supports the Arm instruction set. It is not defined for M-profile cores.

__ARM_ARCH_ISA_THUMB is defined to 1 if the core supports the original T32 instruction set (including the v6-M architecture) and 2 if it supports the T32 instruction set as found in the v6T2 architecture and all v7 architectures.

__ARM_ARCH_ISA_A64 is defined to 1 if the core supports AArch64’s A64 instruction set.

__ARM_32BIT_STATE is defined to 1 if code is being generated for AArch32.

__ARM_64BIT_STATE is defined to 1 if code is being generated for AArch64.

Architectural profile (A, R, M or pre-Cortex)

__ARM_ARCH_PROFILE is defined as A, R, M or S, or unset, according to the architectural profile of the target. S indicates the common subset of A and R. The common subset of A, R and M is indicated by:

__ARM_ARCH == 7 && !defined (__ARM_ARCH_PROFILE)

This macro corresponds to the Tag_CPU_arch_profile object build attribute. It may be useful to writers of system code. It is expected in most cases programmers will use more feature-specific tests.

The macro is undefined for architectural targets which predate the use of architectural profiles.

Unaligned access supported in hardware

__ARM_FEATURE_UNALIGNED is defined if the target supports unaligned access in hardware, at least to the extent of being able to load or store an integer word at any alignment with a single instruction. (There may be restrictions on load-multiple and floating-point accesses.) Note that whether a code generation target permits unaligned access will in general depend on the settings of system register bits, so an implementation should define this macro to match the user’s expectations and intentions. For example, a command-line option might be provided to disable the use of unaligned access, in which case this macro would not be defined.

LDREX/STREX

This feature was deprecated in ACLE 2.0. It is strongly recommended that C11/C++11 atomics be used instead.

__ARM_FEATURE_LDREX is defined if the load/store-exclusive instructions (LDREX/STREX) are supported. Its value is a set of bits indicating available widths of the access, as powers of 2. The following bits are used:

Bit Value Access width Instruction
0 0x01 byte LDREXB/STREXB
1 0x02 halfword LDREXH/STREXH
2 0x04 word LDREX/STREX
3 0x08 doubleword LDREXD/STREXD

Other bits are reserved.

The following values of __ARM_FEATURE_LDREX may occur:

Macro value Access widths Example architecture
(undefined) none Armv5, Armv6-M
0x04 word Armv6
0x07 word, halfword, byte Armv7-M
0x0F doubleword, word, halfword, byte Armv6K, Armv7-A/R

Other values are reserved.

The LDREX/STREX instructions are introduced in recent versions of the Arm architecture and supersede the SWP instruction. Where both are available, Arm strongly recommends programmers to use LDREX/STREX rather than SWP. Note that platforms may choose to make SWP unavailable in user mode and emulate it through a trap to a platform routine, or fault it.

Large System Extensions

__ARM_FEATURE_ATOMICS is defined if the Large System Extensions introduced in the Armv8.1-A [ARMARMv81] architecture are supported on this target. Note: It is strongly recommended that standardized C11/C++11 atomics are used to implement atomic operations in user code.

CLZ

__ARM_FEATURE_CLZ is defined to 1 if the CLZ (count leading zeroes) instruction is supported in hardware. Note that ACLE provides the __clz() family of intrinsics (see Miscellaneous data-processing intrinsics) even when __ARM_FEATURE_CLZ is not defined.

Q (saturation) flag

__ARM_FEATURE_QBIT is defined to 1 if the Q (saturation) global flag exists and the intrinsics defined in The Q (saturation) flag are available. This flag is used with the DSP saturating-arithmetic instructions (such as QADD) and the width-specified saturating instructions (SSAT and USAT). Note that either of these classes of instructions may exist without the other: for example, v5E has only QADD while v7-M has only SSAT.

Intrinsics associated with the Q-bit and their feature macro __ARM_FEATURE_QBIT are deprecated in ACLE 2.0 for A-profile. They are fully supported for M-profile and R-profile. This macro is defined for AArch32 only.

DSP instructions

__ARM_FEATURE_DSP is defined to 1 if the DSP (v5E) instructions are supported and the intrinsics defined in Saturating intrinsics are available. These instructions include QADD, SMULBB and others. This feature also implies support for the Q flag.

__ARM_FEATURE_DSP and its associated intrinsics are deprecated in ACLE 2.0 for A-profile. They are fully supported for M and R-profiles. This macro is defined for AArch32 only.

Saturation instructions

__ARM_FEATURE_SAT is defined to 1 if the SSAT and USAT instructions are supported and the intrinsics defined in Width-specified saturation intrinsics are available. This feature also implies support for the Q flag.

__ARM_FEATURE_SAT and its associated intrinsics are deprecated in ACLE 2.0 for A-profile. They are fully supported for M and R-profiles. This macro is defined for AArch32 only.

32-bit SIMD instructions

__ARM_FEATURE_SIMD32 is defined to 1 if the 32-bit SIMD instructions are supported and the intrinsics defined in 32-bit SIMD intrinsics are available. This also implies support for the GE global flags which indicate byte-by-byte comparison results.

__ARM_FEATURE_SIMD32 is deprecated in ACLE 2.0 for A-profile. Users are encouraged to use Neon Intrinsics as an equivalent for the 32-bit SIMD intrinsics functionality. However they are fully supported for M and R-profiles. This is defined for AArch32 only.

Hardware integer divide

__ARM_FEATURE_IDIV is defined to 1 if the target has hardware support for 32-bit integer division in all available instruction sets. Signed and unsigned versions are both assumed to be available. The intention is to allow programmers to choose alternative algorithm implementations depending on the likely speed of integer division.

Some older R-profile targets have hardware divide available in the T32 instruction set only. This can be tested for using the following test:

#if __ARM_FEATURE_IDIV || (__ARM_ARCH_PROFILE == R)

Transactional Memory Extension

__ARM_FEATURE_TME is defined to 1 if the Transactional Memory Extension instructions are supported in hardware and intrinsics defined in Transactional Memory Extension (TME) intrinsics are available.

Floating-point, Advanced SIMD (Neon) and MVE hardware

Hardware floating point

__ARM_FP is set if hardware floating-point is available. The value is a set of bits indicating the floating-point precisions supported. The following bits are used:

Bit Value Precision
1 0x02 half (16-bit) data type only
2 0x04 single (32-bit)
3 0x08 double (64-bit)

Bits 0 and 4..31 are reserved

Currently, the following values of __ARM_FP may occur (assuming the processor configuration option for hardware floating-point support is selected where available):

Value Precisions Example processor
(undefined) none any processor without hardware floating-point support
0x04 single Cortex-R5 when configured with SP only
0x06 single, half Cortex-M4.fp
0x0C double, single Arm9, Arm11, Cortex-A8, Cortex-R4
0x0E double, single, half Cortex-A9, Cortex-A15, Cortex-R7

Other values are reserved.

Standard C implementations support single and double precision floating-point irrespective of whether floating-point hardware is available. However, an implementation might choose to offer a mode to diagnose or fault use of floating-point arithmetic at a precision not supported in hardware.

Support for 16-bit floating-point language or 16-bit brain floating-point language extensions (see Half-precision (16-bit) floating-point format and Brain half-precision (16-bit) floating-point format) is only required if supported in hardware

Half-precision (16-bit) floating-point format

__ARM_FP16_FORMAT_IEEE is defined to 1 if the IEEE 754-2008 [IEEE-FP] 16-bit floating-point format is used.

__ARM_FP16_FORMAT_ALTERNATIVE is defined to 1 if the Arm alternative [ARMARM] 16-bit floating-point format is used. This format removes support for infinities and NaNs in order to provide an extra exponent bit.

At most one of these macros will be defined. See Half-precision floating-point for details of half-precision floating-point types.

Brain half-precision (16-bit) floating-point format

__ARM_BF16_FORMAT_ALTERNATIVE is defined to 1 if the Arm alternative [ARMARM] 16-bit brain floating-point format is used. This format closely resembles the IEEE 754 single-precision format. As such a brain half-precision floating point value can be converted to an IEEE 754 single-floating point format by appending 16 zero bits at the end.

__ARM_FEATURE_BF16_VECTOR_ARITHMETIC is defined to 1 if the brain 16-bit floating-point arithmetic instructions are supported in hardware and the associated vector intrinsics defined by ACLE are available. Note that this implies:

  • __ARM_FP & 0x02 == 1
  • __ARM_NEON_FP & 0x02 == 1

See Half-precision brain floating-point for details of half-precision brain floating-point types.

Fused multiply-accumulate (FMA)

__ARM_FEATURE_FMA is defined to 1 if the hardware floating-point architecture supports fused floating-point multiply-accumulate, i.e. without intermediate rounding. Note that C implementations are encouraged [C99] (7.12) to ensure that <math.h> defines FP_FAST_FMAF or FP_FAST_FMA, which can be tested by portable C code. A C implementation on Arm might define these macros by testing __ARM_FEATURE_FMA and __ARM_FP.

Advanced SIMD architecture extension (Neon)

__ARM_NEON is defined to a value indicating the Advanced SIMD (Neon) architecture supported. The only current value is 1.

In principle, for AArch32, the Neon architecture can exist in an integer-only version. To test for the presence of Neon floating-point vector instructions, test __ARM_NEON_FP. When Neon does occur in an integer-only version, the VFP scalar instruction set is also not present. See [ARMARM] (table A2-4) for architecturally permitted combinations.

__ARM_NEON is always set to 1 for AArch64.

Neon floating-point

__ARM_NEON_FP is defined as a bitmap to indicate floating-point support in the Neon architecture. The meaning of the values is the same as for __ARM_FP. This macro is undefined when the Neon extension is not present or does not support floating-point.

Current AArch32 Neon implementations do not support double-precision floating-point even when it is present in VFP. 16-bit floating-point format is supported in Neon if and only if it is supported in VFP. Consequently, the definition of __ARM_NEON_FP is the same as __ARM_FP except that the bit to indicate double-precision is not set for AArch32. Double-precision is always set for AArch64.

If __ARM_FEATURE_FMA and __ARM_NEON_FP are both defined, fused-multiply instructions are available in Neon also.

M-profile Vector Extension

__ARM_FEATURE_MVE is defined as a bitmap to indicate M-profile Vector Extension (MVE) support.

Bit Value Support
0 0x01 Integer MVE
1 0x02 Floating-point MVE

Wireless MMX

If Wireless MMX operations are available on the target, __ARM_WMMX is defined to a value that indicates the level of support, corresponding to the Tag_WMMX_arch build attribute.

This specification does not further define source-language features to support Wireless MMX.

Crypto extension

NOTE: The __ARM_FEATURE_CRYPTO macro is deprecated in favor of the finer grained feature macros described below.

__ARM_FEATURE_CRYPTO is defined to 1 if the Armv8-A Crypto instructions are supported and intrinsics targeting them are available. These instructions include AES{E, D}, SHA1{C, P, M} and others. This also implies __ARM_FEATURE_AES and __ARM_FEATURE_SHA2.

AES extension

__ARM_FEATURE_AES is defined to 1 if the AES Crypto instructions from Armv8-A are supported and intrinsics targeting them are available. These instructions include AES{E, D}, AESMC, AESIMC and others.

SHA2 extension

__ARM_FEATURE_SHA2 is defined to 1 if the SHA1 & SHA2 Crypto instructions from Armv8-A are supported and intrinsics targeting them are available. These instructions include SHA1{C, P, M} and others.

SHA512 extension

__ARM_FEATURE_SHA512 is defined to 1 if the SHA2 Crypto instructions from Armv8.2-A are supported and intrinsics targeting them are available. These instructions include SHA1{C, P, M} and others.

SHA3 extension

__ARM_FEATURE_SHA3 is defined to 1 if the SHA1 & SHA2 Crypto instructions from Armv8-A and the SHA2 and SHA3 instructions from Armv8.2-A and newer are supported and intrinsics targeting them are available. These instructions include AES{E, D}, SHA1{C, P, M}, RAX, and others.

SM3 extension

__ARM_FEATURE_SM3 is defined to 1 if the SM3 Crypto instructions from Armv8.2-A are supported and intrinsics targeting them are available. These instructions include SM3{TT1A, TT1B}, and others.

SM4 extension

__ARM_FEATURE_SM4 is defined to 1 if the SM4 Crypto instructions from Armv8.2-A are supported and intrinsics targeting them are available. These instructions include SM4{E, EKEY} and others.

FP16 FML extension

__ARM_FEATURE_FP16_FML is defined to 1 if the FP16 multiplication variant instructions from Armv8.2-A are supported and intrinsics targeting them are available. Available when __ARM_FEATURE_FP16_SCALAR_ARITHMETIC.

CRC32 extension

__ARM_FEATURE_CRC32 is defined to 1 if the CRC32 instructions are supported and the intrinsics defined in CRC32 intrinsics are available. These instructions include CRC32B, CRC32H and others. This is only available when __ARM_ARCH >= 8.

Random Number Generation Extension

__ARM_FEATURE_RNG is defined to 1 if the Random Number Generation instructions are supported and the intrinsics defined in Random number generation intrinsics are available.

Directed rounding

__ARM_FEATURE_DIRECTED_ROUNDING is defined to 1 if the directed rounding and conversion vector instructions are supported and rounding and conversion intrinsics are available. This is only available when __ARM_ARCH >= 8.

Numeric maximum and minimum

__ARM_FEATURE_NUMERIC_MAXMIN is defined to 1 if the IEEE 754-2008 compliant floating point maximum and minimum vector instructions are supported and intrinsics targeting these instructions are available. This is only available when __ARM_ARCH >= 8.

Half-precision argument and result

__ARM_FP16_ARGS is defined to 1 if __fp16 can be used as an argument and result.

Rounding doubling multiplies

__ARM_FEATURE_QRDMX is defined to 1 if SQRDMLAH and SQRDMLSH instructions and their associated intrinsics are available.

16-bit floating-point data processing operations

__ARM_FEATURE_FP16_SCALAR_ARITHMETIC is defined to 1 if the 16-bit floating-point arithmetic instructions are supported in hardware and the associated scalar intrinsics defined by ACLE are available. Note that this implies:

  • __ARM_FP16_FORMAT_IEEE == 1
  • __ARM_FP16_FORMAT_ALTERNATIVE == 0
  • __ARM_FP & 0x02 == 1

__ARM_FEATURE_FP16_VECTOR_ARITHMETIC is defined to 1 if the 16-bit floating-point arithmetic instructions are supported in hardware and the associated vector intrinsics defined by ACLE are available. Note that this implies:

  • __ARM_FP16_FORMAT_IEEE == 1
  • __ARM_FP16_FORMAT_ALTERNATIVE == 0
  • __ARM_FP & 0x02 == 1
  • __ARM_NEON_FP & 0x02 == 1

Javascript floating-point conversion

__ARM_FEATURE_JCVT is defined to 1 if the FJCVTZS (AArch64) or VJCVT (AArch32) instruction and the associated intrinsic is available.

Floating-point model

These macros test the floating-point model implemented by the compiler and libraries. The model determines the guarantees on arithmetic and exceptions.

__ARM_FP_FAST is defined to 1 if floating-point optimizations may occur such that the computed results are different from those prescribed by the order of operations according to the C standard. Examples of such optimizations would be reassociation of expressions to reduce depth, and replacement of a division by constant with multiplication by its reciprocal.

__ARM_FP_FENV_ROUNDING is defined to 1 if the implementation allows the rounding to be configured at runtime using the standard C fesetround() function and will apply this rounding to future floating-point operations. The rounding mode applies to both scalar floating-point and Neon.

The floating-point implementation might or might not support denormal values. If denormal values are not supported then they are flushed to zero.

Implementations may also define the following macros in appropriate floating-point modes:

__STDC_IEC_559__ is defined if the implementation conforms to IEC This implies support for floating-point exception status flags, including the inexact exception. This macro is specified by [C99] (6.10.8).

__SUPPORT_SNAN__ is defined if the implementation supports signalling NaNs. This macro is specified by the C standards proposal WG14 N965 Optional support for Signaling NaNs. (Note: this was not adopted into C11.)

Procedure call standard

__ARM_PCS is defined to 1 if the default procedure calling standard for the translation unit conforms to the base PCS defined in [AAPCS]. This is supported on AArch32 only.

__ARM_PCS_VFP is defined to 1 if the default is to pass floating-point parameters in hardware floating-point registers using the VFP variant PCS defined in [AAPCS]. This is supported on AArch32 only.

__ARM_PCS_AAPCS64 is defined to 1 if the default procedure calling standard for the translation unit conforms to the [AAPCS64].

Note that this should reflect the implementation default for the translation unit. Implementations which allow the PCS to be set for a function, class or namespace are not expected to redefine the macro within that scope.

Position-independent code

__ARM_ROPI is defined to 1 if the translation unit is being compiled in read-only position independent mode. In this mode, all read-only data and functions are at a link-time constant offset from the program counter.

__ARM_RWPI is defined to 1 if the translation unit is being compiled in read-write position independent mode. In this mode, all writable data is at a link-time constant offset from the static base register defined in [AAPCS].

The ROPI and RWPI position independence modes are compatible with each other, so the __ARM_ROPI and __ARM_RWPI macros may be defined at the same time.

Coprocessor intrinsics

__ARM_FEATURE_COPROC is defined as a bitmap to indicate the presence of coprocessor intrinsics for the target architecture. If __ARM_FEATURE_COPROC is undefined or zero, that means there is no support for coprocessor intrinsics on the target architecture. The following bits are used:

Bit Value Intrinsics Available
0 0x1 __arm_cdp __arm_ldc, __arm_ldcl, __arm_stc, __arm_stcl, __arm_mcr and __arm_mrc
1 0x2 __arm_cdp2, __arm_ldc2, __arm_stc2, __arm_ldc2l, __arm_stc2l, __arm_mcr2 and __arm_mrc2
2 0x4 __arm_mcrr and __arm_mrrc
3 0x8 __arm_mcrr2 and __arm_mrrc2

Armv8.5-A Floating-point rounding extension

__ARM_FEATURE_FRINT is defined to 1 if the Armv8.5-A rounding number instructions are supported and the scalar and vector intrinsics are available. This macro may only ever be defined in the AArch64 execution state. The scalar intrinsics are specified in Floating-point data-processing intrinsics and are not expected to be for general use. They are defined for uses that require the specialist rounding behavior of the relevant instructions. The vector intrinsics are specified in the Arm Neon Intrinsics Reference Architecture Specification [Neon].

Dot Product extension

__ARM_FEATURE_DOTPROD is defined if the dot product data manipulation instructions are supported and the vector intrinsics are available. Note that this implies:

  • __ARM_NEON == 1

Complex number intrinsics

__ARM_FEATURE_COMPLEX is defined if the complex addition and complex multiply-accumulate vector instructions are supported. Note that this implies:

  • __ARM_NEON == 1

These instructions require that the input vectors are organized such that the real and imaginary parts of the complex number are stored in alternating sequences: real, imag, real, imag, … etc.

Matrix Multiply Intrinsics

__ARM_FEATURE_MATMUL_INT8 is defined if the integer matrix multiply instructions are supported. Note that this implies:

  • __ARM_NEON == 1

Mapping of object build attributes to predefines

This section is provided for guidance. Details of build attributes can be found in [BA].

Mapping of object build attributes to predefines
Tag no. Tag Predefined macro
6 Tag_CPU_arch __ARM_ARCH, __ARM_FEATURE_DSP
7 Tag_CPU_arch_profile __ARM_PROFILE
8 Tag_ARM_ISA_use __ARM_ISA_ARM
9 Tag_THUMB_ISA_use __ARM_ISA_THUMB
11 Tag_WMMX_arch __ARM_WMMX
18 Tag_ABI_PCS_wchar_t __ARM_SIZEOF_WCHAR_T
20 Tag_ABI_FP_denormal  
21 Tag_ABI_FP_exceptions  
22 Tag_ABI_FP_user_exceptions  
23 Tag_ABI_FP_number_model  
26 Tag_ABI_enum_size __ARM_SIZEOF_MINIMAL_ENUM
34 Tag_CPU_unaligned_access __ARM_FEATURE_UNALIGNED
36 Tag_FP_HP_extension

__ARM_FP16_FORMAT_IEEE

__ARM_FP16_FORMAT_ALTERNATIVE

38 Tag_ABI_FP_16bit_for

__ARM_FP16_FORMAT_IEEE

__ARM_FP16_FORMAT_ALTERNATIVE

Summary of predefined macros

Summary of predefined macros
Macro name Meaning Example See section
__ARM_32BIT_STATE Code is for AArch32 state 1 A32/T32 instruction set architecture
__ARM_64BIT_STATE Code is for AArch64 state 1 A32/T32 instruction set architecture
__ARM_ACLE Indicates ACLE implemented 101 Testing for Arm C Language Extensions
__ARM_ALIGN_MAX_PWR Log of maximum alignment of static object 20 Alignment of static objects
__ARM_ALIGN_MAX_STACK_PWR Log of maximum alignment of stack object 3 Alignment of stack objects
__ARM_ARCH Arm architecture level 7 A32/T32 instruction set architecture
__ARM_ARCH_ISA_A64 AArch64 ISA present 1 A32/T32 instruction set architecture
__ARM_ARCH_ISA_ARM Arm instruction set present 1 A32/T32 instruction set architecture
__ARM_ARCH_ISA_THUMB T32 instruction set present 2 A32/T32 instruction set architecture
__ARM_ARCH_PROFILE Architecture profile A Architectural profile (A, R, M or pre-Cortex)
__ARM_BIG_ENDIAN Memory is big-endian 1 Endianness
__ARM_FEATURE_COMPLEX Armv8.3-A extension 1 Complex number intrinsics
__ARM_FEATURE_CLZ CLZ instruction 1 CLZ, Miscellaneous data-processing intrinsics
__ARM_FEATURE_CRC32 CRC32 extension 1 CRC32 extension
__ARM_FEATURE_CRYPTO Crypto extension 1 Crypto extension
__ARM_FEATURE_DIRECTED_ROUNDING Directed Rounding 1 Directed rounding
__ARM_FEATURE_DOTPROD Dot product extension (ARM v8.2-A) 1 Dot Product extension, Availability of Dot Product intrinsics
__ARM_FEATURE_FRINT Floating-point rounding extension (Arm v8.5-A) 1 Armv8.5-A Floating-point rounding extension, Availability of Armv8.5-A floating-point rounding intrinsics
__ARM_FEATURE_DSP DSP instructions (Arm v5E) (32-bit-only) 1 DSP instructions, Saturating intrinsics
__ARM_FEATURE_AES AES Crypto extension (Arm v8-A) 1 Crypto extension, AES extension
__ARM_FEATURE_FMA Floating-point fused multiply-accumulate 1 Fused multiply-accumulate (FMA), Floating-point data-processing intrinsics
__ARM_FEATURE_IDIV Hardware Integer Divide 1 Hardware integer divide
__ARM_FEATURE_JCVT Javascript conversion (ARMv8.3-A) 1 Javascript floating-point conversion Floating-point data-processing intrinsics
__ARM_FEATURE_LDREX (Deprecated) Load/store exclusive instructions 0x0F LDREX/STREX, Synchronization, barrier, and hint intrinsics
__ARM_FEATURE_MATMUL_INT8 Integer Matrix Multiply extension (Armv8.6-A, optional Armv8.2-A, Armv8.3-A, Armv8.4-A, Armv8.5-A) 1 Matrix Multiply Intrinsics Availability of Armv8.6-A Integer Matrix Multiply intrinsics
__ARM_FEATURE_MEMORY_TAGGING Memory Tagging (Armv8.5-A) 1 Memory tagging
__ARM_FEATURE_ATOMICS Large System Extensions 1 Large System Extensions
__ARM_FEATURE_NUMERIC_MAXMIN Numeric Maximum and Minimum 1 Numeric maximum and minimum
__ARM_FEATURE_QBIT Q (saturation) flag (32-bit-only) 1 (saturation) flag, The Q (saturation) flag
__ARM_FEATURE_QRDMX SQRDMLxH instructions and associated intrinsics availability 1 Rounding doubling multiplies
__ARM_FEATURE_SAT Width-specified saturation instructions (32-bit-only) 1 Saturation instructions Width-specified saturation intrinsics
__ARM_FEATURE_SHA2 SHA2 Crypto extension (Arm v8-A) 1 Crypto extension, SHA2 extension
__ARM_FEATURE_SHA512 SHA2 Crypto ext. (Arm v8.4-A, optional Armv8.2-A, Armv8.3-A) 1 Crypto extension, SHA512 extension
__ARM_FEATURE_SHA3 SHA3 Crypto extension (Arm v8.4-A) 1 Crypto extension, SHA3 extension
__ARM_FEATURE_SIMD32 32-bit SIMD instructions (Armv6) (32-bit-only) 1 Saturation instructions, 32-bit SIMD intrinsics
__ARM_FEATURE_SM3 SM3 Crypto extension (Arm v8.4-A, optional Armv8.2-A, Armv8.3-A) 1 Crypto extension, SM3 extension
__ARM_FEATURE_SM4 SM4 Crypto extension (Arm v8.4-A, optional Armv8.2-A, Armv8.3-A) 1 Crypto extension, SM4 extension
__ARM_FEATURE_FP16_FML FP16 FML extension (Arm v8.4-A, optional Armv8.2-A, Armv8.3-A) 1 FP16 FML extension
__ARM_FEATURE_UNALIGNED Hardware support for unaligned access 1 Unaligned access supported in hardware
__ARM_FP Hardware floating-point 0x0C Hardware floating point
__ARM_FP16_ARGS __fp16 argument and result 1 Half-precision argument and result
__ARM_FP16_FORMAT_ALTERNATIVE 16-bit floating-point, alternative format 1 Half-precision (16-bit) floating-point format
__ARM_FP16_FORMAT_IEEE 16-bit floating-point, IEEE format 1 Half-precision (16-bit) floating-point format
__ARM_FP_FAST Accuracy-losing optimizations 1 Floating-point model
__ARM_FP_FENV_ROUNDING Rounding is configurable at runtime 1 Floating-point model
__ARM_BF16_FORMAT_ALTERNATIVE 16-bit brain floating-point, alternative format 1 Brain half-precision (16-bit) floating-point format
__ARM_FEATURE_BF16 16-bit brain floating-point, vector instruction 1 Brain half-precision (16-bit) floating-point format
__ARM_FEATURE_MVE M-profile Vector Extension 0x01 M-profile Vector Extension
__ARM_NEON Advanced SIMD (Neon) extension 1 Neon floating-point
__ARM_NEON_FP Advanced SIMD (Neon) floating-point 0x04 Wireless MMX
__ARM_FEATURE_COPROC Coprocessor Intrinsics 0x01 Coprocessor intrinsics
__ARM_PCS Arm procedure call standard (32-bit-only) 1 Procedure call standard
__ARM_PCS_AAPCS64 Arm PCS for AArch64. 1 Procedure call standard
__ARM_PCS_VFP Arm PCS hardware FP variant in use (32-bit-only) 1 Procedure call standard
__ARM_FEATURE_RNG Random Number Generation Extension (Armv8.5-A) 1 Random Number Generation Extension
__ARM_ROPI Read-only PIC in use 1 Position-independent code
__ARM_RWPI Read-write PIC in use 1 Position-independent code
__ARM_SIZEOF_MINIMAL_ENUM Size of minimal enumeration type: 1 or 4 1 Implementation-defined type properties
__ARM_SIZEOF_WCHAR_T Size of wchar_t: 2 or 4 2 Implementation-defined type properties
__ARM_WMMX Wireless MMX extension (32-bit-only) 1 Wireless MMX
Was this page helpful? Yes No