other-builtins.html

自己收集的linux入门到学懂高级编程书集 包括linux程序设计第三版

     <p><em>Note:</em> This construct is only available for C.  Furthermore, the
unused expression (<var>exp1</var> or <var>exp2</var> depending on the value of
<var>const_exp</var>) may still generate syntax errors.  This may change in
future revisions.

        </td></tr>
</table>

<p>
<table width="100%">
<tr>
<td align="left">int <b>__builtin_constant_p</b><i> </i>(<i></i><var>exp</var><i></i>)<i>
     </i></td>
<td align="right">Built-in Function</td>
</tr>
</table>
<table width="95%" align="center">
<tr><td>
You can use the built-in function <code>__builtin_constant_p</code> to
determine if a value is known to be constant at compile-time and hence
that GCC can perform constant-folding on expressions involving that
value.  The argument of the function is the value to test.  The function
returns the integer 1 if the argument is known to be a compile-time
constant and 0 if it is not known to be a compile-time constant.  A
return of 0 does not indicate that the value is <em>not</em> a constant,
but merely that GCC cannot prove it is a constant with the specified
value of the <code>-O</code> option.

     <p>You would typically use this function in an embedded application where
memory was a critical resource.  If you have some complex calculation,
you may want it to be folded if it involves constants, but need to call
a function if it does not.  For example:

     <pre class="smallexample">          #define Scale_Value(X)      \
            (__builtin_constant_p (X) \
            ? ((X) * SCALE + OFFSET) : Scale (X))
          </pre>

     <p>You may use this built-in function in either a macro or an inline
function.  However, if you use it in an inlined function and pass an
argument of the function as the argument to the built-in, GCC will
never return 1 when you call the inline function with a string constant
or compound literal (see <a href="Compound-Literals.html#Compound%20Literals">Compound Literals</a>) and will not return 1
when you pass a constant numeric value to the inline function unless you
specify the <code>-O</code> option.

     <p>You may also use <code>__builtin_constant_p</code> in initializers for static
data.  For instance, you can write

     <pre class="smallexample">          static const int table[] = {
             __builtin_constant_p (EXPRESSION) ? (EXPRESSION) : -1,
             /* <small class="dots">...</small> */
          };
          </pre>

     <p>This is an acceptable initializer even if <var>EXPRESSION</var> is not a
constant expression.  GCC must be more conservative about evaluating the
built-in in this case, because it has no opportunity to perform
optimization.

     <p>Previous versions of GCC did not accept this built-in in data
initializers.  The earliest version where it is completely safe is
3.0.1. 
</td></tr>
</table>

<p>
<table width="100%">
<tr>
<td align="left">long <b>__builtin_expect</b><i> </i>(<i>long </i><var>exp</var><i>, long </i><var>c</var><i></i>)<i>
     </i></td>
<td align="right">Built-in Function</td>
</tr>
</table>
<table width="95%" align="center">
<tr><td>
You may use <code>__builtin_expect</code> to provide the compiler with
branch prediction information.  In general, you should prefer to
use actual profile feedback for this (<code>-fprofile-arcs</code>), as
programmers are notoriously bad at predicting how their programs
actually perform.  However, there are applications in which this
data is hard to collect.

     <p>The return value is the value of <var>exp</var>, which should be an
integral expression.  The value of <var>c</var> must be a compile-time
constant.  The semantics of the built-in are that it is expected
that <var>exp</var> == <var>c</var>.  For example:

     <pre class="smallexample">          if (__builtin_expect (x, 0))
            foo ();
          </pre>

     <p>would indicate that we do not expect to call <code>foo</code>, since
we expect <code>x</code> to be zero.  Since you are limited to integral
expressions for <var>exp</var>, you should use constructions such as

     <pre class="smallexample">          if (__builtin_expect (ptr != NULL, 1))
            error ();
          </pre>

     <p>when testing pointer or floating-point values. 
</td></tr>
</table>

<p>
<table width="100%">
<tr>
<td align="left">void <b>__builtin_prefetch</b><i> </i>(<i>const void *</i><var>addr</var><i>, ...</i>)<i>
     </i></td>
<td align="right">Built-in Function</td>
</tr>
</table>
<table width="95%" align="center">
<tr><td>
This function is used to minimize cache-miss latency by moving data into
a cache before it is accessed. 
You can insert calls to <code>__builtin_prefetch</code> into code for which
you know addresses of data in memory that is likely to be accessed soon. 
If the target supports them, data prefetch instructions will be generated. 
If the prefetch is done early enough before the access then the data will
be in the cache by the time it is accessed.

     <p>The value of <var>addr</var> is the address of the memory to prefetch. 
