This is doc/gcc.info, produced by makeinfo version 4.0b 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: 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.

   There are some problems with the semantics of attributes in C++.  For
example, there are no manglings for attributes, although they may affect
code generation, so problems may arise when attributed types are used in
conjunction with templates or overloading.  Similarly, `typeid' does
not distinguish between types with different attributes.  Support for
attributes in C++ may be restricted in future to attributes on
declarations only, but not on nested declarators.

   *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), or to a particular
declarator within a declaration.  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.  Such attribute specifiers apply
only to the identifier before whose declarator they appear.  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 only applies to `d1'.

   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).

   Attribute specifiers may be mixed with type qualifiers appearing
inside the `[]' of a parameter array declarator, in the C99 construct by
which such qualifiers are applied to the pointer to which the array is
implicitly converted.  Such attribute specifiers apply to the pointer,
not to the array, but at present this is not implemented and they are
ignored.

   An attribute specifier list may appear at the start of a nested
declarator.  At present, there are some limitations in this usage: the
attributes correctly apply to the declarator, but for most individual
attributes the semantics this implies are not implemented.  When
attribute specifiers follow the `*' of a pointer declarator, they may
be mixed with any type qualifiers present.  The following describes the
formal semantics of this syntax.  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) (void);

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 does not work with most attributes; for example, the
usage of `aligned' and `noreturn' attributes given above is not yet
supported.

   For compatibility with existing code written for compiler versions
that did not implement attributes on nested declarators, some laxity is
allowed in the placing of attributes.  If an attribute that only applies
to types is applied to a declaration, it will be treated as applying to
the type of that declaration.  If an attribute that only applies to
declarations is applied to the type of a declaration, it will be treated
as applying to that declaration; and, for compatibility with code
placing the attributes immediately before the identifier declared, such
an attribute applied to a function return type will be treated as
applying to the function type, and such an attribute applied to an array
element type will be treated as applying to the array type.  If an
attribute that only applies to function types is applied to a
pointer-to-function type, it will be treated as applying to the pointer
target type; if such an attribute is applied to a function return type
that is not a pointer-to-function type, it will be treated as applying
to the function type.


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.


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

Specifying Attributes of Variables
==================================

   The keyword `__attribute__' allows you to specify special attributes
of variables or structure fields.  This keyword is followed by an
attribute specification inside double parentheses.  Eight attributes
are currently defined for variables: `aligned', `mode', `nocommon',
`packed', `section', `transparent_union', `unused', and `weak'.  Some
other attributes are defined for variables on particular target
systems.  Other attributes are available for functions (*note Function
Attributes::) and for types (*note Type Attributes::).  Other front
ends might define more attributes (*note Extensions to the C++
Language: C++ Extensions.).

   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 `__aligned__' instead of `aligned'.

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

`aligned (ALIGNMENT)'
     This attribute specifies a minimum alignment for the variable or
     structure field, measured in bytes.  For example, the declaration:

          int x __attribute__ ((aligned (16))) = 0;

     causes the compiler to allocate the global variable `x' on a
     16-byte boundary.  On a 68040, this could be used in conjunction
     with an `asm' expression to access the `move16' instruction which
     requires 16-byte aligned operands.

     You can also specify the alignment of structure fields.  For
     example, to create a double-word aligned `int' pair, you could
     write:

          struct foo { int x[2] __attribute__ ((aligned (8))); };

     This is an alternative to creating a union with a `double' member
     that forces the union to be double-word aligned.

     It is not possible to specify the alignment of functions; the
     alignment of functions is determined by the machine's requirements
     and cannot be changed.  You cannot specify alignment for a typedef
     name because such a name is just an alias, not a distinct type.

     As in the preceding examples, you can explicitly specify the
     alignment (in bytes) that you wish the compiler to use for a given
     variable or structure field.  Alternatively, you can leave out the
     alignment factor and just ask the compiler to align a variable or
     field to the maximum useful alignment for the target machine you
     are compiling for.  For example, you could write:

          short array[3] __attribute__ ((aligned));

     Whenever you leave out the alignment factor in an `aligned'
     attribute specification, the compiler automatically sets the
     alignment for the declared variable or field to the largest
     alignment which is ever used for any data type on the target
     machine you are compiling for.  Doing this can often make copy
     operations more efficient, because the compiler can use whatever
     instructions copy the biggest chunks of memory when performing
     copies to or from the variables or fields that you have aligned
     this way.

     The `aligned' attribute can only increase the alignment; but you
     can decrease it by specifying `packed' as well.  See below.

     Note that the effectiveness of `aligned' attributes may be limited
     by inherent limitations in your linker.  On many systems, the
     linker is only able to arrange for variables to be aligned up to a
     certain maximum alignment.  (For some linkers, the maximum
     supported alignment may be very very small.)  If your linker is
     only able to align variables up to a maximum of 8 byte alignment,
     then specifying `aligned(16)' in an `__attribute__' will still
     only provide you with 8 byte alignment.  See your linker
     documentation for further information.

