This is ../../gcc-3.4/gcc/doc/gcc.info, produced by makeinfo version
4.2 from ../../gcc-3.4/gcc/doc/gcc.texi.

Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc.

   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "GNU General Public License" and "Funding Free
Software", the Front-Cover texts being (a) (see below), and with the
Back-Cover Texts being (b) (see below).  A copy of the license is
included in the section entitled "GNU Free Documentation License".

   (a) The FSF's Front-Cover Text is:

   A GNU Manual

   (b) The FSF's Back-Cover Text is:

   You have freedom to copy and modify this GNU Manual, like GNU
software.  Copies published by the Free Software Foundation raise
funds for GNU development.
INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* gcc: (gcc).                  The GNU Compiler Collection.
END-INFO-DIR-ENTRY
   This file documents the use of the GNU compilers.

   Published by the Free Software Foundation
59 Temple Place - Suite 330
Boston, MA 02111-1307 USA

File: gcc.info,  Node: Asm Labels,  Next: Explicit Reg Vars,  Prev: Constraints,  Up: C Extensions

Controlling Names Used in Assembler Code
========================================

   You can specify the name to be used in the assembler code for a C
function or variable by writing the `asm' (or `__asm__') keyword after
the declarator as follows:

     int foo asm ("myfoo") = 2;

This specifies that the name to be used for the variable `foo' in the
assembler code should be `myfoo' rather than the usual `_foo'.

   On systems where an underscore is normally prepended to the name of
a C function or variable, this feature allows you to define names for
the linker that do not start with an underscore.

   It does not make sense to use this feature with a non-static local
variable since such variables do not have assembler names.  If you are
trying to put the variable in a particular register, see *Note Explicit
Reg Vars::.  GCC presently accepts such code with a warning, but will
probably be changed to issue an error, rather than a warning, in the
future.

   You cannot use `asm' in this way in a function _definition_; but you
can get the same effect by writing a declaration for the function
before its definition and putting `asm' there, like this:

     extern func () asm ("FUNC");
     
     func (x, y)
          int x, y;
     /* ... */

   It is up to you to make sure that the assembler names you choose do
not conflict with any other assembler symbols.  Also, you must not use a
register name; that would produce completely invalid assembler code.
GCC does not as yet have the ability to store static variables in
registers.  Perhaps that will be added.


File: gcc.info,  Node: Explicit Reg Vars,  Next: Alternate Keywords,  Prev: Asm Labels,  Up: C Extensions

Variables in Specified Registers
================================

   GNU C allows you to put a few global variables into specified
hardware registers.  You can also specify the register in which an
ordinary register variable should be allocated.

   * Global register variables reserve registers throughout the program.
     This may be useful in programs such as programming language
     interpreters which have a couple of global variables that are
     accessed very often.

   * Local register variables in specific registers do not reserve the
     registers.  The compiler's data flow analysis is capable of
     determining where the specified registers contain live values, and
     where they are available for other uses.  Stores into local
     register variables may be deleted when they appear to be dead
     according to dataflow analysis.  References to local register
     variables may be deleted or moved or simplified.

     These local variables are sometimes convenient for use with the
     extended `asm' feature (*note Extended Asm::), if you want to
     write one output of the assembler instruction directly into a
     particular register.  (This will work provided the register you
     specify fits the constraints specified for that operand in the
     `asm'.)

* Menu:

* Global Reg Vars::
* Local Reg Vars::


File: gcc.info,  Node: Global Reg Vars,  Next: Local Reg Vars,  Up: Explicit Reg Vars

Defining Global Register Variables
----------------------------------

   You can define a global register variable in GNU C like this:

     register int *foo asm ("a5");

Here `a5' is the name of the register which should be used.  Choose a
register which is normally saved and restored by function calls on your
machine, so that library routines will not clobber it.

   Naturally the register name is cpu-dependent, so you would need to
conditionalize your program according to cpu type.  The register `a5'
would be a good choice on a 68000 for a variable of pointer type.  On
machines with register windows, be sure to choose a "global" register
that is not affected magically by the function call mechanism.

   In addition, operating systems on one type of cpu may differ in how
they name the registers; then you would need additional conditionals.
For example, some 68000 operating systems call this register `%a5'.

   Eventually there may be a way of asking the compiler to choose a
register automatically, but first we need to figure out how it should
choose and how to enable you to guide the choice.  No solution is
evident.

   Defining a global register variable in a certain register reserves
that register entirely for this use, at least within the current
compilation.  The register will not be allocated for any other purpose
in the functions in the current compilation.  The register will not be
saved and restored by these functions.  Stores into this register are
never deleted even if they would appear to be dead, but references may
be deleted or moved or simplified.

   It is not safe to access the global register variables from signal
handlers, or from more than one thread of control, because the system
library routines may temporarily use the register for other things
(unless you recompile them specially for the task at hand).

   It is not safe for one function that uses a global register variable
to call another such function `foo' by way of a third function `lose'
that was compiled without knowledge of this variable (i.e. in a
different source file in which the variable wasn't declared).  This is
because `lose' might save the register and put some other value there.
For example, you can't expect a global register variable to be
available in the comparison-function that you pass to `qsort', since
`qsort' might have put something else in that register.  (If you are
prepared to recompile `qsort' with the same global register variable,
you can solve this problem.)

   If you want to recompile `qsort' or other source files which do not
actually use your global register variable, so that they will not use
that register for any other purpose, then it suffices to specify the
compiler option `-ffixed-REG'.  You need not actually add a global
register declaration to their source code.

   A function which can alter the value of a global register variable