There are two optional arguments, <var>rw</var> and <var>locality</var>. 
The value of <var>rw</var> is a compile-time constant one or zero; one
means that the prefetch is preparing for a write to the memory address
and zero, the default, means that the prefetch is preparing for a read. 
The value <var>locality</var> must be a compile-time constant integer between
zero and three.  A value of zero means that the data has no temporal
locality, so it need not be left in the cache after the access.  A value
of three means that the data has a high degree of temporal locality and
should be left in all levels of cache possible.  Values of one and two
mean, respectively, a low or moderate degree of temporal locality.  The
default is three.

     <pre class="smallexample">          for (i = 0; i &lt; n; i++)
            {
              a[i] = a[i] + b[i];
              __builtin_prefetch (&amp;a[i+j], 1, 1);
              __builtin_prefetch (&amp;b[i+j], 0, 1);
              /* <small class="dots">...</small> */
            }
          </pre>

     <p>Data prefetch does not generate faults if <var>addr</var> is invalid, but
the address expression itself must be valid.  For example, a prefetch
of <code>p-&gt;next</code> will not fault if <code>p-&gt;next</code> is not a valid
address, but evaluation will fault if <code>p</code> is not a valid address.

     <p>If the target does not support data prefetch, the address expression
is evaluated if it includes side effects but no other code is generated
and GCC does not issue a warning. 
</td></tr>
</table>

<p>
<table width="100%">
<tr>
<td align="left">double <b>__builtin_huge_val</b><i> </i>(<i>void</i>)<i>
     </i></td>
<td align="right">Built-in Function</td>
</tr>
</table>
<table width="95%" align="center">
<tr><td>
Returns a positive infinity, if supported by the floating-point format,
else <code>DBL_MAX</code>.  This function is suitable for implementing the
ISO C macro <code>HUGE_VAL</code>. 
</td></tr>
</table>

<p>
<table width="100%">
<tr>
<td align="left">float <b>__builtin_huge_valf</b><i> </i>(<i>void</i>)<i>
     </i></td>
<td align="right">Built-in Function</td>
</tr>
</table>
<table width="95%" align="center">
<tr><td>
Similar to <code>__builtin_huge_val</code>, except the return type is <code>float</code>. 
</td></tr>
</table>

<p>
<table width="100%">
<tr>
<td align="left">long double <b>__builtin_huge_vall</b><i> </i>(<i>void</i>)<i>
     </i></td>
<td align="right">Built-in Function</td>
</tr>
</table>
<table width="95%" align="center">
<tr><td>
Similar to <code>__builtin_huge_val</code>, except the return
type is <code>long double</code>. 
</td></tr>
</table>

<p>
<table width="100%">
<tr>
<td align="left">double <b>__builtin_inf</b><i> </i>(<i>void</i>)<i>
     </i></td>
<td align="right">Built-in Function</td>
</tr>
</table>
<table width="95%" align="center">
<tr><td>
Similar to <code>__builtin_huge_val</code>, except a warning is generated
if the target floating-point format does not support infinities. 
This function is suitable for implementing the ISO C99 macro <code>INFINITY</code>. 
</td></tr>
</table>

<p>
<table width="100%">
<tr>
<td align="left">float <b>__builtin_inff</b><i> </i>(<i>void</i>)<i>
     </i></td>
<td align="right">Built-in Function</td>
</tr>
</table>
<table width="95%" align="center">
<tr><td>
Similar to <code>__builtin_inf</code>, except the return type is <code>float</code>. 
</td></tr>
</table>

<p>
<table width="100%">
<tr>
<td align="left">long double <b>__builtin_infl</b><i> </i>(<i>void</i>)<i>
     </i></td>
<td align="right">Built-in Function</td>
</tr>
</table>
<table width="95%" align="center">
<tr><td>
Similar to <code>__builtin_inf</code>, except the return
type is <code>long double</code>. 
</td></tr>
</table>

<p>
<table width="100%">
<tr>
<td align="left">double <b>__builtin_nan</b><i> </i>(<i>const char *str</i>)<i>
     </i></td>
<td align="right">Built-in Function</td>
</tr>
</table>
<table width="95%" align="center">
<tr><td>
This is an implementation of the ISO C99 function <code>nan</code>.

     <p>Since ISO C99 defines this function in terms of <code>strtod</code>, which we
do not implement, a description of the parsing is in order.  The string
is parsed as by <code>strtol</code>; that is, the base is recognized by
leading <code>0</code> or <code>0x</code> prefixes.  The number parsed is placed
in the significand such that the least significant bit of the number
is at the least significant bit of the significand.  The number is
truncated to fit the significand field provided.  The significand is
forced to be a quiet NaN.

     <p>This function, if given a string literal, is evaluated early enough
that it is considered a compile-time constant. 
</td></tr>
</table>

<p>
<table width="100%">
<tr>
<td align="left">float <b>__builtin_nanf</b><i> </i>(<i>const char *str</i>)<i>
     </i></td>
<td align="right">Built-in Function</td>
</tr>
</table>
<table width="95%" align="center">
<tr><td>
Similar to <code>__builtin_nan</code>, except the return type is <code>float</code>. 
</td></tr>
</table>

<p>