`mode (MODE)'
     This attribute specifies the data type for the
     declaration--whichever type corresponds to the mode MODE.  This in
     effect lets you request an integer or floating point type
     according to its width.

     You may also specify a mode of `byte' or `__byte__' to indicate
     the mode corresponding to a one-byte integer, `word' or `__word__'
     for the mode of a one-word integer, and `pointer' or `__pointer__'
     for the mode used to represent pointers.

`nocommon'
     This attribute specifies requests GCC not to place a variable
     "common" but instead to allocate space for it directly.  If you
     specify the `-fno-common' flag, GCC will do this for all variables.

     Specifying the `nocommon' attribute for a variable provides an
     initialization of zeros.  A variable may only be initialized in one
     source file.

`packed'
     The `packed' attribute specifies that a variable or structure field
     should have the smallest possible alignment--one byte for a
     variable, and one bit for a field, unless you specify a larger
     value with the `aligned' attribute.

     Here is a structure in which the field `x' is packed, so that it
     immediately follows `a':

          struct foo
          {
            char a;
            int x[2] __attribute__ ((packed));
          };

`section ("SECTION-NAME")'
     Normally, the compiler places the objects it generates in sections
     like `data' and `bss'.  Sometimes, however, you need additional
     sections, or you need certain particular variables to appear in
     special sections, for example to map to special hardware.  The
     `section' attribute specifies that a variable (or function) lives
     in a particular section.  For example, this small program uses
     several specific section names:

          struct duart a __attribute__ ((section ("DUART_A"))) = { 0 };
          struct duart b __attribute__ ((section ("DUART_B"))) = { 0 };
          char stack[10000] __attribute__ ((section ("STACK"))) = { 0 };
          int init_data __attribute__ ((section ("INITDATA"))) = 0;
          
          main()
          {
            /* Initialize stack pointer */
            init_sp (stack + sizeof (stack));
          
            /* Initialize initialized data */
            memcpy (&init_data, &data, &edata - &data);
          
            /* Turn on the serial ports */
            init_duart (&a);
            init_duart (&b);
          }

     Use the `section' attribute with an _initialized_ definition of a
     _global_ variable, as shown in the example.  GCC issues a warning
     and otherwise ignores the `section' attribute in uninitialized
     variable declarations.

     You may only use the `section' attribute with a fully initialized
     global definition because of the way linkers work.  The linker
     requires each object be defined once, with the exception that
     uninitialized variables tentatively go in the `common' (or `bss')
     section and can be multiply "defined".  You can force a variable
     to be initialized with the `-fno-common' flag or the `nocommon'
     attribute.

     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.

`shared'
     On Windows NT, in addition to putting variable definitions in a
     named section, the section can also be shared among all running
     copies of an executable or DLL.  For example, this small program
     defines shared data by putting it in a named section `shared' and
     marking the section shareable:

          int foo __attribute__((section ("shared"), shared)) = 0;
          
          int
          main()
          {
            /* Read and write foo.  All running
               copies see the same value.  */
            return 0;
          }

     You may only use the `shared' attribute along with `section'
     attribute with a fully initialized global definition because of
     the way linkers work.  See `section' attribute for more
     information.

     The `shared' attribute is only available on Windows NT.