cannot safely be called from a function compiled without this variable,
because it could clobber the value the caller expects to find there on
return.  Therefore, the function which is the entry point into the part
of the program that uses the global register variable must explicitly
save and restore the value which belongs to its caller.

   On most machines, `longjmp' will restore to each global register
variable the value it had at the time of the `setjmp'.  On some
machines, however, `longjmp' will not change the value of global
register variables.  To be portable, the function that called `setjmp'
should make other arrangements to save the values of the global register
variables, and to restore them in a `longjmp'.  This way, the same
thing will happen regardless of what `longjmp' does.

   All global register variable declarations must precede all function
definitions.  If such a declaration could appear after function
definitions, the declaration would be too late to prevent the register
from being used for other purposes in the preceding functions.

   Global register variables may not have initial values, because an
executable file has no means to supply initial contents for a register.

   On the SPARC, there are reports that g3 ... g7 are suitable
registers, but certain library functions, such as `getwd', as well as
the subroutines for division and remainder, modify g3 and g4.  g1 and
g2 are local temporaries.

   On the 68000, a2 ... a5 should be suitable, as should d2 ... d7.  Of
course, it will not do to use more than a few of those.


File: gcc.info,  Node: Local Reg Vars,  Prev: Global Reg Vars,  Up: Explicit Reg Vars

Specifying Registers for Local Variables
----------------------------------------

   You can define a local register variable with a specified register
like this:

     register int *foo asm ("a5");

Here `a5' is the name of the register which should be used.  Note that
this is the same syntax used for defining global register variables,
but for a local variable it would appear within a function.

   Naturally the register name is cpu-dependent, but this is not a
problem, since specific registers are most often useful with explicit
assembler instructions (*note Extended Asm::).  Both of these things
generally require that you conditionalize your program according to cpu
type.

   In addition, operating systems on one type of cpu may differ in how
they name the registers; then you would need additional conditionals.
For example, some 68000 operating systems call this register `%a5'.

   Defining such a register variable does not reserve the register; it
remains available for other uses in places where flow control determines
the variable's value is not live.  However, these registers are made
unavailable for use in the reload pass; excessive use of this feature
leaves the compiler too few available registers to compile certain
functions.

   This option does not guarantee that GCC will generate code that has
this variable in the register you specify at all times.  You may not
code an explicit reference to this register in an `asm' statement and
assume it will always refer to this variable.

   Stores into local register variables may be deleted when they appear
to be dead according to dataflow analysis.  References to local
register variables may be deleted or moved or simplified.


File: gcc.info,  Node: Alternate Keywords,  Next: Incomplete Enums,  Prev: Explicit Reg Vars,  Up: C Extensions

Alternate Keywords
==================

   `-ansi' and the various `-std' options disable certain keywords.
This causes trouble when you want to use GNU C extensions, or a
general-purpose header file that should be usable by all programs,
including ISO C programs.  The keywords `asm', `typeof' and `inline'
are not available in programs compiled with `-ansi' or `-std' (although
`inline' can be used in a program compiled with `-std=c99').  The ISO
C99 keyword `restrict' is only available when `-std=gnu99' (which will
eventually be the default) or `-std=c99' (or the equivalent
`-std=iso9899:1999') is used.

   The way to solve these problems is to put `__' at the beginning and
end of each problematical keyword.  For example, use `__asm__' instead
of `asm', and `__inline__' instead of `inline'.

   Other C compilers won't accept these alternative keywords; if you
want to compile with another compiler, you can define the alternate
keywords as macros to replace them with the customary keywords.  It
looks like this:

     #ifndef __GNUC__
     #define __asm__ asm
     #endif

   `-pedantic' and other options cause warnings for many GNU C
extensions.  You can prevent such warnings within one expression by
writing `__extension__' before the expression.  `__extension__' has no
effect aside from this.


File: gcc.info,  Node: Incomplete Enums,  Next: Function Names,  Prev: Alternate Keywords,  Up: C Extensions

Incomplete `enum' Types
=======================

   You can define an `enum' tag without specifying its possible values.
This results in an incomplete type, much like what you get if you write
`struct foo' without describing the elements.  A later declaration
which does specify the possible values completes the type.

   You can't allocate variables or storage using the type while it is
incomplete.  However, you can work with pointers to that type.

   This extension may not be very useful, but it makes the handling of
`enum' more consistent with the way `struct' and `union' are handled.

   This extension is not supported by GNU C++.


File: gcc.info,  Node: Function Names,  Next: Return Address,  Prev: Incomplete Enums,  Up: C Extensions

Function Names as Strings
=========================

   GCC provides three magic variables which hold the name of the current
function, as a string.  The first of these is `__func__', which is part
of the C99 standard:

     The identifier `__func__' is implicitly declared by the translator
     as if, immediately following the opening brace of each function
     definition, the declaration
          static const char __func__[] = "function-name";
     
     appeared, where function-name is the name of the lexically-enclosing
     function.  This name is the unadorned name of the function.

   `__FUNCTION__' is another name for `__func__'.  Older versions of
GCC recognize only this name.  However, it is not standardized.  For
maximum portability, we recommend you use `__func__', but provide a
fallback definition with the preprocessor:

     #if __STDC_VERSION__ < 199901L
     # if __GNUC__ >= 2
     #  define __func__ __FUNCTION__
     # else
     #  define __func__ "<unknown>"
     # endif
     #endif

   In C, `__PRETTY_FUNCTION__' is yet another name for `__func__'.
