-
Dmitri Gribenko authored
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172729 91177308-0d34-0410-b5e6-96231b3b80d8
Dmitri Gribenko authoredgit-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172729 91177308-0d34-0410-b5e6-96231b3b80d8
Clang Language Extensions
- Introduction
- Feature Checking Macros
- Include File Checking Macros
- Builtin Macros
- Vectors and Extended Vectors
- Messages on
deprecated
andunavailable
Attributes - Attributes on Enumerators
- 'User-Specified' System Frameworks
- Availability attribute
- Checks for Standard Language Features
- Checks for Type Traits
- Blocks
- Objective-C Features
- Function Overloading in C
- Initializer lists for complex numbers in C
- Builtin Functions
- Non-standard C++11 Attributes
- Target-Specific Extensions
- Extensions for Static Analysis
- Extensions for Dynamic Analysis
- Thread-Safety Annotation Checking
- Type Safety Checking
- Format String Checking
Introduction
This document describes the language extensions provided by Clang. In addition to the language extensions listed here, Clang aims to support a broad range of GCC extensions. Please see the GCC manual for more information on these extensions.
Feature Checking Macros
Language extensions can be very useful, but only if you know you can depend on them. In order to allow fine-grain features checks, we support three builtin function-like macros. This allows you to directly test for a feature in your code without having to resort to something like autoconf or fragile "compiler version checks".
__has_builtin
This function-like macro takes a single identifier argument that is the name of a builtin function. It evaluates to 1 if the builtin is supported or 0 if not. It can be used like this:
#ifndef __has_builtin // Optional of course.
#define __has_builtin(x) 0 // Compatibility with non-clang compilers.
#endif
...
#if __has_builtin(__builtin_trap)
__builtin_trap();
#else
abort();
#endif
...
__has_feature
and __has_extension
These function-like macros take a single identifier argument that is the name
of a feature. __has_feature
evaluates to 1 if the feature is both
supported by Clang and standardized in the current language standard or 0 if
not (but see :ref:`below <langext-has-feature-back-compat>`), while
__has_extension
evaluates to 1 if the feature is supported by Clang in the
current language (either as a language extension or a standard language
feature) or 0 if not. They can be used like this:
#ifndef __has_feature // Optional of course.
#define __has_feature(x) 0 // Compatibility with non-clang compilers.
#endif
#ifndef __has_extension
#define __has_extension __has_feature // Compatibility with pre-3.0 compilers.
#endif
...
#if __has_feature(cxx_rvalue_references)
// This code will only be compiled with the -std=c++11 and -std=gnu++11
// options, because rvalue references are only standardized in C++11.
#endif
#if __has_extension(cxx_rvalue_references)
// This code will be compiled with the -std=c++11, -std=gnu++11, -std=c++98
// and -std=gnu++98 options, because rvalue references are supported as a
// language extension in C++98.
#endif
For backwards compatibility reasons, __has_feature
can also be used to test
for support for non-standardized features, i.e. features not prefixed c_
,
cxx_
or objc_
.
Another use of __has_feature
is to check for compiler features not related
to the language standard, such as e.g. :doc:`AddressSanitizer
<AddressSanitizer>`.
If the -pedantic-errors
option is given, __has_extension
is equivalent
to __has_feature
.
The feature tag is described along with the language feature below.
The feature name or extension name can also be specified with a preceding and
following __
(double underscore) to avoid interference from a macro with
the same name. For instance, __cxx_rvalue_references__
can be used instead
of cxx_rvalue_references
.
__has_attribute
This function-like macro takes a single identifier argument that is the name of an attribute. It evaluates to 1 if the attribute is supported or 0 if not. It can be used like this:
#ifndef __has_attribute // Optional of course.
#define __has_attribute(x) 0 // Compatibility with non-clang compilers.
#endif
...
#if __has_attribute(always_inline)
#define ALWAYS_INLINE __attribute__((always_inline))
#else
#define ALWAYS_INLINE
#endif
...
The attribute name can also be specified with a preceding and following __
(double underscore) to avoid interference from a macro with the same name. For
instance, __always_inline__
can be used instead of always_inline
.
Include File Checking Macros
Not all developments systems have the same include files. The
:ref:`langext-__has_include` and :ref:`langext-__has_include_next` macros allow
you to check for the existence of an include file before doing a possibly
failing #include
directive. Include file checking macros must be used
as expressions in #if
or #elif
preprocessing directives.
__has_include
This function-like macro takes a single file name string argument that is the name of an include file. It evaluates to 1 if the file can be found using the include paths, or 0 otherwise:
// Note the two possible file name string formats.
#if __has_include("myinclude.h") && __has_include(<stdint.h>)
# include "myinclude.h"
#endif
// To avoid problem with non-clang compilers not having this macro.
#if defined(__has_include) && __has_include("myinclude.h")
# include "myinclude.h"
#endif
To test for this feature, use #if defined(__has_include)
.
__has_include_next
This function-like macro takes a single file name string argument that is the
name of an include file. It is like __has_include
except that it looks for
the second instance of the given file found in the include paths. It evaluates
to 1 if the second instance of the file can be found using the include paths,
or 0 otherwise:
// Note the two possible file name string formats.
#if __has_include_next("myinclude.h") && __has_include_next(<stdint.h>)
# include_next "myinclude.h"
#endif
// To avoid problem with non-clang compilers not having this macro.
#if defined(__has_include_next) && __has_include_next("myinclude.h")
# include_next "myinclude.h"
#endif
Note that __has_include_next
, like the GNU extension #include_next
directive, is intended for use in headers only, and will issue a warning if
used in the top-level compilation file. A warning will also be issued if an
absolute path is used in the file argument.
__has_warning
This function-like macro takes a string literal that represents a command line option for a warning and returns true if that is a valid warning option.
#if __has_warning("-Wformat")
...
#endif
Builtin Macros
__BASE_FILE__
- Defined to a string that contains the name of the main input file passed to Clang.
__COUNTER__
- Defined to an integer value that starts at zero and is incremented each time
the
__COUNTER__
macro is expanded. __INCLUDE_LEVEL__
- Defined to an integral value that is the include depth of the file currently being translated. For the main file, this value is zero.
__TIMESTAMP__
- Defined to the date and time of the last modification of the current source file.
__clang__
- Defined when compiling with Clang
__clang_major__
- Defined to the major marketing version number of Clang (e.g., the 2 in 2.0.1). Note that marketing version numbers should not be used to check for language features, as different vendors use different numbering schemes. Instead, use the :ref:`langext-feature_check`.
__clang_minor__
- Defined to the minor version number of Clang (e.g., the 0 in 2.0.1). Note that marketing version numbers should not be used to check for language features, as different vendors use different numbering schemes. Instead, use the :ref:`langext-feature_check`.
__clang_patchlevel__
- Defined to the marketing patch level of Clang (e.g., the 1 in 2.0.1).
__clang_version__
- Defined to a string that captures the Clang marketing version, including the
Subversion tag or revision number, e.g., "
1.5 (trunk 102332)
".
Vectors and Extended Vectors
Supports the GCC, OpenCL, AltiVec and NEON vector extensions.
OpenCL vector types are created using ext_vector_type
attribute. It
support for V.xyzw
syntax and other tidbits as seen in OpenCL. An example
is:
typedef float float4 __attribute__((ext_vector_type(4)));
typedef float float2 __attribute__((ext_vector_type(2)));
float4 foo(float2 a, float2 b) {
float4 c;
c.xz = a;
c.yw = b;
return c;
}
Query for this feature with __has_extension(attribute_ext_vector_type)
.
Giving -faltivec
option to clang enables support for AltiVec vector syntax
and functions. For example:
vector float foo(vector int a) {
vector int b;
b = vec_add(a, a) + a;
return (vector float)b;
}
NEON vector types are created using neon_vector_type
and
neon_polyvector_type
attributes. For example:
typedef __attribute__((neon_vector_type(8))) int8_t int8x8_t;
typedef __attribute__((neon_polyvector_type(16))) poly8_t poly8x16_t;
int8x8_t foo(int8x8_t a) {
int8x8_t v;
v = a;
return v;
}
Vector Literals
Vector literals can be used to create vectors from a set of scalars, or vectors. Either parentheses or braces form can be used. In the parentheses form the number of literal values specified must be one, i.e. referring to a scalar value, or must match the size of the vector type being created. If a single scalar literal value is specified, the scalar literal value will be replicated to all the components of the vector type. In the brackets form any number of literals can be specified. For example:
typedef int v4si __attribute__((__vector_size__(16)));
typedef float float4 __attribute__((ext_vector_type(4)));
typedef float float2 __attribute__((ext_vector_type(2)));
v4si vsi = (v4si){1, 2, 3, 4};
float4 vf = (float4)(1.0f, 2.0f, 3.0f, 4.0f);
vector int vi1 = (vector int)(1); // vi1 will be (1, 1, 1, 1).
vector int vi2 = (vector int){1}; // vi2 will be (1, 0, 0, 0).
vector int vi3 = (vector int)(1, 2); // error
vector int vi4 = (vector int){1, 2}; // vi4 will be (1, 2, 0, 0).
vector int vi5 = (vector int)(1, 2, 3, 4);
float4 vf = (float4)((float2)(1.0f, 2.0f), (float2)(3.0f, 4.0f));