diff --git a/CMakeLists.txt b/CMakeLists.txt index ff1ff210b56d..ca696b1ce79f 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -82,6 +82,7 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR ) set(LLVM_SHLIB_OUTPUT_INTDIR ${LLVM_LIBRARY_OUTPUT_INTDIR}) endif() + option(LLVM_ENABLE_WARNINGS "Enable compiler warnings." ON) option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 'install' target." OFF) @@ -185,6 +186,8 @@ if (LIBXML2_FOUND) set(CLANG_HAVE_LIBXML 1) endif() +find_package(Z3 4.5) + include(CheckIncludeFile) check_include_file(sys/resource.h CLANG_HAVE_RLIMITS) @@ -329,10 +332,6 @@ if (APPLE) endif() endif() -configure_file( - ${CLANG_SOURCE_DIR}/include/clang/Config/config.h.cmake - ${CLANG_BINARY_DIR}/include/clang/Config/config.h) - include(CMakeParseArguments) include(AddClang) @@ -368,21 +367,21 @@ option(CLANG_BUILD_TOOLS "Build the Clang tools. If OFF, just generate build targets." ON) option(CLANG_ENABLE_ARCMT "Build ARCMT." ON) -if (CLANG_ENABLE_ARCMT) - set(ENABLE_CLANG_ARCMT "1") -else() - set(ENABLE_CLANG_ARCMT "0") -endif() - option(CLANG_ENABLE_STATIC_ANALYZER "Build static analyzer." ON) -if (CLANG_ENABLE_STATIC_ANALYZER) - set(ENABLE_CLANG_STATIC_ANALYZER "1") -else() - set(ENABLE_CLANG_STATIC_ANALYZER "0") + +option(CLANG_ANALYZER_BUILD_Z3 + "Build the static analyzer with the Z3 constraint manager." OFF) + +if(NOT CLANG_ENABLE_STATIC_ANALYZER AND (CLANG_ENABLE_ARCMT OR CLANG_ANALYZER_BUILD_Z3)) + message(FATAL_ERROR "Cannot disable static analyzer while enabling ARCMT or Z3") endif() -if (NOT CLANG_ENABLE_STATIC_ANALYZER AND CLANG_ENABLE_ARCMT) - message(FATAL_ERROR "Cannot disable static analyzer while enabling ARCMT") +if(CLANG_ANALYZER_BUILD_Z3) + if(Z3_FOUND) + set(CLANG_ANALYZER_WITH_Z3 1) + else() + message(FATAL_ERROR "Cannot find Z3 header file or shared library") + endif() endif() if(CLANG_ENABLE_ARCMT) @@ -419,11 +418,6 @@ add_subdirectory(tools) add_subdirectory(runtime) option(CLANG_BUILD_EXAMPLES "Build CLANG example programs by default." OFF) -if (CLANG_BUILD_EXAMPLES) - set(ENABLE_CLANG_EXAMPLES "1") -else() - set(ENABLE_CLANG_EXAMPLES "0") -endif() add_subdirectory(examples) if(APPLE) @@ -519,6 +513,10 @@ if (CLANG_ENABLE_BOOTSTRAP) set(STAMP_DIR ${CMAKE_CURRENT_BINARY_DIR}/${NEXT_CLANG_STAGE}-stamps/) set(BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/${NEXT_CLANG_STAGE}-bins/) + if(BOOTSTRAP_LLVM_ENABLE_LLD) + add_dependencies(clang-bootstrap-deps lld) + endif() + # If the next stage is LTO we need to depend on LTO and possibly lld or LLVMgold if(BOOTSTRAP_LLVM_ENABLE_LTO OR LLVM_ENABLE_LTO AND NOT LLVM_BUILD_INSTRUMENTED) if(APPLE) @@ -535,9 +533,7 @@ if (CLANG_ENABLE_BOOTSTRAP) -DDYLD_LIBRARY_PATH=${LLVM_LIBRARY_OUTPUT_INTDIR}) elseif(NOT WIN32) add_dependencies(clang-bootstrap-deps llvm-ar llvm-ranlib) - if(BOOTSTRAP_LLVM_ENABLE_LLD) - add_dependencies(clang-bootstrap-deps lld) - elseif(LLVM_BINUTILS_INCDIR) + if(NOT BOOTSTRAP_LLVM_ENABLE_LLD AND LLVM_BINUTILS_INCDIR) add_dependencies(clang-bootstrap-deps LLVMgold) endif() set(LTO_AR -DCMAKE_AR=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-ar) @@ -700,3 +696,7 @@ endif() if (LLVM_ADD_NATIVE_VISUALIZERS_TO_SOLUTION) add_subdirectory(utils/ClangVisualizers) endif() + +configure_file( + ${CLANG_SOURCE_DIR}/include/clang/Config/config.h.cmake + ${CLANG_BINARY_DIR}/include/clang/Config/config.h) diff --git a/bindings/python/clang/cindex.py b/bindings/python/clang/cindex.py index cf867bbf7d0b..48fc8b13a209 100644 --- a/bindings/python/clang/cindex.py +++ b/bindings/python/clang/cindex.py @@ -1887,6 +1887,7 @@ TypeKind.OBJCID = TypeKind(27) TypeKind.OBJCCLASS = TypeKind(28) TypeKind.OBJCSEL = TypeKind(29) TypeKind.FLOAT128 = TypeKind(30) +TypeKind.HALF = TypeKind(31) TypeKind.COMPLEX = TypeKind(100) TypeKind.POINTER = TypeKind(101) TypeKind.BLOCKPOINTER = TypeKind(102) diff --git a/cmake/caches/Apple-stage2-ThinLTO.cmake b/cmake/caches/Apple-stage2-ThinLTO.cmake new file mode 100644 index 000000000000..54e54e306e7a --- /dev/null +++ b/cmake/caches/Apple-stage2-ThinLTO.cmake @@ -0,0 +1,6 @@ +# This file sets up a CMakeCache for Apple-style stage2 ThinLTO bootstrap. It is +# specified by the stage1 build. + + +set(LLVM_ENABLE_LTO THIN CACHE BOOL "") +include(${CMAKE_CURRENT_LIST_DIR}/Apple-stage2.cmake) diff --git a/cmake/caches/Fuchsia-stage2.cmake b/cmake/caches/Fuchsia-stage2.cmake new file mode 100644 index 000000000000..2e1e9a155e14 --- /dev/null +++ b/cmake/caches/Fuchsia-stage2.cmake @@ -0,0 +1,66 @@ +# This file sets up a CMakeCache for the second stage of a Fuchsia toolchain +# build. + +set(LLVM_TARGETS_TO_BUILD X86;AArch64 CACHE STRING "") + +set(PACKAGE_VENDOR Fuchsia CACHE STRING "") + +set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "") +set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "") +set(LLVM_TOOL_CLANG_TOOLS_EXTRA_BUILD OFF CACHE BOOL "") +set(LLVM_ENABLE_ZLIB ON CACHE BOOL "") +set(LLVM_ENABLE_BACKTRACES OFF CACHE BOOL "") +set(LLVM_EXTERNALIZE_DEBUGINFO ON CACHE BOOL "") +set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "") + +set(LLVM_ENABLE_LTO ON CACHE BOOL "") +if(NOT APPLE) + set(LLVM_ENABLE_LLD ON CACHE BOOL "") + set(CLANG_DEFAULT_LINKER lld CACHE STRING "") +endif() + +if(APPLE) + set(LLDB_CODESIGN_IDENTITY "" CACHE STRING "") +endif() + +set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "") +set(CMAKE_C_FLAGS_RELWITHDEBINFO "-O2 -gline-tables-only -DNDEBUG" CACHE STRING "") +set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O2 -gline-tables-only -DNDEBUG" CACHE STRING "") + +set(LLVM_BUILTIN_TARGETS "x86_64-fuchsia-none;aarch64-fuchsia-none" CACHE STRING "") +set(BUILTINS_x86_64-fuchsia-none_CMAKE_SYSROOT ${FUCHSIA_SYSROOT} CACHE STRING "") +set(BUILTINS_x86_64-fuchsia-none_CMAKE_SYSTEM_NAME Fuchsia CACHE STRING "") +set(BUILTINS_aarch64-fuchsia-none_CMAKE_SYSROOT ${FUCHSIA_SYSROOT} CACHE STRING "") +set(BUILTINS_aarch64-fuchsia-none_CMAKE_SYSTEM_NAME Fuchsia CACHE STRING "") + +# Setup toolchain. +set(LLVM_INSTALL_TOOLCHAIN_ONLY ON CACHE BOOL "") +set(LLVM_TOOLCHAIN_TOOLS + llvm-ar + llvm-cov + llvm-cxxfilt + llvm-dwarfdump + llvm-dsymutil + llvm-lib + llvm-nm + llvm-objdump + llvm-profdata + llvm-ranlib + llvm-readobj + llvm-size + llvm-symbolizer + CACHE STRING "") + +set(LLVM_DISTRIBUTION_COMPONENTS + clang + lld + lldb + liblldb + LTO + clang-format + clang-headers + builtins-x86_64-fuchsia-none + builtins-aarch64-fuchsia-none + runtimes + ${LLVM_TOOLCHAIN_TOOLS} + CACHE STRING "") diff --git a/cmake/caches/Fuchsia.cmake b/cmake/caches/Fuchsia.cmake new file mode 100644 index 000000000000..c8a8cf6d58b7 --- /dev/null +++ b/cmake/caches/Fuchsia.cmake @@ -0,0 +1,50 @@ +# This file sets up a CMakeCache for a Fuchsia toolchain build. + +set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "") + +set(PACKAGE_VENDOR Fuchsia CACHE STRING "") + +set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "") +set(LLVM_INCLUDE_TESTS OFF CACHE BOOL "") +set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "") +set(CLANG_INCLUDE_TESTS OFF CACHE BOOL "") +set(LLVM_ENABLE_ZLIB OFF CACHE BOOL "") +set(LLVM_ENABLE_BACKTRACES OFF CACHE BOOL "") +set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "") + +set(CMAKE_BUILD_TYPE Release CACHE STRING "") + +set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "") +if(NOT APPLE) + set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "") +endif() + +if(APPLE) + set(COMPILER_RT_ENABLE_IOS OFF CACHE BOOL "") + set(COMPILER_RT_ENABLE_TVOS OFF CACHE BOOL "") + set(COMPILER_RT_ENABLE_WATCHOS OFF CACHE BOOL "") +endif() + +set(CLANG_BOOTSTRAP_TARGETS + check-all + check-llvm + check-clang + llvm-config + test-suite + test-depends + llvm-test-depends + clang-test-depends + distribution + install-distribution + clang CACHE STRING "") + +if(FUCHSIA_SYSROOT) + set(EXTRA_ARGS -DFUCHSIA_SYSROOT=${FUCHSIA_SYSROOT}) +endif() + +# Setup the bootstrap build. +set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "") +set(CLANG_BOOTSTRAP_CMAKE_ARGS + ${EXTRA_ARGS} + -C ${CMAKE_CURRENT_LIST_DIR}/Fuchsia-stage2.cmake + CACHE STRING "") diff --git a/cmake/modules/CMakeLists.txt b/cmake/modules/CMakeLists.txt index b784c0d215ea..be6d1d7257bc 100644 --- a/cmake/modules/CMakeLists.txt +++ b/cmake/modules/CMakeLists.txt @@ -4,17 +4,27 @@ set(CLANG_INSTALL_PACKAGE_DIR lib${LLVM_LIBDIR_SUFFIX}/cmake/clang) set(clang_cmake_builddir "${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}") +# Keep this in sync with llvm/cmake/CMakeLists.txt! +set(LLVM_INSTALL_PACKAGE_DIR lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm) +set(llvm_cmake_builddir "${LLVM_BINARY_DIR}/${LLVM_INSTALL_PACKAGE_DIR}") + get_property(CLANG_EXPORTS GLOBAL PROPERTY CLANG_EXPORTS) export(TARGETS ${CLANG_EXPORTS} FILE ${clang_cmake_builddir}/ClangTargets.cmake) # Generate ClangConfig.cmake for the build tree. set(CLANG_CONFIG_CMAKE_DIR "${clang_cmake_builddir}") +set(CLANG_CONFIG_LLVM_CMAKE_DIR "${llvm_cmake_builddir}") set(CLANG_CONFIG_EXPORTS_FILE "${clang_cmake_builddir}/ClangTargets.cmake") +set(CLANG_CONFIG_INCLUDE_DIRS + "${CLANG_SOURCE_DIR}/include" + "${CLANG_BINARY_DIR}/include" + ) configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in ${clang_cmake_builddir}/ClangConfig.cmake @ONLY) set(CLANG_CONFIG_CMAKE_DIR) +set(CLANG_CONFIG_LLVM_CMAKE_DIR) set(CLANG_CONFIG_EXPORTS_FILE) # Generate ClangConfig.cmake for the install tree. @@ -29,7 +39,11 @@ foreach(p ${_count}) get_filename_component(CLANG_INSTALL_PREFIX \"\${CLANG_INSTALL_PREFIX}\" PATH)") endforeach(p) set(CLANG_CONFIG_CMAKE_DIR "\${CLANG_INSTALL_PREFIX}/${CLANG_INSTALL_PACKAGE_DIR}") +set(CLANG_CONFIG_LLVM_CMAKE_DIR "\${CLANG_INSTALL_PREFIX}/${LLVM_INSTALL_PACKAGE_DIR}") set(CLANG_CONFIG_EXPORTS_FILE "\${CLANG_CMAKE_DIR}/ClangTargets.cmake") +set(CLANG_CONFIG_INCLUDE_DIRS + "\${CLANG_INSTALL_PREFIX}/include" + ) configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake diff --git a/cmake/modules/ClangConfig.cmake.in b/cmake/modules/ClangConfig.cmake.in index a946944dd991..03bca691c2b6 100644 --- a/cmake/modules/ClangConfig.cmake.in +++ b/cmake/modules/ClangConfig.cmake.in @@ -1,11 +1,13 @@ # This file allows users to call find_package(Clang) and pick up our targets. -find_package(LLVM REQUIRED CONFIG) - @CLANG_CONFIG_CODE@ +find_package(LLVM REQUIRED CONFIG + HINTS "@CLANG_CONFIG_LLVM_CMAKE_DIR@") + set(CLANG_EXPORTED_TARGETS "@CLANG_EXPORTS@") set(CLANG_CMAKE_DIR "@CLANG_CONFIG_CMAKE_DIR@") +set(CLANG_INCLUDE_DIRS "@CLANG_CONFIG_INCLUDE_DIRS@") # Provide all our library targets to users. include("@CLANG_CONFIG_EXPORTS_FILE@") diff --git a/cmake/modules/FindZ3.cmake b/cmake/modules/FindZ3.cmake new file mode 100644 index 000000000000..779ef928da1b --- /dev/null +++ b/cmake/modules/FindZ3.cmake @@ -0,0 +1,28 @@ +find_path(Z3_INCLUDE_DIR NAMES z3.h + PATH_SUFFIXES libz3 z3 + ) + +find_library(Z3_LIBRARIES NAMES z3 libz3 + ) + +find_program(Z3_EXECUTABLE z3) + +if(Z3_INCLUDE_DIR AND Z3_EXECUTABLE) + execute_process (COMMAND ${Z3_EXECUTABLE} -version + OUTPUT_VARIABLE libz3_version_str + ERROR_QUIET + OUTPUT_STRIP_TRAILING_WHITESPACE) + + string(REGEX REPLACE "^Z3 version ([0-9.]+)" "\\1" + Z3_VERSION_STRING "${libz3_version_str}") + unset(libz3_version_str) +endif() + +# handle the QUIETLY and REQUIRED arguments and set Z3_FOUND to TRUE if +# all listed variables are TRUE +include(FindPackageHandleStandardArgs) +FIND_PACKAGE_HANDLE_STANDARD_ARGS(Z3 + REQUIRED_VARS Z3_LIBRARIES Z3_INCLUDE_DIR + VERSION_VAR Z3_VERSION_STRING) + +mark_as_advanced(Z3_INCLUDE_DIR Z3_LIBRARIES) diff --git a/docs/AttributeReference.rst b/docs/AttributeReference.rst index db4812afdaa0..a763ddeaeb10 100644 --- a/docs/AttributeReference.rst +++ b/docs/AttributeReference.rst @@ -1,3119 +1,13 @@ .. ------------------------------------------------------------------- NOTE: This file is automatically generated by running clang-tblgen - -gen-attr-docs. Do not edit this file by hand!! + -gen-attr-docs. Do not edit this file by hand!! The contents for + this file are automatically generated by a server-side process. + + Please do not commit this file. The file exists for local testing + purposes only. ------------------------------------------------------------------- =================== Attributes in Clang -=================== -.. contents:: - :local: - -Introduction -============ - -This page lists the attributes currently supported by Clang. - -Function Attributes -=================== - - -interrupt ---------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "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. - - -abi_tag (gnu::abi_tag) ----------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``abi_tag`` attribute can be applied to a function, variable, class or -inline namespace declaration to modify the mangled name of the entity. It gives -the ability to distinguish between different versions of the same entity but -with different ABI versions supported. For example, a newer version of a class -could have a different set of data members and thus have a different size. Using -the ``abi_tag`` attribute, it is possible to have different mangled names for -a global variable of the class type. Therefor, the old code could keep using -the old manged name and the new code will use the new mangled name with tags. - - -acquire_capability (acquire_shared_capability, clang::acquire_capability, clang::acquire_shared_capability) ------------------------------------------------------------------------------------------------------------ -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -Marks a function as acquiring a capability. - - -alloc_size (gnu::alloc_size) ----------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``alloc_size`` attribute can be placed on functions that return pointers in -order to hint to the compiler how many bytes of memory will be available at the -returned poiner. ``alloc_size`` takes one or two arguments. - -- ``alloc_size(N)`` implies that argument number N equals the number of - available bytes at the returned pointer. -- ``alloc_size(N, M)`` implies that the product of argument number N and - argument number M equals the number of available bytes at the returned - pointer. - -Argument numbers are 1-based. - -An example of how to use ``alloc_size`` - -.. code-block:: c - - void *my_malloc(int a) __attribute__((alloc_size(1))); - void *my_calloc(int a, int b) __attribute__((alloc_size(1, 2))); - - int main() { - void *const p = my_malloc(100); - assert(__builtin_object_size(p, 0) == 100); - void *const a = my_calloc(20, 5); - assert(__builtin_object_size(a, 0) == 100); - } - -.. Note:: This attribute works differently in clang than it does in GCC. - Specifically, clang will only trace ``const`` pointers (as above); we give up - on pointers that are not marked as ``const``. In the vast majority of cases, - this is unimportant, because LLVM has support for the ``alloc_size`` - attribute. However, this may cause mildly unintuitive behavior when used with - other attributes, such as ``enable_if``. - - -interrupt ---------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -Clang supports the GNU style ``__attribute__((interrupt))`` attribute on -x86/x86-64 targets.The compiler generates function entry and exit sequences -suitable for use in an interrupt handler when this attribute is present. -The 'IRET' instruction, instead of the 'RET' instruction, is used to return -from interrupt or exception handlers. All registers, except for the EFLAGS -register which is restored by the 'IRET' instruction, are preserved by the -compiler. - -Any interruptible-without-stack-switch code must be compiled with --mno-red-zone since interrupt handlers can and will, because of the -hardware design, touch the red zone. - -1. interrupt handler must be declared with a mandatory pointer argument: - - .. code-block:: c - - struct interrupt_frame - { - uword_t ip; - uword_t cs; - uword_t flags; - uword_t sp; - uword_t ss; - }; - - __attribute__ ((interrupt)) - void f (struct interrupt_frame *frame) { - ... - } - -2. exception handler: - - The exception handler is very similar to the interrupt handler with - a different mandatory function signature: - - .. code-block:: c - - __attribute__ ((interrupt)) - void f (struct interrupt_frame *frame, uword_t error_code) { - ... - } - - and compiler pops 'ERROR_CODE' off stack before the 'IRET' instruction. - - The exception handler should only be used for exceptions which push an - error code and all other exceptions must use the interrupt handler. - The system will crash if the wrong handler is used. - - -assert_capability (assert_shared_capability, clang::assert_capability, clang::assert_shared_capability) -------------------------------------------------------------------------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -Marks a function that dynamically tests whether a capability is held, and halts -the program if it is not held. - - -assume_aligned (gnu::assume_aligned) ------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -Use ``__attribute__((assume_aligned([,]))`` on a function -declaration to specify that the return value of the function (which must be a -pointer type) has the specified offset, in bytes, from an address with the -specified alignment. The offset is taken to be zero if omitted. - -.. code-block:: c++ - - // The returned pointer value has 32-byte alignment. - void *a() __attribute__((assume_aligned (32))); - - // The returned pointer value is 4 bytes greater than an address having - // 32-byte alignment. - void *b() __attribute__((assume_aligned (32, 4))); - -Note that this attribute provides information to the compiler regarding a -condition that the code already ensures is true. It does not cause the compiler -to enforce the provided alignment assumption. - - -availability ------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "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``: - -.. code-block:: c++ - - void f(void) __attribute__((availability(macos,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. - -replacement=\ *string-literal* - Additional message text that Clang will use to provide Fix-It when emitting - a warning about use of a deprecated declaration. The Fix-It will replace - the deprecated declaration with the new declaration specified. - -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. - -``macos`` - Apple's Mac OS X operating system. The minimum deployment target is - specified by the ``-mmacosx-version-min=*version*`` command-line argument. - ``macosx`` is supported for backward-compatibility reasons, but it is - deprecated. - -``tvos`` - Apple's tvOS operating system. The minimum deployment target is specified by - the ``-mtvos-version-min=*version*`` command-line argument. - -``watchos`` - Apple's watchOS operating system. The minimum deployment target is specified by - the ``-mwatchos-version-min=*version*`` command-line argument. - -A declaration can typically 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. - -The flag ``strict`` disallows using API when deploying back to a -platform version prior to when the declaration was introduced. An -attempt to use such API before its introduction causes a hard error. -Weakly-linking is almost always a better API choice, since it allows -users to query availability at runtime. - -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: - -.. code-block:: c - - void g(void) __attribute__((availability(macos,introduced=10.4))); - void g(void) __attribute__((availability(macos,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 macos and ios availability from above. - void g(void) __attribute__((availability(macos,introduced=10.5))); // error: mismatch - -When one method overrides another, the overriding method can be more widely available than the overridden method, e.g.,: - -.. code-block:: objc - - @interface A - - (id)method __attribute__((availability(macos,introduced=10.4))); - - (id)method2 __attribute__((availability(macos,introduced=10.4))); - @end - - @interface B : A - - (id)method __attribute__((availability(macos,introduced=10.3))); // okay: method moved into base class later - - (id)method __attribute__((availability(macos,introduced=10.5))); // error: this method was available via the base class in 10.4 - @end - - -_Noreturn ---------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","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 --------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","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 ------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "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. - -Note, this attribute does not change the meaning of the program, but may result -in generation of more efficient code. - - -convergent (clang::convergent) ------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``convergent`` attribute can be placed on a function declaration. It is -translated into the LLVM ``convergent`` attribute, which indicates that the call -instructions of a function with this attribute cannot be made control-dependent -on any additional values. - -In languages designed for SPMD/SIMT programming model, e.g. OpenCL or CUDA, -the call instructions of a function with this attribute must be executed by -all work items or threads in a work group or sub group. - -This attribute is different from ``noduplicate`` because it allows duplicating -function calls if it can be proved that the duplicated function calls are -not made control-dependent on any additional values, e.g., unrolling a loop -executed by all work items. - -Sample usage: -.. code-block:: c - - void convfunc(void) __attribute__((convergent)); - // Setting it as a C++11 attribute is also valid in a C++ program. - // void convfunc(void) [[clang::convergent]]; - - -deprecated (gnu::deprecated) ----------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","X","", "" - -The ``deprecated`` attribute can be applied to a function, a variable, or a -type. This is useful when identifying functions, variables, or types that are -expected to be removed in a future version of a program. - -Consider the function declaration for a hypothetical function ``f``: - -.. code-block:: c++ - - void f(void) __attribute__((deprecated("message", "replacement"))); - -When spelled as `__attribute__((deprecated))`, the deprecated attribute can have -two optional string arguments. The first one is the message to display when -emitting the warning; the second one enables the compiler to provide a Fix-It -to replace the deprecated name with a new name. Otherwise, when spelled as -`[[gnu::deprecated]] or [[deprecated]]`, the attribute can have one optional -string argument which is the message to display when emitting the warning. - - -diagnose_if ------------ -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -The ``diagnose_if`` attribute can be placed on function declarations to emit -warnings or errors at compile-time if calls to the attributed function meet -certain user-defined criteria. For example: - -.. code-block:: c - - void abs(int a) - __attribute__((diagnose_if(a >= 0, "Redundant abs call", "warning"))); - void must_abs(int a) - __attribute__((diagnose_if(a >= 0, "Redundant abs call", "error"))); - - int val = abs(1); // warning: Redundant abs call - int val2 = must_abs(1); // error: Redundant abs call - int val3 = abs(val); - int val4 = must_abs(val); // Because run-time checks are not emitted for - // diagnose_if attributes, this executes without - // issue. - - -``diagnose_if`` is closely related to ``enable_if``, with a few key differences: - -* Overload resolution is not aware of ``diagnose_if`` attributes: they're - considered only after we select the best candidate from a given candidate set. -* Function declarations that differ only in their ``diagnose_if`` attributes are - considered to be redeclarations of the same function (not overloads). -* If the condition provided to ``diagnose_if`` cannot be evaluated, no - diagnostic will be emitted. - -Otherwise, ``diagnose_if`` is essentially the logical negation of ``enable_if``. - -As a result of bullet number two, ``diagnose_if`` attributes will stack on the -same function. For example: - -.. code-block:: c - - int foo() __attribute__((diagnose_if(1, "diag1", "warning"))); - int foo() __attribute__((diagnose_if(1, "diag2", "warning"))); - - int bar = foo(); // warning: diag1 - // warning: diag2 - int (*fooptr)(void) = foo; // warning: diag1 - // warning: diag2 - - constexpr int supportsAPILevel(int N) { return N < 5; } - int baz(int a) - __attribute__((diagnose_if(!supportsAPILevel(10), - "Upgrade to API level 10 to use baz", "error"))); - int baz(int a) - __attribute__((diagnose_if(!a, "0 is not recommended.", "warning"))); - - int (*bazptr)(int) = baz; // error: Upgrade to API level 10 to use baz - int v = baz(0); // error: Upgrade to API level 10 to use baz - -Query for this feature with ``__has_attribute(diagnose_if)``. - - -disable_tail_calls (clang::disable_tail_calls) ----------------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``disable_tail_calls`` attribute instructs the backend to not perform tail call optimization inside the marked function. - -For example: - - .. code-block:: c - - int callee(int); - - int foo(int a) __attribute__((disable_tail_calls)) { - return callee(a); // This call is not tail-call optimized. - } - -Marking virtual functions as ``disable_tail_calls`` is legal. - - .. code-block:: c++ - - int callee(int); - - class Base { - public: - [[clang::disable_tail_calls]] virtual int foo1() { - return callee(); // This call is not tail-call optimized. - } - }; - - class Derived1 : public Base { - public: - int foo1() override { - return callee(); // This call is tail-call optimized. - } - }; - - -enable_if ---------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -.. Note:: Some features of this attribute are experimental. The meaning of - multiple enable_if attributes on a single declaration is subject to change in - a future version of clang. Also, the ABI is not standardized and the name - mangling may change in future versions. To avoid that, use asm labels. - -The ``enable_if`` attribute can be placed on function declarations to control -which overload is selected based on the values of the function's arguments. -When combined with the ``overloadable`` attribute, this feature is also -available in C. - -.. code-block:: c++ - - int isdigit(int c); - int isdigit(int c) __attribute__((enable_if(c <= -1 || c > 255, "chosen when 'c' is out of range"))) __attribute__((unavailable("'c' must have the value of an unsigned char or EOF"))); - - void foo(char c) { - isdigit(c); - isdigit(10); - isdigit(-10); // results in a compile-time error. - } - -The enable_if attribute takes two arguments, the first is an expression written -in terms of the function parameters, the second is a string explaining why this -overload candidate could not be selected to be displayed in diagnostics. The -expression is part of the function signature for the purposes of determining -whether it is a redeclaration (following the rules used when determining -whether a C++ template specialization is ODR-equivalent), but is not part of -the type. - -The enable_if expression is evaluated as if it were the body of a -bool-returning constexpr function declared with the arguments of the function -it is being applied to, then called with the parameters at the call site. If the -result is false or could not be determined through constant expression -evaluation, then this overload will not be chosen and the provided string may -be used in a diagnostic if the compile fails as a result. - -Because the enable_if expression is an unevaluated context, there are no global -state changes, nor the ability to pass information from the enable_if -expression to the function body. For example, suppose we want calls to -strnlen(strbuf, maxlen) to resolve to strnlen_chk(strbuf, maxlen, size of -strbuf) only if the size of strbuf can be determined: - -.. code-block:: c++ - - __attribute__((always_inline)) - static inline size_t strnlen(const char *s, size_t maxlen) - __attribute__((overloadable)) - __attribute__((enable_if(__builtin_object_size(s, 0) != -1))), - "chosen when the buffer size is known but 'maxlen' is not"))) - { - return strnlen_chk(s, maxlen, __builtin_object_size(s, 0)); - } - -Multiple enable_if attributes may be applied to a single declaration. In this -case, the enable_if expressions are evaluated from left to right in the -following manner. First, the candidates whose enable_if expressions evaluate to -false or cannot be evaluated are discarded. If the remaining candidates do not -share ODR-equivalent enable_if expressions, the overload resolution is -ambiguous. Otherwise, enable_if overload resolution continues with the next -enable_if attribute on the candidates that have not been discarded and have -remaining enable_if attributes. In this way, we pick the most specific -overload out of a number of viable overloads using enable_if. - -.. code-block:: c++ - - void f() __attribute__((enable_if(true, ""))); // #1 - void f() __attribute__((enable_if(true, ""))) __attribute__((enable_if(true, ""))); // #2 - - void g(int i, int j) __attribute__((enable_if(i, ""))); // #1 - void g(int i, int j) __attribute__((enable_if(j, ""))) __attribute__((enable_if(true))); // #2 - -In this example, a call to f() is always resolved to #2, as the first enable_if -expression is ODR-equivalent for both declarations, but #1 does not have another -enable_if expression to continue evaluating, so the next round of evaluation has -only a single candidate. In a call to g(1, 1), the call is ambiguous even though -#2 has more enable_if attributes, because the first enable_if expressions are -not ODR-equivalent. - -Query for this feature with ``__has_attribute(enable_if)``. - -Note that functions with one or more ``enable_if`` attributes may not have -their address taken, unless all of the conditions specified by said -``enable_if`` are constants that evaluate to ``true``. For example: - -.. code-block:: c - - const int TrueConstant = 1; - const int FalseConstant = 0; - int f(int a) __attribute__((enable_if(a > 0, ""))); - int g(int a) __attribute__((enable_if(a == 0 || a != 0, ""))); - int h(int a) __attribute__((enable_if(1, ""))); - int i(int a) __attribute__((enable_if(TrueConstant, ""))); - int j(int a) __attribute__((enable_if(FalseConstant, ""))); - - void fn() { - int (*ptr)(int); - ptr = &f; // error: 'a > 0' is not always true - ptr = &g; // error: 'a == 0 || a != 0' is not a truthy constant - ptr = &h; // OK: 1 is a truthy constant - ptr = &i; // OK: 'TrueConstant' is a truthy constant - ptr = &j; // error: 'FalseConstant' is a constant, but not truthy - } - -Because ``enable_if`` evaluation happens during overload resolution, -``enable_if`` may give unintuitive results when used with templates, depending -on when overloads are resolved. In the example below, clang will emit a -diagnostic about no viable overloads for ``foo`` in ``bar``, but not in ``baz``: - -.. code-block:: c++ - - double foo(int i) __attribute__((enable_if(i > 0, ""))); - void *foo(int i) __attribute__((enable_if(i <= 0, ""))); - template - auto bar() { return foo(I); } - - template - auto baz() { return foo(T::number); } - - struct WithNumber { constexpr static int number = 1; }; - void callThem() { - bar(); - baz(); - } - -This is because, in ``bar``, ``foo`` is resolved prior to template -instantiation, so the value for ``I`` isn't known (thus, both ``enable_if`` -conditions for ``foo`` fail). However, in ``baz``, ``foo`` is resolved during -template instantiation, so the value for ``T::number`` is known. - - -flatten (gnu::flatten) ----------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``flatten`` attribute causes calls within the attributed function to -be inlined unless it is impossible to do so, for example if the body of the -callee is unavailable or if the callee has the ``noinline`` attribute. - - -format (gnu::format) --------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -Clang supports the ``format`` attribute, which indicates that the function -accepts a ``printf`` or ``scanf``-like format string and corresponding -arguments or a ``va_list`` that contains these arguments. - -Please see `GCC documentation about format attribute -`_ to find details -about attribute syntax. - -Clang implements two kinds of checks with this attribute. - -#. Clang checks that the function with the ``format`` attribute is called with - a format string that uses format specifiers that are allowed, and that - arguments match the format string. This is the ``-Wformat`` warning, it is - on by default. - -#. Clang checks that the format string argument is a literal string. This is - the ``-Wformat-nonliteral`` warning, it is off by default. - - Clang implements this mostly the same way as GCC, but there is a difference - for functions that accept a ``va_list`` argument (for example, ``vprintf``). - GCC does not emit ``-Wformat-nonliteral`` warning for calls to such - functions. Clang does not warn if the format string comes from a function - parameter, where the function is annotated with a compatible attribute, - otherwise it warns. For example: - - .. code-block:: c - - __attribute__((__format__ (__scanf__, 1, 3))) - void foo(const char* s, char *buf, ...) { - va_list ap; - va_start(ap, buf); - - vprintf(s, ap); // warning: format string is not a string literal - } - - In this case we warn because ``s`` contains a format string for a - ``scanf``-like function, but it is passed to a ``printf``-like function. - - If the attribute is removed, clang still warns, because the format string is - not a string literal. - - Another example: - - .. code-block:: c - - __attribute__((__format__ (__printf__, 1, 3))) - void foo(const char* s, char *buf, ...) { - va_list ap; - va_start(ap, buf); - - vprintf(s, ap); // warning - } - - In this case Clang does not warn because the format string ``s`` and - the corresponding arguments are annotated. If the arguments are - incorrect, the caller of ``foo`` will receive a warning. - - -ifunc (gnu::ifunc) ------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -``__attribute__((ifunc("resolver")))`` is used to mark that the address of a declaration should be resolved at runtime by calling a resolver function. - -The symbol name of the resolver function is given in quotes. A function with this name (after mangling) must be defined in the current translation unit; it may be ``static``. The resolver function should take no arguments and return a pointer. - -The ``ifunc`` attribute may only be used on a function declaration. A function declaration with an ``ifunc`` attribute is considered to be a definition of the declared entity. The entity must not have weak linkage; for example, in C++, it cannot be applied to a declaration if a definition at that location would be considered inline. - -Not all targets support this attribute. ELF targets support this attribute when using binutils v2.20.1 or higher and glibc v2.11.1 or higher. Non-ELF targets currently do not support this attribute. - - -internal_linkage (clang::internal_linkage) ------------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``internal_linkage`` attribute changes the linkage type of the declaration to internal. -This is similar to C-style ``static``, but can be used on classes and class methods. When applied to a class definition, -this attribute affects all methods and static data members of that class. -This can be used to contain the ABI of a C++ library by excluding unwanted class methods from the export tables. - - -interrupt ---------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -Clang supports the GNU style ``__attribute__((interrupt("ARGUMENT")))`` attribute on -MIPS 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. - -By default, the compiler will produce a function prologue and epilogue suitable for -an interrupt service routine that handles an External Interrupt Controller (eic) -generated interrupt. This behaviour can be explicitly requested with the "eic" -argument. - -Otherwise, for use with vectored interrupt mode, the argument passed should be -of the form "vector=LEVEL" where LEVEL is one of the following values: -"sw0", "sw1", "hw0", "hw1", "hw2", "hw3", "hw4", "hw5". The compiler will -then set the interrupt mask to the corresponding level which will mask all -interrupts up to and including the argument. - -The semantics are as follows: - -- The prologue is modified so that the Exception Program Counter (EPC) and - Status coprocessor registers are saved to the stack. The interrupt mask is - set so that the function can only be interrupted by a higher priority - interrupt. The epilogue will restore the previous values of EPC and Status. - -- The prologue and epilogue are modified to save and restore all non-kernel - registers as necessary. - -- The FPU is disabled in the prologue, as the floating pointer registers are not - spilled to the stack. - -- The function return sequence is changed to use an exception return instruction. - -- The parameter sets the interrupt mask for the function corresponding to the - interrupt level specified. If no mask is specified the interrupt mask - defaults to "eic". - - -noalias -------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","X","", "" - -The ``noalias`` attribute indicates that the only memory accesses inside -function are loads and stores from objects pointed to by its pointer-typed -arguments, with arbitrary offsets. - - -noduplicate (clang::noduplicate) --------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``noduplicate`` attribute can be placed on function declarations to control -whether function calls to this function can be duplicated or not as a result of -optimizations. This is required for the implementation of functions with -certain special requirements, like the OpenCL "barrier" function, that might -need to be run concurrently by all the threads that are executing in lockstep -on the hardware. For example this attribute applied on the function -"nodupfunc" in the code below avoids that: - -.. code-block:: c - - void nodupfunc() __attribute__((noduplicate)); - // Setting it as a C++11 attribute is also valid - // void nodupfunc() [[clang::noduplicate]]; - void foo(); - void bar(); - - nodupfunc(); - if (a > n) { - foo(); - } else { - bar(); - } - -gets possibly modified by some optimizations into code similar to this: - -.. code-block:: c - - if (a > n) { - nodupfunc(); - foo(); - } else { - nodupfunc(); - bar(); - } - -where the call to "nodupfunc" is duplicated and sunk into the two branches -of the condition. - - -no_sanitize (clang::no_sanitize) --------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -Use the ``no_sanitize`` attribute on a function declaration to specify -that a particular instrumentation or set of instrumentations should not be -applied to that function. The attribute takes a list of string literals, -which have the same meaning as values accepted by the ``-fno-sanitize=`` -flag. For example, ``__attribute__((no_sanitize("address", "thread")))`` -specifies that AddressSanitizer and ThreadSanitizer should not be applied -to the function. - -See :ref:`Controlling Code Generation ` for a -full list of supported sanitizer flags. - - -no_sanitize_address (no_address_safety_analysis, gnu::no_address_safety_analysis, gnu::no_sanitize_address) ------------------------------------------------------------------------------------------------------------ -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -.. _langext-address_sanitizer: - -Use ``__attribute__((no_sanitize_address))`` on a function declaration to -specify that address safety instrumentation (e.g. AddressSanitizer) should -not be applied to that function. - - -no_sanitize_thread ------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -.. _langext-thread_sanitizer: - -Use ``__attribute__((no_sanitize_thread))`` on a function declaration to -specify that checks for data races on plain (non-atomic) memory accesses should -not be inserted by ThreadSanitizer. The function is still instrumented by the -tool to avoid false positives and provide meaningful stack traces. - - -no_sanitize_memory ------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -.. _langext-memory_sanitizer: - -Use ``__attribute__((no_sanitize_memory))`` on a function declaration to -specify that checks for uninitialized memory should not be inserted -(e.g. by MemorySanitizer). The function may still be instrumented by the tool -to avoid false positives in other places. - - -no_split_stack (gnu::no_split_stack) ------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``no_split_stack`` attribute disables the emission of the split stack -preamble for a particular function. It has no effect if ``-fsplit-stack`` -is not specified. - - -not_tail_called (clang::not_tail_called) ----------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``not_tail_called`` attribute prevents tail-call optimization on statically bound calls. It has no effect on indirect calls. Virtual functions, objective-c methods, and functions marked as ``always_inline`` cannot be marked as ``not_tail_called``. - -For example, it prevents tail-call optimization in the following case: - - .. code-block:: c - - int __attribute__((not_tail_called)) foo1(int); - - int foo2(int a) { - return foo1(a); // No tail-call optimization on direct calls. - } - -However, it doesn't prevent tail-call optimization in this case: - - .. code-block:: c - - int __attribute__((not_tail_called)) foo1(int); - - int foo2(int a) { - int (*fn)(int) = &foo1; - - // not_tail_called has no effect on an indirect call even if the call can be - // resolved at compile time. - return (*fn)(a); - } - -Marking virtual functions as ``not_tail_called`` is an error: - - .. code-block:: c++ - - class Base { - public: - // not_tail_called on a virtual function is an error. - [[clang::not_tail_called]] virtual int foo1(); - - virtual int foo2(); - - // Non-virtual functions can be marked ``not_tail_called``. - [[clang::not_tail_called]] int foo3(); - }; - - class Derived1 : public Base { - public: - int foo1() override; - - // not_tail_called on a virtual function is an error. - [[clang::not_tail_called]] int foo2() override; - }; - - -#pragma omp declare simd ------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","", "X" - -The `declare simd` construct can be applied to a function to enable the creation -of one or more versions that can process multiple arguments using SIMD -instructions from a single invocation in a SIMD loop. The `declare simd` -directive is a declarative directive. There may be multiple `declare simd` -directives for a function. The use of a `declare simd` construct on a function -enables the creation of SIMD versions of the associated function that can be -used to process multiple arguments from a single invocation from a SIMD loop -concurrently. -The syntax of the `declare simd` construct is as follows: - - .. code-block:: c - - #pragma omp declare simd [clause[[,] clause] ...] new-line - [#pragma omp declare simd [clause[[,] clause] ...] new-line] - [...] - function definition or declaration - -where clause is one of the following: - - .. code-block:: c - - simdlen(length) - linear(argument-list[:constant-linear-step]) - aligned(argument-list[:alignment]) - uniform(argument-list) - inbranch - notinbranch - - -#pragma omp declare target --------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","", "X" - -The `declare target` directive specifies that variables and functions are mapped -to a device for OpenMP offload mechanism. - -The syntax of the declare target directive is as follows: - - .. code-block:: c - - #pragma omp declare target new-line - declarations-definition-seq - #pragma omp end declare target new-line - - -objc_boxable ------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -Structs and unions marked with the ``objc_boxable`` attribute can be used -with the Objective-C boxed expression syntax, ``@(...)``. - -**Usage**: ``__attribute__((objc_boxable))``. This attribute -can only be placed on a declaration of a trivially-copyable struct or union: - -.. code-block:: objc - - struct __attribute__((objc_boxable)) some_struct { - int i; - }; - union __attribute__((objc_boxable)) some_union { - int i; - float f; - }; - typedef struct __attribute__((objc_boxable)) _some_struct some_struct; - - // ... - - some_struct ss; - NSValue *boxed = @(ss); - - -objc_method_family ------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -Many methods in Objective-C have conventional meanings determined by their -selectors. It is sometimes useful to be able to mark a method as having a -particular conventional meaning despite not having the right selector, or as -not having the conventional meaning that its selector would suggest. For these -use cases, we provide an attribute to specifically describe the "method family" -that a method belongs to. - -**Usage**: ``__attribute__((objc_method_family(X)))``, where ``X`` is one of -``none``, ``alloc``, ``copy``, ``init``, ``mutableCopy``, or ``new``. This -attribute can only be placed at the end of a method declaration: - -.. code-block:: objc - - - (NSString *)initMyStringValue __attribute__((objc_method_family(none))); - -Users who do not wish to change the conventional meaning of a method, and who -merely want to document its non-standard retain and release semantics, should -use the retaining behavior attributes (``ns_returns_retained``, -``ns_returns_not_retained``, etc). - -Query for this feature with ``__has_attribute(objc_method_family)``. - - -objc_requires_super -------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -Some Objective-C classes allow a subclass to override a particular method in a -parent class but expect that the overriding method also calls the overridden -method in the parent class. For these cases, we provide an attribute to -designate that a method requires a "call to ``super``" in the overriding -method in the subclass. - -**Usage**: ``__attribute__((objc_requires_super))``. This attribute can only -be placed at the end of a method declaration: - -.. code-block:: objc - - - (void)foo __attribute__((objc_requires_super)); - -This attribute can only be applied the method declarations within a class, and -not a protocol. Currently this attribute does not enforce any placement of -where the call occurs in the overriding method (such as in the case of -``-dealloc`` where the call must appear at the end). It checks only that it -exists. - -Note that on both OS X and iOS that the Foundation framework provides a -convenience macro ``NS_REQUIRES_SUPER`` that provides syntactic sugar for this -attribute: - -.. code-block:: objc - - - (void)foo NS_REQUIRES_SUPER; - -This macro is conditionally defined depending on the compiler's support for -this attribute. If the compiler does not support the attribute the macro -expands to nothing. - -Operationally, when a method has this annotation the compiler will warn if the -implementation of an override in a subclass does not call super. For example: - -.. code-block:: objc - - warning: method possibly missing a [super AnnotMeth] call - - (void) AnnotMeth{}; - ^ - - -objc_runtime_name ------------------ -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -By default, the Objective-C interface or protocol identifier is used -in the metadata name for that object. The `objc_runtime_name` -attribute allows annotated interfaces or protocols to use the -specified string argument in the object's metadata name instead of the -default name. - -**Usage**: ``__attribute__((objc_runtime_name("MyLocalName")))``. This attribute -can only be placed before an @protocol or @interface declaration: - -.. code-block:: objc - - __attribute__((objc_runtime_name("MyLocalName"))) - @interface Message - @end - - -objc_runtime_visible --------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -This attribute specifies that the Objective-C class to which it applies is visible to the Objective-C runtime but not to the linker. Classes annotated with this attribute cannot be subclassed and cannot have categories defined for them. - - -optnone (clang::optnone) ------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``optnone`` attribute suppresses essentially all optimizations -on a function or method, regardless of the optimization level applied to -the compilation unit as a whole. This is particularly useful when you -need to debug a particular function, but it is infeasible to build the -entire application without optimization. Avoiding optimization on the -specified function can improve the quality of the debugging information -for that function. - -This attribute is incompatible with the ``always_inline`` and ``minsize`` -attributes. - - -overloadable ------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -Clang provides support for C++ function overloading in C. Function overloading -in C is introduced using the ``overloadable`` attribute. For example, one -might provide several overloaded versions of a ``tgsin`` function that invokes -the appropriate standard function computing the sine of a value with ``float``, -``double``, or ``long double`` precision: - -.. code-block:: c - - #include - float __attribute__((overloadable)) tgsin(float x) { return sinf(x); } - double __attribute__((overloadable)) tgsin(double x) { return sin(x); } - long double __attribute__((overloadable)) tgsin(long double x) { return sinl(x); } - -Given these declarations, one can call ``tgsin`` with a ``float`` value to -receive a ``float`` result, with a ``double`` to receive a ``double`` result, -etc. Function overloading in C follows the rules of C++ function overloading -to pick the best overload given the call arguments, with a few C-specific -semantics: - -* Conversion from ``float`` or ``double`` to ``long double`` is ranked as a - floating-point promotion (per C99) rather than as a floating-point conversion - (as in C++). - -* A conversion from a pointer of type ``T*`` to a pointer of type ``U*`` is - considered a pointer conversion (with conversion rank) if ``T`` and ``U`` are - compatible types. - -* A conversion from type ``T`` to a value of type ``U`` is permitted if ``T`` - and ``U`` are compatible types. This conversion is given "conversion" rank. - -* If no viable candidates are otherwise available, we allow a conversion from a - pointer of type ``T*`` to a pointer of type ``U*``, where ``T`` and ``U`` are - incompatible. This conversion is ranked below all other types of conversions. - Please note: ``U`` lacking qualifiers that are present on ``T`` is sufficient - for ``T`` and ``U`` to be incompatible. - -The declaration of ``overloadable`` functions is restricted to function -declarations and definitions. Most importantly, if any function with a given -name is given the ``overloadable`` attribute, then all function declarations -and definitions with that name (and in that scope) must have the -``overloadable`` attribute. This rule even applies to redeclarations of -functions whose original declaration had the ``overloadable`` attribute, e.g., - -.. code-block:: c - - int f(int) __attribute__((overloadable)); - float f(float); // error: declaration of "f" must have the "overloadable" attribute - - int g(int) __attribute__((overloadable)); - int g(int) { } // error: redeclaration of "g" must also have the "overloadable" attribute - -Functions marked ``overloadable`` must have prototypes. Therefore, the -following code is ill-formed: - -.. code-block:: c - - int h() __attribute__((overloadable)); // error: h does not have a prototype - -However, ``overloadable`` functions are allowed to use a ellipsis even if there -are no named parameters (as is permitted in C++). This feature is particularly -useful when combined with the ``unavailable`` attribute: - -.. code-block:: c++ - - void honeypot(...) __attribute__((overloadable, unavailable)); // calling me is an error - -Functions declared with the ``overloadable`` attribute have their names mangled -according to the same rules as C++ function names. For example, the three -``tgsin`` functions in our motivating example get the mangled names -``_Z5tgsinf``, ``_Z5tgsind``, and ``_Z5tgsine``, respectively. There are two -caveats to this use of name mangling: - -* Future versions of Clang may change the name mangling of functions overloaded - in C, so you should not depend on an specific mangling. To be completely - safe, we strongly urge the use of ``static inline`` with ``overloadable`` - functions. - -* The ``overloadable`` attribute has almost no meaning when used in C++, - because names will already be mangled and functions are already overloadable. - However, when an ``overloadable`` function occurs within an ``extern "C"`` - linkage specification, it's name *will* be mangled in the same way as it - would in C. - -Query for this feature with ``__has_extension(attribute_overloadable)``. - - -release_capability (release_shared_capability, clang::release_capability, clang::release_shared_capability) ------------------------------------------------------------------------------------------------------------ -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -Marks a function as releasing a capability. - - -kernel ------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -``__attribute__((kernel))`` is used to mark a ``kernel`` function in -RenderScript. - -In RenderScript, ``kernel`` functions are used to express data-parallel -computations. The RenderScript runtime efficiently parallelizes ``kernel`` -functions to run on computational resources such as multi-core CPUs and GPUs. -See the RenderScript_ documentation for more information. - -.. _RenderScript: https://developer.android.com/guide/topics/renderscript/compute.html - - -target (gnu::target) --------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -Clang supports the GNU style ``__attribute__((target("OPTIONS")))`` attribute. -This attribute may be attached to a function definition and instructs -the backend to use different code generation options than were passed on the -command line. - -The current set of options correspond to the existing "subtarget features" for -the target with or without a "-mno-" in front corresponding to the absence -of the feature, as well as ``arch="CPU"`` which will change the default "CPU" -for the function. - -Example "subtarget features" from the x86 backend include: "mmx", "sse", "sse4.2", -"avx", "xop" and largely correspond to the machine specific options handled by -the front end. - - -try_acquire_capability (try_acquire_shared_capability, clang::try_acquire_capability, clang::try_acquire_shared_capability) ---------------------------------------------------------------------------------------------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -Marks a function that attempts to acquire a capability. This function may fail to -actually acquire the capability; they accept a Boolean value determining -whether acquiring the capability means success (true), or failing to acquire -the capability means success (false). - - -nodiscard, warn_unused_result, clang::warn_unused_result, gnu::warn_unused_result ---------------------------------------------------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -Clang supports the ability to diagnose when the results of a function call -expression are discarded under suspicious circumstances. A diagnostic is -generated when a function or its return type is marked with ``[[nodiscard]]`` -(or ``__attribute__((warn_unused_result))``) and the function call appears as a -potentially-evaluated discarded-value expression that is not explicitly cast to -`void`. - -.. code-block: c++ - struct [[nodiscard]] error_info { /*...*/ }; - error_info enable_missile_safety_mode(); - - void launch_missiles(); - void test_missiles() { - enable_missile_safety_mode(); // diagnoses - launch_missiles(); - } - error_info &foo(); - void f() { foo(); } // Does not diagnose, error_info is a reference. - - -xray_always_instrument (clang::xray_always_instrument), xray_never_instrument (clang::xray_never_instrument) ------------------------------------------------------------------------------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -``__attribute__((xray_always_instrument))`` or ``[[clang::xray_always_instrument]]`` is used to mark member functions (in C++), methods (in Objective C), and free functions (in C, C++, and Objective C) to be instrumented with XRay. This will cause the function to always have space at the beginning and exit points to allow for runtime patching. - -Conversely, ``__attribute__((xray_never_instrument))`` or ``[[clang::xray_never_instrument]]`` will inhibit the insertion of these instrumentation points. - -If a function has neither of these attributes, they become subject to the XRay heuristics used to determine whether a function should be instrumented or otherwise. - - -Variable Attributes -=================== - - -dllexport (gnu::dllexport) --------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","X","", "" - -The ``__declspec(dllexport)`` attribute declares a variable, function, or -Objective-C interface to be exported from the module. It is available under the -``-fdeclspec`` flag for compatibility with various compilers. The primary use -is for COFF object files which explicitly specify what interfaces are available -for external use. See the dllexport_ documentation on MSDN for more -information. - -.. _dllexport: https://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx - - -dllimport (gnu::dllimport) --------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","X","", "" - -The ``__declspec(dllimport)`` attribute declares a variable, function, or -Objective-C interface to be imported from an external module. It is available -under the ``-fdeclspec`` flag for compatibility with various compilers. The -primary use is for COFF object files which explicitly specify what interfaces -are imported from external modules. See the dllimport_ documentation on MSDN -for more information. - -.. _dllimport: https://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx - - -init_seg --------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","", "X" - -The attribute applied by ``pragma init_seg()`` controls the section into -which global initialization function pointers are emitted. It is only -available with ``-fms-extensions``. Typically, this function pointer is -emitted into ``.CRT$XCU`` on Windows. The user can change the order of -initialization by using a different section name with the same -``.CRT$XC`` prefix and a suffix that sorts lexicographically before or -after the standard ``.CRT$XCU`` sections. See the init_seg_ -documentation on MSDN for more information. - -.. _init_seg: http://msdn.microsoft.com/en-us/library/7977wcck(v=vs.110).aspx - - -nodebug (gnu::nodebug) ----------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``nodebug`` attribute allows you to suppress debugging information for a -function or method, or for a variable that is not a parameter or a non-static -data member. - - -nosvm ------ -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -OpenCL 2.0 supports the optional ``__attribute__((nosvm))`` qualifier for -pointer variable. It informs the compiler that the pointer does not refer -to a shared virtual memory region. See OpenCL v2.0 s6.7.2 for details. - -Since it is not widely used and has been removed from OpenCL 2.1, it is ignored -by Clang. - - -pass_object_size ----------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -.. Note:: The mangling of functions with parameters that are annotated with - ``pass_object_size`` is subject to change. You can get around this by - using ``__asm__("foo")`` to explicitly name your functions, thus preserving - your ABI; also, non-overloadable C functions with ``pass_object_size`` are - not mangled. - -The ``pass_object_size(Type)`` attribute can be placed on function parameters to -instruct clang to call ``__builtin_object_size(param, Type)`` at each callsite -of said function, and implicitly pass the result of this call in as an invisible -argument of type ``size_t`` directly after the parameter annotated with -``pass_object_size``. Clang will also replace any calls to -``__builtin_object_size(param, Type)`` in the function by said implicit -parameter. - -Example usage: - -.. code-block:: c - - int bzero1(char *const p __attribute__((pass_object_size(0)))) - __attribute__((noinline)) { - int i = 0; - for (/**/; i < (int)__builtin_object_size(p, 0); ++i) { - p[i] = 0; - } - return i; - } - - int main() { - char chars[100]; - int n = bzero1(&chars[0]); - assert(n == sizeof(chars)); - return 0; - } - -If successfully evaluating ``__builtin_object_size(param, Type)`` at the -callsite is not possible, then the "failed" value is passed in. So, using the -definition of ``bzero1`` from above, the following code would exit cleanly: - -.. code-block:: c - - int main2(int argc, char *argv[]) { - int n = bzero1(argv); - assert(n == -1); - return 0; - } - -``pass_object_size`` plays a part in overload resolution. If two overload -candidates are otherwise equally good, then the overload with one or more -parameters with ``pass_object_size`` is preferred. This implies that the choice -between two identical overloads both with ``pass_object_size`` on one or more -parameters will always be ambiguous; for this reason, having two such overloads -is illegal. For example: - -.. code-block:: c++ - - #define PS(N) __attribute__((pass_object_size(N))) - // OK - void Foo(char *a, char *b); // Overload A - // OK -- overload A has no parameters with pass_object_size. - void Foo(char *a PS(0), char *b PS(0)); // Overload B - // Error -- Same signature (sans pass_object_size) as overload B, and both - // overloads have one or more parameters with the pass_object_size attribute. - void Foo(void *a PS(0), void *b); - - // OK - void Bar(void *a PS(0)); // Overload C - // OK - void Bar(char *c PS(1)); // Overload D - - void main() { - char known[10], *unknown; - Foo(unknown, unknown); // Calls overload B - Foo(known, unknown); // Calls overload B - Foo(unknown, known); // Calls overload B - Foo(known, known); // Calls overload B - - Bar(known); // Calls overload D - Bar(unknown); // Calls overload D - } - -Currently, ``pass_object_size`` is a bit restricted in terms of its usage: - -* Only one use of ``pass_object_size`` is allowed per parameter. - -* It is an error to take the address of a function with ``pass_object_size`` on - any of its parameters. If you wish to do this, you can create an overload - without ``pass_object_size`` on any parameters. - -* It is an error to apply the ``pass_object_size`` attribute to parameters that - are not pointers. Additionally, any parameter that ``pass_object_size`` is - applied to must be marked ``const`` at its function's definition. - - -require_constant_initialization (clang::require_constant_initialization) ------------------------------------------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -This attribute specifies that the variable to which it is attached is intended -to have a `constant initializer `_ -according to the rules of [basic.start.static]. The variable is required to -have static or thread storage duration. If the initialization of the variable -is not a constant initializer an error will be produced. This attribute may -only be used in C++. - -Note that in C++03 strict constant expression checking is not done. Instead -the attribute reports if Clang can emit the variable as a constant, even if it's -not technically a 'constant initializer'. This behavior is non-portable. - -Static storage duration variables with constant initializers avoid hard-to-find -bugs caused by the indeterminate order of dynamic initialization. They can also -be safely used during dynamic initialization across translation units. - -This attribute acts as a compile time assertion that the requirements -for constant initialization have been met. Since these requirements change -between dialects and have subtle pitfalls it's important to fail fast instead -of silently falling back on dynamic initialization. - -.. code-block:: c++ - - // -std=c++14 - #define SAFE_STATIC [[clang::require_constant_initialization]] - struct T { - constexpr T(int) {} - ~T(); // non-trivial - }; - SAFE_STATIC T x = {42}; // Initialization OK. Doesn't check destructor. - SAFE_STATIC T y = 42; // error: variable does not have a constant initializer - // copy initialization is not a constant expression on a non-literal type. - - -section (gnu::section, __declspec(allocate)) --------------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","X","", "" - -The ``section`` attribute allows you to specify a specific section a -global variable or function should be in after translation. - - -swiftcall (gnu::swiftcall) --------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``swiftcall`` attribute indicates that a function should be called -using the Swift calling convention for a function or function pointer. - -The lowering for the Swift calling convention, as described by the Swift -ABI documentation, occurs in multiple phases. The first, "high-level" -phase breaks down the formal parameters and results into innately direct -and indirect components, adds implicit paraameters for the generic -signature, and assigns the context and error ABI treatments to parameters -where applicable. The second phase breaks down the direct parameters -and results from the first phase and assigns them to registers or the -stack. The ``swiftcall`` convention only handles this second phase of -lowering; the C function type must accurately reflect the results -of the first phase, as follows: - -- Results classified as indirect by high-level lowering should be - represented as parameters with the ``swift_indirect_result`` attribute. - -- Results classified as direct by high-level lowering should be represented - as follows: - - - First, remove any empty direct results. - - - If there are no direct results, the C result type should be ``void``. - - - If there is one direct result, the C result type should be a type with - the exact layout of that result type. - - - If there are a multiple direct results, the C result type should be - a struct type with the exact layout of a tuple of those results. - -- Parameters classified as indirect by high-level lowering should be - represented as parameters of pointer type. - -- Parameters classified as direct by high-level lowering should be - omitted if they are empty types; otherwise, they should be represented - as a parameter type with a layout exactly matching the layout of the - Swift parameter type. - -- The context parameter, if present, should be represented as a trailing - parameter with the ``swift_context`` attribute. - -- The error result parameter, if present, should be represented as a - trailing parameter (always following a context parameter) with the - ``swift_error_result`` attribute. - -``swiftcall`` does not support variadic arguments or unprototyped functions. - -The parameter ABI treatment attributes are aspects of the function type. -A function type which which applies an ABI treatment attribute to a -parameter is a different type from an otherwise-identical function type -that does not. A single parameter may not have multiple ABI treatment -attributes. - -Support for this feature is target-dependent, although it should be -supported on every target that Swift supports. Query for this support -with ``__has_attribute(swiftcall)``. This implies support for the -``swift_context``, ``swift_error_result``, and ``swift_indirect_result`` -attributes. - - -swift_context (gnu::swift_context) ----------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``swift_context`` attribute marks a parameter of a ``swiftcall`` -function as having the special context-parameter ABI treatment. - -This treatment generally passes the context value in a special register -which is normally callee-preserved. - -A ``swift_context`` parameter must either be the last parameter or must be -followed by a ``swift_error_result`` parameter (which itself must always be -the last parameter). - -A context parameter must have pointer or reference type. - - -swift_error_result (gnu::swift_error_result) --------------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``swift_error_result`` attribute marks a parameter of a ``swiftcall`` -function as having the special error-result ABI treatment. - -This treatment generally passes the underlying error value in and out of -the function through a special register which is normally callee-preserved. -This is modeled in C by pretending that the register is addressable memory: - -- The caller appears to pass the address of a variable of pointer type. - The current value of this variable is copied into the register before - the call; if the call returns normally, the value is copied back into the - variable. - -- The callee appears to receive the address of a variable. This address - is actually a hidden location in its own stack, initialized with the - value of the register upon entry. When the function returns normally, - the value in that hidden location is written back to the register. - -A ``swift_error_result`` parameter must be the last parameter, and it must be -preceded by a ``swift_context`` parameter. - -A ``swift_error_result`` parameter must have type ``T**`` or ``T*&`` for some -type T. Note that no qualifiers are permitted on the intermediate level. - -It is undefined behavior if the caller does not pass a pointer or -reference to a valid object. - -The standard convention is that the error value itself (that is, the -value stored in the apparent argument) will be null upon function entry, -but this is not enforced by the ABI. - - -swift_indirect_result (gnu::swift_indirect_result) --------------------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``swift_indirect_result`` attribute marks a parameter of a ``swiftcall`` -function as having the special indirect-result ABI treatment. - -This treatment gives the parameter the target's normal indirect-result -ABI treatment, which may involve passing it differently from an ordinary -parameter. However, only the first indirect result will receive this -treatment. Furthermore, low-level lowering may decide that a direct result -must be returned indirectly; if so, this will take priority over the -``swift_indirect_result`` parameters. - -A ``swift_indirect_result`` parameter must either be the first parameter or -follow another ``swift_indirect_result`` parameter. - -A ``swift_indirect_result`` parameter must have type ``T*`` or ``T&`` for -some object type ``T``. If ``T`` is a complete type at the point of -definition of a function, it is undefined behavior if the argument -value does not point to storage of adequate size and alignment for a -value of type ``T``. - -Making indirect results explicit in the signature allows C functions to -directly construct objects into them without relying on language -optimizations like C++'s named return value optimization (NRVO). - - -tls_model (gnu::tls_model) --------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``tls_model`` attribute allows you to specify which thread-local storage -model to use. It accepts the following strings: - -* global-dynamic -* local-dynamic -* initial-exec -* local-exec - -TLS models are mutually exclusive. - - -thread ------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","X","", "" - -The ``__declspec(thread)`` attribute declares a variable with thread local -storage. It is available under the ``-fms-extensions`` flag for MSVC -compatibility. See the documentation for `__declspec(thread)`_ on MSDN. - -.. _`__declspec(thread)`: http://msdn.microsoft.com/en-us/library/9w1sdazb.aspx - -In Clang, ``__declspec(thread)`` is generally equivalent in functionality to the -GNU ``__thread`` keyword. The variable must not have a destructor and must have -a constant initializer, if any. The attribute only applies to variables -declared with static storage duration, such as globals, class static data -members, and static locals. - - -maybe_unused, unused, gnu::unused ---------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -When passing the ``-Wunused`` flag to Clang, entities that are unused by the -program may be diagnosed. The ``[[maybe_unused]]`` (or -``__attribute__((unused))``) attribute can be used to silence such diagnostics -when the entity cannot be removed. For instance, a local variable may exist -solely for use in an ``assert()`` statement, which makes the local variable -unused when ``NDEBUG`` is defined. - -The attribute may be applied to the declaration of a class, a typedef, a -variable, a function or method, a function parameter, an enumeration, an -enumerator, a non-static data member, or a label. - -.. code-block: c++ - #include - - [[maybe_unused]] void f([[maybe_unused]] bool thing1, - [[maybe_unused]] bool thing2) { - [[maybe_unused]] bool b = thing1 && thing2; - assert(b); - } - - -Type Attributes -=============== - - -align_value ------------ -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -The align_value attribute can be added to the typedef of a pointer type or the -declaration of a variable of pointer or reference type. It specifies that the -pointer will point to, or the reference will bind to, only objects with at -least the provided alignment. This alignment value must be some positive power -of 2. - - .. code-block:: c - - typedef double * aligned_double_ptr __attribute__((align_value(64))); - void foo(double & x __attribute__((align_value(128)), - aligned_double_ptr y) { ... } - -If the pointer value does not have the specified alignment at runtime, the -behavior of the program is undefined. - - -empty_bases ------------ -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","X","", "" - -The empty_bases attribute permits the compiler to utilize the -empty-base-optimization more frequently. -This attribute only applies to struct, class, and union types. -It is only supported when using the Microsoft C++ ABI. - - -flag_enum ---------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -This attribute can be added to an enumerator to signal to the compiler that it -is intended to be used as a flag type. This will cause the compiler to assume -that the range of the type includes all of the values that you can get by -manipulating bits of the enumerator when issuing warnings. - - -lto_visibility_public (clang::lto_visibility_public) ----------------------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","X","","", "" - -See :doc:`LTOVisibility`. - - -layout_version --------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","X","", "" - -The layout_version attribute requests that the compiler utilize the class -layout rules of a particular compiler version. -This attribute only applies to struct, class, and union types. -It is only supported when using the Microsoft C++ ABI. - - -__single_inhertiance, __multiple_inheritance, __virtual_inheritance -------------------------------------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","X", "" - -This collection of keywords is enabled under ``-fms-extensions`` and controls -the pointer-to-member representation used on ``*-*-win32`` targets. - -The ``*-*-win32`` targets utilize a pointer-to-member representation which -varies in size and alignment depending on the definition of the underlying -class. - -However, this is problematic when a forward declaration is only available and -no definition has been made yet. In such cases, Clang is forced to utilize the -most general representation that is available to it. - -These keywords make it possible to use a pointer-to-member representation other -than the most general one regardless of whether or not the definition will ever -be present in the current translation unit. - -This family of keywords belong between the ``class-key`` and ``class-name``: - -.. code-block:: c++ - - struct __single_inheritance S; - int S::*i; - struct S {}; - -This keyword can be applied to class templates but only has an effect when used -on full specializations: - -.. code-block:: c++ - - template struct __single_inheritance A; // warning: inheritance model ignored on primary template - template struct __multiple_inheritance A; // warning: inheritance model ignored on partial specialization - template <> struct __single_inheritance A; - -Note that choosing an inheritance model less general than strictly necessary is -an error: - -.. code-block:: c++ - - struct __multiple_inheritance S; // error: inheritance model does not match definition - int S::*i; - struct S {}; - - -novtable --------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","X","", "" - -This attribute can be added to a class declaration or definition to signal to -the compiler that constructors and destructors will not reference the virtual -function table. It is only supported when using the Microsoft C++ ABI. - - -objc_subclassing_restricted ---------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -This attribute can be added to an Objective-C ``@interface`` declaration to -ensure that this class cannot be subclassed. - - -transparent_union (gnu::transparent_union) ------------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -This attribute can be applied to a union to change the behaviour of calls to -functions that have an argument with a transparent union type. The compiler -behaviour is changed in the following manner: - -- A value whose type is any member of the transparent union can be passed as an - argument without the need to cast that value. - -- The argument is passed to the function using the calling convention of the - first member of the transparent union. Consequently, all the members of the - transparent union should have the same calling convention as its first member. - -Transparent unions are not supported in C++. - - -Statement Attributes -==================== - - -fallthrough, clang::fallthrough -------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","X","","", "" - -The ``fallthrough`` (or ``clang::fallthrough``) attribute is used -to annotate intentional fall-through -between switch labels. It can only be applied to a null statement placed at a -point of execution between any statement and the next switch label. It is -common to mark these places with a specific comment, but this attribute is -meant to replace comments with a more strict annotation, which can be checked -by the compiler. This attribute doesn't change semantics of the code and can -be used wherever an intended fall-through occurs. It is designed to mimic -control-flow statements like ``break;``, so it can be placed in most places -where ``break;`` can, but only if there are no statements on the execution path -between it and the next switch label. - -By default, Clang does not warn on unannotated fallthrough from one ``switch`` -case to another. Diagnostics on fallthrough without a corresponding annotation -can be enabled with the ``-Wimplicit-fallthrough`` argument. - -Here is an example: - -.. code-block:: c++ - - // compile with -Wimplicit-fallthrough - switch (n) { - case 22: - case 33: // no warning: no statements between case labels - f(); - case 44: // warning: unannotated fall-through - g(); - [[clang::fallthrough]]; - case 55: // no warning - if (x) { - h(); - break; - } - else { - i(); - [[clang::fallthrough]]; - } - case 66: // no warning - p(); - [[clang::fallthrough]]; // warning: fallthrough annotation does not - // directly precede case label - q(); - case 77: // warning: unannotated fall-through - r(); - } - - -#pragma clang loop ------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","", "X" - -The ``#pragma clang loop`` directive allows loop optimization hints to be -specified for the subsequent loop. The directive allows vectorization, -interleaving, and unrolling to be enabled or disabled. Vector width as well -as interleave and unrolling count can be manually specified. See -`language extensions -`_ -for details. - - -#pragma unroll, #pragma nounroll --------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","", "X" - -Loop unrolling optimization hints can be specified with ``#pragma unroll`` and -``#pragma nounroll``. The pragma is placed immediately before a for, while, -do-while, or c++11 range-based for loop. - -Specifying ``#pragma unroll`` without a parameter directs the loop unroller to -attempt to fully unroll the loop if the trip count is known at compile time and -attempt to partially unroll the loop if the trip count is not known at compile -time: - -.. code-block:: c++ - - #pragma unroll - for (...) { - ... - } - -Specifying the optional parameter, ``#pragma unroll _value_``, directs the -unroller to unroll the loop ``_value_`` times. The parameter may optionally be -enclosed in parentheses: - -.. code-block:: c++ - - #pragma unroll 16 - for (...) { - ... - } - - #pragma unroll(16) - for (...) { - ... - } - -Specifying ``#pragma nounroll`` indicates that the loop should not be unrolled: - -.. code-block:: c++ - - #pragma nounroll - for (...) { - ... - } - -``#pragma unroll`` and ``#pragma unroll _value_`` have identical semantics to -``#pragma clang loop unroll(full)`` and -``#pragma clang loop unroll_count(_value_)`` respectively. ``#pragma nounroll`` -is equivalent to ``#pragma clang loop unroll(disable)``. See -`language extensions -`_ -for further details including limitations of the unroll hints. - - -__read_only, __write_only, __read_write (read_only, write_only, read_write) ---------------------------------------------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","X", "" - -The access qualifiers must be used with image object arguments or pipe arguments -to declare if they are being read or written by a kernel or function. - -The read_only/__read_only, write_only/__write_only and read_write/__read_write -names are reserved for use as access qualifiers and shall not be used otherwise. - -.. code-block:: c - - kernel void - foo (read_only image2d_t imageA, - write_only image2d_t imageB) { - ... - } - -In the above example imageA is a read-only 2D image object, and imageB is a -write-only 2D image object. - -The read_write (or __read_write) qualifier can not be used with pipe. - -More details can be found in the OpenCL C language Spec v2.0, Section 6.6. - - -__attribute__((opencl_unroll_hint)) ------------------------------------ -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -The opencl_unroll_hint attribute qualifier can be used to specify that a loop -(for, while and do loops) can be unrolled. This attribute qualifier can be -used to specify full unrolling or partial unrolling by a specified amount. -This is a compiler hint and the compiler may ignore this directive. See -`OpenCL v2.0 `_ -s6.11.5 for details. - - -Type Safety Checking -==================== -Clang supports additional attributes to enable checking type safety properties -that can't be enforced by the C type system. To see warnings produced by these -checks, ensure that -Wtype-safety is enabled. Use cases include: - -* MPI library implementations, where these attributes enable checking that - the buffer type matches the passed ``MPI_Datatype``; -* for HDF5 library there is a similar use case to MPI; -* checking types of variadic functions' arguments for functions like - ``fcntl()`` and ``ioctl()``. - -You can detect support for these attributes with ``__has_attribute()``. For -example: - -.. code-block:: c++ - - #if defined(__has_attribute) - # if __has_attribute(argument_with_type_tag) && \ - __has_attribute(pointer_with_type_tag) && \ - __has_attribute(type_tag_for_datatype) - # define ATTR_MPI_PWT(buffer_idx, type_idx) __attribute__((pointer_with_type_tag(mpi,buffer_idx,type_idx))) - /* ... other macros ... */ - # endif - #endif - - #if !defined(ATTR_MPI_PWT) - # define ATTR_MPI_PWT(buffer_idx, type_idx) - #endif - - int MPI_Send(void *buf, int count, MPI_Datatype datatype /*, other args omitted */) - ATTR_MPI_PWT(1,3); - -argument_with_type_tag ----------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -Use ``__attribute__((argument_with_type_tag(arg_kind, arg_idx, -type_tag_idx)))`` on a function declaration to specify that the function -accepts a type tag that determines the type of some other argument. - -This attribute is primarily useful for checking arguments of variadic functions -(``pointer_with_type_tag`` can be used in most non-variadic cases). - -In the attribute prototype above: - * ``arg_kind`` is an identifier that should be used when annotating all - applicable type tags. - * ``arg_idx`` provides the position of a function argument. The expected type of - this function argument will be determined by the function argument specified - by ``type_tag_idx``. In the code example below, "3" means that the type of the - function's third argument will be determined by ``type_tag_idx``. - * ``type_tag_idx`` provides the position of a function argument. This function - argument will be a type tag. The type tag will determine the expected type of - the argument specified by ``arg_idx``. In the code example below, "2" means - that the type tag associated with the function's second argument should agree - with the type of the argument specified by ``arg_idx``. - -For example: - -.. code-block:: c++ - - int fcntl(int fd, int cmd, ...) - __attribute__(( argument_with_type_tag(fcntl,3,2) )); - // The function's second argument will be a type tag; this type tag will - // determine the expected type of the function's third argument. - - -pointer_with_type_tag ---------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -Use ``__attribute__((pointer_with_type_tag(ptr_kind, ptr_idx, type_tag_idx)))`` -on a function declaration to specify that the function accepts a type tag that -determines the pointee type of some other pointer argument. - -In the attribute prototype above: - * ``ptr_kind`` is an identifier that should be used when annotating all - applicable type tags. - * ``ptr_idx`` provides the position of a function argument; this function - argument will have a pointer type. The expected pointee type of this pointer - type will be determined by the function argument specified by - ``type_tag_idx``. In the code example below, "1" means that the pointee type - of the function's first argument will be determined by ``type_tag_idx``. - * ``type_tag_idx`` provides the position of a function argument; this function - argument will be a type tag. The type tag will determine the expected pointee - type of the pointer argument specified by ``ptr_idx``. In the code example - below, "3" means that the type tag associated with the function's third - argument should agree with the pointee type of the pointer argument specified - by ``ptr_idx``. - -For example: - -.. code-block:: c++ - - typedef int MPI_Datatype; - int MPI_Send(void *buf, int count, MPI_Datatype datatype /*, other args omitted */) - __attribute__(( pointer_with_type_tag(mpi,1,3) )); - // The function's 3rd argument will be a type tag; this type tag will - // determine the expected pointee type of the function's 1st argument. - - -type_tag_for_datatype ---------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -When declaring a variable, use -``__attribute__((type_tag_for_datatype(kind, type)))`` to create a type tag that -is tied to the ``type`` argument given to the attribute. - -In the attribute prototype above: - * ``kind`` is an identifier that should be used when annotating all applicable - type tags. - * ``type`` indicates the name of the type. - -Clang supports annotating type tags of two forms. - - * **Type tag that is a reference to a declared identifier.** - Use ``__attribute__((type_tag_for_datatype(kind, type)))`` when declaring that - identifier: - - .. code-block:: c++ - - typedef int MPI_Datatype; - extern struct mpi_datatype mpi_datatype_int - __attribute__(( type_tag_for_datatype(mpi,int) )); - #define MPI_INT ((MPI_Datatype) &mpi_datatype_int) - // &mpi_datatype_int is a type tag. It is tied to type "int". - - * **Type tag that is an integral literal.** - Declare a ``static const`` variable with an initializer value and attach - ``__attribute__((type_tag_for_datatype(kind, type)))`` on that declaration: - - .. code-block:: c++ - - typedef int MPI_Datatype; - static const MPI_Datatype mpi_datatype_int - __attribute__(( type_tag_for_datatype(mpi,int) )) = 42; - #define MPI_INT ((MPI_Datatype) 42) - // The number 42 is a type tag. It is tied to type "int". - - -The ``type_tag_for_datatype`` attribute also accepts an optional third argument -that determines how the type of the function argument specified by either -``arg_idx`` or ``ptr_idx`` is compared against the type associated with the type -tag. (Recall that for the ``argument_with_type_tag`` attribute, the type of the -function argument specified by ``arg_idx`` is compared against the type -associated with the type tag. Also recall that for the ``pointer_with_type_tag`` -attribute, the pointee type of the function argument specified by ``ptr_idx`` is -compared against the type associated with the type tag.) There are two supported -values for this optional third argument: - - * ``layout_compatible`` will cause types to be compared according to - layout-compatibility rules (In C++11 [class.mem] p 17, 18, see the - layout-compatibility rules for two standard-layout struct types and for two - standard-layout union types). This is useful when creating a type tag - associated with a struct or union type. For example: - - .. code-block:: c++ - - /* In mpi.h */ - typedef int MPI_Datatype; - struct internal_mpi_double_int { double d; int i; }; - extern struct mpi_datatype mpi_datatype_double_int - __attribute__(( type_tag_for_datatype(mpi, - struct internal_mpi_double_int, layout_compatible) )); - - #define MPI_DOUBLE_INT ((MPI_Datatype) &mpi_datatype_double_int) - - int MPI_Send(void *buf, int count, MPI_Datatype datatype, ...) - __attribute__(( pointer_with_type_tag(mpi,1,3) )); - - /* In user code */ - struct my_pair { double a; int b; }; - struct my_pair *buffer; - MPI_Send(buffer, 1, MPI_DOUBLE_INT /*, ... */); // no warning because the - // layout of my_pair is - // compatible with that of - // internal_mpi_double_int - - struct my_int_pair { int a; int b; } - struct my_int_pair *buffer2; - MPI_Send(buffer2, 1, MPI_DOUBLE_INT /*, ... */); // warning because the - // layout of my_int_pair - // does not match that of - // internal_mpi_double_int - - * ``must_be_null`` specifies that the function argument specified by either - ``arg_idx`` (for the ``argument_with_type_tag`` attribute) or ``ptr_idx`` (for - the ``pointer_with_type_tag`` attribute) should be a null pointer constant. - The second argument to the ``type_tag_for_datatype`` attribute is ignored. For - example: - - .. code-block:: c++ - - /* In mpi.h */ - typedef int MPI_Datatype; - extern struct mpi_datatype mpi_datatype_null - __attribute__(( type_tag_for_datatype(mpi, void, must_be_null) )); - - #define MPI_DATATYPE_NULL ((MPI_Datatype) &mpi_datatype_null) - int MPI_Send(void *buf, int count, MPI_Datatype datatype, ...) - __attribute__(( pointer_with_type_tag(mpi,1,3) )); - - /* In user code */ - struct my_pair { double a; int b; }; - struct my_pair *buffer; - MPI_Send(buffer, 1, MPI_DATATYPE_NULL /*, ... */); // warning: MPI_DATATYPE_NULL - // was specified but buffer - // is not a null pointer - - -AMD GPU Attributes -================== - - -amdgpu_flat_work_group_size ---------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -The flat work-group size is the number of work-items in the work-group size -specified when the kernel is dispatched. It is the product of the sizes of the -x, y, and z dimension of the work-group. - -Clang supports the -``__attribute__((amdgpu_flat_work_group_size(, )))`` attribute for the -AMDGPU target. This attribute may be attached to a kernel function definition -and is an optimization hint. - -```` parameter specifies the minimum flat work-group size, and ```` -parameter specifies the maximum flat work-group size (must be greater than -````) to which all dispatches of the kernel will conform. Passing ``0, 0`` -as ``, `` implies the default behavior (``128, 256``). - -If specified, the AMDGPU target backend might be able to produce better machine -code for barriers and perform scratch promotion by estimating available group -segment size. - -An error will be given if: - - Specified values violate subtarget specifications; - - Specified values are not compatible with values provided through other - attributes. - - -amdgpu_num_sgpr ---------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -Clang supports the ``__attribute__((amdgpu_num_sgpr()))`` and -``__attribute__((amdgpu_num_vgpr()))`` attributes for the AMDGPU -target. These attributes may be attached to a kernel function definition and are -an optimization hint. - -If these attributes are specified, then the AMDGPU target backend will attempt -to limit the number of SGPRs and/or VGPRs used to the specified value(s). The -number of used SGPRs and/or VGPRs may further be rounded up to satisfy the -allocation requirements or constraints of the subtarget. Passing ``0`` as -``num_sgpr`` and/or ``num_vgpr`` implies the default behavior (no limits). - -These attributes can be used to test the AMDGPU target backend. It is -recommended that the ``amdgpu_waves_per_eu`` attribute be used to control -resources such as SGPRs and VGPRs since it is aware of the limits for different -subtargets. - -An error will be given if: - - Specified values violate subtarget specifications; - - Specified values are not compatible with values provided through other - attributes; - - The AMDGPU target backend is unable to create machine code that can meet the - request. - - -amdgpu_num_vgpr ---------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -Clang supports the ``__attribute__((amdgpu_num_sgpr()))`` and -``__attribute__((amdgpu_num_vgpr()))`` attributes for the AMDGPU -target. These attributes may be attached to a kernel function definition and are -an optimization hint. - -If these attributes are specified, then the AMDGPU target backend will attempt -to limit the number of SGPRs and/or VGPRs used to the specified value(s). The -number of used SGPRs and/or VGPRs may further be rounded up to satisfy the -allocation requirements or constraints of the subtarget. Passing ``0`` as -``num_sgpr`` and/or ``num_vgpr`` implies the default behavior (no limits). - -These attributes can be used to test the AMDGPU target backend. It is -recommended that the ``amdgpu_waves_per_eu`` attribute be used to control -resources such as SGPRs and VGPRs since it is aware of the limits for different -subtargets. - -An error will be given if: - - Specified values violate subtarget specifications; - - Specified values are not compatible with values provided through other - attributes; - - The AMDGPU target backend is unable to create machine code that can meet the - request. - - -amdgpu_waves_per_eu -------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -A compute unit (CU) is responsible for executing the wavefronts of a work-group. -It is composed of one or more execution units (EU), which are responsible for -executing the wavefronts. An EU can have enough resources to maintain the state -of more than one executing wavefront. This allows an EU to hide latency by -switching between wavefronts in a similar way to symmetric multithreading on a -CPU. In order to allow the state for multiple wavefronts to fit on an EU, the -resources used by a single wavefront have to be limited. For example, the number -of SGPRs and VGPRs. Limiting such resources can allow greater latency hiding, -but can result in having to spill some register state to memory. - -Clang supports the ``__attribute__((amdgpu_waves_per_eu([, ])))`` -attribute for the AMDGPU target. This attribute may be attached to a kernel -function definition and is an optimization hint. - -```` parameter specifies the requested minimum number of waves per EU, and -*optional* ```` parameter specifies the requested maximum number of waves -per EU (must be greater than ```` if specified). If ```` is omitted, -then there is no restriction on the maximum number of waves per EU other than -the one dictated by the hardware for which the kernel is compiled. Passing -``0, 0`` as ``, `` implies the default behavior (no limits). - -If specified, this attribute allows an advanced developer to tune the number of -wavefronts that are capable of fitting within the resources of an EU. The AMDGPU -target backend can use this information to limit resources, such as number of -SGPRs, number of VGPRs, size of available group and private memory segments, in -such a way that guarantees that at least ```` wavefronts and at most -```` wavefronts are able to fit within the resources of an EU. Requesting -more wavefronts can hide memory latency but limits available registers which -can result in spilling. Requesting fewer wavefronts can help reduce cache -thrashing, but can reduce memory latency hiding. - -This attribute controls the machine code generated by the AMDGPU target backend -to ensure it is capable of meeting the requested values. However, when the -kernel is executed, there may be other reasons that prevent meeting the request, -for example, there may be wavefronts from other kernels executing on the EU. - -An error will be given if: - - Specified values violate subtarget specifications; - - Specified values are not compatible with values provided through other - attributes; - - The AMDGPU target backend is unable to create machine code that can meet the - request. - - -Calling Conventions -=================== -Clang supports several different calling conventions, depending on the target -platform and architecture. The calling convention used for a function determines -how parameters are passed, how results are returned to the caller, and other -low-level details of calling a function. - -fastcall (gnu::fastcall, __fastcall, _fastcall) ------------------------------------------------ -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","X", "" - -On 32-bit x86 targets, this attribute changes the calling convention of a -function to use ECX and EDX as register parameters and clear parameters off of -the stack on return. This convention does not support variadic calls or -unprototyped functions in C, and has no effect on x86_64 targets. This calling -convention is supported primarily for compatibility with existing code. Users -seeking register parameters should use the ``regparm`` attribute, which does -not require callee-cleanup. See the documentation for `__fastcall`_ on MSDN. - -.. _`__fastcall`: http://msdn.microsoft.com/en-us/library/6xa169sk.aspx - - -ms_abi (gnu::ms_abi) --------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -On non-Windows x86_64 targets, this attribute changes the calling convention of -a function to match the default convention used on Windows x86_64. This -attribute has no effect on Windows targets or non-x86_64 targets. - - -pcs (gnu::pcs) --------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -On ARM targets, this attribute can be used to select calling conventions -similar to ``stdcall`` on x86. Valid parameter values are "aapcs" and -"aapcs-vfp". - - -preserve_all ------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -On X86-64 and AArch64 targets, this attribute changes the calling convention of -a function. The ``preserve_all`` calling convention attempts to make the code -in the caller even less intrusive than the ``preserve_most`` calling convention. -This calling convention also behaves identical to the ``C`` calling convention -on how arguments and return values are passed, but it uses a different set of -caller/callee-saved registers. This removes the burden of saving and -recovering a large register set before and after the call in the caller. If -the arguments are passed in callee-saved registers, then they will be -preserved by the callee across the call. This doesn't apply for values -returned in callee-saved registers. - -- On X86-64 the callee preserves all general purpose registers, except for - R11. R11 can be used as a scratch register. Furthermore it also preserves - all floating-point registers (XMMs/YMMs). - -The idea behind this convention is to support calls to runtime functions -that don't need to call out to any other functions. - -This calling convention, like the ``preserve_most`` calling convention, will be -used by a future version of the Objective-C runtime and should be considered -experimental at this time. - - -preserve_most -------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -On X86-64 and AArch64 targets, this attribute changes the calling convention of -a function. The ``preserve_most`` calling convention attempts to make the code -in the caller as unintrusive as possible. This convention behaves identically -to the ``C`` calling convention on how arguments and return values are passed, -but it uses a different set of caller/callee-saved registers. This alleviates -the burden of saving and recovering a large register set before and after the -call in the caller. If the arguments are passed in callee-saved registers, -then they will be preserved by the callee across the call. This doesn't -apply for values returned in callee-saved registers. - -- On X86-64 the callee preserves all general purpose registers, except for - R11. R11 can be used as a scratch register. Floating-point registers - (XMMs/YMMs) are not preserved and need to be saved by the caller. - -The idea behind this convention is to support calls to runtime functions -that have a hot path and a cold path. The hot path is usually a small piece -of code that doesn't use many registers. The cold path might need to call out to -another function and therefore only needs to preserve the caller-saved -registers, which haven't already been saved by the caller. The -`preserve_most` calling convention is very similar to the ``cold`` calling -convention in terms of caller/callee-saved registers, but they are used for -different types of function calls. ``coldcc`` is for function calls that are -rarely executed, whereas `preserve_most` function calls are intended to be -on the hot path and definitely executed a lot. Furthermore ``preserve_most`` -doesn't prevent the inliner from inlining the function call. - -This calling convention will be used by a future version of the Objective-C -runtime and should therefore still be considered experimental at this time. -Although this convention was created to optimize certain runtime calls to -the Objective-C runtime, it is not limited to this runtime and might be used -by other runtimes in the future too. The current implementation only -supports X86-64 and AArch64, but the intention is to support more architectures -in the future. - - -regcall (gnu::regcall, __regcall) ---------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","X", "" - -On x86 targets, this attribute changes the calling convention to -`__regcall`_ convention. This convention aims to pass as many arguments -as possible in registers. It also tries to utilize registers for the -return value whenever it is possible. - -.. _`__regcall`: https://software.intel.com/en-us/node/693069 - - -regparm (gnu::regparm) ----------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -On 32-bit x86 targets, the regparm attribute causes the compiler to pass -the first three integer parameters in EAX, EDX, and ECX instead of on the -stack. This attribute has no effect on variadic functions, and all parameters -are passed via the stack as normal. - - -stdcall (gnu::stdcall, __stdcall, _stdcall) -------------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","X", "" - -On 32-bit x86 targets, this attribute changes the calling convention of a -function to clear parameters off of the stack on return. This convention does -not support variadic calls or unprototyped functions in C, and has no effect on -x86_64 targets. This calling convention is used widely by the Windows API and -COM applications. See the documentation for `__stdcall`_ on MSDN. - -.. _`__stdcall`: http://msdn.microsoft.com/en-us/library/zxk0tw93.aspx - - -thiscall (gnu::thiscall, __thiscall, _thiscall) ------------------------------------------------ -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","X", "" - -On 32-bit x86 targets, this attribute changes the calling convention of a -function to use ECX for the first parameter (typically the implicit ``this`` -parameter of C++ methods) and clear parameters off of the stack on return. This -convention does not support variadic calls or unprototyped functions in C, and -has no effect on x86_64 targets. See the documentation for `__thiscall`_ on -MSDN. - -.. _`__thiscall`: http://msdn.microsoft.com/en-us/library/ek8tkfbw.aspx - - -vectorcall (__vectorcall, _vectorcall) --------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","X", "" - -On 32-bit x86 *and* x86_64 targets, this attribute changes the calling -convention of a function to pass vector parameters in SSE registers. - -On 32-bit x86 targets, this calling convention is similar to ``__fastcall``. -The first two integer parameters are passed in ECX and EDX. Subsequent integer -parameters are passed in memory, and callee clears the stack. On x86_64 -targets, the callee does *not* clear the stack, and integer parameters are -passed in RCX, RDX, R8, and R9 as is done for the default Windows x64 calling -convention. - -On both 32-bit x86 and x86_64 targets, vector and floating point arguments are -passed in XMM0-XMM5. Homogeneous vector aggregates of up to four elements are -passed in sequential SSE registers if enough are available. If AVX is enabled, -256 bit vectors are passed in YMM0-YMM5. Any vector or aggregate type that -cannot be passed in registers for any reason is passed by reference, which -allows the caller to align the parameter memory. - -See the documentation for `__vectorcall`_ on MSDN for more details. - -.. _`__vectorcall`: http://msdn.microsoft.com/en-us/library/dn375768.aspx - - -Consumed Annotation Checking -============================ -Clang supports additional attributes for checking basic resource management -properties, specifically for unique objects that have a single owning reference. -The following attributes are currently supported, although **the implementation -for these annotations is currently in development and are subject to change.** - -callable_when -------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -Use ``__attribute__((callable_when(...)))`` to indicate what states a method -may be called in. Valid states are unconsumed, consumed, or unknown. Each -argument to this attribute must be a quoted string. E.g.: - -``__attribute__((callable_when("unconsumed", "unknown")))`` - - -consumable ----------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -Each ``class`` that uses any of the typestate annotations must first be marked -using the ``consumable`` attribute. Failure to do so will result in a warning. - -This attribute accepts a single parameter that must be one of the following: -``unknown``, ``consumed``, or ``unconsumed``. - - -param_typestate ---------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -This attribute specifies expectations about function parameters. Calls to an -function with annotated parameters will issue a warning if the corresponding -argument isn't in the expected state. The attribute is also used to set the -initial state of the parameter when analyzing the function's body. - - -return_typestate ----------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -The ``return_typestate`` attribute can be applied to functions or parameters. -When applied to a function the attribute specifies the state of the returned -value. The function's body is checked to ensure that it always returns a value -in the specified state. On the caller side, values returned by the annotated -function are initialized to the given state. - -When applied to a function parameter it modifies the state of an argument after -a call to the function returns. The function's body is checked to ensure that -the parameter is in the expected state before returning. - - -set_typestate -------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -Annotate methods that transition an object into a new state with -``__attribute__((set_typestate(new_state)))``. The new state must be -unconsumed, consumed, or unknown. - - -test_typestate --------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","","","", "" - -Use ``__attribute__((test_typestate(tested_state)))`` to indicate that a method -returns true if the object is in the specified state.. - - -OpenCL Address Spaces -===================== -The address space qualifier may be used to specify the region of memory that is -used to allocate the object. OpenCL supports the following address spaces: -__generic(generic), __global(global), __local(local), __private(private), -__constant(constant). - - .. code-block:: c - - __constant int c = ...; - - __generic int* foo(global int* g) { - __local int* l; - private int p; - ... - return l; - } - -More details can be found in the OpenCL C language Spec v2.0, Section 6.5. - -constant (__constant) ---------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","X", "" - -The constant address space attribute signals that an object is located in -a constant (non-modifiable) memory region. It is available to all work items. -Any type can be annotated with the constant address space attribute. Objects -with the constant address space qualifier can be declared in any scope and must -have an initializer. - - -generic (__generic) -------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","X", "" - -The generic address space attribute is only available with OpenCL v2.0 and later. -It can be used with pointer types. Variables in global and local scope and -function parameters in non-kernel functions can have the generic address space -type attribute. It is intended to be a placeholder for any other address space -except for '__constant' in OpenCL code which can be used with multiple address -spaces. - - -global (__global) ------------------ -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","X", "" - -The global address space attribute specifies that an object is allocated in -global memory, which is accessible by all work items. The content stored in this -memory area persists between kernel executions. Pointer types to the global -address space are allowed as function parameters or local variables. Starting -with OpenCL v2.0, the global address space can be used with global (program -scope) variables and static local variable as well. - - -local (__local) ---------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","X", "" - -The local address space specifies that an object is allocated in the local (work -group) memory area, which is accessible to all work items in the same work -group. The content stored in this memory region is not accessible after -the kernel execution ends. In a kernel function scope, any variable can be in -the local address space. In other scopes, only pointer types to the local address -space are allowed. Local address space variables cannot have an initializer. - - -private (__private) -------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","X", "" - -The private address space specifies that an object is allocated in the private -(work item) memory. Other work items cannot access the same memory area and its -content is destroyed after work item execution ends. Local variables can be -declared in the private address space. Function arguments are always in the -private address space. Kernel function arguments of a pointer or an array type -cannot point to the private address space. - - -Nullability Attributes -====================== -Whether a particular pointer may be "null" is an important concern when working with pointers in the C family of languages. The various nullability attributes indicate whether a particular pointer can be null or not, which makes APIs more expressive and can help static analysis tools identify bugs involving null pointers. Clang supports several kinds of nullability attributes: the ``nonnull`` and ``returns_nonnull`` attributes indicate which function or method parameters and result types can never be null, while nullability type qualifiers indicate which pointer types can be null (``_Nullable``) or cannot be null (``_Nonnull``). - -The nullability (type) qualifiers express whether a value of a given pointer type can be null (the ``_Nullable`` qualifier), doesn't have a defined meaning for null (the ``_Nonnull`` qualifier), or for which the purpose of null is unclear (the ``_Null_unspecified`` qualifier). Because nullability qualifiers are expressed within the type system, they are more general than the ``nonnull`` and ``returns_nonnull`` attributes, allowing one to express (for example) a nullable pointer to an array of nonnull pointers. Nullability qualifiers are written to the right of the pointer to which they apply. For example: - - .. code-block:: c - - // No meaningful result when 'ptr' is null (here, it happens to be undefined behavior). - int fetch(int * _Nonnull ptr) { return *ptr; } - - // 'ptr' may be null. - int fetch_or_zero(int * _Nullable ptr) { - return ptr ? *ptr : 0; - } - - // A nullable pointer to non-null pointers to const characters. - const char *join_strings(const char * _Nonnull * _Nullable strings, unsigned n); - -In Objective-C, there is an alternate spelling for the nullability qualifiers that can be used in Objective-C methods and properties using context-sensitive, non-underscored keywords. For example: - - .. code-block:: objective-c - - @interface NSView : NSResponder - - (nullable NSView *)ancestorSharedWithView:(nonnull NSView *)aView; - @property (assign, nullable) NSView *superview; - @property (readonly, nonnull) NSArray *subviews; - @end - -nonnull (gnu::nonnull) ----------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``nonnull`` attribute indicates that some function parameters must not be null, and can be used in several different ways. It's original usage (`from GCC `_) is as a function (or Objective-C method) attribute that specifies which parameters of the function are nonnull in a comma-separated list. For example: - - .. code-block:: c - - extern void * my_memcpy (void *dest, const void *src, size_t len) - __attribute__((nonnull (1, 2))); - -Here, the ``nonnull`` attribute indicates that parameters 1 and 2 -cannot have a null value. Omitting the parenthesized list of parameter indices means that all parameters of pointer type cannot be null: - - .. code-block:: c - - extern void * my_memcpy (void *dest, const void *src, size_t len) - __attribute__((nonnull)); - -Clang also allows the ``nonnull`` attribute to be placed directly on a function (or Objective-C method) parameter, eliminating the need to specify the parameter index ahead of type. For example: - - .. code-block:: c - - extern void * my_memcpy (void *dest __attribute__((nonnull)), - const void *src __attribute__((nonnull)), size_t len); - -Note that the ``nonnull`` attribute indicates that passing null to a non-null parameter is undefined behavior, which the optimizer may take advantage of to, e.g., remove null checks. The ``_Nonnull`` type qualifier indicates that a pointer cannot be null in a more general manner (because it is part of the type system) and does not imply undefined behavior, making it more widely applicable. - - -returns_nonnull (gnu::returns_nonnull) --------------------------------------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "X","X","","", "" - -The ``returns_nonnull`` attribute indicates that a particular function (or Objective-C method) always returns a non-null pointer. For example, a particular system ``malloc`` might be defined to terminate a process when memory is not available rather than returning a null pointer: - - .. code-block:: c - - extern void * malloc (size_t size) __attribute__((returns_nonnull)); - -The ``returns_nonnull`` attribute implies that returning a null pointer is undefined behavior, which the optimizer may take advantage of. The ``_Nonnull`` type qualifier indicates that a pointer cannot be null in a more general manner (because it is part of the type system) and does not imply undefined behavior, making it more widely applicable - - -_Nonnull --------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","X", "" - -The ``_Nonnull`` nullability qualifier indicates that null is not a meaningful value for a value of the ``_Nonnull`` pointer type. For example, given a declaration such as: - - .. code-block:: c - - int fetch(int * _Nonnull ptr); - -a caller of ``fetch`` should not provide a null value, and the compiler will produce a warning if it sees a literal null value passed to ``fetch``. Note that, unlike the declaration attribute ``nonnull``, the presence of ``_Nonnull`` does not imply that passing null is undefined behavior: ``fetch`` is free to consider null undefined behavior or (perhaps for backward-compatibility reasons) defensively handle null. - - -_Null_unspecified ------------------ -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","X", "" - -The ``_Null_unspecified`` nullability qualifier indicates that neither the ``_Nonnull`` nor ``_Nullable`` qualifiers make sense for a particular pointer type. It is used primarily to indicate that the role of null with specific pointers in a nullability-annotated header is unclear, e.g., due to overly-complex implementations or historical factors with a long-lived API. - - -_Nullable ---------- -.. csv-table:: Supported Syntaxes - :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma" - - "","","","X", "" - -The ``_Nullable`` nullability qualifier indicates that a value of the ``_Nullable`` pointer type can be null. For example, given: - - .. code-block:: c - - int fetch_or_zero(int * _Nullable ptr); - -a caller of ``fetch_or_zero`` can provide null. - - +=================== \ No newline at end of file diff --git a/docs/ClangCommandLineReference.rst b/docs/ClangCommandLineReference.rst new file mode 100644 index 000000000000..add168829e1b --- /dev/null +++ b/docs/ClangCommandLineReference.rst @@ -0,0 +1,2591 @@ +.. + ------------------------------------------------------------------- + NOTE: This file is automatically generated by running clang-tblgen + -gen-opt-docs. Do not edit this file by hand!! + ------------------------------------------------------------------- + +===================================== +Clang command line argument reference +===================================== +.. contents:: + :local: + +Introduction +============ + +This page lists the command line arguments currently supported by the +GCC-compatible ``clang`` and ``clang++`` drivers. + + +.. program:: clang +.. option:: -B, --prefix , --prefix= + +Add to search path for binaries and object files used implicitly + +.. option:: -F + +Add directory to framework include search path + +.. option:: -ObjC + +Treat source input files as Objective-C inputs + +.. program:: clang1 +.. option:: -ObjC++ +.. program:: clang + +Treat source input files as Objective-C++ inputs + +.. option:: -Qunused-arguments + +Don't emit warning for unused driver arguments + +.. option:: -Wa,,... + +Pass the comma separated arguments in to the assembler + +.. option:: -Wlarge-by-value-copy= + +.. option:: -Xarch\_ + +.. option:: -Xcuda-fatbinary + +Pass to fatbinary invocation + +.. option:: -Xcuda-ptxas + +Pass to the ptxas assembler + +.. option:: -Z + +.. option:: -a, --profile-blocks + +.. option:: -all\_load + +.. option:: -allowable\_client + +.. option:: --analyze + +Run the static analyzer + +.. option:: --analyze-auto + +.. option:: --analyzer-no-default-checks + +.. option:: --analyzer-output + +Static analyzer report output format (html\|plist\|plist-multi-file\|plist-html\|text). + +.. option:: -ansi, --ansi + +.. option:: -arch + +.. program:: clang1 +.. option:: -arch\_errors\_fatal +.. program:: clang + +.. program:: clang2 +.. option:: -arch\_only +.. program:: clang + +.. option:: -arcmt-migrate-emit-errors + +Emit ARC errors even if the migrator can fix them + +.. option:: -arcmt-migrate-report-output + +Output path for the plist report + +.. option:: -bind\_at\_load + +.. option:: -bundle + +.. program:: clang1 +.. option:: -bundle\_loader +.. program:: clang + +.. option:: -client\_name + +.. option:: -compatibility\_version + +.. option:: --constant-cfstrings + +.. option:: -coverage, --coverage + +.. option:: --cuda-compile-host-device + +Compile CUDA code for both host and device (default). Has no effect on non-CUDA compilations. + +.. option:: --cuda-device-only + +Compile CUDA code for device only + +.. option:: --cuda-gpu-arch=, --no-cuda-gpu-arch= + +CUDA GPU architecture (e.g. sm\_35). May be specified more than once. + +.. option:: --cuda-host-only + +Compile CUDA code for host only. Has no effect on non-CUDA compilations. + +.. option:: --cuda-noopt-device-debug, --no-cuda-noopt-device-debug + +Enable device-side debug info generation. Disables ptxas optimizations. + +.. option:: -current\_version + +.. option:: -dead\_strip + +.. option:: -dependency-dot + +Filename to write DOT-formatted header dependencies to + +.. option:: -dependency-file + +Filename (or -) to write dependency output to + +.. option:: -dumpmachine + +.. option:: -dumpversion + +.. option:: --dyld-prefix=, --dyld-prefix + +.. option:: -dylib\_file + +.. option:: -dylinker + +.. program:: clang1 +.. option:: -dylinker\_install\_name +.. program:: clang + +.. option:: -dynamic + +.. option:: -dynamiclib + +.. option:: -emit-ast + +Emit Clang AST files for source inputs + +.. option:: -exported\_symbols\_list + +.. option:: -faligned-new= + +.. option:: -fcuda-approx-transcendentals, -fno-cuda-approx-transcendentals + +Use approximate transcendental functions + +.. option:: -fcuda-flush-denormals-to-zero, -fno-cuda-flush-denormals-to-zero + +Flush denormal floating point values to zero in CUDA device mode. + +.. option:: -fheinous-gnu-extensions + +.. option:: -flat\_namespace + +.. option:: -fopenmp-targets=,... + +Specify comma-separated list of triples OpenMP offloading targets to be supported + +.. option:: -force\_cpusubtype\_ALL + +.. program:: clang1 +.. option:: -force\_flat\_namespace +.. program:: clang + +.. program:: clang2 +.. option:: -force\_load +.. program:: clang + +.. option:: -framework + +.. option:: -frtlib-add-rpath, -fno-rtlib-add-rpath + +Add -rpath with architecture-specific resource directory to the linker flags + +.. option:: --gcc-toolchain=, -gcc-toolchain + +Use the gcc toolchain at the given directory + +.. option:: -gcodeview + +Generate CodeView debug information + +.. option:: -headerpad\_max\_install\_names + +.. option:: -help, --help + +Display available options + +.. option:: --help-hidden + +.. option:: -image\_base + +.. option:: -index-header-map + +Make the next included directory (-I or -F) an indexer header map + +.. option:: -init + +.. option:: -install\_name + +.. option:: -keep\_private\_externs + +.. option:: -lazy\_framework + +.. program:: clang1 +.. option:: -lazy\_library +.. program:: clang + +.. option:: -mbig-endian, -EB + +.. option:: --migrate + +Run the migrator + +.. option:: -mios-simulator-version-min=, -miphonesimulator-version-min= + +.. option:: -mlinker-version= + +.. option:: -mlittle-endian, -EL + +.. option:: -mllvm + +Additional arguments to forward to LLVM's option processing + +.. option:: -module-dependency-dir + +Directory to dump module dependencies to + +.. option:: -mtvos-simulator-version-min=, -mappletvsimulator-version-min= + +.. option:: -multi\_module + +.. option:: -multiply\_defined + +.. program:: clang1 +.. option:: -multiply\_defined\_unused +.. program:: clang + +.. option:: -mwatchos-simulator-version-min=, -mwatchsimulator-version-min= + +.. option:: --no-cuda-version-check + +Don't error out if the detected version of the CUDA install is too low for the requested CUDA gpu architecture. + +.. option:: -no-integrated-cpp, --no-integrated-cpp + +.. option:: -no\_dead\_strip\_inits\_and\_terms + +.. option:: -nobuiltininc + +Disable builtin #include directories + +.. option:: -nocudainc + +.. option:: -nocudalib + +.. option:: -nodefaultlibs + +.. option:: -nofixprebinding + +.. option:: -nolibc + +.. option:: -nomultidefs + +.. option:: -nopie + +.. option:: -noprebind + +.. option:: -noseglinkedit + +.. option:: -nostartfiles + +.. option:: -nostdinc, --no-standard-includes + +.. program:: clang1 +.. option:: -nostdinc++ +.. program:: clang + +Disable standard #include directories for the C++ standard library + +.. option:: -nostdlib, --no-standard-libraries + +.. option:: -nostdlibinc + +.. option:: -o, --output , --output= + +Write output to + +.. option:: -objcmt-atomic-property + +Make migration to 'atomic' properties + +.. option:: -objcmt-migrate-all + +Enable migration to modern ObjC + +.. option:: -objcmt-migrate-annotation + +Enable migration to property and method annotations + +.. option:: -objcmt-migrate-designated-init + +Enable migration to infer NS\_DESIGNATED\_INITIALIZER for initializer methods + +.. option:: -objcmt-migrate-instancetype + +Enable migration to infer instancetype for method result type + +.. option:: -objcmt-migrate-literals + +Enable migration to modern ObjC literals + +.. option:: -objcmt-migrate-ns-macros + +Enable migration to NS\_ENUM/NS\_OPTIONS macros + +.. option:: -objcmt-migrate-property + +Enable migration to modern ObjC property + +.. option:: -objcmt-migrate-property-dot-syntax + +Enable migration of setter/getter messages to property-dot syntax + +.. option:: -objcmt-migrate-protocol-conformance + +Enable migration to add protocol conformance on classes + +.. option:: -objcmt-migrate-readonly-property + +Enable migration to modern ObjC readonly property + +.. option:: -objcmt-migrate-readwrite-property + +Enable migration to modern ObjC readwrite property + +.. option:: -objcmt-migrate-subscripting + +Enable migration to modern ObjC subscripting + +.. option:: -objcmt-ns-nonatomic-iosonly + +Enable migration to use NS\_NONATOMIC\_IOSONLY macro for setting property's 'atomic' attribute + +.. option:: -objcmt-returns-innerpointer-property + +Enable migration to annotate property with NS\_RETURNS\_INNER\_POINTER + +.. option:: -objcmt-whitelist-dir-path=, -objcmt-white-list-dir-path= + +Only modify files with a filename contained in the provided directory path + +.. option:: -object + +.. option:: -p, --profile + +.. option:: -pagezero\_size + +.. option:: -pg + +Enable mcount instrumentation + +.. option:: -pie + +.. option:: -pipe, --pipe + +Use pipes between commands, when possible + +.. option:: -prebind + +.. program:: clang1 +.. option:: -prebind\_all\_twolevel\_modules +.. program:: clang + +.. option:: -preload + +.. option:: --print-diagnostic-categories + +.. option:: -print-file-name=, --print-file-name=, --print-file-name + +Print the full library path of + +.. option:: -print-ivar-layout + +Enable Objective-C Ivar layout bitmap print trace + +.. option:: -print-libgcc-file-name, --print-libgcc-file-name + +Print the library path for the currently used compiler runtime library ("libgcc.a" or "libclang\_rt.builtins.\*.a") + +.. option:: -print-multi-directory, --print-multi-directory + +.. option:: -print-multi-lib, --print-multi-lib + +.. option:: -print-prog-name=, --print-prog-name=, --print-prog-name + +Print the full program path of + +.. option:: -print-resource-dir, --print-resource-dir + +Print the resource directory pathname + +.. option:: -print-search-dirs, --print-search-dirs + +Print the paths used for finding libraries and programs + +.. option:: -private\_bundle + +.. option:: -pthread, -no-pthread + +Support POSIX threads in generated code + +.. option:: -pthreads + +.. option:: -rdynamic + +.. option:: -read\_only\_relocs + +.. option:: -relocatable-pch, --relocatable-pch + +Whether to build a relocatable precompiled header + +.. option:: -remap + +.. option:: -rewrite-legacy-objc + +Rewrite Legacy Objective-C source to C++ + +.. option:: -rtlib=, --rtlib=, --rtlib + +Compiler runtime library to use + +.. option:: -save-stats=, --save-stats=, -save-stats (equivalent to -save-stats=cwd), --save-stats (equivalent to -save-stats=cwd) + +Save llvm statistics. + +.. option:: -save-temps=, --save-temps=, -save-temps (equivalent to -save-temps=cwd), --save-temps (equivalent to -save-temps=cwd) + +Save intermediate compilation results. + +.. option:: -sectalign + +.. option:: -sectcreate + +.. option:: -sectobjectsymbols + +.. option:: -sectorder + +.. option:: -seg1addr + +.. option:: -seg\_addr\_table + +.. program:: clang1 +.. option:: -seg\_addr\_table\_filename +.. program:: clang + +.. option:: -segaddr + +.. option:: -segcreate + +.. option:: -seglinkedit + +.. option:: -segprot + +.. option:: -segs\_read\_ + +.. program:: clang1 +.. option:: -segs\_read\_only\_addr +.. program:: clang + +.. program:: clang2 +.. option:: -segs\_read\_write\_addr +.. program:: clang + +.. option:: -serialize-diagnostics , --serialize-diagnostics + +Serialize compiler diagnostics to a file + +.. option:: -shared, --shared + +.. option:: -shared-libasan + +.. option:: -shared-libgcc + +.. option:: -single\_module + +.. option:: -specs=, --specs= + +.. option:: -static, --static + +.. option:: -static-libgcc + +.. option:: -static-libstdc++ + +.. option:: -std-default= + +.. option:: -stdlib=, --stdlib=, --stdlib + +C++ standard library to use + +.. option:: -sub\_library + +.. program:: clang1 +.. option:: -sub\_umbrella +.. program:: clang + +.. option:: --sysroot=, --sysroot + +.. option:: --target-help + +.. option:: --target=, -target + +Generate code for the given target + +.. option:: -time + +Time individual commands + +.. option:: -traditional, --traditional + +.. option:: -traditional-cpp, --traditional-cpp + +Enable some traditional CPP emulation + +.. option:: -twolevel\_namespace + +.. program:: clang1 +.. option:: -twolevel\_namespace\_hints +.. program:: clang + +.. option:: -umbrella + +.. option:: -unexported\_symbols\_list + +.. option:: -v, --verbose + +Show commands to run and use verbose output + +.. option:: --verify-debug-info + +Verify the binary representation of debug output + +.. option:: --version + +.. option:: -w, --no-warnings + +Suppress all warnings + +.. option:: -weak-l + +.. option:: -weak\_framework + +.. program:: clang1 +.. option:: -weak\_library +.. program:: clang + +.. program:: clang2 +.. option:: -weak\_reference\_mismatches +.. program:: clang + +.. option:: -whatsloaded + +.. option:: -whyload + +.. option:: -working-directory, -working-directory= + +Resolve file paths relative to the specified directory + +.. option:: -x, --language , --language= + +Treat subsequent input files as having type + +.. option:: -y + +Actions +======= +The action to perform on the input. + +.. option:: -E, --preprocess + +Only run the preprocessor + +.. option:: -S, --assemble + +Only run preprocess and compilation steps + +.. option:: -c, --compile + +Only run preprocess, compile, and assemble steps + +.. option:: -emit-llvm + +Use the LLVM representation for assembler and object files + +.. option:: -fsyntax-only + +.. option:: -module-file-info + +Provide information about a particular module file + +.. option:: --precompile + +Only precompile the input + +.. option:: -rewrite-objc + +Rewrite Objective-C source to C++ + +.. option:: -verify-pch + +Load and verify that a pre-compiled header file is not stale + +Compilation flags +================= + +Flags controlling the behavior of Clang during compilation. These flags have +no effect during actions that do not perform compilation. + +.. option:: -Xassembler + +Pass to the assembler + +.. option:: -Xclang + +Pass to the clang compiler + +.. option:: -fcomment-block-commands=,... + +Treat each comma separated argument in as a documentation comment block command + +.. option:: -fdeclspec, -fno-declspec + +Allow \_\_declspec as a keyword + +.. option:: -fdepfile-entry= + +.. option:: -fdiagnostics-fixit-info, -fno-diagnostics-fixit-info + +.. option:: -fdiagnostics-format= + +.. option:: -fdiagnostics-parseable-fixits + +Print fix-its in machine parseable form + +.. option:: -fdiagnostics-print-source-range-info + +Print source range spans in numeric form + +.. option:: -fdiagnostics-show-category= + +.. option:: -fexperimental-new-pass-manager, -fno-experimental-new-pass-manager + +Enables an experimental new pass manager in LLVM. + +.. option:: -finline-functions, -fno-inline-functions + +Inline suitable functions + +.. option:: -finline-hint-functions + +Inline functions which are (explicitly or implicitly) marked inline + +.. option:: -fno-crash-diagnostics + +Disable auto-generation of preprocessed source files and a script for reproduction during a clang crash + +.. option:: -fno-sanitize-blacklist + +Don't use blacklist file for sanitizers + +.. option:: -fparse-all-comments + +.. option:: -fsanitize-address-field-padding= + +Level of field padding for AddressSanitizer + +.. option:: -fsanitize-address-use-after-scope, -fno-sanitize-address-use-after-scope + +Enable use-after-scope detection in AddressSanitizer + +.. option:: -fsanitize-blacklist= + +Path to blacklist file for sanitizers + +.. option:: -fsanitize-cfi-cross-dso, -fno-sanitize-cfi-cross-dso + +Enable control flow integrity (CFI) checks for cross-DSO calls. + +.. option:: -fsanitize-coverage=,..., -fno-sanitize-coverage=,... + +Specify the type of coverage instrumentation for Sanitizers + +.. option:: -fsanitize-link-c++-runtime + +.. option:: -fsanitize-memory-track-origins, -fno-sanitize-memory-track-origins + +Enable origins tracking in MemorySanitizer + +.. program:: clang1 +.. option:: -fsanitize-memory-track-origins= +.. program:: clang + +Enable origins tracking in MemorySanitizer + +.. option:: -fsanitize-memory-use-after-dtor + +Enable use-after-destroy detection in MemorySanitizer + +.. option:: -fsanitize-recover, -fno-sanitize-recover + +.. program:: clang1 +.. option:: -fsanitize-recover=,..., -fno-sanitize-recover=,... +.. program:: clang + +Enable recovery for specified sanitizers + +.. option:: -fsanitize-stats, -fno-sanitize-stats + +Enable sanitizer statistics gathering. + +.. option:: -fsanitize-thread-atomics, -fno-sanitize-thread-atomics + +Enable atomic operations instrumentation in ThreadSanitizer (default) + +.. option:: -fsanitize-thread-func-entry-exit, -fno-sanitize-thread-func-entry-exit + +Enable function entry/exit instrumentation in ThreadSanitizer (default) + +.. option:: -fsanitize-thread-memory-access, -fno-sanitize-thread-memory-access + +Enable memory access instrumentation in ThreadSanitizer (default) + +.. option:: -fsanitize-trap=,..., -fno-sanitize-trap=,... + +Enable trapping for specified sanitizers + +.. option:: -fsanitize-undefined-strip-path-components= + +Strip (or keep only, if negative) a given number of path components when emitting check metadata. + +.. option:: -fsanitize-undefined-trap-on-error, -fno-sanitize-undefined-trap-on-error + +.. option:: -fsanitize=,..., -fno-sanitize=,... + +Turn on runtime checks for various forms of undefined or suspicious behavior. See user manual for available checks + +.. option:: --param , --param= + +.. option:: -std=, --std=, --std + +Language standard to compile for + +Preprocessor flags +~~~~~~~~~~~~~~~~~~ + +Flags controlling the behavior of the Clang preprocessor. + +.. option:: -C, --comments + +Include comments in preprocessed output + +.. option:: -CC, --comments-in-macros + +Include comments from within macros in preprocessed output + +.. option:: -D=, --define-macro , --define-macro= + +Define to (or 1 if omitted) + +.. option:: -H, --trace-includes + +Show header includes and nesting depth + +.. option:: -P, --no-line-commands + +Disable linemarker output in -E mode + +.. option:: -U, --undefine-macro , --undefine-macro= + +Undefine macro + +.. option:: -Wp,,... + +Pass the comma separated arguments in to the preprocessor + +.. option:: -Xpreprocessor + +Pass to the preprocessor + +Include path management +----------------------- + +Flags controlling how ``#include``\s are resolved to files. + +.. option:: -I, --include-directory , --include-directory= + +Add directory to include search path + +.. option:: -I-, --include-barrier + +Restrict all prior -I flags to double-quoted inclusion and remove current directory from include path + +.. option:: --cuda-path= + +CUDA installation path + +.. option:: -cxx-isystem + +Add directory to the C++ SYSTEM include search path + +.. option:: -fbuild-session-file= + +Use the last modification time of as the build session timestamp + +.. option:: -fbuild-session-timestamp=