However, in C++, `__PRETTY_FUNCTION__' contains the type signature of
the function as well as its bare name.  For example, this program:

     extern "C" {
     extern int printf (char *, ...);
     }
     
     class a {
      public:
       void sub (int i)
         {
           printf ("__FUNCTION__ = %s\n", __FUNCTION__);
           printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__);
         }
     };
     
     int
     main (void)
     {
       a ax;
       ax.sub (0);
       return 0;
     }

gives this output:

     __FUNCTION__ = sub
     __PRETTY_FUNCTION__ = void a::sub(int)

   These identifiers are not preprocessor macros.  In GCC 3.3 and
earlier, in C only, `__FUNCTION__' and `__PRETTY_FUNCTION__' were
treated as string literals; they could be used to initialize `char'
arrays, and they could be concatenated with other string literals.  GCC
3.4 and later treat them as variables, like `__func__'.  In C++,
`__FUNCTION__' and `__PRETTY_FUNCTION__' have always been variables.


File: gcc.info,  Node: Return Address,  Next: Vector Extensions,  Prev: Function Names,  Up: C Extensions

Getting the Return or Frame Address of a Function
=================================================

   These functions may be used to get information about the callers of a
function.

 - Built-in Function: void * __builtin_return_address (unsigned int
          LEVEL)
     This function returns the return address of the current function,
     or of one of its callers.  The LEVEL argument is number of frames
     to scan up the call stack.  A value of `0' yields the return
     address of the current function, a value of `1' yields the return
     address of the caller of the current function, and so forth. When
     inlining the expected behavior is that the function will return
     the address of the function that will be returned to.  To work
     around this behavior use the `noinline' function attribute.

     The LEVEL argument must be a constant integer.

     On some machines it may be impossible to determine the return
     address of any function other than the current one; in such cases,
     or when the top of the stack has been reached, this function will
     return `0' or a random value. In addition,
     `__builtin_frame_address' may be used to determine if the top of
     the stack has been reached.

     This function should only be used with a nonzero argument for
     debugging purposes.

 - Built-in Function: void * __builtin_frame_address (unsigned int
          LEVEL)
     This function is similar to `__builtin_return_address', but it
     returns the address of the function frame rather than the return
     address of the function.  Calling `__builtin_frame_address' with a
     value of `0' yields the frame address of the current function, a
     value of `1' yields the frame address of the caller of the current
     function, and so forth.

     The frame is the area on the stack which holds local variables and
     saved registers.  The frame address is normally the address of the
     first word pushed on to the stack by the function.  However, the
     exact definition depends upon the processor and the calling
     convention.  If the processor has a dedicated frame pointer
     register, and the function has a frame, then
     `__builtin_frame_address' will return the value of the frame
     pointer register.

     On some machines it may be impossible to determine the frame
     address of any function other than the current one; in such cases,
     or when the top of the stack has been reached, this function will
     return `0' if the first frame pointer is properly initialized by
     the startup code.

     This function should only be used with a nonzero argument for
     debugging purposes.


File: gcc.info,  Node: Vector Extensions,  Next: Other Builtins,  Prev: Return Address,  Up: C Extensions

Using vector instructions through built-in functions
====================================================

   On some targets, the instruction set contains SIMD vector
instructions that operate on multiple values contained in one large
register at the same time.  For example, on the i386 the MMX, 3Dnow!
and SSE extensions can be used this way.

   The first step in using these extensions is to provide the necessary
data types.  This should be done using an appropriate `typedef':

     typedef int v4si __attribute__ ((mode(V4SI)));

   The base type `int' is effectively ignored by the compiler, the
actual properties of the new type `v4si' are defined by the
`__attribute__'.  It defines the machine mode to be used; for vector
types these have the form `VNB'; N should be the number of elements in
the vector, and B should be the base mode of the individual elements.
The following can be used as base modes:

`QI'
     An integer that is as wide as the smallest addressable unit,
     usually 8 bits.

`HI'
     An integer, twice as wide as a QI mode integer, usually 16 bits.

`SI'
     An integer, four times as wide as a QI mode integer, usually 32
     bits.

`DI'
     An integer, eight times as wide as a QI mode integer, usually 64
     bits.

`SF'
     A floating point value, as wide as a SI mode integer, usually 32
     bits.

`DF'
     A floating point value, as wide as a DI mode integer, usually 64
     bits.

   Specifying a combination that is not valid for the current
architecture will cause gcc to synthesize the instructions using a
narrower mode.  For example, if you specify a variable of type `V4SI'
and your architecture does not allow for this specific SIMD type, gcc
will produce code that uses 4 `SIs'.

   The types defined in this manner can be used with a subset of normal
C operations.  Currently, gcc will allow using the following operators
on these types: `+, -, *, /, unary minus'.

   The operations behave like C++ `valarrays'.  Addition is defined as
the addition of the corresponding elements of the operands.  For
example, in the code below, each of the 4 elements in A will be added
to the corresponding 4 elements in B and the resulting vector will be
stored in C.

     typedef int v4si __attribute__ ((mode(V4SI)));
     
     v4si a, b, c;
     
     c = a + b;

   Subtraction, multiplication, and division operate in a similar
manner.  Likewise, the result of using the unary minus operator on a
vector type is a vector whose elements are the negative value of the
corresponding elements in the operand.

   You can declare variables and use them in function calls and
returns, as well as in assignments and some casts.  You can specify a
vector type as a return type for a function.  Vector types can also be
used as function arguments.  It is possible to cast from one vector
type to another, provided they are of the same size (in fact, you can
also cast vectors to and from other datatypes of the same size).

   You cannot operate between vectors of different lengths or different
