| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 1 | <html> | 
|  | 2 | <head> | 
|  | 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"> | 
|  | 7 | td { | 
|  | 8 | vertical-align: top; | 
|  | 9 | } | 
|  | 10 | </style> | 
|  | 11 | </head> | 
|  | 12 | <body> | 
|  | 13 |  | 
|  | 14 | <!--#include virtual="../menu.html.incl"--> | 
|  | 15 |  | 
|  | 16 | <div id="content"> | 
|  | 17 |  | 
|  | 18 | <h1>Clang Language Extensions</h1> | 
|  | 19 |  | 
|  | 20 | <ul> | 
|  | 21 | <li><a href="#intro">Introduction</a></li> | 
| Chris Lattner | 148772a | 2009-06-13 07:13:28 +0000 | [diff] [blame] | 22 | <li><a href="#feature_check">Feature Checking Macros</a></li> | 
| John Thompson | 92bd8c7 | 2009-11-02 22:28:12 +0000 | [diff] [blame] | 23 | <li><a href="#has_include">Include File Checking Macros</a></li> | 
| Chris Lattner | 81edc9f | 2009-04-13 02:45:46 +0000 | [diff] [blame] | 24 | <li><a href="#builtinmacros">Builtin Macros</a></li> | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 25 | <li><a href="#vectors">Vectors and Extended Vectors</a></li> | 
| Ted Kremenek | 87774fd | 2009-12-03 02:04:01 +0000 | [diff] [blame] | 26 | <li><a href="#checking_language_features">Checks for Standard Language Features</a></li> | 
| Ted Kremenek | 22c3410 | 2009-12-03 02:05:57 +0000 | [diff] [blame] | 27 | <ul> | 
|  | 28 | <li><a href="#cxx_exceptions">C++ exceptions</a></li> | 
|  | 29 | <li><a href="#cxx_rtti">C++ RTTI</a></li> | 
|  | 30 | </ul> | 
| Sean Hunt | 4ef4c6b | 2010-01-13 08:31:49 +0000 | [diff] [blame] | 31 | <li><a href="#checking_upcoming_features">Checks for Upcoming Standard Language Features</a></li> | 
|  | 32 | <ul> | 
|  | 33 | <li><a href="#cxx_attributes">C++0x attributes</a></li> | 
|  | 34 | <li><a href="#cxx_decltype">C++0x <tt>decltype()</tt></a></li> | 
|  | 35 | <li><a href="#cxx_deleted_functions">C++0x deleted functions</a></li> | 
|  | 36 | <li><a href="#cxx_concepts">C++ TR concepts</a></li> | 
|  | 37 | <li><a href="#cxx_lambdas">C++0x lambdas</a></li> | 
|  | 38 | <li><a href="#cxx_nullptr">C++0x nullptr</a></li> | 
|  | 39 | <li><a href="#cxx_rvalue_references">C++0x rvalue references</a></li> | 
|  | 40 | <li><a href="#cxx_static_assert">C++0x <tt>static_assert()</tt></a></li> | 
|  | 41 | <li><a href="#cxx_auto_type">C++0x type inference</a></li> | 
|  | 42 | <li><a href="#cxx_variadic_templates">C++0x variadic templates</a></li> | 
|  | 43 | </ul> | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 44 | <li><a href="#blocks">Blocks</a></li> | 
| Douglas Gregor | cb54d43 | 2009-02-13 00:57:04 +0000 | [diff] [blame] | 45 | <li><a href="#overloading-in-c">Function Overloading in C</a></li> | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 46 | <li><a href="#builtins">Builtin Functions</a> | 
|  | 47 | <ul> | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 48 | <li><a href="#__builtin_shufflevector">__builtin_shufflevector</a></li> | 
| Chris Lattner | 21190d5 | 2009-09-21 03:09:59 +0000 | [diff] [blame] | 49 | <li><a href="#__builtin_unreachable">__builtin_unreachable</a></li> | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 50 | </ul> | 
|  | 51 | </li> | 
| Chris Lattner | 1177f91 | 2009-04-09 19:58:15 +0000 | [diff] [blame] | 52 | <li><a href="#targetspecific">Target-Specific Extensions</a> | 
|  | 53 | <ul> | 
|  | 54 | <li><a href="#x86-specific">X86/X86-64 Language Extensions</a></li> | 
|  | 55 | </ul> | 
|  | 56 | </li> | 
| Ted Kremenek | ed86931 | 2009-04-10 05:03:33 +0000 | [diff] [blame] | 57 | <li><a href="#analyzerspecific">Static Analysis-Specific Extensions</a> | 
|  | 58 | <ul> | 
|  | 59 | <li><a href="#analyzerattributes">Analyzer Attributes</a></li> | 
|  | 60 | </ul> | 
|  | 61 | </li> | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 62 | </ul> | 
|  | 63 |  | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 64 | <!-- ======================================================================= --> | 
|  | 65 | <h2 id="intro">Introduction</h2> | 
|  | 66 | <!-- ======================================================================= --> | 
|  | 67 |  | 
|  | 68 | <p>This document describes the language extensions provided by Clang.  In | 
| Chris Lattner | 148772a | 2009-06-13 07:13:28 +0000 | [diff] [blame] | 69 | addition to the language extensions listed here, Clang aims to support a broad | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 70 | range of GCC extensions.  Please see the <a | 
|  | 71 | href="http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html">GCC manual</a> for | 
|  | 72 | more information on these extensions.</p> | 
|  | 73 |  | 
|  | 74 | <!-- ======================================================================= --> | 
| Chris Lattner | 148772a | 2009-06-13 07:13:28 +0000 | [diff] [blame] | 75 | <h2 id="feature_check">Feature Checking Macros</h2> | 
|  | 76 | <!-- ======================================================================= --> | 
|  | 77 |  | 
|  | 78 | <p>Language extensions can be very useful, but only if you know you can depend | 
|  | 79 | on them.  In order to allow fine-grain features checks, we support two builtin | 
|  | 80 | function-like macros.  This allows you to directly test for a feature in your | 
|  | 81 | code without having to resort to something like autoconf or fragile "compiler | 
|  | 82 | version checks".</p> | 
|  | 83 |  | 
|  | 84 | <!-- ======================================================================= --> | 
|  | 85 | <h3 id="__has_builtin">__has_builtin</h3> | 
|  | 86 | <!-- ======================================================================= --> | 
|  | 87 |  | 
|  | 88 | <p>This function-like macro takes a single identifier argument that is the name | 
|  | 89 | of a builtin function.  It evaluates to 1 if the builtin is supported or 0 if | 
|  | 90 | not.  It can be used like this:</p> | 
|  | 91 |  | 
|  | 92 | <blockquote> | 
|  | 93 | <pre> | 
|  | 94 | #ifndef __has_builtin         // Optional of course. | 
|  | 95 | #define __has_builtin(x) 0  // Compatibility with non-clang compilers. | 
|  | 96 | #endif | 
|  | 97 |  | 
|  | 98 | ... | 
|  | 99 | #if __has_builtin(__builtin_trap) | 
|  | 100 | __builtin_trap(); | 
|  | 101 | #else | 
|  | 102 | abort(); | 
|  | 103 | #endif | 
|  | 104 | ... | 
|  | 105 | </pre> | 
|  | 106 | </blockquote> | 
|  | 107 |  | 
|  | 108 |  | 
|  | 109 | <!-- ======================================================================= --> | 
|  | 110 | <h3 id="__has_feature">__has_feature</h3> | 
|  | 111 | <!-- ======================================================================= --> | 
|  | 112 |  | 
|  | 113 | <p>This function-like macro takes a single identifier argument that is the name | 
|  | 114 | of a feature.  It evaluates to 1 if the feature is supported or 0 if not.  It | 
|  | 115 | can be used like this:</p> | 
|  | 116 |  | 
|  | 117 | <blockquote> | 
|  | 118 | <pre> | 
|  | 119 | #ifndef __has_feature         // Optional of course. | 
|  | 120 | #define __has_feature(x) 0  // Compatibility with non-clang compilers. | 
|  | 121 | #endif | 
|  | 122 |  | 
|  | 123 | ... | 
|  | 124 | #if __has_feature(attribute_overloadable) || \ | 
|  | 125 | __has_feature(blocks) | 
|  | 126 | ... | 
|  | 127 | #endif | 
|  | 128 | ... | 
|  | 129 | </pre> | 
|  | 130 | </blockquote> | 
|  | 131 |  | 
|  | 132 | <p>The feature tag is described along with the language feature below.</p> | 
|  | 133 |  | 
| John Thompson | 92bd8c7 | 2009-11-02 22:28:12 +0000 | [diff] [blame] | 134 | <!-- ======================================================================= --> | 
|  | 135 | <h2 id="has_include">Include File Checking Macros</h2> | 
|  | 136 | <!-- ======================================================================= --> | 
|  | 137 |  | 
|  | 138 | <p>Not all developments systems have the same include files. | 
|  | 139 | The <a href="#__has_include">__has_include</a> and | 
|  | 140 | <a href="#__has_include_next">__has_include_next</a> macros allow you to | 
|  | 141 | check for the existence of an include file before doing | 
|  | 142 | a possibly failing #include directive.</p> | 
|  | 143 |  | 
|  | 144 | <!-- ======================================================================= --> | 
|  | 145 | <h3 id="__has_include">__has_include</h3> | 
|  | 146 | <!-- ======================================================================= --> | 
|  | 147 |  | 
|  | 148 | <p>This function-like macro takes a single file name string argument that | 
|  | 149 | is the name of an include file.  It evaluates to 1 if the file can | 
|  | 150 | be found using the include paths, or 0 otherwise:</p> | 
|  | 151 |  | 
|  | 152 | <blockquote> | 
|  | 153 | <pre> | 
|  | 154 | // Note the two possible file name string formats. | 
|  | 155 | #if __has_include("myinclude.h") && __has_include(<stdint.h>) | 
|  | 156 | # include "myinclude.h" | 
|  | 157 | #endif | 
|  | 158 |  | 
|  | 159 | // To avoid problem with non-clang compilers not having this macro. | 
|  | 160 | #if defined(__has_include) && __has_include("myinclude.h") | 
|  | 161 | # include "myinclude.h" | 
|  | 162 | #endif | 
|  | 163 | </pre> | 
|  | 164 | </blockquote> | 
|  | 165 |  | 
|  | 166 | <p>To test for this feature, use #if defined(__has_include).</p> | 
|  | 167 |  | 
|  | 168 | <!-- ======================================================================= --> | 
|  | 169 | <h3 id="__has_include_next">__has_include_next</h3> | 
|  | 170 | <!-- ======================================================================= --> | 
|  | 171 |  | 
|  | 172 | <p>This function-like macro takes a single file name string argument that | 
|  | 173 | is the name of an include file.  It is like __has_include except that it | 
|  | 174 | looks for the second instance of the given file found in the include | 
|  | 175 | paths.  It evaluates to 1 if the second instance of the file can | 
|  | 176 | be found using the include paths, or 0 otherwise:</p> | 
|  | 177 |  | 
|  | 178 | <blockquote> | 
|  | 179 | <pre> | 
|  | 180 | // Note the two possible file name string formats. | 
|  | 181 | #if __has_include_next("myinclude.h") && __has_include_next(<stdint.h>) | 
|  | 182 | # include_next "myinclude.h" | 
|  | 183 | #endif | 
|  | 184 |  | 
|  | 185 | // To avoid problem with non-clang compilers not having this macro. | 
|  | 186 | #if defined(__has_include_next) && __has_include_next("myinclude.h") | 
|  | 187 | # include_next "myinclude.h" | 
|  | 188 | #endif | 
|  | 189 | </pre> | 
|  | 190 | </blockquote> | 
|  | 191 |  | 
|  | 192 | <p>Note that __has_include_next, like the GNU extension | 
|  | 193 | #include_next directive, is intended for use in headers only, | 
|  | 194 | and will issue a warning if used in the top-level compilation | 
|  | 195 | file.  A warning will also be issued if an absolute path | 
|  | 196 | is used in the file argument.</p> | 
| Chris Lattner | 148772a | 2009-06-13 07:13:28 +0000 | [diff] [blame] | 197 |  | 
|  | 198 | <!-- ======================================================================= --> | 
| Chris Lattner | 81edc9f | 2009-04-13 02:45:46 +0000 | [diff] [blame] | 199 | <h2 id="builtinmacros">Builtin Macros</h2> | 
|  | 200 | <!-- ======================================================================= --> | 
|  | 201 |  | 
|  | 202 | <p>__BASE_FILE__, __INCLUDE_LEVEL__, __TIMESTAMP__, __COUNTER__</p> | 
|  | 203 |  | 
|  | 204 | <!-- ======================================================================= --> | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 205 | <h2 id="vectors">Vectors and Extended Vectors</h2> | 
|  | 206 | <!-- ======================================================================= --> | 
|  | 207 |  | 
|  | 208 | <p>Supports the GCC vector extensions, plus some stuff like V[1].  ext_vector | 
|  | 209 | with V.xyzw syntax and other tidbits.  See also <a | 
|  | 210 | href="#__builtin_shufflevector">__builtin_shufflevector</a>.</p> | 
|  | 211 |  | 
| Chris Lattner | 148772a | 2009-06-13 07:13:28 +0000 | [diff] [blame] | 212 | <p>Query for this feature with __has_feature(attribute_ext_vector_type).</p> | 
|  | 213 |  | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 214 | <!-- ======================================================================= --> | 
| Ted Kremenek | 87774fd | 2009-12-03 02:04:01 +0000 | [diff] [blame] | 215 | <h2 id="checking_language_features">Checks for Standard Language Features</h2> | 
|  | 216 | <!-- ======================================================================= --> | 
|  | 217 |  | 
|  | 218 | <p>The <tt>__has_feature</tt> macro can be used to query if certain standard language features are | 
|  | 219 | enabled.  Those features are listed here.</p> | 
|  | 220 |  | 
| Ted Kremenek | 22c3410 | 2009-12-03 02:05:57 +0000 | [diff] [blame] | 221 | <h3 id="cxx_exceptions">C++ exceptions</h3> | 
| Ted Kremenek | 87774fd | 2009-12-03 02:04:01 +0000 | [diff] [blame] | 222 |  | 
| Ted Kremenek | 22c3410 | 2009-12-03 02:05:57 +0000 | [diff] [blame] | 223 | <p>Use <tt>__has_feature(cxx_exceptions)</tt> to determine if C++ exceptions have been enabled. For | 
|  | 224 | example, compiling code with <tt>-fexceptions</tt> enables C++ exceptions.</p> | 
| Ted Kremenek | 87774fd | 2009-12-03 02:04:01 +0000 | [diff] [blame] | 225 |  | 
| Ted Kremenek | 22c3410 | 2009-12-03 02:05:57 +0000 | [diff] [blame] | 226 | <h3 id="cxx_rtti">C++ RTTI</h3> | 
| Ted Kremenek | 87774fd | 2009-12-03 02:04:01 +0000 | [diff] [blame] | 227 |  | 
| Ted Kremenek | 0eb9560 | 2009-12-03 02:06:43 +0000 | [diff] [blame] | 228 | <p>Use <tt>__has_feature(cxx_rtti)</tt> to determine if C++ RTTI has been enabled. For example, | 
| Ted Kremenek | 22c3410 | 2009-12-03 02:05:57 +0000 | [diff] [blame] | 229 | compiling code with <tt>-fno-rtti</tt> disables the use of RTTI.</p> | 
| Ted Kremenek | 87774fd | 2009-12-03 02:04:01 +0000 | [diff] [blame] | 230 |  | 
|  | 231 | <!-- ======================================================================= --> | 
| Sean Hunt | 4ef4c6b | 2010-01-13 08:31:49 +0000 | [diff] [blame] | 232 | <h2 id="checking_upcoming_features">Checks for Upcoming Standard Language Features</h2> | 
|  | 233 | <!-- ======================================================================= --> | 
|  | 234 |  | 
|  | 235 | <p>The <tt>__has_feature</tt> macro can be used to query if certain upcoming | 
|  | 236 | standard language features are enabled.  Those features are listed here.</p> | 
|  | 237 |  | 
|  | 238 | <p>Currently, all features listed here are slated for inclusion in the upcoming | 
|  | 239 | C++0x standard. As a result, all the features that clang supports are enabled | 
|  | 240 | with the <tt>-std=c++0x</tt> option when compiling C++ code. Features that are | 
|  | 241 | not yet implemented will be noted.</p> | 
|  | 242 |  | 
|  | 243 | <h3 id="cxx_decltype">C++0x <tt>decltype()</tt></h3> | 
|  | 244 |  | 
|  | 245 | <p>Use <tt>__has_feature(cxx_decltype)</tt> to determine if support for the | 
|  | 246 | <tt>decltype()</tt> specifier is enabled.</p> | 
|  | 247 |  | 
|  | 248 | <h3 id="cxx_attributes">C++0x attributes</h3> | 
|  | 249 |  | 
|  | 250 | <p>Use <tt>__has_feature(cxx_attributes)</tt> to determine if support for | 
|  | 251 | attribute parsing with C++0x's square bracket notation is enabled. | 
|  | 252 |  | 
|  | 253 | <h3 id="cxx_deleted_functions">C++0x deleted functions</tt></h3> | 
|  | 254 |  | 
|  | 255 | <p>Use <tt>__has_feature(cxx_deleted_functions)</tt> to determine if support for | 
|  | 256 | deleted function definitions (with <tt>= delete</tt>) is enabled. | 
|  | 257 |  | 
|  | 258 | <h3 id="cxx_concepts">C++ TR <tt>concepts</tt></h3> | 
|  | 259 |  | 
|  | 260 | <p>Use <tt>__has_feature(cxx_lambdas)</tt> to determine if support for | 
|  | 261 | concepts is enabled. clang does not currently implement this feature. | 
|  | 262 |  | 
|  | 263 | <h3 id="cxx_lambdas">C++0x <tt>nullptr</tt></h3> | 
|  | 264 |  | 
|  | 265 | <p>Use <tt>__has_feature(cxx_lambdas)</tt> to determine if support for | 
|  | 266 | lambdas is enabled. clang does not currently implement this feature. | 
|  | 267 |  | 
|  | 268 | <h3 id="cxx_nullptr">C++0x <tt>nullptr</tt></h3> | 
|  | 269 |  | 
|  | 270 | <p>Use <tt>__has_feature(cxx_nullptr)</tt> to determine if support for | 
|  | 271 | <tt>nullptr</tt> is enabled. clang does not yet fully implement this feature. | 
|  | 272 |  | 
|  | 273 | <h3 id="cxx_rvalue_references">C++0x rvalue references</tt></h3> | 
|  | 274 |  | 
|  | 275 | <p>Use <tt>__has_feature(cxx_rvalue_references)</tt> to determine if support for | 
|  | 276 | rvalue references is enabled. clang does not yet fully implement this feature. | 
|  | 277 |  | 
|  | 278 | <h3 id="cxx_static_assert">C++0x <tt>static_assert()</tt></h3> | 
|  | 279 |  | 
|  | 280 | <p>Use <tt>__has_feature(cxx_static_assert)</tt> to determine if support for | 
|  | 281 | compile-time assertions using <tt>static_assert</tt> is enabled.</p> | 
|  | 282 |  | 
|  | 283 | <h3 id="cxx_auto_type">C++0x type inference</h3> | 
|  | 284 |  | 
|  | 285 | <p>Use <tt>__has_feature(cxx_auto_type)</tt> to determine C++0x type inference | 
|  | 286 | is supported using the <tt>auto</tt> specifier. If this is disabled, | 
|  | 287 | <tt>auto</tt> will instead be a storage class specifier, as in C or C++98.</p> | 
|  | 288 |  | 
|  | 289 | <h3 id="cxx_variadic_templates">C++0x variadic templates</tt></h3> | 
|  | 290 |  | 
|  | 291 | <p>Use <tt>__has_feature(cxx_variadic_templates)</tt> to determine if support | 
|  | 292 | for templates taking any number of arguments with the ellipsis notation is | 
|  | 293 | enabled. clang does not yet fully implement this feature.</p> | 
|  | 294 |  | 
|  | 295 | <!-- ======================================================================= --> | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 296 | <h2 id="blocks">Blocks</h2> | 
|  | 297 | <!-- ======================================================================= --> | 
|  | 298 |  | 
| Chris Lattner | a7dbdf5 | 2009-03-09 07:03:22 +0000 | [diff] [blame] | 299 | <p>The syntax and high level language feature description is in <a | 
|  | 300 | href="BlockLanguageSpec.txt">BlockLanguageSpec.txt</a>.  Implementation and ABI | 
|  | 301 | details for the clang implementation are in <a | 
|  | 302 | href="BlockImplementation.txt">BlockImplementation.txt</a>.</p> | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 303 |  | 
| Chris Lattner | 148772a | 2009-06-13 07:13:28 +0000 | [diff] [blame] | 304 |  | 
|  | 305 | <p>Query for this feature with __has_feature(blocks).</p> | 
|  | 306 |  | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 307 | <!-- ======================================================================= --> | 
| Douglas Gregor | cb54d43 | 2009-02-13 00:57:04 +0000 | [diff] [blame] | 308 | <h2 id="overloading-in-c">Function Overloading in C</h2> | 
|  | 309 | <!-- ======================================================================= --> | 
|  | 310 |  | 
| Chris Lattner | f161d41 | 2009-02-13 21:51:45 +0000 | [diff] [blame] | 311 | <p>Clang provides support for C++ function overloading in C. Function | 
|  | 312 | overloading in C is introduced using the <tt>overloadable</tt> attribute. For | 
|  | 313 | example, one might provide several overloaded versions of a <tt>tgsin</tt> | 
|  | 314 | function that invokes the appropriate standard function computing the sine of a | 
|  | 315 | value with <tt>float</tt>, <tt>double</tt>, or <tt>long double</tt> | 
|  | 316 | precision:</p> | 
| Douglas Gregor | cb54d43 | 2009-02-13 00:57:04 +0000 | [diff] [blame] | 317 |  | 
|  | 318 | <blockquote> | 
|  | 319 | <pre> | 
|  | 320 | #include <math.h> | 
|  | 321 | float <b>__attribute__((overloadable))</b> tgsin(float x) { return sinf(x); } | 
|  | 322 | double <b>__attribute__((overloadable))</b> tgsin(double x) { return sin(x); } | 
|  | 323 | long double <b>__attribute__((overloadable))</b> tgsin(long double x) { return sinl(x); } | 
|  | 324 | </pre> | 
|  | 325 | </blockquote> | 
|  | 326 |  | 
|  | 327 | <p>Given these declarations, one can call <tt>tgsin</tt> with a | 
|  | 328 | <tt>float</tt> value to receive a <tt>float</tt> result, with a | 
|  | 329 | <tt>double</tt> to receive a <tt>double</tt> result, etc. Function | 
|  | 330 | overloading in C follows the rules of C++ function overloading to pick | 
|  | 331 | the best overload given the call arguments, with a few C-specific | 
|  | 332 | semantics:</p> | 
|  | 333 | <ul> | 
|  | 334 | <li>Conversion from <tt>float</tt> or <tt>double</tt> to <tt>long | 
|  | 335 | double</tt> is ranked as a floating-point promotion (per C99) rather | 
|  | 336 | than as a floating-point conversion (as in C++).</li> | 
|  | 337 |  | 
|  | 338 | <li>A conversion from a pointer of type <tt>T*</tt> to a pointer of type | 
|  | 339 | <tt>U*</tt> is considered a pointer conversion (with conversion | 
|  | 340 | rank) if <tt>T</tt> and <tt>U</tt> are compatible types.</li> | 
|  | 341 |  | 
|  | 342 | <li>A conversion from type <tt>T</tt> to a value of type <tt>U</tt> | 
|  | 343 | is permitted if <tt>T</tt> and <tt>U</tt> are compatible types. This | 
|  | 344 | conversion is given "conversion" rank.</li> | 
|  | 345 | </ul> | 
|  | 346 |  | 
|  | 347 | <p>The declaration of <tt>overloadable</tt> functions is restricted to | 
|  | 348 | function declarations and definitions. Most importantly, if any | 
|  | 349 | function with a given name is given the <tt>overloadable</tt> | 
|  | 350 | attribute, then all function declarations and definitions with that | 
|  | 351 | name (and in that scope) must have the <tt>overloadable</tt> | 
| Chris Lattner | f161d41 | 2009-02-13 21:51:45 +0000 | [diff] [blame] | 352 | attribute. This rule even applies to redeclarations of functions whose original | 
|  | 353 | declaration had the <tt>overloadable</tt> attribute, e.g.,</p> | 
| Douglas Gregor | cb54d43 | 2009-02-13 00:57:04 +0000 | [diff] [blame] | 354 |  | 
|  | 355 | <blockquote> | 
|  | 356 | <pre> | 
|  | 357 | int f(int) __attribute__((overloadable)); | 
|  | 358 | float f(float); <i>// error: declaration of "f" must have the "overloadable" attribute</i> | 
|  | 359 |  | 
|  | 360 | int g(int) __attribute__((overloadable)); | 
|  | 361 | int g(int) { } <i>// error: redeclaration of "g" must also have the "overloadable" attribute</i> | 
|  | 362 | </pre> | 
|  | 363 | </blockquote> | 
|  | 364 |  | 
| Douglas Gregor | 965acbb | 2009-02-18 07:07:28 +0000 | [diff] [blame] | 365 | <p>Functions marked <tt>overloadable</tt> must have | 
|  | 366 | prototypes. Therefore, the following code is ill-formed:</p> | 
|  | 367 |  | 
|  | 368 | <blockquote> | 
|  | 369 | <pre> | 
|  | 370 | int h() __attribute__((overloadable)); <i>// error: h does not have a prototype</i> | 
|  | 371 | </pre> | 
|  | 372 | </blockquote> | 
|  | 373 |  | 
|  | 374 | <p>However, <tt>overloadable</tt> functions are allowed to use a | 
|  | 375 | 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> | 
|  | 376 |  | 
|  | 377 | <blockquote> | 
|  | 378 | <pre> | 
| Chris Lattner | 0224680 | 2009-02-18 22:27:46 +0000 | [diff] [blame] | 379 | void honeypot(...) __attribute__((overloadable, unavailable)); <i>// calling me is an error</i> | 
| Douglas Gregor | 965acbb | 2009-02-18 07:07:28 +0000 | [diff] [blame] | 380 | </pre> | 
|  | 381 | </blockquote> | 
|  | 382 |  | 
| Douglas Gregor | cb54d43 | 2009-02-13 00:57:04 +0000 | [diff] [blame] | 383 | <p>Functions declared with the <tt>overloadable</tt> attribute have | 
|  | 384 | their names mangled according to the same rules as C++ function | 
|  | 385 | names. For example, the three <tt>tgsin</tt> functions in our | 
|  | 386 | motivating example get the mangled names <tt>_Z5tgsinf</tt>, | 
|  | 387 | <tt>_Z5tgsind</tt>, and <tt>Z5tgsine</tt>, respectively. There are two | 
|  | 388 | caveats to this use of name mangling:</p> | 
|  | 389 |  | 
|  | 390 | <ul> | 
|  | 391 |  | 
|  | 392 | <li>Future versions of Clang may change the name mangling of | 
|  | 393 | functions overloaded in C, so you should not depend on an specific | 
|  | 394 | mangling. To be completely safe, we strongly urge the use of | 
|  | 395 | <tt>static inline</tt> with <tt>overloadable</tt> functions.</li> | 
|  | 396 |  | 
|  | 397 | <li>The <tt>overloadable</tt> attribute has almost no meaning when | 
|  | 398 | used in C++, because names will already be mangled and functions are | 
|  | 399 | already overloadable. However, when an <tt>overloadable</tt> | 
|  | 400 | function occurs within an <tt>extern "C"</tt> linkage specification, | 
|  | 401 | it's name <i>will</i> be mangled in the same way as it would in | 
|  | 402 | C.</li> | 
|  | 403 | </ul> | 
|  | 404 |  | 
| Chris Lattner | 148772a | 2009-06-13 07:13:28 +0000 | [diff] [blame] | 405 | <p>Query for this feature with __has_feature(attribute_overloadable).</p> | 
|  | 406 |  | 
|  | 407 |  | 
| Douglas Gregor | cb54d43 | 2009-02-13 00:57:04 +0000 | [diff] [blame] | 408 | <!-- ======================================================================= --> | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 409 | <h2 id="builtins">Builtin Functions</h2> | 
|  | 410 | <!-- ======================================================================= --> | 
|  | 411 |  | 
|  | 412 | <p>Clang supports a number of builtin library functions with the same syntax as | 
|  | 413 | GCC, including things like <tt>__builtin_nan</tt>, | 
|  | 414 | <tt>__builtin_constant_p</tt>, <tt>__builtin_choose_expr</tt>, | 
|  | 415 | <tt>__builtin_types_compatible_p</tt>, <tt>__sync_fetch_and_add</tt>, etc.  In | 
|  | 416 | addition to the GCC builtins, Clang supports a number of builtins that GCC does | 
|  | 417 | not, which are listed here.</p> | 
|  | 418 |  | 
|  | 419 | <p>Please note that Clang does not and will not support all of the GCC builtins | 
|  | 420 | for vector operations.  Instead of using builtins, you should use the functions | 
|  | 421 | defined in target-specific header files like <tt><xmmintrin.h></tt>, which | 
|  | 422 | define portable wrappers for these.  Many of the Clang versions of these | 
|  | 423 | functions are implemented directly in terms of <a href="#vectors">extended | 
|  | 424 | vector support</a> instead of builtins, in order to reduce the number of | 
|  | 425 | builtins that we need to implement.</p> | 
|  | 426 |  | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 427 | <!-- ======================================================================= --> | 
| Chris Lattner | 6f72da5 | 2009-02-13 20:00:20 +0000 | [diff] [blame] | 428 | <h3 id="__builtin_shufflevector">__builtin_shufflevector</h3> | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 429 | <!-- ======================================================================= --> | 
|  | 430 |  | 
| Chris Lattner | aad826b | 2009-09-16 18:56:12 +0000 | [diff] [blame] | 431 | <p><tt>__builtin_shufflevector</tt> is used to express generic vector | 
| Chris Lattner | 6f72da5 | 2009-02-13 20:00:20 +0000 | [diff] [blame] | 432 | permutation/shuffle/swizzle operations. This builtin is also very important for | 
|  | 433 | the implementation of various target-specific header files like | 
|  | 434 | <tt><xmmintrin.h></tt>. | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 435 | </p> | 
|  | 436 |  | 
|  | 437 | <p><b>Syntax:</b></p> | 
|  | 438 |  | 
|  | 439 | <pre> | 
| Chris Lattner | 6f72da5 | 2009-02-13 20:00:20 +0000 | [diff] [blame] | 440 | __builtin_shufflevector(vec1, vec2, index1, index2, ...) | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 441 | </pre> | 
|  | 442 |  | 
|  | 443 | <p><b>Examples:</b></p> | 
|  | 444 |  | 
|  | 445 | <pre> | 
| Chris Lattner | 6f72da5 | 2009-02-13 20:00:20 +0000 | [diff] [blame] | 446 | // Identity operation - return 4-element vector V1. | 
|  | 447 | __builtin_shufflevector(V1, V1, 0, 1, 2, 3) | 
|  | 448 |  | 
|  | 449 | // "Splat" element 0 of V1 into a 4-element result. | 
|  | 450 | __builtin_shufflevector(V1, V1, 0, 0, 0, 0) | 
|  | 451 |  | 
|  | 452 | // Reverse 4-element vector V1. | 
|  | 453 | __builtin_shufflevector(V1, V1, 3, 2, 1, 0) | 
|  | 454 |  | 
|  | 455 | // Concatenate every other element of 4-element vectors V1 and V2. | 
|  | 456 | __builtin_shufflevector(V1, V2, 0, 2, 4, 6) | 
|  | 457 |  | 
|  | 458 | // Concatenate every other element of 8-element vectors V1 and V2. | 
|  | 459 | __builtin_shufflevector(V1, V2, 0, 2, 4, 6, 8, 10, 12, 14) | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 460 | </pre> | 
|  | 461 |  | 
|  | 462 | <p><b>Description:</b></p> | 
|  | 463 |  | 
| Chris Lattner | 6f72da5 | 2009-02-13 20:00:20 +0000 | [diff] [blame] | 464 | <p>The first two arguments to __builtin_shufflevector are vectors that have the | 
|  | 465 | same element type.  The remaining arguments are a list of integers that specify | 
|  | 466 | the elements indices of the first two vectors that should be extracted and | 
|  | 467 | returned in a new vector.  These element indices are numbered sequentially | 
|  | 468 | starting with the first vector, continuing into the second vector.  Thus, if | 
|  | 469 | vec1 is a 4-element vector, index 5 would refer to the second element of vec2. | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 470 | </p> | 
|  | 471 |  | 
| Chris Lattner | 6f72da5 | 2009-02-13 20:00:20 +0000 | [diff] [blame] | 472 | <p>The result of __builtin_shufflevector is a vector | 
|  | 473 | with the same element type as vec1/vec2 but that has an element count equal to | 
|  | 474 | the number of indices specified. | 
|  | 475 | </p> | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 476 |  | 
| Chris Lattner | 21190d5 | 2009-09-21 03:09:59 +0000 | [diff] [blame] | 477 | <p>Query for this feature with __has_builtin(__builtin_shufflevector).</p> | 
|  | 478 |  | 
|  | 479 | <!-- ======================================================================= --> | 
|  | 480 | <h3 id="__builtin_unreachable">__builtin_unreachable</h3> | 
|  | 481 | <!-- ======================================================================= --> | 
|  | 482 |  | 
|  | 483 | <p><tt>__builtin_unreachable</tt> is used to indicate that a specific point in | 
|  | 484 | the program cannot be reached, even if the compiler might otherwise think it | 
|  | 485 | can.  This is useful to improve optimization and eliminates certain warnings. | 
|  | 486 | For example, without the <tt>__builtin_unreachable</tt> in the example below, | 
|  | 487 | the compiler assumes that the inline asm can fall through and prints a "function | 
|  | 488 | declared 'noreturn' should not return" warning. | 
|  | 489 | </p> | 
|  | 490 |  | 
|  | 491 | <p><b>Syntax:</b></p> | 
|  | 492 |  | 
|  | 493 | <pre> | 
|  | 494 | __builtin_unreachable() | 
|  | 495 | </pre> | 
|  | 496 |  | 
|  | 497 | <p><b>Example of Use:</b></p> | 
|  | 498 |  | 
|  | 499 | <pre> | 
|  | 500 | void myabort(void) __attribute__((noreturn)); | 
|  | 501 | void myabort(void) { | 
|  | 502 | asm("int3"); | 
|  | 503 | __builtin_unreachable(); | 
|  | 504 | } | 
|  | 505 | </pre> | 
|  | 506 |  | 
|  | 507 | <p><b>Description:</b></p> | 
|  | 508 |  | 
|  | 509 | <p>The __builtin_unreachable() builtin has completely undefined behavior.  Since | 
|  | 510 | it has undefined behavior, it is a statement that it is never reached and the | 
|  | 511 | optimizer can take advantage of this to produce better code.  This builtin takes | 
|  | 512 | no arguments and produces a void result. | 
|  | 513 | </p> | 
|  | 514 |  | 
|  | 515 | <p>Query for this feature with __has_builtin(__builtin_unreachable).</p> | 
|  | 516 |  | 
|  | 517 |  | 
| Chris Lattner | 1177f91 | 2009-04-09 19:58:15 +0000 | [diff] [blame] | 518 | <!-- ======================================================================= --> | 
|  | 519 | <h2 id="targetspecific">Target-Specific Extensions</h2> | 
|  | 520 | <!-- ======================================================================= --> | 
|  | 521 |  | 
|  | 522 | <p>Clang supports some language features conditionally on some targets.</p> | 
|  | 523 |  | 
|  | 524 | <!-- ======================================================================= --> | 
|  | 525 | <h3 id="x86-specific">X86/X86-64 Language Extensions</h3> | 
|  | 526 | <!-- ======================================================================= --> | 
|  | 527 |  | 
|  | 528 | <p>The X86 backend has these language extensions:</p> | 
|  | 529 |  | 
|  | 530 | <!-- ======================================================================= --> | 
|  | 531 | <h4 id="x86-gs-segment">Memory references off the GS segment</h4> | 
|  | 532 | <!-- ======================================================================= --> | 
|  | 533 |  | 
|  | 534 | <p>Annotating a pointer with address space #256 causes it to  be code generated | 
| Chris Lattner | a021e7c | 2009-05-05 18:54:47 +0000 | [diff] [blame] | 535 | relative to the X86 GS segment register, and address space #257 causes it to be | 
|  | 536 | relative to the X86 FS segment.  Note that this is a very very low-level | 
|  | 537 | feature that should only be used if you know what you're doing (for example in | 
|  | 538 | an OS kernel).</p> | 
| Chris Lattner | 1177f91 | 2009-04-09 19:58:15 +0000 | [diff] [blame] | 539 |  | 
|  | 540 | <p>Here is an example:</p> | 
|  | 541 |  | 
|  | 542 | <pre> | 
|  | 543 | #define GS_RELATIVE __attribute__((address_space(256))) | 
|  | 544 | int foo(int GS_RELATIVE *P) { | 
|  | 545 | return *P; | 
|  | 546 | } | 
|  | 547 | </pre> | 
|  | 548 |  | 
|  | 549 | <p>Which compiles to (on X86-32):</p> | 
|  | 550 |  | 
|  | 551 | <pre> | 
|  | 552 | _foo: | 
|  | 553 | movl	4(%esp), %eax | 
|  | 554 | movl	%gs:(%eax), %eax | 
|  | 555 | ret | 
|  | 556 | </pre> | 
|  | 557 |  | 
| Ted Kremenek | ed86931 | 2009-04-10 05:03:33 +0000 | [diff] [blame] | 558 | <!-- ======================================================================= --> | 
|  | 559 | <h2 id="analyzerspecific">Static Analysis-Specific Extensions</h2> | 
|  | 560 | <!-- ======================================================================= --> | 
|  | 561 |  | 
|  | 562 | <p>Clang supports additional attributes that are useful for documenting program | 
|  | 563 | invariants and rules for static analysis tools. The extensions documented here | 
|  | 564 | are used by the <a | 
|  | 565 | href="http://clang.llvm.org/StaticAnalysis.html">path-sensitive static analyzer | 
|  | 566 | engine</a> that is part of Clang's Analysis library.</p> | 
|  | 567 |  | 
|  | 568 | <!-- ======================================================================= --> | 
|  | 569 | <h3 id="analyzerattributes">Analyzer Attributes</h3> | 
|  | 570 | <!-- ======================================================================= --> | 
|  | 571 |  | 
|  | 572 | <h4 id="attr_analyzer_noreturn"><tt>analyzer_noreturn</tt></h4> | 
|  | 573 |  | 
|  | 574 | <p>Clang's static analysis engine understands the standard <tt>noreturn</tt> | 
| Ted Kremenek | 4df2114 | 2009-04-10 05:04:22 +0000 | [diff] [blame] | 575 | attribute. This attribute, which is typically affixed to a function prototype, | 
|  | 576 | indicates that a call to a given function never returns. Function prototypes for | 
|  | 577 | common functions like <tt>exit</tt> are typically annotated with this attribute, | 
|  | 578 | as well as a variety of common assertion handlers. Users can educate the static | 
|  | 579 | analyzer about their own custom assertion handles (thus cutting down on false | 
|  | 580 | positives due to false paths) by marking their own "panic" functions | 
|  | 581 | with this attribute.</p> | 
| Ted Kremenek | ed86931 | 2009-04-10 05:03:33 +0000 | [diff] [blame] | 582 |  | 
|  | 583 | <p>While useful, <tt>noreturn</tt> is not applicable in all cases. Sometimes | 
| Nick Lewycky | 625b586 | 2009-06-14 04:08:08 +0000 | [diff] [blame] | 584 | there are special functions that for all intents and purposes should be | 
|  | 585 | considered panic functions (i.e., they are only called when an internal program | 
|  | 586 | error occurs) but may actually return so that the program can fail gracefully. | 
|  | 587 | The <tt>analyzer_noreturn</tt> attribute allows one to annotate such functions | 
|  | 588 | as being interpreted as "no return" functions by the analyzer (thus | 
| Chris Lattner | 2893589 | 2009-04-10 05:54:56 +0000 | [diff] [blame] | 589 | pruning bogus paths) but will not affect compilation (as in the case of | 
| Ted Kremenek | ed86931 | 2009-04-10 05:03:33 +0000 | [diff] [blame] | 590 | <tt>noreturn</tt>).</p> | 
|  | 591 |  | 
|  | 592 | <p><b>Usage</b>: The <tt>analyzer_noreturn</tt> attribute can be placed in the | 
| Chris Lattner | 2893589 | 2009-04-10 05:54:56 +0000 | [diff] [blame] | 593 | same places where the <tt>noreturn</tt> attribute can be placed. It is commonly | 
| Ted Kremenek | ed86931 | 2009-04-10 05:03:33 +0000 | [diff] [blame] | 594 | placed at the end of function prototypes:</p> | 
|  | 595 |  | 
|  | 596 | <pre> | 
|  | 597 | void foo() <b>__attribute__((analyzer_noreturn))</b>; | 
| Chris Lattner | 148772a | 2009-06-13 07:13:28 +0000 | [diff] [blame] | 598 | </pre> | 
|  | 599 |  | 
|  | 600 | <p>Query for this feature with __has_feature(attribute_analyzer_noreturn).</p> | 
|  | 601 |  | 
| Ted Kremenek | ed86931 | 2009-04-10 05:03:33 +0000 | [diff] [blame] | 602 |  | 
| Chris Lattner | 5ce933f | 2009-02-09 08:46:11 +0000 | [diff] [blame] | 603 | </div> | 
|  | 604 | </body> | 
|  | 605 | </html> |