This is doc/gcc.info, produced by makeinfo version 4.0 from
doc/gcc.texi.

INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* gcc: (gcc).                  The GNU Compiler Collection.
END-INFO-DIR-ENTRY
   This file documents the use and the internals of the GNU compiler.


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


   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
1999, 2000, 2001 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.1 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.


File: gcc.info,  Node: Variadic Macros,  Next: Escaped Newlines,  Prev: Variable Length,  Up: C Extensions

Macros with a Variable Number of Arguments.
===========================================

   In the ISO C standard of 1999, a macro can be declared to accept a
variable number of arguments much as a function can.  The syntax for
defining the macro is similar to that of a function.  Here is an
example:

     #define debug(format, ...) fprintf (stderr, format, __VA_ARGS__)

   Here `...' is a "variable argument".  In the invocation of such a
macro, it represents the zero or more tokens until the closing
parenthesis that ends the invocation, including any commas.  This set of
tokens replaces the identifier `__VA_ARGS__' in the macro body wherever
it appears.  See the CPP manual for more information.

   GCC has long supported variadic macros, and used a different syntax
that allowed you to give a name to the variable arguments just like any
other argument.  Here is an example:

     #define debug(format, args...) fprintf (stderr, format, args)

   This is in all ways equivalent to the ISO C example above, but
arguably more readable and descriptive.

   GNU CPP has two further variadic macro extensions, and permits them
to be used with either of the above forms of macro definition.

   In standard C, you are not allowed to leave the variable argument out
entirely; but you are allowed to pass an empty argument.  For example,
this invocation is invalid in ISO C, because there is no comma after
the string:

     debug ("A message")

   GNU CPP permits you to completely omit the variable arguments in this
way.  In the above examples, the compiler would complain, though since
the expansion of the macro still has the extra comma after the format
string.

   To help solve this problem, CPP behaves specially for variable
arguments used with the token paste operator, `##'.  If instead you
write

     #define debug(format, ...) fprintf (stderr, format, ## __VA_ARGS__)

   and if the variable arguments are omitted or empty, the `##'
operator causes the preprocessor to remove the comma before it.  If you
do provide some variable arguments in your macro invocation, GNU CPP
does not complain about the paste operation and instead places the
variable arguments after the comma.  Just like any other pasted macro
argument, these arguments are not macro expanded.


File: gcc.info,  Node: Escaped Newlines,  Next: Multi-line Strings,  Prev: Variadic Macros,  Up: C Extensions

Slightly Looser Rules for Escaped Newlines
==========================================

   Recently, the non-traditional preprocessor has relaxed its treatment
of escaped newlines.  Previously, the newline had to immediately follow
a backslash.  The current implementation allows whitespace in the form
of spaces, horizontal and vertical tabs, and form feeds between the
backslash and the subsequent newline.  The preprocessor issues a
warning, but treats it as a valid escaped newline and combines the two
lines to form a single logical line.  This works within comments and
tokens, including multi-line strings, as well as between tokens.
Comments are _not_ treated as whitespace for the purposes of this
relaxation, since they have not yet been replaced with spaces.


File: gcc.info,  Node: Multi-line Strings,  Next: Subscripting,  Prev: Escaped Newlines,  Up: C Extensions

String Literals with Embedded Newlines
======================================

   As an extension, GNU CPP permits string literals to cross multiple
lines without escaping the embedded newlines.  Each embedded newline is
replaced with a single `\n' character in the resulting string literal,
regardless of what form the newline took originally.

   CPP currently allows such strings in directives as well (other than
the `#include' family).  This is deprecated and will eventually be
removed.


File: gcc.info,  Node: Subscripting,  Next: Pointer Arith,  Prev: Multi-line Strings,  Up: C Extensions

Non-Lvalue Arrays May Have Subscripts
=====================================

   Subscripting is allowed on arrays that are not lvalues, even though
the unary `&' operator is not.  (In ISO C99, both are allowed (though
the array may not be used after the next sequence point), but this ISO
C99 feature is not yet fully supported in GCC.)  For example, this is
valid in GNU C though not valid in C89:

     struct foo {int a[4];};
     
     struct foo f();
     
     bar (int index)
     {
       return f().a[index];
     }


File: gcc.info,  Node: Pointer Arith,  Next: Initializers,  Prev: Subscripting,  Up: C Extensions

Arithmetic on `void'- and Function-Pointers
===========================================

   In GNU C, addition and subtraction operations are supported on
pointers to `void' and on pointers to functions.  This is done by
treating the size of a `void' or of a function as 1.

   A consequence of this is that `sizeof' is also allowed on `void' and
on function types, and returns 1.

   The option `-Wpointer-arith' requests a warning if these extensions
are used.


File: gcc.info,  Node: Initializers,  Next: Compound Literals,  Prev: Pointer Arith,  Up: C Extensions

Non-Constant Initializers
=========================

   As in standard C++ and ISO C99, the elements of an aggregate
initializer for an automatic variable are not required to be constant
expressions in GNU C.  Here is an example of an initializer with
run-time varying elements:

     foo (float f, float g)
     {
       float beat_freqs[2] = { f-g, f+g };
       ...
     }


File: gcc.info,  Node: Compound Literals,  Next: Designated Inits,  Prev: Initializers,  Up: C Extensions

Compound Literals
=================

   ISO C99 supports compound literals.  A compound literal looks like a
cast containing an initializer.  Its value is an object of the type
specified in the cast, containing the elements specified in the
initializer.  (GCC does not yet implement the full ISO C99 semantics
for compound literals.)  As an extension, GCC supports compound literals
in C89 mode and in C++.

   Usually, the specified type is a structure.  Assume that `struct
