3 <title>Clang Language Extensions
</title>
4 <link type=
"text/css" rel=
"stylesheet" href=
"../menu.css" />
5 <link type=
"text/css" rel=
"stylesheet" href=
"../content.css" />
6 <style type=
"text/css">
14 <!--#include virtual="../menu.html.incl"-->
18 <h1>Clang Language Extensions
</h1>
21 <li><a href=
"#intro">Introduction
</a></li>
22 <li><a href=
"#feature_check">Feature Checking Macros
</a></li>
23 <li><a href=
"#has_include">Include File Checking Macros
</a></li>
24 <li><a href=
"#builtinmacros">Builtin Macros
</a></li>
25 <li><a href=
"#vectors">Vectors and Extended Vectors
</a></li>
26 <li><a href=
"#deprecated">Messages on
<tt>deprecated
</tt> and
<tt>unavailable
</tt> attributes
</a></li>
27 <li><a href=
"#attributes-on-enumerators">Attributes on enumerators
</a></li>
28 <li><a href=
"#checking_language_features">Checks for Standard Language Features
</a></li>
30 <li><a href=
"#cxx_exceptions">C++ exceptions
</a></li>
31 <li><a href=
"#cxx_rtti">C++ RTTI
</a></li>
33 <li><a href=
"#checking_upcoming_features">Checks for Upcoming Standard Language Features
</a></li>
35 <li><a href=
"#cxx_attributes">C++
0x attributes
</a></li>
36 <li><a href=
"#cxx_decltype">C++
0x
<tt>decltype()
</tt></a></li>
37 <li><a href=
"#cxx_default_function_template_args">C++
0x default template arguments in function templates
</a></li>
38 <li><a href=
"#cxx_deleted_functions">C++
0x deleted functions
</a></li>
39 <li><a href=
"#cxx_lambdas">C++
0x lambdas
</a></li>
40 <li><a href=
"#cxx_nullptr">C++
0x nullptr
</a></li>
41 <li><a href=
"#cxx_rvalue_references">C++
0x rvalue references
</a></li>
42 <li><a href=
"#cxx_reference_qualified_functions">C++
0x reference-qualified functions
</a></li>
43 <li><a href=
"#cxx_static_assert">C++
0x
<tt>static_assert()
</tt></a></li>
44 <li><a href=
"#cxx_auto_type">C++
0x type inference
</a></li>
45 <li><a href=
"#cxx_variadic_templates">C++
0x variadic templates
</a></li>
46 <li><a href=
"#cxx_inline_namespaces">C++
0x inline namespaces
</a></li>
47 <li><a href=
"#cxx_strong_enums">C++
0x strongly-typed enumerations
</a></li>
48 <li><a href=
"#cxx_trailing_return">C++
0x trailing return type
</a></li>
50 <li><a href=
"#checking_type_traits">Checks for Type Traits
</a></li>
51 <li><a href=
"#blocks">Blocks
</a></li>
52 <li><a href=
"#overloading-in-c">Function Overloading in C
</a></li>
53 <li><a href=
"#builtins">Builtin Functions
</a>
55 <li><a href=
"#__builtin_shufflevector">__builtin_shufflevector
</a></li>
56 <li><a href=
"#__builtin_unreachable">__builtin_unreachable
</a></li>
59 <li><a href=
"#targetspecific">Target-Specific Extensions
</a>
61 <li><a href=
"#x86-specific">X86/X86-
64 Language Extensions
</a></li>
64 <li><a href=
"#analyzerspecific">Static Analysis-Specific Extensions
</a>
66 <li><a href=
"#analyzerattributes">Analyzer Attributes
</a></li>
71 <!-- ======================================================================= -->
72 <h2 id=
"intro">Introduction
</h2>
73 <!-- ======================================================================= -->
75 <p>This document describes the language extensions provided by Clang. In
76 addition to the language extensions listed here, Clang aims to support a broad
77 range of GCC extensions. Please see the
<a
78 href=
"http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html">GCC manual
</a> for
79 more information on these extensions.
</p>
81 <!-- ======================================================================= -->
82 <h2 id=
"feature_check">Feature Checking Macros
</h2>
83 <!-- ======================================================================= -->
85 <p>Language extensions can be very useful, but only if you know you can depend
86 on them. In order to allow fine-grain features checks, we support two builtin
87 function-like macros. This allows you to directly test for a feature in your
88 code without having to resort to something like autoconf or fragile
"compiler
91 <!-- ======================================================================= -->
92 <h3 id=
"__has_builtin">__has_builtin
</h3>
93 <!-- ======================================================================= -->
95 <p>This function-like macro takes a single identifier argument that is the name
96 of a builtin function. It evaluates to
1 if the builtin is supported or
0 if
97 not. It can be used like this:
</p>
101 #ifndef __has_builtin // Optional of course.
102 #define __has_builtin(x)
0 // Compatibility with non-clang compilers.
106 #if __has_builtin(__builtin_trap)
116 <!-- ======================================================================= -->
117 <h3 id=
"__has_feature">__has_feature
</h3>
118 <!-- ======================================================================= -->
120 <p>This function-like macro takes a single identifier argument that is the name
121 of a feature. It evaluates to
1 if the feature is supported or
0 if not. It
122 can be used like this:
</p>
126 #ifndef __has_feature // Optional of course.
127 #define __has_feature(x)
0 // Compatibility with non-clang compilers.
131 #if __has_feature(attribute_overloadable) || \
132 __has_feature(blocks)
139 <p>The feature tag is described along with the language feature below.
</p>
141 <!-- ======================================================================= -->
142 <h3 id=
"__has_attribute">__has_attribute
</h3>
143 <!-- ======================================================================= -->
145 <p>This function-like macro takes a single identifier argument that is the name
146 of an attribute. It evaluates to
1 if the attribute is supported or
0 if not. It
147 can be used like this:
</p>
151 #ifndef __has_attribute // Optional of course.
152 #define __has_attribute(x)
0 // Compatibility with non-clang compilers.
156 #if __has_attribute(always_inline)
157 #define ALWAYS_INLINE __attribute__((always_inline))
159 #define ALWAYS_INLINE
165 <!-- ======================================================================= -->
166 <h2 id=
"has_include">Include File Checking Macros
</h2>
167 <!-- ======================================================================= -->
169 <p>Not all developments systems have the same include files.
170 The
<a href=
"#__has_include">__has_include
</a> and
171 <a href=
"#__has_include_next">__has_include_next
</a> macros allow you to
172 check for the existence of an include file before doing
173 a possibly failing #include directive.
</p>
175 <!-- ======================================================================= -->
176 <h3 id=
"__has_include">__has_include
</h3>
177 <!-- ======================================================================= -->
179 <p>This function-like macro takes a single file name string argument that
180 is the name of an include file. It evaluates to
1 if the file can
181 be found using the include paths, or
0 otherwise:
</p>
185 // Note the two possible file name string formats.
186 #if __has_include(
"myinclude.h") && __has_include(
<stdint.h
>)
187 # include
"myinclude.h"
190 // To avoid problem with non-clang compilers not having this macro.
191 #if defined(__has_include) && __has_include(
"myinclude.h")
192 # include
"myinclude.h"
197 <p>To test for this feature, use #if defined(__has_include).
</p>
199 <!-- ======================================================================= -->
200 <h3 id=
"__has_include_next">__has_include_next
</h3>
201 <!-- ======================================================================= -->
203 <p>This function-like macro takes a single file name string argument that
204 is the name of an include file. It is like __has_include except that it
205 looks for the second instance of the given file found in the include
206 paths. It evaluates to
1 if the second instance of the file can
207 be found using the include paths, or
0 otherwise:
</p>
211 // Note the two possible file name string formats.
212 #if __has_include_next(
"myinclude.h") && __has_include_next(
<stdint.h
>)
213 # include_next
"myinclude.h"
216 // To avoid problem with non-clang compilers not having this macro.
217 #if defined(__has_include_next) && __has_include_next(
"myinclude.h")
218 # include_next
"myinclude.h"
223 <p>Note that __has_include_next, like the GNU extension
224 #include_next directive, is intended for use in headers only,
225 and will issue a warning if used in the top-level compilation
226 file. A warning will also be issued if an absolute path
227 is used in the file argument.
</p>
229 <!-- ======================================================================= -->
230 <h2 id=
"builtinmacros">Builtin Macros
</h2>
231 <!-- ======================================================================= -->
234 <dt><code>__BASE_FILE__
</code></dt>
235 <dd>Defined to a string that contains the name of the main input
236 file passed to Clang.
</dd>
238 <dt><code>__COUNTER__
</code></dt>
239 <dd>Defined to an integer value that starts at zero and is
240 incremented each time the
<code>__COUNTER__
</code> macro is
243 <dt><code>__INCLUDE_LEVEL__
</code></dt>
244 <dd>Defined to an integral value that is the include depth of the
245 file currently being translated. For the main file, this value is
248 <dt><code>__TIMESTAMP__
</code></dt>
249 <dd>Defined to the date and time of the last modification of the
250 current source file.
</dd>
252 <dt><code>__clang__
</code></dt>
253 <dd>Defined when compiling with Clang
</dd>
255 <dt><code>__clang_major__
</code></dt>
256 <dd>Defined to the major version number of Clang (e.g., the
2 in
259 <dt><code>__clang_minor__
</code></dt>
260 <dd>Defined to the minor version number of Clang (e.g., the
0 in
263 <dt><code>__clang_patchlevel__
</code></dt>
264 <dd>Defined to the patch level of Clang (e.g., the
1 in
2.0.1).
</dd>
266 <dt><code>__clang_version__
</code></dt>
267 <dd>Defined to a string that captures the Clang version, including
268 the Subversion tag or revision number, e.g.,
"1.5 (trunk
272 <!-- ======================================================================= -->
273 <h2 id=
"vectors">Vectors and Extended Vectors
</h2>
274 <!-- ======================================================================= -->
276 <p>Supports the GCC vector extensions, plus some stuff like V[
1].
</p>
278 <p>Also supports
<tt>ext_vector
</tt>, which additionally support for V.xyzw
279 syntax and other tidbits as seen in OpenCL. An example is:
</p>
283 typedef float float4
<b>__attribute__((ext_vector_type(
4)))
</b>;
284 typedef float float2
<b>__attribute__((ext_vector_type(
2)))
</b>;
286 float4 foo(float2 a, float2 b) {
295 <p>Query for this feature with __has_feature(attribute_ext_vector_type).
</p>
297 <p>See also
<a href=
"#__builtin_shufflevector">__builtin_shufflevector
</a>.
</p>
299 <!-- ======================================================================= -->
300 <h2 id=
"deprecated">Messages on
<tt>deprecated
</tt> and
<tt>unavailable
</tt> Attributes
</h2>
301 <!-- ======================================================================= -->
303 <p>An optional string message can be added to the
<tt>deprecated
</tt>
304 and
<tt>unavailable
</tt> attributes. For example:
</p>
307 <pre>void explode(void) __attribute__((deprecated(
"extremely unsafe, use 'combust' instead!!!")));
</pre>
310 <p>If the deprecated or unavailable declaration is used, the message
311 will be incorporated into the appropriate diagnostic:
</p>
314 <pre>harmless.c:
4:
3: warning: 'explode' is deprecated: extremely unsafe, use 'combust' instead!!! [-Wdeprecated-declarations]
319 <p>Query for this feature
320 with
<tt>__has_feature(attribute_deprecated_with_message)
</tt>
321 and
<tt>__has_feature(attribute_unavailable_with_message)
</tt>.
</p>
323 <!-- ======================================================================= -->
324 <h2 id=
"attributes-on-enumerators">Attributes on Enumerators
</h2>
325 <!-- ======================================================================= -->
327 <p>Clang allows attributes to be written on individual enumerators.
328 This allows enumerators to be deprecated, made unavailable, etc. The
329 attribute must appear after the enumerator name and before any
330 initializer, like so:
</p>
333 <pre>enum OperationMode {
336 OM_Terrified __attribute__((deprecated)),
337 OM_AbortOnError __attribute__((deprecated)) =
4
341 <p>Attributes on the
<tt>enum
</tt> declaration do not apply to
342 individual enumerators.
</p>
344 <p>Query for this feature with
<tt>__has_feature(enumerator_attributes)
</tt>.
</p>
346 <!-- ======================================================================= -->
347 <h2 id=
"checking_language_features">Checks for Standard Language Features
</h2>
348 <!-- ======================================================================= -->
350 <p>The
<tt>__has_feature
</tt> macro can be used to query if certain standard language features are
351 enabled. Those features are listed here.
</p>
353 <h3 id=
"cxx_exceptions">C++ exceptions
</h3>
355 <p>Use
<tt>__has_feature(cxx_exceptions)
</tt> to determine if C++ exceptions have been enabled. For
356 example, compiling code with
<tt>-fexceptions
</tt> enables C++ exceptions.
</p>
358 <h3 id=
"cxx_rtti">C++ RTTI
</h3>
360 <p>Use
<tt>__has_feature(cxx_rtti)
</tt> to determine if C++ RTTI has been enabled. For example,
361 compiling code with
<tt>-fno-rtti
</tt> disables the use of RTTI.
</p>
363 <!-- ======================================================================= -->
364 <h2 id=
"checking_upcoming_features">Checks for Upcoming Standard Language Features
</h2>
365 <!-- ======================================================================= -->
367 <p>The
<tt>__has_feature
</tt> macro can be used to query if certain upcoming
368 standard language features are enabled. Those features are listed here.
</p>
370 <p>Currently, all features listed here are slated for inclusion in the upcoming
371 C++
0x standard. As a result, all the features that clang supports are enabled
372 with the
<tt>-std=c++
0x
</tt> option when compiling C++ code. Features that are
373 not yet implemented will be noted.
</p>
375 <h3 id=
"cxx_decltype">C++
0x
<tt>decltype()
</tt></h3>
377 <p>Use
<tt>__has_feature(cxx_decltype)
</tt> to determine if support for the
378 <tt>decltype()
</tt> specifier is enabled.
</p>
380 <h3 id=
"cxx_attributes">C++
0x attributes
</h3>
382 <p>Use
<tt>__has_feature(cxx_attributes)
</tt> to determine if support for
383 attribute parsing with C++
0x's square bracket notation is enabled.
</p>
385 <h3 id=
"cxx_default_function_template_args">C++
0x default template arguments in function templates
</h3>
387 <p>Use
<tt>__has_feature(cxx_default_function_template_args)
</tt> to determine if support for default template arguments in function templates is enabled.
</p>
389 <h3 id=
"cxx_deleted_functions">C++
0x deleted functions
</tt></h3>
391 <p>Use
<tt>__has_feature(cxx_deleted_functions)
</tt> to determine if support for
392 deleted function definitions (with
<tt>= delete
</tt>) is enabled.
</p>
394 <h3 id=
"cxx_lambdas">C++
0x lambdas
</h3>
396 <p>Use
<tt>__has_feature(cxx_lambdas)
</tt> to determine if support for
397 lambdas is enabled. clang does not currently implement this feature.
</p>
399 <h3 id=
"cxx_nullptr">C++
0x
<tt>nullptr
</tt></h3>
401 <p>Use
<tt>__has_feature(cxx_nullptr)
</tt> to determine if support for
402 <tt>nullptr
</tt> is enabled. clang does not yet fully implement this
405 <h3 id=
"cxx_reference_qualified_functions">C++
0x reference-qualified functions
</h3>
406 <p>Use
<tt>__has_feature(cxx_reference_qualified_functions)
</tt> to determine if support for reference-qualified functions (e.g., member functions with
<code>&</code> or
<code>&&</code> applied to
<code>*this
</code>) is enabled.
</p>
408 <h3 id=
"cxx_rvalue_references">C++
0x rvalue references
</tt></h3>
410 <p>Use
<tt>__has_feature(cxx_rvalue_references)
</tt> to determine if support for
411 rvalue references is enabled.
</p>
413 <h3 id=
"cxx_static_assert">C++
0x
<tt>static_assert()
</tt></h3>
415 <p>Use
<tt>__has_feature(cxx_static_assert)
</tt> to determine if support for
416 compile-time assertions using
<tt>static_assert
</tt> is enabled.
</p>
418 <h3 id=
"cxx_auto_type">C++
0x type inference
</h3>
420 <p>Use
<tt>__has_feature(cxx_auto_type)
</tt> to determine C++
0x type inference
421 is supported using the
<tt>auto
</tt> specifier. If this is disabled,
422 <tt>auto
</tt> will instead be a storage class specifier, as in C or C++
98.
423 Clang does not currently implement this feature.
</p>
425 <h3 id=
"cxx_variadic_templates">C++
0x variadic templates
</h3>
427 <p>Use
<tt>__has_feature(cxx_variadic_templates)
</tt> to determine if support
428 for variadic templates is enabled.
</p>
430 <h3 id=
"cxx_inline_namespaces">C++
0x inline namespaces
</h3>
432 <p>Use
<tt>__has_feature(cxx_inline_namespaces)
</tt> to determine if support for
433 inline namespaces is enabled.
</p>
435 <h3 id=
"cxx_trailing_return">C++
0x trailing return type
</h3>
437 <p>Use
<tt>__has_feature(cxx_trailing_return)
</tt> to determine if support for
438 the alternate function declaration syntax with trailing return type is enabled.
</p>
440 <h3 id=
"cxx_strong_enums">C++
0x strongly typed enumerations
</h3>
442 <p>Use
<tt>__has_feature(cxx_strong_enums)
</tt> to determine if support for
443 strongly typed, scoped enumerations is enabled.
</p>
445 <!-- ======================================================================= -->
446 <h2 id=
"checking_type_traits">Checks for Type Traits
</h2>
447 <!-- ======================================================================= -->
449 <p>Clang supports the
<a hef=
"http://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html">GNU C++ type traits
</a> and a subset of the
<a href=
"http://msdn.microsoft.com/en-us/library/ms177194(v=VS.100).aspx">Microsoft Visual C++ Type traits
</a>. For each supported type trait
<code>__X
</code>,
<code>__has_feature(X)
</code> indicates the presence of the type trait. For example:
452 #if __has_feature(is_convertible_to)
453 template
<typename From, typename To
>
454 struct is_convertible_to {
455 static const bool value = __is_convertible_to(From, To);
458 // Emulate type trait
463 <p>The following type traits are supported by Clang:
</p>
465 <li><code>__has_nothrow_assign
</code> (GNU, Microsoft)
</li>
466 <li><code>__has_nothrow_copy
</code> (GNU, Microsoft)
</li>
467 <li><code>__has_nothrow_constructor
</code> (GNU, Microsoft)
</li>
468 <li><code>__has_trivial_assign
</code> (GNU, Microsoft)
</li>
469 <li><code>__has_trivial_copy
</code> (GNU, Microsoft)
</li>
470 <li><code>__has_trivial_constructor
</code> (GNU, Microsoft)
</li>
471 <li><code>__has_trivial_destructor
</code> (GNU, Microsoft)
</li>
472 <li><code>__has_virtual_destructor
</code> (GNU, Microsoft)
</li>
473 <li><code>__is_abstract
</code> (GNU, Microsoft)
</li>
474 <li><code>__is_base_of
</code> (GNU, Microsoft)
</li>
475 <li><code>__is_class
</code> (GNU, Microsoft)
</li>
476 <li><code>__is_convertible_to
</code> (Microsoft)
</li>
477 <li><code>__is_empty
</code> (GNU, Microsoft)
</li>
478 <li><code>__is_enum
</code> (GNU, Microsoft)
</li>
479 <li><code>__is_pod
</code> (GNU, Microsoft)
</li>
480 <li><code>__is_polymorphic
</code> (GNU, Microsoft)
</li>
481 <li><code>__is_union
</code> (GNU, Microsoft)
</li>
482 <li><code>__is_literal(type)
</code>: Determines whether the given type is a literal type
</li>
485 <!-- ======================================================================= -->
486 <h2 id=
"blocks">Blocks
</h2>
487 <!-- ======================================================================= -->
489 <p>The syntax and high level language feature description is in
<a
490 href=
"BlockLanguageSpec.txt">BlockLanguageSpec.txt
</a>. Implementation and ABI
491 details for the clang implementation are in
<a
492 href=
"Block-ABI-Apple.txt">Block-ABI-Apple.txt
</a>.
</p>
495 <p>Query for this feature with __has_feature(blocks).
</p>
497 <!-- ======================================================================= -->
498 <h2 id=
"overloading-in-c">Function Overloading in C
</h2>
499 <!-- ======================================================================= -->
501 <p>Clang provides support for C++ function overloading in C. Function
502 overloading in C is introduced using the
<tt>overloadable
</tt> attribute. For
503 example, one might provide several overloaded versions of a
<tt>tgsin
</tt>
504 function that invokes the appropriate standard function computing the sine of a
505 value with
<tt>float
</tt>,
<tt>double
</tt>, or
<tt>long double
</tt>
510 #include
<math.h
>
511 float
<b>__attribute__((overloadable))
</b> tgsin(float x) { return sinf(x); }
512 double
<b>__attribute__((overloadable))
</b> tgsin(double x) { return sin(x); }
513 long double
<b>__attribute__((overloadable))
</b> tgsin(long double x) { return sinl(x); }
517 <p>Given these declarations, one can call
<tt>tgsin
</tt> with a
518 <tt>float
</tt> value to receive a
<tt>float
</tt> result, with a
519 <tt>double
</tt> to receive a
<tt>double
</tt> result, etc. Function
520 overloading in C follows the rules of C++ function overloading to pick
521 the best overload given the call arguments, with a few C-specific
524 <li>Conversion from
<tt>float
</tt> or
<tt>double
</tt> to
<tt>long
525 double
</tt> is ranked as a floating-point promotion (per C99) rather
526 than as a floating-point conversion (as in C++).
</li>
528 <li>A conversion from a pointer of type
<tt>T*
</tt> to a pointer of type
529 <tt>U*
</tt> is considered a pointer conversion (with conversion
530 rank) if
<tt>T
</tt> and
<tt>U
</tt> are compatible types.
</li>
532 <li>A conversion from type
<tt>T
</tt> to a value of type
<tt>U
</tt>
533 is permitted if
<tt>T
</tt> and
<tt>U
</tt> are compatible types. This
534 conversion is given
"conversion" rank.
</li>
537 <p>The declaration of
<tt>overloadable
</tt> functions is restricted to
538 function declarations and definitions. Most importantly, if any
539 function with a given name is given the
<tt>overloadable
</tt>
540 attribute, then all function declarations and definitions with that
541 name (and in that scope) must have the
<tt>overloadable
</tt>
542 attribute. This rule even applies to redeclarations of functions whose original
543 declaration had the
<tt>overloadable
</tt> attribute, e.g.,
</p>
547 int f(int) __attribute__((overloadable));
548 float f(float);
<i>// error: declaration of
"f" must have the
"overloadable" attribute
</i>
550 int g(int) __attribute__((overloadable));
551 int g(int) { }
<i>// error: redeclaration of
"g" must also have the
"overloadable" attribute
</i>
555 <p>Functions marked
<tt>overloadable
</tt> must have
556 prototypes. Therefore, the following code is ill-formed:
</p>
560 int h() __attribute__((overloadable));
<i>// error: h does not have a prototype
</i>
564 <p>However,
<tt>overloadable
</tt> functions are allowed to use a
565 ellipsis even if there are no named parameters (as is permitted in C++). This feature is particularly useful when combined with the
<tt>unavailable
</tt> attribute:
</p>
569 void honeypot(...) __attribute__((overloadable, unavailable));
<i>// calling me is an error
</i>
573 <p>Functions declared with the
<tt>overloadable
</tt> attribute have
574 their names mangled according to the same rules as C++ function
575 names. For example, the three
<tt>tgsin
</tt> functions in our
576 motivating example get the mangled names
<tt>_Z5tgsinf
</tt>,
577 <tt>_Z5tgsind
</tt>, and
<tt>_Z5tgsine
</tt>, respectively. There are two
578 caveats to this use of name mangling:
</p>
582 <li>Future versions of Clang may change the name mangling of
583 functions overloaded in C, so you should not depend on an specific
584 mangling. To be completely safe, we strongly urge the use of
585 <tt>static inline
</tt> with
<tt>overloadable
</tt> functions.
</li>
587 <li>The
<tt>overloadable
</tt> attribute has almost no meaning when
588 used in C++, because names will already be mangled and functions are
589 already overloadable. However, when an
<tt>overloadable
</tt>
590 function occurs within an
<tt>extern
"C"</tt> linkage specification,
591 it's name
<i>will
</i> be mangled in the same way as it would in
595 <p>Query for this feature with __has_feature(attribute_overloadable).
</p>
598 <!-- ======================================================================= -->
599 <h2 id=
"builtins">Builtin Functions
</h2>
600 <!-- ======================================================================= -->
602 <p>Clang supports a number of builtin library functions with the same syntax as
603 GCC, including things like
<tt>__builtin_nan
</tt>,
604 <tt>__builtin_constant_p
</tt>,
<tt>__builtin_choose_expr
</tt>,
605 <tt>__builtin_types_compatible_p
</tt>,
<tt>__sync_fetch_and_add
</tt>, etc. In
606 addition to the GCC builtins, Clang supports a number of builtins that GCC does
607 not, which are listed here.
</p>
609 <p>Please note that Clang does not and will not support all of the GCC builtins
610 for vector operations. Instead of using builtins, you should use the functions
611 defined in target-specific header files like
<tt><xmmintrin.h
></tt>, which
612 define portable wrappers for these. Many of the Clang versions of these
613 functions are implemented directly in terms of
<a href=
"#vectors">extended
614 vector support
</a> instead of builtins, in order to reduce the number of
615 builtins that we need to implement.
</p>
617 <!-- ======================================================================= -->
618 <h3 id=
"__builtin_shufflevector">__builtin_shufflevector
</h3>
619 <!-- ======================================================================= -->
621 <p><tt>__builtin_shufflevector
</tt> is used to express generic vector
622 permutation/shuffle/swizzle operations. This builtin is also very important for
623 the implementation of various target-specific header files like
624 <tt><xmmintrin.h
></tt>.
627 <p><b>Syntax:
</b></p>
630 __builtin_shufflevector(vec1, vec2, index1, index2, ...)
633 <p><b>Examples:
</b></p>
636 // Identity operation - return
4-element vector V1.
637 __builtin_shufflevector(V1, V1,
0,
1,
2,
3)
639 //
"Splat" element
0 of V1 into a
4-element result.
640 __builtin_shufflevector(V1, V1,
0,
0,
0,
0)
642 // Reverse
4-element vector V1.
643 __builtin_shufflevector(V1, V1,
3,
2,
1,
0)
645 // Concatenate every other element of
4-element vectors V1 and V2.
646 __builtin_shufflevector(V1, V2,
0,
2,
4,
6)
648 // Concatenate every other element of
8-element vectors V1 and V2.
649 __builtin_shufflevector(V1, V2,
0,
2,
4,
6,
8,
10,
12,
14)
652 <p><b>Description:
</b></p>
654 <p>The first two arguments to __builtin_shufflevector are vectors that have the
655 same element type. The remaining arguments are a list of integers that specify
656 the elements indices of the first two vectors that should be extracted and
657 returned in a new vector. These element indices are numbered sequentially
658 starting with the first vector, continuing into the second vector. Thus, if
659 vec1 is a
4-element vector, index
5 would refer to the second element of vec2.
662 <p>The result of __builtin_shufflevector is a vector
663 with the same element type as vec1/vec2 but that has an element count equal to
664 the number of indices specified.
667 <p>Query for this feature with __has_builtin(__builtin_shufflevector).
</p>
669 <!-- ======================================================================= -->
670 <h3 id=
"__builtin_unreachable">__builtin_unreachable
</h3>
671 <!-- ======================================================================= -->
673 <p><tt>__builtin_unreachable
</tt> is used to indicate that a specific point in
674 the program cannot be reached, even if the compiler might otherwise think it
675 can. This is useful to improve optimization and eliminates certain warnings.
676 For example, without the
<tt>__builtin_unreachable
</tt> in the example below,
677 the compiler assumes that the inline asm can fall through and prints a
"function
678 declared 'noreturn' should not return" warning.
681 <p><b>Syntax:
</b></p>
684 __builtin_unreachable()
687 <p><b>Example of Use:
</b></p>
690 void myabort(void) __attribute__((noreturn));
693 __builtin_unreachable();
697 <p><b>Description:
</b></p>
699 <p>The __builtin_unreachable() builtin has completely undefined behavior. Since
700 it has undefined behavior, it is a statement that it is never reached and the
701 optimizer can take advantage of this to produce better code. This builtin takes
702 no arguments and produces a void result.
705 <p>Query for this feature with __has_builtin(__builtin_unreachable).
</p>
708 <!-- ======================================================================= -->
709 <h2 id=
"targetspecific">Target-Specific Extensions
</h2>
710 <!-- ======================================================================= -->
712 <p>Clang supports some language features conditionally on some targets.
</p>
714 <!-- ======================================================================= -->
715 <h3 id=
"x86-specific">X86/X86-
64 Language Extensions
</h3>
716 <!-- ======================================================================= -->
718 <p>The X86 backend has these language extensions:
</p>
720 <!-- ======================================================================= -->
721 <h4 id=
"x86-gs-segment">Memory references off the GS segment
</h4>
722 <!-- ======================================================================= -->
724 <p>Annotating a pointer with address space #
256 causes it to be code generated
725 relative to the X86 GS segment register, and address space #
257 causes it to be
726 relative to the X86 FS segment. Note that this is a very very low-level
727 feature that should only be used if you know what you're doing (for example in
730 <p>Here is an example:
</p>
733 #define GS_RELATIVE __attribute__((address_space(
256)))
734 int foo(int GS_RELATIVE *P) {
739 <p>Which compiles to (on X86-
32):
</p>
744 movl %gs:(%eax), %eax
748 <!-- ======================================================================= -->
749 <h2 id=
"analyzerspecific">Static Analysis-Specific Extensions
</h2>
750 <!-- ======================================================================= -->
752 <p>Clang supports additional attributes that are useful for documenting program
753 invariants and rules for static analysis tools. The extensions documented here
755 href=
"http://clang.llvm.org/StaticAnalysis.html">path-sensitive static analyzer
756 engine
</a> that is part of Clang's Analysis library.
</p>
758 <!-- ======================================================================= -->
759 <h3 id=
"analyzerattributes">Analyzer Attributes
</h3>
760 <!-- ======================================================================= -->
762 <h4 id=
"attr_analyzer_noreturn"><tt>analyzer_noreturn
</tt></h4>
764 <p>Clang's static analysis engine understands the standard
<tt>noreturn
</tt>
765 attribute. This attribute, which is typically affixed to a function prototype,
766 indicates that a call to a given function never returns. Function prototypes for
767 common functions like
<tt>exit
</tt> are typically annotated with this attribute,
768 as well as a variety of common assertion handlers. Users can educate the static
769 analyzer about their own custom assertion handles (thus cutting down on false
770 positives due to false paths) by marking their own
"panic
" functions
771 with this attribute.
</p>
773 <p>While useful,
<tt>noreturn
</tt> is not applicable in all cases. Sometimes
774 there are special functions that for all intents and purposes should be
775 considered panic functions (i.e., they are only called when an internal program
776 error occurs) but may actually return so that the program can fail gracefully.
777 The
<tt>analyzer_noreturn
</tt> attribute allows one to annotate such functions
778 as being interpreted as
"no return
" functions by the analyzer (thus
779 pruning bogus paths) but will not affect compilation (as in the case of
780 <tt>noreturn
</tt>).
</p>
782 <p><b>Usage
</b>: The
<tt>analyzer_noreturn
</tt> attribute can be placed in the
783 same places where the
<tt>noreturn
</tt> attribute can be placed. It is commonly
784 placed at the end of function prototypes:
</p>
787 void foo()
<b>__attribute__((analyzer_noreturn))
</b>;
790 <p>Query for this feature with __has_feature(attribute_analyzer_noreturn).
</p>
792 <h4 id=
"attr_retain_release">Objective-C retaining behavior attributes
</h4>
794 <p>In Objective-C, functions and methods are generally assumed to take
795 and return objects with +
0 retain counts, with some exceptions for
796 special methods like
<tt>+alloc
</tt> and
<tt>init
</tt>. However,
797 there are exceptions, and so Clang provides attributes to allow these
798 exceptions to be documented, which helps the analyzer find leaks (and
799 ignore non-leaks).
</p>
801 <p><b>Usage
</b>: The
<tt>ns_returns_retained
</tt>,
<tt>ns_returns_not_retained
</tt>,
802 <tt>ns_returns_autoreleased
</tt>,
<tt>cf_returns_retained
</tt>,
803 and
<tt>cf_returns_not_retained
</tt> attributes can be placed on
804 methods and functions that return Objective-C or CoreFoundation
805 objects. They are commonly placed at the end of a function prototype
806 or method declaration:
</p>
809 id foo()
<b>__attribute__((ns_returns_retained))
</b>;
811 - (NSString*) bar: (int) x
<b>__attribute__((ns_returns_retained))
</b>;
814 <p>The
<tt>*_returns_retained
</tt> attributes specify that the
815 returned object has a +
1 retain count.
816 The
<tt>*_returns_not_retained
</tt> attributes specify that the return
817 object has a +
0 retain count, even if the normal convention for its
818 selector would be +
1.
<tt>ns_returns_autoreleased
</tt> specifies that the
819 returned object is +
0, but is guaranteed to live at least as long as the
820 next flush of an autorelease pool.
</p>
822 <p><b>Usage
</b>: The
<tt>ns_consumed
</tt> and
<tt>cf_consumed
</tt>
823 attributes can be placed on an parameter declaration; they specify
824 that the argument is expected to have a +
1 retain count, which will be
825 balanced in some way by the function or method.
826 The
<tt>ns_consumes_self
</tt> attribute can only be placed on an
827 Objective-C method; it specifies that the method expects
828 its
<tt>self
</tt> parameter to have a +
1 retain count, which it will
829 balance in some way.
</p>
832 void
<b>foo(__attribute__((ns_consumed))
</b> NSString *string);
834 - (void) bar
<b>__attribute__((ns_consumes_self))
</b>;
835 - (void) baz: (id)
<b>__attribute__((ns_consumed))
</b> x;