`transparent_union'
     This attribute, attached to a function parameter which is a union,
     means that the corresponding argument may have the type of any
     union member, but the argument is passed as if its type were that
     of the first union member.  For more details see *Note Type
     Attributes::.  You can also use this attribute on a `typedef' for
     a union data type; then it applies to all function parameters with
     that type.

`unused'
     This attribute, attached to a variable, means that the variable is
     meant to be possibly unused.  GCC will not produce a warning for
     this variable.

`weak'
     The `weak' attribute is described in *Note Function Attributes::.

`model (MODEL-NAME)'
     Use this attribute on the M32R/D to set the addressability of an
     object.  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).

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

   To specify multiple attributes, separate them by commas within the
double parentheses: for example, `__attribute__ ((aligned (16),
packed))'.


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

Specifying Attributes of Types
==============================

   The keyword `__attribute__' allows you to specify special attributes
of `struct' and `union' types when you define such types.  This keyword
is followed by an attribute specification inside double parentheses.
Four attributes are currently defined for types: `aligned', `packed',
`transparent_union', and `unused'.  Other attributes are defined for
functions (*note Function Attributes::) and for variables (*note
Variable Attributes::).

   You may also specify any one of these attributes with `__' preceding
and following its keyword.  This allows you to use these attributes in
header files without being concerned about a possible macro of the same
name.  For example, you may use `__aligned__' instead of `aligned'.

   You may specify the `aligned' and `transparent_union' attributes
either in a `typedef' declaration or just past the closing curly brace
of a complete enum, struct or union type _definition_ and the `packed'
attribute only past the closing brace of a definition.

   You may also specify attributes between the enum, struct or union
tag and the name of the type rather than after the closing brace.

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

`aligned (ALIGNMENT)'
     This attribute specifies a minimum alignment (in bytes) for
     variables of the specified type.  For example, the declarations:

          struct S { short f[3]; } __attribute__ ((aligned (8)));
          typedef int more_aligned_int __attribute__ ((aligned (8)));

     force the compiler to insure (as far as it can) that each variable
     whose type is `struct S' or `more_aligned_int' will be allocated
     and aligned _at least_ on a 8-byte boundary.  On a Sparc, having
     all variables of type `struct S' aligned to 8-byte boundaries
     allows the compiler to use the `ldd' and `std' (doubleword load and
     store) instructions when copying one variable of type `struct S' to
     another, thus improving run-time efficiency.

     Note that the alignment of any given `struct' or `union' type is
     required by the ISO C standard to be at least a perfect multiple of
     the lowest common multiple of the alignments of all of the members
     of the `struct' or `union' in question.  This means that you _can_
     effectively adjust the alignment of a `struct' or `union' type by
     attaching an `aligned' attribute to any one of the members of such
     a type, but the notation illustrated in the example above is a
     more obvious, intuitive, and readable way to request the compiler
     to adjust the alignment of an entire `struct' or `union' type.

     As in the preceding example, you can explicitly specify the
     alignment (in bytes) that you wish the compiler to use for a given
     `struct' or `union' type.  Alternatively, you can leave out the
     alignment factor and just ask the compiler to align a type to the
     maximum useful alignment for the target machine you are compiling
     for.  For example, you could write:

          struct S { short f[3]; } __attribute__ ((aligned));

     Whenever you leave out the alignment factor in an `aligned'
     attribute specification, the compiler automatically sets the
     alignment for the type to the largest alignment which is ever used
     for any data type on the target machine you are compiling for.
     Doing this can often make copy operations more efficient, because
     the compiler can use whatever instructions copy the biggest chunks
     of memory when performing copies to or from the variables which
     have types that you have aligned this way.

     In the example above, if the size of each `short' is 2 bytes, then
     the size of the entire `struct S' type is 6 bytes.  The smallest
     power of two which is greater than or equal to that is 8, so the
     compiler sets the alignment for the entire `struct S' type to 8
     bytes.

     Note that although you can ask the compiler to select a
     time-efficient alignment for a given type and then declare only
     individual stand-alone objects of that type, the compiler's
     ability to select a time-efficient alignment is primarily useful
     only when you plan to create arrays of variables having the
     relevant (efficiently aligned) type.  If you declare or use arrays
     of variables of an efficiently-aligned type, then it is likely
     that your program will also be doing pointer arithmetic (or
     subscripting, which amounts to the same thing) on pointers to the
     relevant type, and the code that the compiler generates for these
     pointer arithmetic operations will often be more efficient for
     efficiently-aligned types than for other types.

     The `aligned' attribute can only increase the alignment; but you
     can decrease it by specifying `packed' as well.  See below.

     Note that the effectiveness of `aligned' attributes may be limited
     by inherent limitations in your linker.  On many systems, the
     linker is only able to arrange for variables to be aligned up to a
     certain maximum alignment.  (For some linkers, the maximum
     supported alignment may be very very small.)  If your linker is
     only able to align variables up to a maximum of 8 byte alignment,
     then specifying `aligned(16)' in an `__attribute__' will still
     only provide you with 8 byte alignment.  See your linker
     documentation for further information.