foo' and `structure' are declared as shown:

     struct foo {int a; char b[2];} structure;

Here is an example of constructing a `struct foo' with a compound
literal:

     structure = ((struct foo) {x + y, 'a', 0});

This is equivalent to writing the following:

     {
       struct foo temp = {x + y, 'a', 0};
       structure = temp;
     }

   You can also construct an array.  If all the elements of the
compound literal are (made up of) simple constant expressions, suitable
for use in initializers, then the compound literal is an lvalue and can
be coerced to a pointer to its first element, as shown here:

     char **foo = (char *[]) { "x", "y", "z" };

   Array compound literals whose elements are not simple constants are
not very useful, because the compound literal is not an lvalue; ISO C99
specifies that it is, being a temporary object with automatic storage
duration associated with the enclosing block, but GCC does not yet
implement this.  There are currently only two valid ways to use it with
GCC: to subscript it, or initialize an array variable with it.  The
former is probably slower than a `switch' statement, while the latter
does the same thing an ordinary C initializer would do.  Here is an
example of subscripting an array compound literal:

     output = ((int[]) { 2, x, 28 }) [input];

   Compound literals for scalar types and union types are is also
allowed, but then the compound literal is equivalent to a cast.


File: gcc.info,  Node: Designated Inits,  Next: Cast to Union,  Prev: Compound Literals,  Up: C Extensions

Designated Initializers
=======================

   Standard C89 requires the elements of an initializer to appear in a
fixed order, the same as the order of the elements in the array or
structure being initialized.

   In ISO C99 you can give the elements in any order, specifying the
array indices or structure field names they apply to, and GNU C allows
this as an extension in C89 mode as well.  This extension is not
implemented in GNU C++.

   To specify an array index, write `[INDEX] =' before the element
value.  For example,

     int a[6] = { [4] = 29, [2] = 15 };

is equivalent to

     int a[6] = { 0, 0, 15, 0, 29, 0 };

The index values must be constant expressions, even if the array being
initialized is automatic.

   An alternative syntax for this which has been obsolete since GCC 2.5
but GCC still accepts is to write `[INDEX]' before the element value,
with no `='.

   To initialize a range of elements to the same value, write `[FIRST
... LAST] = VALUE'.  This is a GNU extension.  For example,

     int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };

If the value in it has side-effects, the side-effects will happen only
once, not for each initialized field by the range initializer.

Note that the length of the array is the highest value specified plus
one.

   In a structure initializer, specify the name of a field to initialize
with `.FIELDNAME =' before the element value.  For example, given the
following structure,

     struct point { int x, y; };

the following initialization

     struct point p = { .y = yvalue, .x = xvalue };

is equivalent to

     struct point p = { xvalue, yvalue };

   Another syntax which has the same meaning, obsolete since GCC 2.5, is
`FIELDNAME:', as shown here:

     struct point p = { y: yvalue, x: xvalue };

   The `[INDEX]' or `.FIELDNAME' is known as a "designator".  You can
also use a designator (or the obsolete colon syntax) when initializing
a union, to specify which element of the union should be used.  For
example,

     union foo { int i; double d; };
     
     union foo f = { .d = 4 };

will convert 4 to a `double' to store it in the union using the second
element.  By contrast, casting 4 to type `union foo' would store it
into the union as the integer `i', since it is an integer.  (*Note Cast
to Union::.)

   You can combine this technique of naming elements with ordinary C
initialization of successive elements.  Each initializer element that
does not have a designator applies to the next consecutive element of
the array or structure.  For example,

     int a[6] = { [1] = v1, v2, [4] = v4 };

is equivalent to

     int a[6] = { 0, v1, v2, 0, v4, 0 };

   Labeling the elements of an array initializer is especially useful
when the indices are characters or belong to an `enum' type.  For
example:

     int whitespace[256]
       = { [' '] = 1, ['\t'] = 1, ['\h'] = 1,
           ['\f'] = 1, ['\n'] = 1, ['\r'] = 1 };

   You can also write a series of `.FIELDNAME' and `[INDEX]'
designators before an `=' to specify a nested subobject to initialize;
the list is taken relative to the subobject corresponding to the
closest surrounding brace pair.  For example, with the `struct point'
declaration above:

     struct point ptarray[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };

If the same field is initialized multiple times, it will have value from
the last initialization.  If any such overridden initialization has
side-effect, it is unspecified whether the side-effect happens or not.
Currently, gcc will discard them and issue a warning.


File: gcc.info,  Node: Case Ranges,  Next: Mixed Declarations,  Prev: Cast to Union,  Up: C Extensions

