Skip to content
Snippets Groups Projects
Code owners
Assign users and groups as approvers for specific file changes. Learn more.
AttributeReference.rst 39.68 KiB

Attributes in Clang

Introduction

This page lists the attributes currently supported by Clang.

Function Attributes

interrupt

Supported Syntaxes
GNU C++11 __declspec Keyword
X      

Clang supports the GNU style __attribute__((interrupt("TYPE"))) attribute on ARM targets. This attribute may be attached to a function definition and instructs the backend to generate appropriate function entry/exit code so that it can be used directly as an interrupt service routine.

The parameter passed to the interrupt attribute is optional, but if provided it must be a string literal with one of the following values: "IRQ", "FIQ", "SWI", "ABORT", "UNDEF".

The semantics are as follows:

  • If the function is AAPCS, Clang instructs the backend to realign the stack to 8 bytes on entry. This is a general requirement of the AAPCS at public interfaces, but may not hold when an exception is taken. Doing this allows other AAPCS functions to be called.

  • If the CPU is M-class this is all that needs to be done since the architecture itself is designed in such a way that functions obeying the normal AAPCS ABI constraints are valid exception handlers.

  • If the CPU is not M-class, the prologue and epilogue are modified to save all non-banked registers that are used, so that upon return the user-mode state will not be corrupted. Note that to avoid unnecessary overhead, only general-purpose (integer) registers are saved in this way. If VFP operations are needed, that state must be saved manually.

    Specifically, interrupt kinds other than "FIQ" will save all core registers except "lr" and "sp". "FIQ" interrupts will save r0-r7.

  • If the CPU is not M-class, the return instruction is changed to one of the canonical sequences permitted by the architecture for exception return. Where possible the function itself will make the necessary "lr" adjustments so that the "preferred return address" is selected.

    Unfortunately the compiler is unable to make this guarantee for an "UNDEF" handler, where the offset from "lr" to the preferred return address depends on the execution state of the code which generated the exception. In this case a sequence equivalent to "movs pc, lr" will be used.

acquire_capability (acquire_shared_capability, clang::acquire_capability, clang::acquire_shared_capability)

Supported Syntaxes
GNU C++11 __declspec Keyword
X X    

Marks a function as acquiring a capability.

assert_capability (assert_shared_capability, clang::assert_capability, clang::assert_shared_capability)

Supported Syntaxes
GNU C++11 __declspec Keyword
X X    

Marks a function that dynamically tests whether a capability is held, and halts the program if it is not held.

availability

Supported Syntaxes
GNU C++11 __declspec Keyword
X      

The availability attribute can be placed on declarations to describe the lifecycle of that declaration relative to operating system versions. Consider the function declaration for a hypothetical function f:

void f(void) __attribute__((availability(macosx,introduced=10.4,deprecated=10.6,obsoleted=10.7)));

The availability attribute states that f was introduced in Mac OS X 10.4, deprecated in Mac OS X 10.6, and obsoleted in Mac OS X 10.7. This information is used by Clang to determine when it is safe to use f: for example, if Clang is instructed to compile code for Mac OS X 10.5, a call to f() succeeds. If Clang is instructed to compile code for Mac OS X 10.6, the call succeeds but Clang emits a warning specifying that the function is deprecated. Finally, if Clang is instructed to compile code for Mac OS X 10.7, the call fails because f() is no longer available.

The availability attribute is a comma-separated list starting with the platform name and then including clauses specifying important milestones in the declaration's lifetime (in any order) along with additional information. Those clauses can be:

introduced=version
The first version in which this declaration was introduced.
deprecated=version
The first version in which this declaration was deprecated, meaning that users should migrate away from this API.
obsoleted=version
The first version in which this declaration was obsoleted, meaning that it was removed completely and can no longer be used.
unavailable
This declaration is never available on this platform.
message=string-literal
Additional message text that Clang will provide when emitting a warning or error about use of a deprecated or obsoleted declaration. Useful to direct users to replacement APIs.

Multiple availability attributes can be placed on a declaration, which may correspond to different platforms. Only the availability attribute with the platform corresponding to the target platform will be used; any others will be ignored. If no availability attribute specifies availability for the current target platform, the availability attributes are ignored. Supported platforms are:

ios
Apple's iOS operating system. The minimum deployment target is specified by the -mios-version-min=*version* or -miphoneos-version-min=*version* command-line arguments.
macosx
Apple's Mac OS X operating system. The minimum deployment target is specified by the -mmacosx-version-min=*version* command-line argument.

A declaration can be used even when deploying back to a platform version prior to when the declaration was introduced. When this happens, the declaration is weakly linked, as if the weak_import attribute were added to the declaration. A weakly-linked declaration may or may not be present a run-time, and a program can determine whether the declaration is present by checking whether the address of that declaration is non-NULL.

If there are multiple declarations of the same entity, the availability attributes must either match on a per-platform basis or later declarations must not have availability attributes for that platform. For example:

void g(void) __attribute__((availability(macosx,introduced=10.4)));
void g(void) __attribute__((availability(macosx,introduced=10.4))); // okay, matches
void g(void) __attribute__((availability(ios,introduced=4.0))); // okay, adds a new platform
void g(void); // okay, inherits both macosx and ios availability from above.
void g(void) __attribute__((availability(macosx,introduced=10.5))); // error: mismatch

When one method overrides another, the overriding method can be more widely available than the overridden method, e.g.,:

@interface A
- (id)method __attribute__((availability(macosx,introduced=10.4)));
- (id)method2 __attribute__((availability(macosx,introduced=10.4)));
@end

@interface B : A
- (id)method __attribute__((availability(macosx,introduced=10.3))); // okay: method moved into base class later
- (id)method __attribute__((availability(macosx,introduced=10.5))); // error: this method was available via the base class in 10.4
@end

_Noreturn

Supported Syntaxes
GNU C++11 __declspec Keyword
      X

A function declared as _Noreturn shall not return to its caller. The compiler will generate a diagnostic for a function declared as _Noreturn that appears to be capable of returning to its caller.

noreturn

Supported Syntaxes
GNU C++11 __declspec Keyword
  X    

A function declared as [[noreturn]] shall not return to its caller. The compiler will generate a diagnostic for a function declared as [[noreturn]] that appears to be capable of returning to its caller.

carries_dependency

Supported Syntaxes
GNU C++11 __declspec Keyword
X X    

The carries_dependency attribute specifies dependency propagation into and out of functions.

When specified on a function or Objective-C method, the carries_dependency attribute means that the return value carries a dependency out of the function, so that the implementation need not constrain ordering upon return from that function. Implementations of the function and its caller may choose to preserve dependencies instead of emitting memory ordering instructions such as fences.