`packed'
     This attribute, attached to an `enum', `struct', or `union' type
     definition, specified that the minimum required memory be used to
     represent the type.

     Specifying this attribute for `struct' and `union' types is
     equivalent to specifying the `packed' attribute on each of the
     structure or union members.  Specifying the `-fshort-enums' flag
     on the line is equivalent to specifying the `packed' attribute on
     all `enum' definitions.

     You may only specify this attribute after a closing curly brace on
     an `enum' definition, not in a `typedef' declaration, unless that
     declaration also contains the definition of the `enum'.

`transparent_union'
     This attribute, attached to a `union' type definition, indicates
     that any function parameter having that union type causes calls to
     that function to be treated in a special way.

     First, the argument corresponding to a transparent union type can
     be of any type in the union; no cast is required.  Also, if the
     union contains a pointer type, the corresponding argument can be a
     null pointer constant or a void pointer expression; and if the
     union contains a void pointer type, the corresponding argument can
     be any pointer expression.  If the union member type is a pointer,
     qualifiers like `const' on the referenced type must be respected,
     just as with normal pointer conversions.

     Second, the argument is passed to the function using the calling
     conventions of first member of the transparent union, not the
     calling conventions of the union itself.  All members of the union
     must have the same machine representation; this is necessary for
     this argument passing to work properly.

     Transparent unions are designed for library functions that have
     multiple interfaces for compatibility reasons.  For example,
     suppose the `wait' function must accept either a value of type
     `int *' to comply with Posix, or a value of type `union wait *' to
     comply with the 4.1BSD interface.  If `wait''s parameter were
     `void *', `wait' would accept both kinds of arguments, but it
     would also accept any other pointer type and this would make
     argument type checking less useful.  Instead, `<sys/wait.h>' might
     define the interface as follows:

          typedef union
            {
              int *__ip;
              union wait *__up;
            } wait_status_ptr_t __attribute__ ((__transparent_union__));
          
          pid_t wait (wait_status_ptr_t);

     This interface allows either `int *' or `union wait *' arguments
     to be passed, using the `int *' calling convention.  The program
     can call `wait' with arguments of either type:

          int w1 () { int w; return wait (&w); }
          int w2 () { union wait w; return wait (&w); }

     With this interface, `wait''s implementation might look like this:

          pid_t wait (wait_status_ptr_t p)
          {
            return waitpid (-1, p.__ip, 0);
          }

`unused'
     When attached to a type (including a `union' or a `struct'), this
     attribute means that variables of that type are meant to appear
     possibly unused.  GCC will not produce a warning for any variables
     of that type, even if the variable appears to do nothing.  This is
     often the case with lock or thread classes, which are usually
     defined and then not referenced, but contain constructors and
     destructors that have nontrivial bookkeeping functions.

   To specify multiple attributes, separate them by commas within the
double parentheses: for example, `__attribute__ ((aligned (16),
packed))'.


File: gcc.info,  Node: Inline,  Next: Extended Asm,  Prev: Alignment,  Up: C Extensions

An Inline Function is As Fast As a Macro
========================================

   By declaring a function `inline', you can direct GCC to integrate
that function's code into the code for its callers.  This makes
execution faster by eliminating the function-call overhead; in
addition, if any of the actual argument values are constant, their known
values may permit simplifications at compile time so that not all of the
inline function's code needs to be included.  The effect on code size is
less predictable; object code may be larger or smaller with function
inlining, depending on the particular case.  Inlining of functions is an
optimization and it really "works" only in optimizing compilation.  If
you don't use `-O', no function is really inline.

   Inline functions are included in the ISO C99 standard, but there are
currently substantial differences between what GCC implements and what
the ISO C99 standard requires.

   To declare a function inline, use the `inline' keyword in its
declaration, like this:

     inline int
     inc (int *a)
     {
       (*a)++;
     }

   (If you are writing a header file to be included in ISO C programs,
write `__inline__' instead of `inline'.  *Note Alternate Keywords::.)
You can also make all "simple enough" functions inline with the option
`-finline-functions'.

   Note that certain usages in a function definition can make it
unsuitable for inline substitution.  Among these usages are: use of
varargs, use of alloca, use of variable sized data types (*note
Variable Length::), use of computed goto (*note Labels as Values::),
use of nonlocal goto, and nested functions (*note Nested Functions::).
Using `-Winline' will warn when a function marked `inline' could not be
substituted, and will give the reason for the failure.

   Note that in C and Objective-C, unlike C++, the `inline' keyword
does not affect the linkage of the function.

   GCC automatically inlines member functions defined within the class
body of C++ programs even if they are not explicitly declared `inline'.
(You can override this with `-fno-default-inline'; *note Options
Controlling C++ Dialect: C++ Dialect Options..)

   When a function is both inline and `static', if all calls to the
function are integrated into the caller, and the function's address is
never used, then the function's own assembler code is never referenced.
In this case, GCC does not actually output assembler code for the
function, unless you specify the option `-fkeep-inline-functions'.
Some calls cannot be integrated for various reasons (in particular,
calls that precede the function's definition cannot be integrated, and
neither can recursive calls within the definition).  If there is a
nonintegrated call, then the function is compiled to assembler code as
usual.  The function must also be compiled as usual if the program
refers to its address, because that can't be inlined.

   When an inline function is not `static', then the compiler must
assume that there may be calls from other source files; since a global
symbol can be defined only once in any program, the function must not
be defined in the other source files, so the calls therein cannot be
integrated.  Therefore, a non-`static' inline function is always
compiled on its own in the usual fashion.

   If you specify both `inline' and `extern' in the function
definition, then the definition is used only for inlining.  In no case
is the function compiled on its own, not even if you refer to its
address explicitly.  Such an address becomes an external reference, as
if you had only declared the function, and had not defined it.

   This combination of `inline' and `extern' has almost the effect of a
macro.  The way to use it is to put a function definition in a header
file with these keywords, and put another copy of the definition
(lacking `inline' and `extern') in a library file.  The definition in
the header file will cause most calls to the function to be inlined.
If any uses of the function remain, they will refer to the single copy
in the library.

   For future compatibility with when GCC implements ISO C99 semantics
for inline functions, it is best to use `static inline' only.  (The
existing semantics will remain available when `-std=gnu89' is
specified, but eventually the default will be `-std=gnu99' and that
will implement the C99 semantics, though it does not do so yet.)

   GCC does not inline any functions when not optimizing.  It is not
clear whether it is better to inline or not, in this case, but we found
that a correct implementation when not optimizing was difficult.  So we
did the easy thing, and turned it off.