Case Ranges
===========

   You can specify a range of consecutive values in a single `case'
label, like this:

     case LOW ... HIGH:

This has the same effect as the proper number of individual `case'
labels, one for each integer value from LOW to HIGH, inclusive.

   This feature is especially useful for ranges of ASCII character
codes:

     case 'A' ... 'Z':

   *Be careful:* Write spaces around the `...', for otherwise it may be
parsed wrong when you use it with integer values.  For example, write
this:

     case 1 ... 5:

rather than this:

     case 1...5:


File: gcc.info,  Node: Cast to Union,  Next: Case Ranges,  Prev: Designated Inits,  Up: C Extensions

Cast to a Union Type
====================

   A cast to union type is similar to other casts, except that the type
specified is a union type.  You can specify the type either with `union
TAG' or with a typedef name.  A cast to union is actually a constructor
though, not a cast, and hence does not yield an lvalue like normal
casts.  (*Note Compound Literals::.)

   The types that may be cast to the union type are those of the members
of the union.  Thus, given the following union and variables:

     union foo { int i; double d; };
     int x;
     double y;

both `x' and `y' can be cast to type `union foo'.

   Using the cast as the right-hand side of an assignment to a variable
of union type is equivalent to storing in a member of the union:

     union foo u;
     ...
     u = (union foo) x  ==  u.i = x
     u = (union foo) y  ==  u.d = y

   You can also use the union cast as a function argument:

     void hack (union foo);
     ...
     hack ((union foo) x);


File: gcc.info,  Node: Mixed Declarations,  Next: Function Attributes,  Prev: Case Ranges,  Up: C Extensions

Mixed Declarations and Code
===========================

   ISO C99 and ISO C++ allow declarations and code to be freely mixed
within compound statements.  As an extension, GCC also allows this in
C89 mode.  For example, you could do:

     int i;
     ...
     i++;
     int j = i + 2;

   Each identifier is visible from where it is declared until the end of
the enclosing block.


File: gcc.info,  Node: Function Attributes,  Next: Attribute Syntax,  Prev: Mixed Declarations,  Up: C Extensions

Declaring Attributes of Functions
=================================

   In GNU C, you declare certain things about functions called in your
program which help the compiler optimize function calls and check your
code more carefully.

   The keyword `__attribute__' allows you to specify special attributes
when making a declaration.  This keyword is followed by an attribute
specification inside double parentheses.  Fourteen attributes,
`noreturn', `pure', `const', `format', `format_arg',
`no_instrument_function', `section', `constructor', `destructor',
`unused', `weak', `malloc', `alias' and `no_check_memory_usage' are
currently defined for functions.  Several other attributes are defined
for functions on particular target systems.  Other attributes, including
`section' are supported for variables declarations (*note Variable
Attributes::) and for types (*note Type Attributes::).

   You may also specify attributes with `__' preceding and following
each keyword.  This allows you to use them in header files without
being concerned about a possible macro of the same name.  For example,
you may use `__noreturn__' instead of `noreturn'.

   *Note Attribute Syntax::, for details of the exact syntax for using
attributes.