signedness without a cast.

   A port that supports hardware vector operations, usually provides a
set of built-in functions that can be used to operate on vectors.  For
example, a function to add two vectors and multiply the result by a
third could look like this:

     v4si f (v4si a, v4si b, v4si c)
     {
       v4si tmp = __builtin_addv4si (a, b);
       return __builtin_mulv4si (tmp, c);
     }


File: gcc.info,  Node: Other Builtins,  Next: Target Builtins,  Prev: Vector Extensions,  Up: C Extensions

Other built-in functions provided by GCC
========================================

   GCC provides a large number of built-in functions other than the ones
mentioned above.  Some of these are for internal use in the processing
of exceptions or variable-length argument lists and will not be
documented here because they may change from time to time; we do not
recommend general use of these functions.

   The remaining functions are provided for optimization purposes.

   GCC includes built-in versions of many of the functions in the
standard C library.  The versions prefixed with `__builtin_' will
always be treated as having the same meaning as the C library function
even if you specify the `-fno-builtin' option. (*note C Dialect
Options::) Many of these functions are only optimized in certain cases;
if they are not optimized in a particular case, a call to the library
function will be emitted.

   Outside strict ISO C mode (`-ansi', `-std=c89' or `-std=c99'), the
functions `alloca', `bcmp', `bzero', `dcgettext', `dgettext', `_exit',
`ffs', `fprintf_unlocked', `fputs_unlocked', `gettext', `index',
`mempcpy', `printf_unlocked', `rindex', `stpcpy', `strdup' and `strfmon'
may be handled as built-in functions.  All these functions have
corresponding versions prefixed with `__builtin_', which may be used
even in strict C89 mode.

   The ISO C99 functions `cabs', `cabsf', `cabsl', `conj', `conjf',
`conjl', `creal', `crealf', `creall', `cimag', `cimagf', `cimagl',
`_Exit', `imaxabs', `llabs', `nearbyint', `nearbyintf', `nearbyintl',
`round', `roundf', `roundl', `snprintf', `trunc', `truncf', `truncl',
`vfscanf', `vscanf', `vsnprintf' and `vsscanf' are handled as built-in
functions except in strict ISO C90 mode (`-ansi' or `-std=c89').

   There are also built-in versions of the ISO C99 functions `atan2f',
`atan2l', `atanf', `atanl', `ceilf', `ceill', `cosf', `cosl', `expf',
`expl', `fabsf', `fabsl', `floorf', `floorl', `fmodf', `fmodl', `logf',
`logl', `powf', `powl', `sinf', `sinl', `sqrtf', `sqrtl', `tanf' and
`tanl' that are recognized in any mode since ISO C90 reserves these
names for the purpose to which ISO C99 puts them.  All these functions
have corresponding versions prefixed with `__builtin_'.

   The ISO C90 functions `abort', `abs', `atan', `atan2', `calloc',
