---

6.4.2.4 ARM Attributes ¶

These attributes are supported for ARM targets:

general-regs-only ¶

This attribute applies to functions.

It indicates that no floating-point or Advanced SIMD registers should be used when generating code for this function. If the function explicitly uses floating-point code, then the compiler gives an error. This is the same behavior as that of the command-line option -mgeneral-regs-only.

interrupt ¶

This attribute applies to functions.

It indicates that the specified function is an interrupt handler. The compiler generates function entry and exit sequences suitable for use in an interrupt handler when this attribute is present.

You can specify the kind of interrupt to be handled by adding an optional parameter to the interrupt attribute like this:

void f () __attribute__ ((interrupt ("IRQ")));

Permissible values for this parameter are: IRQ, FIQ, SWI, ABORT and UNDEF.

On ARMv7-M the interrupt type is ignored, and the attribute means the function may be called with a word-aligned stack pointer.

isr ¶

This attribute applies to functions.

Use this attribute on ARM to write Interrupt Service Routines. This is an alias to the interrupt attribute above.

long_call ¶

short_call

These attributes apply to functions.

long_call and short_call specify how a particular function is called. These attributes override the -mlong-calls (see ARM Options) command-line switch and #pragma long_calls settings. For ARM, the long_call attribute indicates that the function might be far away from the call site and require a different (more expensive) calling sequence. The short_call attribute always places the offset to the function from the call site into the ‘BL’ instruction directly.

pcs ¶

This attribute applies to functions.

The pcs attribute can be used to control the calling convention used for a function on ARM. The attribute takes an argument that specifies the calling convention to use.

When compiling using the AAPCS ABI (or a variant of it) then valid values for the argument are "aapcs" and "aapcs-vfp". In order to use a variant other than "aapcs" then the compiler must be permitted to use the appropriate co-processor registers (i.e., the VFP registers must be available in order to use "aapcs-vfp"). For example,

/* Argument passed in r0, and result returned in r0+r1.  */
double f2d (float) __attribute__((pcs("aapcs")));

Variadic functions always use the "aapcs" calling convention and the compiler rejects attempts to specify an alternative.

target (options) ¶

This attribute applies to functions.

As discussed in Common Attributes, this attribute allows specification of target-specific compilation options.

On ARM, the following options are allowed:

‘thumb’ ¶

Force code generation in the Thumb (T16/T32) ISA, depending on the architecture level.

‘arm’ ¶

Force code generation in the ARM (A32) ISA.

Functions from different modes can be inlined in the caller’s mode.

‘fpu=’ ¶

Specifies the fpu for which to tune the performance of this function. The behavior and permissible arguments are the same as for the -mfpu= command-line option.

‘arch=’ ¶

Specifies the architecture version and architectural extensions to use for this function. The behavior and permissible arguments are the same as for the -march= command-line option.

The above target attributes can be specified as follows:

__attribute__((target("arch=armv8-a+crc")))
int
f (int a)
{
  return a + 5;
}

Additionally, the architectural extension string may be specified on its own. This can be used to turn on and off particular architectural extensions without having to specify a particular architecture version or core. Example:

__attribute__((target("+crc+nocrypto")))
int
foo (int a)
{
  return a + 5;
}

In this example target("+crc+nocrypto") enables the crc extension and disables the crypto extension for the function foo without modifying an existing -march= or -mcpu option.

notshared ¶

This attributes applies to class types.

On those ARM targets that support dllimport (such as Symbian OS), you can use the notshared type attribute to indicate that the virtual table and other similar data for a class should not be exported from a DLL. For example:

class __declspec(notshared) C {
public:
  __declspec(dllimport) C();
  virtual void f();
}

__declspec(dllexport)
C::C() {}

In this code, C::C is exported from the current DLL, but the virtual table for C is not exported. (You can use __attribute__ instead of __declspec if you prefer, but most Symbian OS code uses __declspec.)