`noreturn'
     A few standard library functions, such as `abort' and `exit',
     cannot return.  GCC knows this automatically.  Some programs define
     their own functions that never return.  You can declare them
     `noreturn' to tell the compiler this fact.  For example,

          void fatal () __attribute__ ((noreturn));
          
          void
          fatal (...)
          {
            ... /* Print error message. */ ...
            exit (1);
          }

     The `noreturn' keyword tells the compiler to assume that `fatal'
     cannot return.  It can then optimize without regard to what would
     happen if `fatal' ever did return.  This makes slightly better
     code.  More importantly, it helps avoid spurious warnings of
     uninitialized variables.

     Do not assume that registers saved by the calling function are
     restored before calling the `noreturn' function.

     It does not make sense for a `noreturn' function to have a return
     type other than `void'.

     The attribute `noreturn' is not implemented in GCC versions
     earlier than 2.5.  An alternative way to declare that a function
     does not return, which works in the current version and in some
     older versions, is as follows:

          typedef void voidfn ();
          
          volatile voidfn fatal;

`pure'
     Many functions have no effects except the return value and their
     return value depends only on the parameters and/or global
     variables.  Such a function can be subject to common subexpression
     elimination and loop optimization just as an arithmetic operator
     would be.  These functions should be declared with the attribute
     `pure'.  For example,

          int square (int) __attribute__ ((pure));

     says that the hypothetical function `square' is safe to call fewer
     times than the program says.

     Some of common examples of pure functions are `strlen' or `memcmp'.
     Interesting non-pure functions are functions with infinite loops
     or those depending on volatile memory or other system resource,
     that may change between two consecutive calls (such as `feof' in a
     multithreading environment).

     The attribute `pure' is not implemented in GCC versions earlier
     than 2.96.

`const'
     Many functions do not examine any values except their arguments,
     and have no effects except the return value.  Basically this is
     just slightly more strict class than the `pure' attribute above,
     since function is not allowed to read global memory.

     Note that a function that has pointer arguments and examines the
     data pointed to must _not_ be declared `const'.  Likewise, a
     function that calls a non-`const' function usually must not be
     `const'.  It does not make sense for a `const' function to return
     `void'.

     The attribute `const' is not implemented in GCC versions earlier
     than 2.5.  An alternative way to declare that a function has no
     side effects, which works in the current version and in some older
     versions, is as follows:

          typedef int intfn ();
          
          extern const intfn square;

     This approach does not work in GNU C++ from 2.6.0 on, since the
     language specifies that the `const' must be attached to the return
     value.

`format (ARCHETYPE, STRING-INDEX, FIRST-TO-CHECK)'
     The `format' attribute specifies that a function takes `printf',
     `scanf', `strftime' or `strfmon' style arguments which should be
     type-checked against a format string.  For example, the
     declaration:

          extern int
          my_printf (void *my_object, const char *my_format, ...)
                __attribute__ ((format (printf, 2, 3)));

     causes the compiler to check the arguments in calls to `my_printf'
     for consistency with the `printf' style format string argument
     `my_format'.

     The parameter ARCHETYPE determines how the format string is
     interpreted, and should be `printf', `scanf', `strftime' or
     `strfmon'.  (You can also use `__printf__', `__scanf__',
     `__strftime__' or `__strfmon__'.)  The parameter STRING-INDEX
     specifies which argument is the format string argument (starting
     from 1), while FIRST-TO-CHECK is the number of the first argument
     to check against the format string.  For functions where the
     arguments are not available to be checked (such as `vprintf'),
     specify the third parameter as zero.  In this case the compiler
     only checks the format string for consistency.  For `strftime'
     formats, the third parameter is required to be zero.

     In the example above, the format string (`my_format') is the second
     argument of the function `my_print', and the arguments to check
     start with the third argument, so the correct parameters for the
     format attribute are 2 and 3.

     The `format' attribute allows you to identify your own functions
     which take format strings as arguments, so that GCC can check the
     calls to these functions for errors.  The compiler always (unless
     `-ffreestanding' is used) checks formats for the standard library
     functions `printf', `fprintf', `sprintf', `scanf', `fscanf',
     `sscanf', `strftime', `vprintf', `vfprintf' and `vsprintf'
     whenever such warnings are requested (using `-Wformat'), so there
     is no need to modify the header file `stdio.h'.  In C99 mode, the
     functions `snprintf', `vsnprintf', `vscanf', `vfscanf' and
     `vsscanf' are also checked.  Except in strictly conforming C
     standard modes, the X/Open function `strfmon' is also checked.
     *Note Options Controlling C Dialect: C Dialect Options.

`format_arg (STRING-INDEX)'
     The `format_arg' attribute specifies that a function takes a format
     string for a `printf', `scanf', `strftime' or `strfmon' style
     function and modifies it (for example, to translate it into
     another language), so the result can be passed to a `printf',
     `scanf', `strftime' or `strfmon' style function (with the
     remaining arguments to the format function the same as they would
     have been for the unmodified string).  For example, the
     declaration:

          extern char *
          my_dgettext (char *my_domain, const char *my_format)
                __attribute__ ((format_arg (2)));

     causes the compiler to check the arguments in calls to a `printf',
     `scanf', `strftime' or `strfmon' type function, whose format
     string argument is a call to the `my_dgettext' function, for
     consistency with the format string argument `my_format'.  If the
     `format_arg' attribute had not been specified, all the compiler
     could tell in such calls to format functions would be that the
     format string argument is not constant; this would generate a
     warning when `-Wformat-nonliteral' is used, but the calls could
     not be checked without the attribute.

     The parameter STRING-INDEX specifies which argument is the format
     string argument (starting from 1).

     The `format-arg' attribute allows you to identify your own
     functions which modify format strings, so that GCC can check the
     calls to `printf', `scanf', `strftime' or `strfmon' type function
     whose operands are a call to one of your own function.  The
     compiler always treats `gettext', `dgettext', and `dcgettext' in
     this manner except when strict ISO C support is requested by
     `-ansi' or an appropriate `-std' option, or `-ffreestanding' is
     used.  *Note Options Controlling C Dialect: C Dialect Options.

`no_instrument_function'
     If `-finstrument-functions' is given, profiling function calls will
     be generated at entry and exit of most user-compiled functions.
     Functions with this attribute will not be so instrumented.

`section ("SECTION-NAME")'
     Normally, the compiler places the code it generates in the `text'
     section.  Sometimes, however, you need additional sections, or you
     need certain particular functions to appear in special sections.
     The `section' attribute specifies that a function lives in a
     particular section.  For example, the declaration:

          extern void foobar (void) __attribute__ ((section ("bar")));

     puts the function `foobar' in the `bar' section.

     Some file formats do not support arbitrary sections so the
     `section' attribute is not available on all platforms.  If you
     need to map the entire contents of a module to a particular
     section, consider using the facilities of the linker instead.

`constructor'
`destructor'
     The `constructor' attribute causes the function to be called
     automatically before execution enters `main ()'.  Similarly, the
     `destructor' attribute causes the function to be called
     automatically after `main ()' has completed or `exit ()' has been
     called.  Functions with these attributes are useful for
     initializing data that will be used implicitly during the
     execution of the program.

     These attributes are not currently implemented for Objective C.

`unused'
     This attribute, attached to a function, means that the function is
     meant to be possibly unused.  GCC will not produce a warning for
     this function.  GNU C++ does not currently support this attribute
     as definitions without parameters are valid in C++.

`weak'
     The `weak' attribute causes the declaration to be emitted as a weak
     symbol rather than a global.  This is primarily useful in defining
     library functions which can be overridden in user code, though it
     can also be used with non-function declarations.  Weak symbols are
     supported for ELF targets, and also for a.out targets when using
     the GNU assembler and linker.

`malloc'
     The `malloc' attribute is used to tell the compiler that a function
     may be treated as if it were the malloc function.  The compiler
     assumes that calls to malloc result in a pointers that cannot
     alias anything.  This will often improve optimization.

`alias ("TARGET")'
     The `alias' attribute causes the declaration to be emitted as an
     alias for another symbol, which must be specified.  For instance,

          void __f () { /* do something */; }
          void f () __attribute__ ((weak, alias ("__f")));

     declares `f' to be a weak alias for `__f'.  In C++, the mangled
     name for the target must be used.

     Not all target machines support this attribute.

`no_check_memory_usage'
     The `no_check_memory_usage' attribute causes GCC to omit checks of
     memory references when it generates code for that function.
     Normally if you specify `-fcheck-memory-usage' (see *note Code Gen
     Options::), GCC generates calls to support routines before most
     memory accesses to permit support code to record usage and detect
     uses of uninitialized or unallocated storage.  Since GCC cannot
     handle `asm' statements properly they are not allowed in such
     functions.  If you declare a function with this attribute, GCC
     will not generate memory checking code for that function,
     permitting the use of `asm' statements without having to compile
     that function with different options.  This also allows you to
     write support routines of your own if you wish, without getting
     infinite recursion if they get compiled with
     `-fcheck-memory-usage'.

`regparm (NUMBER)'
     On the Intel 386, the `regparm' attribute causes the compiler to
     pass up to NUMBER integer arguments in registers EAX, EDX, and ECX
     instead of on the stack.  Functions that take a variable number of
     arguments will continue to be passed all of their arguments on the
     stack.

`stdcall'
     On the Intel 386, the `stdcall' attribute causes the compiler to
     assume that the called function will pop off the stack space used
     to pass arguments, unless it takes a variable number of arguments.

     The PowerPC compiler for Windows NT currently ignores the `stdcall'
     attribute.

`cdecl'
     On the Intel 386, the `cdecl' attribute causes the compiler to
     assume that the calling function will pop off the stack space used
     to pass arguments.  This is useful to override the effects of the
     `-mrtd' switch.

     The PowerPC compiler for Windows NT currently ignores the `cdecl'
     attribute.

`longcall'
     On the RS/6000 and PowerPC, the `longcall' attribute causes the
     compiler to always call the function via a pointer, so that
     functions which reside further than 64 megabytes (67,108,864
     bytes) from the current location can be called.

`long_call/short_call'
     This attribute allows to specify how to call a particular function
     on ARM.  Both attributes override the `-mlong-calls' (*note ARM
     Options::) command line switch and `#pragma long_calls' settings.
     The `long_call' attribute causes the compiler to always call the
     function by first loading its address into a register and then
     using the contents of that register.   The `short_call' attribute
     always places the offset to the function from the call site into
     the `BL' instruction directly.

`dllimport'
     On the PowerPC running Windows NT, the `dllimport' attribute causes
     the compiler to call the function via a global pointer to the
     function pointer that is set up by the Windows NT dll library.
     The pointer name is formed by combining `__imp_' and the function
     name.

`dllexport'
     On the PowerPC running Windows NT, the `dllexport' attribute causes
     the compiler to provide a global pointer to the function pointer,
     so that it can be called with the `dllimport' attribute.  The
     pointer name is formed by combining `__imp_' and the function name.

`exception (EXCEPT-FUNC [, EXCEPT-ARG])'
     On the PowerPC running Windows NT, the `exception' attribute causes
     the compiler to modify the structured exception table entry it
     emits for the declared function.  The string or identifier
     EXCEPT-FUNC is placed in the third entry of the structured
     exception table.  It represents a function, which is called by the
     exception handling mechanism if an exception occurs.  If it was
     specified, the string or identifier EXCEPT-ARG is placed in the
     fourth entry of the structured exception table.

`function_vector'
     Use this option on the H8/300 and H8/300H to indicate that the
     specified function should be called through the function vector.
     Calling a function through the function vector will reduce code
     size, however; the function vector has a limited size (maximum 128
     entries on the H8/300 and 64 entries on the H8/300H) and shares
     space with the interrupt vector.

     You must use GAS and GLD from GNU binutils version 2.7 or later for
     this option to work correctly.

`interrupt'
     Use this option on the ARM, AVR and M32R/D ports to indicate that
     the specified function is an interrupt handler.  The compiler will
     generate function entry and exit sequences suitable for use in an
     interrupt handler when this attribute is present.

     Note, interrupt handlers for the H8/300, H8/300H and SH processors
     can be specified via the `interrupt_handler' attribute.

     Note, on the AVR interrupts will be enabled inside the function.

     Note, for the ARM you can specify the kind of interrupt to be
     handled by adding an optional parameter to the interrupt attribute
     like this:

          void f () __attribute__ ((interrupt ("IRQ")));

     Permissible values for this parameter are: IRQ, FIQ, SWI, ABORT
     and UNDEF.

`interrupt_handler'
     Use this option on the H8/300, H8/300H and SH to indicate that the
     specified function is an interrupt handler.  The compiler will
     generate function entry and exit sequences suitable for use in an
     interrupt handler when this attribute is present.

`sp_switch'
     Use this option on the SH to indicate an `interrupt_handler'
     function should switch to an alternate stack.  It expects a string
     argument that names a global variable holding the address of the
     alternate stack.

          void *alt_stack;
          void f () __attribute__ ((interrupt_handler,
                                    sp_switch ("alt_stack")));

`trap_exit'
     Use this option on the SH for an `interrupt_handle' to return using
     `trapa' instead of `rte'.  This attribute expects an integer
     argument specifying the trap number to be used.

`eightbit_data'
     Use this option on the H8/300 and H8/300H to indicate that the
     specified variable should be placed into the eight bit data
     section.  The compiler will generate more efficient code for
     certain operations on data in the eight bit data area.  Note the
     eight bit data area is limited to 256 bytes of data.

     You must use GAS and GLD from GNU binutils version 2.7 or later for
     this option to work correctly.

`tiny_data'
     Use this option on the H8/300H to indicate that the specified
     variable should be placed into the tiny data section.  The
     compiler will generate more efficient code for loads and stores on
     data in the tiny data section.  Note the tiny data area is limited
     to slightly under 32kbytes of data.

`signal'
     Use this option on the AVR to indicate that the specified function
     is an signal handler.  The compiler will generate function entry
     and exit sequences suitable for use in an signal handler when this
     attribute is present.  Interrupts will be disabled inside function.

`naked'
     Use this option on the ARM or AVR ports to indicate that the
     specified function do not need prologue/epilogue sequences
     generated by the compiler.  It is up to the programmer to provide
     these sequences.

`model (MODEL-NAME)'
     Use this attribute on the M32R/D to set the addressability of an
     object, and the code generated for a function.  The identifier
     MODEL-NAME is one of `small', `medium', or `large', representing
     each of the code models.

     Small model objects live in the lower 16MB of memory (so that their
     addresses can be loaded with the `ld24' instruction), and are
     callable with the `bl' instruction.

     Medium model objects may live anywhere in the 32-bit address space
     (the compiler will generate `seth/add3' instructions to load their
     addresses), and are callable with the `bl' instruction.

     Large model objects may live anywhere in the 32-bit address space
     (the compiler will generate `seth/add3' instructions to load their
     addresses), and may not be reachable with the `bl' instruction
     (the compiler will generate the much slower `seth/add3/jl'
     instruction sequence).

   You can specify multiple attributes in a declaration by separating