`ceil', `cos', `exit', `exp', `fabs', `floor', `fmod', `fprintf',
`fputs', `fscanf', `labs', `log', `malloc', `memcmp', `memcpy',
`memset', `pow', `printf', `putchar', `puts', `scanf', `sin',
`snprintf', `sprintf', `sqrt', `sscanf', `strcat', `strchr', `strcmp',
`strcpy', `strcspn', `strlen', `strncat', `strncmp', `strncpy',
`strpbrk', `strrchr', `strspn', `strstr', `tan', `vfprintf', `vprintf'
and `vsprintf' are all recognized as built-in functions unless
`-fno-builtin' is specified (or `-fno-builtin-FUNCTION' is specified
for an individual function).  All of these functions have corresponding
versions prefixed with `__builtin_'.

   GCC provides built-in versions of the ISO C99 floating point
comparison macros that avoid raising exceptions for unordered operands.
They have the same names as the standard macros ( `isgreater',
`isgreaterequal', `isless', `islessequal', `islessgreater', and
`isunordered') , with `__builtin_' prefixed.  We intend for a library
implementor to be able to simply `#define' each standard macro to its
built-in equivalent.

 - Built-in Function: int __builtin_types_compatible_p (TYPE1, TYPE2)
     You can use the built-in function `__builtin_types_compatible_p' to
     determine whether two types are the same.

     This built-in function returns 1 if the unqualified versions of the
     types TYPE1 and TYPE2 (which are types, not expressions) are
     compatible, 0 otherwise.  The result of this built-in function can
     be used in integer constant expressions.

     This built-in function ignores top level qualifiers (e.g., `const',
     `volatile').  For example, `int' is equivalent to `const int'.

     The type `int[]' and `int[5]' are compatible.  On the other hand,
     `int' and `char *' are not compatible, even if the size of their
     types, on the particular architecture are the same.  Also, the
     amount of pointer indirection is taken into account when
     determining similarity.  Consequently, `short *' is not similar to
     `short **'.  Furthermore, two types that are typedefed are
     considered compatible if their underlying types are compatible.

     An `enum' type is considered to be compatible with another `enum'
     type.  For example, `enum {foo, bar}' is similar to `enum {hot,
     dog}'.

     You would typically use this function in code whose execution
     varies depending on the arguments' types.  For example:

          #define foo(x)                                                  \
            ({                                                           \
              typeof (x) tmp;                                             \
              if (__builtin_types_compatible_p (typeof (x), long double)) \
                tmp = foo_long_double (tmp);                              \
              else if (__builtin_types_compatible_p (typeof (x), double)) \
                tmp = foo_double (tmp);                                   \
              else if (__builtin_types_compatible_p (typeof (x), float))  \
                tmp = foo_float (tmp);                                    \
              else                                                        \
                abort ();                                                 \
              tmp;                                                        \
            })

     _Note:_ This construct is only available for C.


 - Built-in Function: TYPE __builtin_choose_expr (CONST_EXP, EXP1, EXP2)
     You can use the built-in function `__builtin_choose_expr' to
     evaluate code depending on the value of a constant expression.
     This built-in function returns EXP1 if CONST_EXP, which is a
     constant expression that must be able to be determined at compile
     time, is nonzero.  Otherwise it returns 0.

     This built-in function is analogous to the `? :' operator in C,
     except that the expression returned has its type unaltered by
     promotion rules.  Also, the built-in function does not evaluate
     the expression that was not chosen.  For example, if CONST_EXP
     evaluates to true, EXP2 is not evaluated even if it has
     side-effects.

     This built-in function can return an lvalue if the chosen argument
     is an lvalue.

     If EXP1 is returned, the return type is the same as EXP1's type.
     Similarly, if EXP2 is returned, its return type is the same as
     EXP2.

     Example:

          #define foo(x)                                                    \
            __builtin_choose_expr (                                         \
              __builtin_types_compatible_p (typeof (x), double),            \
              foo_double (x),                                               \
              __builtin_choose_expr (                                       \
                __builtin_types_compatible_p (typeof (x), float),           \
                foo_float (x),                                              \
                /* The void expression results in a compile-time error  \
                   when assigning the result to something.  */          \
                (void)0))

     _Note:_ This construct is only available for C.  Furthermore, the
     unused expression (EXP1 or EXP2 depending on the value of
     CONST_EXP) may still generate syntax errors.  This may change in
     future revisions.


 - Built-in Function: int __builtin_constant_p (EXP)
     You can use the built-in function `__builtin_constant_p' 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 _not_ a constant, but merely that GCC cannot prove it is
     a constant with the specified value of the `-O' option.

     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:

          #define Scale_Value(X)      \
            (__builtin_constant_p (X) \
            ? ((X) * SCALE + OFFSET) : Scale (X))

     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 (*note Compound Literals::)
     and will not return 1 when you pass a constant numeric value to
     the inline function unless you specify the `-O' option.

     You may also use `__builtin_constant_p' in initializers for static
     data.  For instance, you can write

          static const int table[] = {
             __builtin_constant_p (EXPRESSION) ? (EXPRESSION) : -1,
             /* ... */
          };

     This is an acceptable initializer even if EXPRESSION 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.

     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.

 - Built-in Function: long __builtin_expect (long EXP, long C)
     You may use `__builtin_expect' to provide the compiler with branch
     prediction information.  In general, you should prefer to use
     actual profile feedback for this (`-fprofile-arcs'), as
     programmers are notoriously bad at predicting how their programs
     actually perform.  However, there are applications in which this
     data is hard to collect.

     The return value is the value of EXP, which should be an integral
     expression.  The value of C must be a compile-time constant.  The
     semantics of the built-in are that it is expected that EXP == C.
     For example:

          if (__builtin_expect (x, 0))
            foo ();

     would indicate that we do not expect to call `foo', since we
     expect `x' to be zero.  Since you are limited to integral
     expressions for EXP, you should use constructions such as

          if (__builtin_expect (ptr != NULL, 1))
            error ();

     when testing pointer or floating-point values.

 - Built-in Function: void __builtin_prefetch (const void *ADDR, ...)
     This function is used to minimize cache-miss latency by moving
     data into a cache before it is accessed.  You can insert calls to
     `__builtin_prefetch' 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.

     The value of ADDR is the address of the memory to prefetch.  There
     are two optional arguments, RW and LOCALITY.  The value of RW 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
     LOCALITY 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.

          for (i = 0; i < n; i++)
            {
              a[i] = a[i] + b[i];
              __builtin_prefetch (&a[i+j], 1, 1);
              __builtin_prefetch (&b[i+j], 0, 1);
              /* ... */
            }

     Data prefetch does not generate faults if ADDR is invalid, but the
     address expression itself must be valid.  For example, a prefetch
     of `p->next' will not fault if `p->next' is not a valid address,
     but evaluation will fault if `p' is not a valid address.

     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.

 - Built-in Function: double __builtin_huge_val (void)
     Returns a positive infinity, if supported by the floating-point
     format, else `DBL_MAX'.  This function is suitable for
     implementing the ISO C macro `HUGE_VAL'.

 - Built-in Function: float __builtin_huge_valf (void)
     Similar to `__builtin_huge_val', except the return type is `float'.

 - Built-in Function: long double __builtin_huge_vall (void)
     Similar to `__builtin_huge_val', except the return type is `long
     double'.

 - Built-in Function: double __builtin_inf (void)
     Similar to `__builtin_huge_val', 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
     `INFINITY'.

 - Built-in Function: float __builtin_inff (void)
     Similar to `__builtin_inf', except the return type is `float'.

 - Built-in Function: long double __builtin_infl (void)
     Similar to `__builtin_inf', except the return type is `long
     double'.

 - Built-in Function: double __builtin_nan (const char *str)
     This is an implementation of the ISO C99 function `nan'.

     Since ISO C99 defines this function in terms of `strtod', which we
     do not implement, a description of the parsing is in order.  The
     string is parsed as by `strtol'; that is, the base is recognized by
     leading `0' or `0x' 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.

     This function, if given a string literal, is evaluated early enough
     that it is considered a compile-time constant.

 - Built-in Function: float __builtin_nanf (const char *str)
     Similar to `__builtin_nan', except the return type is `float'.

 - Built-in Function: long double __builtin_nanl (const char *str)
     Similar to `__builtin_nan', except the return type is `long
     double'.

 - Built-in Function: double __builtin_nans (const char *str)
     Similar to `__builtin_nan', except the significand is forced to be
     a signaling NaN.  The `nans' function is proposed by WG14 N965.

 - Built-in Function: float __builtin_nansf (const char *str)
     Similar to `__builtin_nans', except the return type is `float'.

 - Built-in Function: long double __builtin_nansl (const char *str)
     Similar to `__builtin_nans', except the return type is `long
     double'.

 - Built-in Function: int __builtin_ffs (unsigned int x)
     Returns one plus the index of the least significant 1-bit of X, or
     if X is zero, returns zero.

 - Built-in Function: int __builtin_clz (unsigned int x)
     Returns the number of leading 0-bits in X, starting at the most
     significant bit position.  If X is 0, the result is undefined.

 - Built-in Function: int __builtin_ctz (unsigned int x)
     Returns the number of trailing 0-bits in X, starting at the least
     significant bit position.  If X is 0, the result is undefined.

 - Built-in Function: int __builtin_popcount (unsigned int x)
     Returns the number of 1-bits in X.

 - Built-in Function: int __builtin_parity (unsigned int x)
     Returns the parity of X, i.e. the number of 1-bits in X modulo 2.

 - Built-in Function: int __builtin_ffsl (unsigned long)
     Similar to `__builtin_ffs', except the argument type is `unsigned
     long'.

 - Built-in Function: int __builtin_clzl (unsigned long)
     Similar to `__builtin_clz', except the argument type is `unsigned
     long'.

 - Built-in Function: int __builtin_ctzl (unsigned long)
     Similar to `__builtin_ctz', except the argument type is `unsigned
     long'.

 - Built-in Function: int __builtin_popcountl (unsigned long)
     Similar to `__builtin_popcount', except the argument type is
     `unsigned long'.

 - Built-in Function: int __builtin_parityl (unsigned long)
     Similar to `__builtin_parity', except the argument type is
     `unsigned long'.

 - Built-in Function: int __builtin_ffsll (unsigned long long)
     Similar to `__builtin_ffs', except the argument type is `unsigned
     long long'.

 - Built-in Function: int __builtin_clzll (unsigned long long)
     Similar to `__builtin_clz', except the argument type is `unsigned
     long long'.

 - Built-in Function: int __builtin_ctzll (unsigned long long)
     Similar to `__builtin_ctz', except the argument type is `unsigned
     long long'.

 - Built-in Function: int __builtin_popcountll (unsigned long long)
     Similar to `__builtin_popcount', except the argument type is
     `unsigned long long'.

 - Built-in Function: int __builtin_parityll (unsigned long long)
     Similar to `__builtin_parity', except the argument type is
     `unsigned long long'.


File: gcc.info,  Node: Target Builtins,  Next: Pragmas,  Prev: Other Builtins,  Up: C Extensions

Built-in Functions Specific to Particular Target Machines
=========================================================

   On some target machines, GCC supports many built-in functions
specific to those machines.  Generally these generate calls to specific
machine instructions, but allow the compiler to schedule those calls.

* Menu:

* Alpha Built-in Functions::
* ARM Built-in Functions::
* X86 Built-in Functions::
* PowerPC AltiVec Built-in Functions::


File: gcc.info,  Node: Alpha Built-in Functions,  Next: ARM Built-in Functions,  Up: Target Builtins

Alpha Built-in Functions
------------------------

   These built-in functions are available for the Alpha family of
processors, depending on the command-line switches used.

   The following built-in functions are always available.  They all
generate the machine instruction that is part of the name.

     long __builtin_alpha_implver (void)
     long __builtin_alpha_rpcc (void)
     long __builtin_alpha_amask (long)
     long __builtin_alpha_cmpbge (long, long)
     long __builtin_alpha_extbl (long, long)
     long __builtin_alpha_extwl (long, long)
     long __builtin_alpha_extll (long, long)
     long __builtin_alpha_extql (long, long)
     long __builtin_alpha_extwh (long, long)
     long __builtin_alpha_extlh (long, long)
     long __builtin_alpha_extqh (long, long)
     long __builtin_alpha_insbl (long, long)
     long __builtin_alpha_inswl (long, long)
     long __builtin_alpha_insll (long, long)
     long __builtin_alpha_insql (long, long)
     long __builtin_alpha_inswh (long, long)
     long __builtin_alpha_inslh (long, long)
     long __builtin_alpha_insqh (long, long)
     long __builtin_alpha_mskbl (long, long)
     long __builtin_alpha_mskwl (long, long)
     long __builtin_alpha_mskll (long, long)
     long __builtin_alpha_mskql (long, long)
     long __builtin_alpha_mskwh (long, long)
     long __builtin_alpha_msklh (long, long)
     long __builtin_alpha_mskqh (long, long)
     long __builtin_alpha_umulh (long, long)
     long __builtin_alpha_zap (long, long)
     long __builtin_alpha_zapnot (long, long)

   The following built-in functions are always with `-mmax' or
`-mcpu=CPU' where CPU is `pca56' or later.  They all generate the
machine instruction that is part of the name.

     long __builtin_alpha_pklb (long)
     long __builtin_alpha_pkwb (long)
     long __builtin_alpha_unpkbl (long)
     long __builtin_alpha_unpkbw (long)
     long __builtin_alpha_minub8 (long, long)
     long __builtin_alpha_minsb8 (long, long)
     long __builtin_alpha_minuw4 (long, long)
     long __builtin_alpha_minsw4 (long, long)
     long __builtin_alpha_maxub8 (long, long)
     long __builtin_alpha_maxsb8 (long, long)
     long __builtin_alpha_maxuw4 (long, long)
     long __builtin_alpha_maxsw4 (long, long)
     long __builtin_alpha_perr (long, long)

   The following built-in functions are always with `-mcix' or
`-mcpu=CPU' where CPU is `ev67' or later.  They all generate the
machine instruction that is part of the name.

     long __builtin_alpha_cttz (long)
     long __builtin_alpha_ctlz (long)
     long __builtin_alpha_ctpop (long)

   The following builtins are available on systems that use the OSF/1
PALcode.  Normally they invoke the `rduniq' and `wruniq' PAL calls, but
when invoked with `-mtls-kernel', they invoke `rdval' and `wrval'.

     void *__builtin_thread_pointer (void)
     void __builtin_set_thread_pointer (void *)


File: gcc.info,  Node: ARM Built-in Functions,  Next: X86 Built-in Functions,  Prev: Alpha Built-in Functions,  Up: Target Builtins

ARM Built-in Functions
----------------------

   These built-in functions are available for the ARM family of
processors, when the `-mcpu=iwmmxt' switch is used:

     typedef int __v2si __attribute__ ((__mode__ (__V2SI__)))
     
     v2si __builtin_arm_waddw (v2si, v2si)
     v2si __builtin_arm_waddw (v2si, v2si)
     v2si __builtin_arm_wsubw (v2si, v2si)
     v2si __builtin_arm_wsubw (v2si, v2si)
     v2si __builtin_arm_waddwss (v2si, v2si)
     v2si __builtin_arm_wsubwss (v2si, v2si)
     v2si __builtin_arm_wsubwss (v2si, v2si)
     v2si __builtin_arm_wsubwss (v2si, v2si)
     v2si __builtin_arm_wsubwss (v2si, v2si)
     v2si __builtin_arm_waddwus (v2si, v2si)
     v2si __builtin_arm_wsubwus (v2si, v2si)
     v2si __builtin_arm_wsubwus (v2si, v2si)
     v2si __builtin_arm_wmaxuw (v2si, v2si)
     v2si __builtin_arm_wmaxsw (v2si, v2si)
     v2si __builtin_arm_wavg2br (v2si, v2si)
     v2si __builtin_arm_wavg2hr (v2si, v2si)
     v2si __builtin_arm_wavg2b (v2si, v2si)
     v2si __builtin_arm_wavg2h (v2si, v2si)
     v2si __builtin_arm_waccb (v2si)
     v2si __builtin_arm_wacch (v2si)
     v2si __builtin_arm_waccw (v2si)
     v2si __builtin_arm_wmacs (v2si, v2si, v2si)
     v2si __builtin_arm_wmacsz (v2si, v2si, v2si)
     v2si __builtin_arm_wmacu (v2si, v2si, v2si)
     v2si __builtin_arm_wmacuz (v2si, v2si)
     v2si __builtin_arm_wsadb (v2si, v2si)
     v2si __builtin_arm_wsadbz (v2si, v2si)
     v2si __builtin_arm_wsadh (v2si, v2si)
     v2si __builtin_arm_wsadhz (v2si, v2si)
     v2si __builtin_arm_walign (v2si, v2si)
     v2si __builtin_arm_tmia (v2si, int, int)
     v2si __builtin_arm_tmiaph (v2si, int, int)
     v2si __builtin_arm_tmiabb (v2si, int, int)
     v2si __builtin_arm_tmiabt (v2si, int, int)
     v2si __builtin_arm_tmiatb (v2si, int, int)
     v2si __builtin_arm_tmiatt (v2si, int, int)
     int  __builtin_arm_tmovmskb (v2si)
     int  __builtin_arm_tmovmskh (v2si)
     int  __builtin_arm_tmovmskw (v2si)
     v2si __builtin_arm_wmadds (v2si, v2si)
     v2si __builtin_arm_wmaddu (v2si, v2si)
     v2si __builtin_arm_wpackhss (v2si, v2si)
     v2si __builtin_arm_wpackwss (v2si, v2si)
     v2si __builtin_arm_wpackdss (v2si, v2si)
     v2si __builtin_arm_wpackhus (v2si, v2si)
     v2si __builtin_arm_wpackwus (v2si, v2si)
     v2si __builtin_arm_wpackdus (v2si, v2si)
     v2si __builtin_arm_waddb (v2si, v2si)
     v2si __builtin_arm_waddh (v2si, v2si)
     v2si __builtin_arm_waddw (v2si, v2si)
     v2si __builtin_arm_waddbss (v2si, v2si)
     v2si __builtin_arm_waddhss (v2si, v2si)
     v2si __builtin_arm_waddwss (v2si, v2si)
     v2si __builtin_arm_waddbus (v2si, v2si)
     v2si __builtin_arm_waddhus (v2si, v2si)
     v2si __builtin_arm_waddwus (v2si, v2si)
     v2si __builtin_arm_wsubb (v2si, v2si)
     v2si __builtin_arm_wsubh (v2si, v2si)
     v2si __builtin_arm_wsubw (v2si, v2si)
     v2si __builtin_arm_wsubbss (v2si, v2si)
     v2si __builtin_arm_wsubhss (v2si, v2si)
     v2si __builtin_arm_wsubwss (v2si, v2si)
     v2si __builtin_arm_wsubbus (v2si, v2si)
     v2si __builtin_arm_wsubhus (v2si, v2si)
     v2si __builtin_arm_wsubwus (v2si, v2si)
     v2si __builtin_arm_wand (v2si, v2si)
     v2si __builtin_arm_wandn (v2si, v2si)
     v2si __builtin_arm_wor (v2si, v2si)
     v2si __builtin_arm_wxor (v2si, v2si)
     v2si __builtin_arm_wcmpeqb (v2si, v2si)
     v2si __builtin_arm_wcmpeqh (v2si, v2si)
     v2si __builtin_arm_wcmpeqw (v2si, v2si)
     v2si __builtin_arm_wcmpgtub (v2si, v2si)
     v2si __builtin_arm_wcmpgtuh (v2si, v2si)
     v2si __builtin_arm_wcmpgtuw (v2si, v2si)
     v2si __builtin_arm_wcmpgtsb (v2si, v2si)
     v2si __builtin_arm_wcmpgtsh (v2si, v2si)
     v2si __builtin_arm_wcmpgtsw (v2si, v2si)
     int  __builtin_arm_textrmsb (v2si, int)
     int  __builtin_arm_textrmsh (v2si, int)
     int  __builtin_arm_textrmsw (v2si, int)
     int  __builtin_arm_textrmub (v2si, int)
     int  __builtin_arm_textrmuh (v2si, int)
     int  __builtin_arm_textrmuw (v2si, int)
     v2si __builtin_arm_tinsrb (v2si, int, int)
     v2si __builtin_arm_tinsrh (v2si, int, int)
     v2si __builtin_arm_tinsrw (v2si, int, int)
     v2si __builtin_arm_wmaxsw (v2si, v2si)
     v2si __builtin_arm_wmaxsh (v2si, v2si)
     v2si __builtin_arm_wmaxsb (v2si, v2si)
     v2si __builtin_arm_wmaxuw (v2si, v2si)
     v2si __builtin_arm_wmaxuh (v2si, v2si)
     v2si __builtin_arm_wmaxub (v2si, v2si)
     v2si __builtin_arm_wminsw (v2si, v2si)
     v2si __builtin_arm_wminsh (v2si, v2si)
     v2si __builtin_arm_wminsb (v2si, v2si)
     v2si __builtin_arm_wminuw (v2si, v2si)
     v2si __builtin_arm_wminuh (v2si, v2si)
     v2si __builtin_arm_wminub (v2si, v2si)
     v2si __builtin_arm_wmuluh (v2si, v2si)
     v2si __builtin_arm_wmulsh (v2si, v2si)
     v2si __builtin_arm_wmulul (v2si, v2si)
     v2si __builtin_arm_wshufh (v2si, int)
     v2si __builtin_arm_wsllh (v2si, v2si)
     v2si __builtin_arm_wsllw (v2si, v2si)
     v2si __builtin_arm_wslld (v2si, v2si)
     v2si __builtin_arm_wsrah (v2si, v2si)
     v2si __builtin_arm_wsraw (v2si, v2si)
     v2si __builtin_arm_wsrad (v2si, v2si)
     v2si __builtin_arm_wsrlh (v2si, v2si)
     v2si __builtin_arm_wsrlw (v2si, v2si)
     v2si __builtin_arm_wsrld (v2si, v2si)
     v2si __builtin_arm_wrorh (v2si, v2si)
     v2si __builtin_arm_wrorw (v2si, v2si)
     v2si __builtin_arm_wrord (v2si, v2si)
     v2si __builtin_arm_wsllhi (v2si, int)
     v2si __builtin_arm_wsllwi (v2si, int)
     v2si __builtin_arm_wslldi (v2si, v2si)
     v2si __builtin_arm_wsrahi (v2si, int)
     v2si __builtin_arm_wsrawi (v2si, int)
     v2si __builtin_arm_wsradi (v2si, v2si)
     v2si __builtin_arm_wsrlwi (v2si, int)
     v2si __builtin_arm_wsrldi (v2si, int)
     v2si __builtin_arm_wrorhi (v2si, int)
     v2si __builtin_arm_wrorwi (v2si, int)
     v2si __builtin_arm_wrordi (v2si, int)
     v2si __builtin_arm_wunpckihb (v2si, v2si)
     v2si __builtin_arm_wunpckihh (v2si, v2si)
     v2si __builtin_arm_wunpckihw (v2si, v2si)
     v2si __builtin_arm_wunpckilb (v2si, v2si)
     v2si __builtin_arm_wunpckilh (v2si, v2si)
     v2si __builtin_arm_wunpckilw (v2si, v2si)
     v2si __builtin_arm_wunpckehsb (v2si)
     v2si __builtin_arm_wunpckehsh (v2si)
     v2si __builtin_arm_wunpckehsw (v2si)
     v2si __builtin_arm_wunpckehub (v2si)
     v2si __builtin_arm_wunpckehuh (v2si)
     v2si __builtin_arm_wunpckehuw (v2si)
     v2si __builtin_arm_wunpckelsb (v2si)
     v2si __builtin_arm_wunpckelsh (v2si)
     v2si __builtin_arm_wunpckelsw (v2si)
     v2si __builtin_arm_wunpckelub (v2si)
     v2si __builtin_arm_wunpckeluh (v2si)
     v2si __builtin_arm_wunpckeluw (v2si)
     v2si __builtin_arm_wsubwss (v2si, v2si)
     v2si __builtin_arm_wsraw (v2si, v2si)
     v2si __builtin_arm_wsrad (v2si, v2si)