them by commas within the double parentheses or by immediately
following an attribute declaration with another attribute declaration.

   Some people object to the `__attribute__' feature, suggesting that
ISO C's `#pragma' should be used instead.  At the time `__attribute__'
was designed, there were two reasons for not doing this.

  1. It is impossible to generate `#pragma' commands from a macro.

  2. There is no telling what the same `#pragma' might mean in another
     compiler.

   These two reasons applied to almost any application that might have
been proposed for `#pragma'.  It was basically a mistake to use
`#pragma' for _anything_.

   The ISO C99 standard includes `_Pragma', which now allows pragmas to
be generated from macros.  In addition, a `#pragma GCC' namespace is
now in use for GCC-specific pragmas.  However, it has been found
convenient to use `__attribute__' to achieve a natural attachment of
attributes to their corresponding declarations, whereas `#pragma GCC'
is of use for constructs that do not naturally form part of the
grammar.  *Note Miscellaneous Preprocessing Directives: (cpp)Other
Directives.


File: gcc.info,  Node: Attribute Syntax,  Next: Function Prototypes,  Prev: Function Attributes,  Up: C Extensions

Attribute Syntax
================

   This section describes the syntax with which `__attribute__' may be
used, and the constructs to which attribute specifiers bind, for the C
language.  Some details may vary for C++ and Objective C.  Because of
infelicities in the grammar for attributes, some forms described here
may not be successfully parsed in all cases.

   *Note Function Attributes::, for details of the semantics of
attributes applying to functions.  *Note Variable Attributes::, for
details of the semantics of attributes applying to variables.  *Note
Type Attributes::, for details of the semantics of attributes applying
to structure, union and enumerated types.

   An "attribute specifier" is of the form `__attribute__
((ATTRIBUTE-LIST))'.  An "attribute list" is a possibly empty
comma-separated sequence of "attributes", where each attribute is one
of the following:

   * Empty.  Empty attributes are ignored.

   * A word (which may be an identifier such as `unused', or a reserved
     word such as `const').

   * A word, followed by, in parentheses, parameters for the attribute.
     These parameters take one of the following forms:

        * An identifier.  For example, `mode' attributes use this form.

        * An identifier followed by a comma and a non-empty
          comma-separated list of expressions.  For example, `format'
          attributes use this form.

        * A possibly empty comma-separated list of expressions.  For
          example, `format_arg' attributes use this form with the list
          being a single integer constant expression, and `alias'
          attributes use this form with the list being a single string
          constant.

   An "attribute specifier list" is a sequence of one or more attribute
specifiers, not separated by any other tokens.

   An attribute specifier list may appear after the colon following a
label, other than a `case' or `default' label.  The only attribute it
makes sense to use after a label is `unused'.  This feature is intended
for code generated by programs which contains labels that may be unused
but which is compiled with `-Wall'.  It would not normally be
appropriate to use in it human-written code, though it could be useful
in cases where the code that jumps to the label is contained within an
`#ifdef' conditional.

   An attribute specifier list may appear as part of a `struct',
`union' or `enum' specifier.  It may go either immediately after the
`struct', `union' or `enum' keyword, or after the closing brace.  It is
ignored if the content of the structure, union or enumerated type is
not defined in the specifier in which the attribute specifier list is
used--that is, in usages such as `struct __attribute__((foo)) bar' with
no following opening brace.  Where attribute specifiers follow the
closing brace, they are considered to relate to the structure, union or
enumerated type defined, not to any enclosing declaration the type
specifier appears in, and the type defined is not complete until after
the attribute specifiers.

   Otherwise, an attribute specifier appears as part of a declaration,
counting declarations of unnamed parameters and type names, and relates
to that declaration (which may be nested in another declaration, for
example in the case of a parameter declaration).  In future, attribute
specifiers in some places may however apply to a particular declarator
within a declaration instead; these cases are noted below.  Where an
attribute specifier is applied to a parameter declared as a function or
an array, it should apply to the function or array rather than the
pointer to which the parameter is implicitly converted, but this is not
yet correctly implemented.

   Any list of specifiers and qualifiers at the start of a declaration
may contain attribute specifiers, whether or not such a list may in that
context contain storage class specifiers.  (Some attributes, however,
are essentially in the nature of storage class specifiers, and only make
sense where storage class specifiers may be used; for example,
`section'.)  There is one necessary limitation to this syntax: the
first old-style parameter declaration in a function definition cannot
begin with an attribute specifier, because such an attribute applies to
the function instead by syntax described below (which, however, is not
yet implemented in this case).  In some other cases, attribute
specifiers are permitted by this grammar but not yet supported by the
compiler.  All attribute specifiers in this place relate to the
declaration as a whole.  In the obsolescent usage where a type of `int'
is implied by the absence of type specifiers, such a list of specifiers
and qualifiers may be an attribute specifier list with no other
specifiers or qualifiers.

   An attribute specifier list may appear immediately before a
declarator (other than the first) in a comma-separated list of
declarators in a declaration of more than one identifier using a single
list of specifiers and qualifiers.  At present, such attribute
specifiers apply not only to the identifier before whose declarator
they appear, but to all subsequent identifiers declared in that
declaration, but in future they may apply only to that single
identifier.  For example, in `__attribute__((noreturn)) void d0 (void),
__attribute__((format(printf, 1, 2))) d1 (const char *, ...), d2
(void)', the `noreturn' attribute applies to all the functions
declared; the `format' attribute should only apply to `d1', but at
present applies to `d2' as well (and so causes an error).

   An attribute specifier list may appear immediately before the comma,
`=' or semicolon terminating the declaration of an identifier other
than a function definition.  At present, such attribute specifiers apply
to the declared object or function, but in future they may attach to the
outermost adjacent declarator.  In simple cases there is no difference,
but, for example, in `void (****f)(void) __attribute__((noreturn));',
at present the `noreturn' attribute applies to `f', which causes a
warning since `f' is not a function, but in future it may apply to the
function `****f'.  The precise semantics of what attributes in such
cases will apply to are not yet specified.  Where an assembler name for
an object or function is specified (*note Asm Labels::), at present the
attribute must follow the `asm' specification; in future, attributes
before the `asm' specification may apply to the adjacent declarator,
and those after it to the declared object or function.

   An attribute specifier list may, in future, be permitted to appear
after the declarator in a function definition (before any old-style
parameter declarations or the function body).

   An attribute specifier list may appear at the start of a nested
declarator.  At present, there are some limitations in this usage: the
attributes apply to the identifier declared, and to all subsequent
identifiers declared in that declaration (if it includes a
comma-separated list of declarators), rather than to a specific
declarator.  When attribute specifiers follow the `*' of a pointer
declarator, they must presently follow any type qualifiers present, and
cannot be mixed with them.  The following describes intended future
semantics which make this syntax more useful only.  It will make the
most sense if you are familiar with the formal specification of
declarators in the ISO C standard.

   Consider (as in C99 subclause 6.7.5 paragraph 4) a declaration `T
D1', where `T' contains declaration specifiers that specify a type TYPE
(such as `int') and `D1' is a declarator that contains an identifier
IDENT.  The type specified for IDENT for derived declarators whose type
does not include an attribute specifier is as in the ISO C standard.

   If `D1' has the form `( ATTRIBUTE-SPECIFIER-LIST D )', and the
declaration `T D' specifies the type "DERIVED-DECLARATOR-TYPE-LIST
TYPE" for IDENT, then `T D1' specifies the type
"DERIVED-DECLARATOR-TYPE-LIST ATTRIBUTE-SPECIFIER-LIST TYPE" for IDENT.

   If `D1' has the form `* TYPE-QUALIFIER-AND-ATTRIBUTE-SPECIFIER-LIST
D', and the declaration `T D' specifies the type
"DERIVED-DECLARATOR-TYPE-LIST TYPE" for IDENT, then `T D1' specifies
the type "DERIVED-DECLARATOR-TYPE-LIST
TYPE-QUALIFIER-AND-ATTRIBUTE-SPECIFIER-LIST TYPE" for IDENT.

   For example, `void (__attribute__((noreturn)) ****f)();' specifies
the type "pointer to pointer to pointer to pointer to non-returning
function returning `void'".  As another example, `char
*__attribute__((aligned(8))) *f;' specifies the type "pointer to
8-byte-aligned pointer to `char'".  Note again that this describes
intended future semantics, not current implementation.


File: gcc.info,  Node: Function Prototypes,  Next: C++ Comments,  Prev: Attribute Syntax,  Up: C Extensions

Prototypes and Old-Style Function Definitions
=============================================

   GNU C extends ISO C to allow a function prototype to override a later
old-style non-prototype definition.  Consider the following example:

     /* Use prototypes unless the compiler is old-fashioned.  */
     #ifdef __STDC__
     #define P(x) x
     #else
     #define P(x) ()
     #endif
     
     /* Prototype function declaration.  */
     int isroot P((uid_t));
     
     /* Old-style function definition.  */
     int
     isroot (x)   /* ??? lossage here ??? */
          uid_t x;
     {
       return x == 0;
     }

   Suppose the type `uid_t' happens to be `short'.  ISO C does not
allow this example, because subword arguments in old-style
non-prototype definitions are promoted.  Therefore in this example the
function definition's argument is really an `int', which does not match
the prototype argument type of `short'.

   This restriction of ISO C makes it hard to write code that is
portable to traditional C compilers, because the programmer does not
know whether the `uid_t' type is `short', `int', or `long'.  Therefore,
in cases like these GNU C allows a prototype to override a later
old-style definition.  More precisely, in GNU C, a function prototype
argument type overrides the argument type specified by a later
old-style definition if the former type is the same as the latter type
before promotion.  Thus in GNU C the above example is equivalent to the
following:

     int isroot (uid_t);
     
     int
     isroot (uid_t x)
     {
       return x == 0;
     }

   GNU C++ does not support old-style function definitions, so this
extension is irrelevant.


File: gcc.info,  Node: C++ Comments,  Next: Dollar Signs,  Prev: Function Prototypes,  Up: C Extensions

C++ Style Comments
==================

   In GNU C, you may use C++ style comments, which start with `//' and
continue until the end of the line.  Many other C implementations allow
such comments, and they are likely to be in a future C standard.
However, C++ style comments are not recognized if you specify `-ansi',
a `-std' option specifying a version of ISO C before C99, or
`-traditional', since they are incompatible with traditional constructs
like `dividend//*comment*/divisor'.


File: gcc.info,  Node: Dollar Signs,  Next: Character Escapes,  Prev: C++ Comments,  Up: C Extensions

Dollar Signs in Identifier Names
================================

   In GNU C, you may normally use dollar signs in identifier names.
This is because many traditional C implementations allow such
identifiers.  However, dollar signs in identifiers are not supported on
a few target machines, typically because the target assembler does not
allow them.


File: gcc.info,  Node: Character Escapes,  Next: Variable Attributes,  Prev: Dollar Signs,  Up: C Extensions

The Character <ESC> in Constants
================================

   You can use the sequence `\e' in a string or character constant to
stand for the ASCII character <ESC>.


File: gcc.info,  Node: Alignment,  Next: Inline,  Prev: Type Attributes,  Up: C Extensions

Inquiring on Alignment of Types or Variables
============================================

   The keyword `__alignof__' allows you to inquire about how an object
is aligned, or the minimum alignment usually required by a type.  Its
syntax is just like `sizeof'.

   For example, if the target machine requires a `double' value to be
aligned on an 8-byte boundary, then `__alignof__ (double)' is 8.  This
is true on many RISC machines.  On more traditional machine designs,
`__alignof__ (double)' is 4 or even 2.

   Some machines never actually require alignment; they allow reference
to any data type even at an odd addresses.  For these machines,
`__alignof__' reports the _recommended_ alignment of a type.

   When the operand of `__alignof__' is an lvalue rather than a type,
the value is the largest alignment that the lvalue is known to have.
It may have this alignment as a result of its data type, or because it
is part of a structure and inherits alignment from that structure.  For
example, after this declaration:

     struct foo { int x; char y; } foo1;

the value of `__alignof__ (foo1.y)' is probably 2 or 4, the same as
`__alignof__ (int)', even though the data type of `foo1.y' does not
itself demand any alignment.

   It is an error to ask for the alignment of an incomplete type.

   A related feature which lets you specify the alignment of an object
is `__attribute__ ((aligned (ALIGNMENT)))'; see the following section.

