This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH 3/4] Docs: extend.texi: Rearrange nodes; no text was removed or added
- From: Michael Witten <mfwitten at gmail dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Wed, 27 Apr 2011 18:21:20 -0700 (PDT)
- Subject: [PATCH 3/4] Docs: extend.texi: Rearrange nodes; no text was removed or added
- References: <378e16b9-5d40-427c-8b4e-00700b2ad30c-mfwitten@gmail.com>
This patch places the following nodes together (after node
`Mixed Declarations') and in the following order:
Function Prototypes
Attribute Syntax
Type Attributes
Variable Attributes
Function Attributes
Currently, they are distributed and ordered in a way
that isn't particularly meaningful.
---
The following patch is admittedly difficult to verify given its length.
However, the same effect of applying this patch can be produced by running
the following commands on the results of the previous 2 patches (but see
the next set of commands for something that is perhaps even more readily
verifiable):
#!/bin/sh
cd trunk/gcc/doc
# Inspired by `e36freak' and `waldner' in `freenode/##sed'
cp_from_to() { awk <extend.texi >>/tmp/e "$2{if(p) exit} $1{p=1} p"; }
rm -rf /tmp/e &&
cp_from_to NR=1 '/^\* Mixed Declarations::/' &&
cp_from_to '/^\* Mixed Declarations::/' /^\*/ &&
cp_from_to '/^\* Function Prototypes::/' /^\*/ &&
cp_from_to '/^\* Attribute Syntax::/' /^\*/ &&
cp_from_to '/^\* Type Attributes::/' /^\*/ &&
cp_from_to '/^\* Variable Attributes::/' /^\*/ &&
cp_from_to '/^\* Function Attributes::/' /^\*/ &&
cp_from_to '/^\* C\+\+ Comments::/' /^\*/ &&
cp_from_to '/^\* Dollar Signs::/' /^\*/ &&
cp_from_to '/^\* Character Escapes::/' /^\*/ &&
cp_from_to '/^\* Alignment::/' '/^@node Mixed Declarations$/' &&
cp_from_to '/^@node Mixed Declarations$/' /^@node/ &&
cp_from_to '/^@node Function Prototypes$/' /^@node/ &&
cp_from_to '/^@node Attribute Syntax$/' /^@node/ &&
cp_from_to '/^@node Type Attributes$/' /^@node/ &&
cp_from_to '/^@node Variable Attributes$/' /^@node/ &&
cp_from_to '/^@node Function Attributes$/' /^@node/ &&
cp_from_to '/^@node C\+\+ Comments$/' /^@node/ &&
cp_from_to '/^@node Dollar Signs$/' /^@node/ &&
cp_from_to '/^@node Character Escapes$/' /^@node/ &&
cp_from_to '/^@node Alignment$/' END &&
mv -f /tmp/e extend.texi
Alternatively, the same effect of applying this patch can be produced by
running these commands on the results of the previous 2 patches:
#!/bin/sh
cd trunk/gcc/doc
# Print only the given address
copy_chunk() { sed <extend.texi >>/tmp/e -n "$1p"; }
rm -rf /tmp/e &&
copy_chunk 1,57 &&
copy_chunk 61 &&
copy_chunk 60 &&
copy_chunk 66 &&
copy_chunk 65 &&
copy_chunk 58,59 &&
copy_chunk 62,64 &&
copy_chunk 67,1900 &&
copy_chunk 4094,4152 &&
copy_chunk 3865,4093 &&
copy_chunk 4799,5190 &&
copy_chunk 4183,4798 &&
copy_chunk 1901,3864 &&
copy_chunk 4153,4182 &&
copy_chunk 5191,\$ &&
mv -f /tmp/e extend.texi
To show that nothing is omitted or duplicated, the line numbers that
appear in the commands can be listed in ascending order to show that
every single existing line is copied into the new file exactly once:
1,57
58,59
60
61
62,64
65
66
67,1900
1901,3864
3865,4093
4094,4152
4153,4182
4183,4798
4799,5190
5191,$
To show that only logical chunks of text were rearanged, the beginning
of each chunk can be inspected with the following command (the original
extend.texi, with [PATCH 2/4] applied, is used):
sed <extend.texi -n \
-e 1p \
-e 58p \
-e 60p \
-e 61p \
-e 62p \
-e 65p \
-e 66p \
-e 67p \
-e 1901p \
-e 3865p \
-e 4094p \
-e 4153p \
-e 4183p \
-e 4799p \
-e 5191p
which has the following output:
@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1996, 1998, 1999, 2000, 2001,
* Function Attributes:: Declaring that functions have no side effects,
* Attribute Syntax:: Formal syntax for attributes.
* Function Prototypes:: Prototype declarations and old-style definitions.
* C++ Comments:: C++ comments are recognized.
* Variable Attributes:: Specifying attributes of variables.
* Type Attributes:: Specifying attributes of types.
* Alignment:: Inquiring about the alignment of a type or variable.
@node Function Attributes
@node Attribute Syntax
@node Function Prototypes
@node C++ Comments
@node Variable Attributes
@node Type Attributes
@node Alignment
Hopefully that serves to convince you that this patch is sound.
diff --git a/trunk/gcc/doc/extend.texi b/trunk/gcc/doc/extend.texi
index c154958..aba8a54 100644
--- a/trunk/gcc/doc/extend.texi
+++ b/trunk/gcc/doc/extend.texi
@@ -55,15 +55,15 @@
* Cast to Union:: Casting to union type from any member of the union.
* Case Ranges:: `case 1 ... 9' and such.
* Mixed Declarations:: Mixing declarations and code.
+* Function Prototypes:: Prototype declarations and old-style definitions.
+* Attribute Syntax:: Formal syntax for attributes.
+* Type Attributes:: Specifying attributes of types.
+* Variable Attributes:: Specifying attributes of variables.
* Function Attributes:: Declaring that functions have no side effects,
or that they can never return.
-* Attribute Syntax:: Formal syntax for attributes.
-* Function Prototypes:: Prototype declarations and old-style definitions.
* C++ Comments:: C++ comments are recognized.
* Dollar Signs:: Dollar sign is allowed in identifiers.
* Character Escapes:: @samp{\e} stands for the character @key{ESC}.
-* Variable Attributes:: Specifying attributes of variables.
-* Type Attributes:: Specifying attributes of types.
* Alignment:: Inquiring about the alignment of a type or variable.
* Inline:: Defining inline functions (as fast as macros).
* Volatiles:: What constitutes an access to a volatile object.
@@ -1898,6 +1898,1302 @@
Each identifier is visible from where it is declared until the end of
the enclosing block.
+@node Function Prototypes
+@section Prototypes and Old-Style Function Definitions
+@cindex function prototype declarations
+@cindex old-style function definitions
+@cindex promotion of formal parameters
+
+GNU C extends ISO C to allow a function prototype to override a later
+old-style non-prototype definition. Consider the following example:
+
+@smallexample
+/* @r{Use prototypes unless the compiler is old-fashioned.} */
+#ifdef __STDC__
+#define P(x) x
+#else
+#define P(x) ()
+#endif
+
+/* @r{Prototype function declaration.} */
+int isroot P((uid_t));
+
+/* @r{Old-style function definition.} */
+int
+isroot (x) /* @r{??? lossage here ???} */
+ uid_t x;
+@{
+ return x == 0;
+@}
+@end smallexample
+
+Suppose the type @code{uid_t} happens to be @code{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 @code{int}, which does not
+match the prototype argument type of @code{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 @code{uid_t} type is @code{short}, @code{int}, or
+@code{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:
+
+@smallexample
+int isroot (uid_t);
+
+int
+isroot (uid_t x)
+@{
+ return x == 0;
+@}
+@end smallexample
+
+@noindent
+GNU C++ does not support old-style function definitions, so this
+extension is irrelevant.
+
+@node Attribute Syntax
+@section Attribute Syntax
+@cindex attribute syntax
+
+This section describes the syntax with which @code{__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, @code{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.
+
+@xref{Function Attributes}, for details of the semantics of attributes
+applying to functions. @xref{Variable Attributes}, for details of the
+semantics of attributes applying to variables. @xref{Type Attributes},
+for details of the semantics of attributes applying to structure, union
+and enumerated types.
+
+An @dfn{attribute specifier} is of the form
+@code{__attribute__ ((@var{attribute-list}))}. An @dfn{attribute list}
+is a possibly empty comma-separated sequence of @dfn{attributes}, where
+each attribute is one of the following:
+
+@itemize @bullet
+@item
+Empty. Empty attributes are ignored.
+
+@item
+A word (which may be an identifier such as @code{unused}, or a reserved
+word such as @code{const}).
+
+@item
+A word, followed by, in parentheses, parameters for the attribute.
+These parameters take one of the following forms:
+
+@itemize @bullet
+@item
+An identifier. For example, @code{mode} attributes use this form.
+
+@item
+An identifier followed by a comma and a non-empty comma-separated list
+of expressions. For example, @code{format} attributes use this form.
+
+@item
+A possibly empty comma-separated list of expressions. For example,
+@code{format_arg} attributes use this form with the list being a single
+integer constant expression, and @code{alias} attributes use this form
+with the list being a single string constant.
+@end itemize
+@end itemize
+
+An @dfn{attribute specifier list} is a sequence of one or more attribute
+specifiers, not separated by any other tokens.
+
+In GNU C, an attribute specifier list may appear after the colon following a
+label, other than a @code{case} or @code{default} label. The only
+attribute it makes sense to use after a label is @code{unused}. This
+feature is intended for code generated by programs which contains labels
+that may be unused but which is compiled with @option{-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 @code{#ifdef} conditional. GNU C++ only permits
+attributes on labels if the attribute specifier is immediately
+followed by a semicolon (i.e., the label applies to an empty
+statement). If the semicolon is missing, C++ label attributes are
+ambiguous, as it is permissible for a declaration, which could begin
+with an attribute list, to be labelled in C++. Declarations cannot be
+labelled in C90 or C99, so the ambiguity does not arise there.
+
+An attribute specifier list may appear as part of a @code{struct},
+@code{union} or @code{enum} specifier. It may go either immediately
+after the @code{struct}, @code{union} or @code{enum} keyword, or after
+the closing brace. The former syntax is preferred.
+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.
+@c Otherwise, there would be the following problems: a shift/reduce
+@c conflict between attributes binding the struct/union/enum and
+@c binding to the list of specifiers/qualifiers; and "aligned"
+@c attributes could use sizeof for the structure, but the size could be
+@c changed later by "packed" attributes.
+
+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,
+@code{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
+@code{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.
+
+At present, the first parameter in a function prototype must have some
+type specifier which is not an attribute specifier; this resolves an
+ambiguity in the interpretation of @code{void f(int
+(__attribute__((foo)) x))}, but is subject to change. At present, if
+the parentheses of a function declarator contain only attributes then
+those attributes are ignored, rather than yielding an error or warning
+or implying a single parameter of type int, but this is subject to
+change.
+
+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
+
+@smallexample
+__attribute__((noreturn)) void d0 (void),
+ __attribute__((format(printf, 1, 2))) d1 (const char *, ...),
+ d2 (void);
+@end smallexample
+
+@noindent
+the @code{noreturn} attribute applies to all the functions
+declared; the @code{format} attribute only applies to @code{d1}.
+
+An attribute specifier list may appear immediately before the comma,
+@code{=} or semicolon terminating the declaration of an identifier other
+than a function definition. Such attribute specifiers apply
+to the declared object or function. Where an
+assembler name for an object or function is specified (@pxref{Asm
+Labels}), the attribute must follow the @code{asm}
+specification.
+
+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 @code{[]} 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 @code{*} 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 @code{T
+D1}, where @code{T} contains declaration specifiers that specify a type
+@var{Type} (such as @code{int}) and @code{D1} is a declarator that
+contains an identifier @var{ident}. The type specified for @var{ident}
+for derived declarators whose type does not include an attribute
+specifier is as in the ISO C standard.
+
+If @code{D1} has the form @code{( @var{attribute-specifier-list} D )},
+and the declaration @code{T D} specifies the type
+``@var{derived-declarator-type-list} @var{Type}'' for @var{ident}, then
+@code{T D1} specifies the type ``@var{derived-declarator-type-list}
+@var{attribute-specifier-list} @var{Type}'' for @var{ident}.
+
+If @code{D1} has the form @code{*
+@var{type-qualifier-and-attribute-specifier-list} D}, and the
+declaration @code{T D} specifies the type
+``@var{derived-declarator-type-list} @var{Type}'' for @var{ident}, then
+@code{T D1} specifies the type ``@var{derived-declarator-type-list}
+@var{type-qualifier-and-attribute-specifier-list} pointer to @var{Type}'' for
+@var{ident}.
+
+For example,
+
+@smallexample
+void (__attribute__((noreturn)) ****f) (void);
+@end smallexample
+
+@noindent
+specifies the type ``pointer to pointer to pointer to pointer to
+non-returning function returning @code{void}''. As another example,
+
+@smallexample
+char *__attribute__((aligned(8))) *f;
+@end smallexample
+
+@noindent
+specifies the type ``pointer to 8-byte-aligned pointer to @code{char}''.
+Note again that this does not work with most attributes; for example,
+the usage of @samp{aligned} and @samp{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.
+
+@node Type Attributes
+@section Specifying Attributes of Types
+@cindex attribute of types
+@cindex type attributes
+
+The keyword @code{__attribute__} allows you to specify special
+attributes of @code{struct} and @code{union} types when you define
+such types. This keyword is followed by an attribute specification
+inside double parentheses. Seven attributes are currently defined for
+types: @code{aligned}, @code{packed}, @code{transparent_union},
+@code{unused}, @code{deprecated}, @code{visibility}, and
+@code{may_alias}. Other attributes are defined for functions
+(@pxref{Function Attributes}) and for variables (@pxref{Variable
+Attributes}).
+
+You may also specify any one of these attributes with @samp{__}
+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 @code{__aligned__}
+instead of @code{aligned}.
+
+You may specify type attributes in an enum, struct or union type
+declaration or definition, or for other types in a @code{typedef}
+declaration.
+
+For an enum, struct or union type, you may specify attributes either
+between the enum, struct or union tag and the name of the type, or
+just past the closing curly brace of the @emph{definition}. The
+former syntax is preferred.
+
+@xref{Attribute Syntax}, for details of the exact syntax for using
+attributes.
+
+@table @code
+@cindex @code{aligned} attribute
+@item aligned (@var{alignment})
+This attribute specifies a minimum alignment (in bytes) for variables
+of the specified type. For example, the declarations:
+
+@smallexample
+struct S @{ short f[3]; @} __attribute__ ((aligned (8)));
+typedef int more_aligned_int __attribute__ ((aligned (8)));
+@end smallexample
+
+@noindent
+force the compiler to insure (as far as it can) that each variable whose
+type is @code{struct S} or @code{more_aligned_int} will be allocated and
+aligned @emph{at least} on a 8-byte boundary. On a SPARC, having all
+variables of type @code{struct S} aligned to 8-byte boundaries allows
+the compiler to use the @code{ldd} and @code{std} (doubleword load and
+store) instructions when copying one variable of type @code{struct S} to
+another, thus improving run-time efficiency.
+
+Note that the alignment of any given @code{struct} or @code{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 @code{struct} or @code{union} in question. This means that you @emph{can}
+effectively adjust the alignment of a @code{struct} or @code{union}
+type by attaching an @code{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 @code{struct} or @code{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 @code{struct}
+or @code{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:
+
+@smallexample
+struct S @{ short f[3]; @} __attribute__ ((aligned));
+@end smallexample
+
+Whenever you leave out the alignment factor in an @code{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 @code{short} is 2 bytes, then
+the size of the entire @code{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 @code{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 @code{aligned} attribute can only increase the alignment; but you
+can decrease it by specifying @code{packed} as well. See below.
+
+Note that the effectiveness of @code{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 @code{aligned(16)}
+in an @code{__attribute__} will still only provide you with 8 byte
+alignment. See your linker documentation for further information.
+
+@item packed
+This attribute, attached to @code{struct} or @code{union} type
+definition, specifies that each member (other than zero-width bitfields)
+of the structure or union is placed to minimize the memory required. When
+attached to an @code{enum} definition, it indicates that the smallest
+integral type should be used.
+
+@opindex fshort-enums
+Specifying this attribute for @code{struct} and @code{union} types is
+equivalent to specifying the @code{packed} attribute on each of the
+structure or union members. Specifying the @option{-fshort-enums}
+flag on the line is equivalent to specifying the @code{packed}
+attribute on all @code{enum} definitions.
+
+In the following example @code{struct my_packed_struct}'s members are
+packed closely together, but the internal layout of its @code{s} member
+is not packed---to do that, @code{struct my_unpacked_struct} would need to
+be packed too.
+
+@smallexample
+struct my_unpacked_struct
+ @{
+ char c;
+ int i;
+ @};
+
+struct __attribute__ ((__packed__)) my_packed_struct
+ @{
+ char c;
+ int i;
+ struct my_unpacked_struct s;
+ @};
+@end smallexample
+
+You may only specify this attribute on the definition of an @code{enum},
+@code{struct} or @code{union}, not on a @code{typedef} which does not
+also define the enumerated type, structure or union.
+
+@item transparent_union
+This attribute, attached to a @code{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 @code{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 the 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
+@code{wait} function must accept either a value of type @code{int *} to
+comply with Posix, or a value of type @code{union wait *} to comply with
+the 4.1BSD interface. If @code{wait}'s parameter were @code{void *},
+@code{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, @code{<sys/wait.h>} might define the interface
+as follows:
+
+@smallexample
+typedef union __attribute__ ((__transparent_union__))
+ @{
+ int *__ip;
+ union wait *__up;
+ @} wait_status_ptr_t;
+
+pid_t wait (wait_status_ptr_t);
+@end smallexample
+
+This interface allows either @code{int *} or @code{union wait *}
+arguments to be passed, using the @code{int *} calling convention.
+The program can call @code{wait} with arguments of either type:
+
+@smallexample
+int w1 () @{ int w; return wait (&w); @}
+int w2 () @{ union wait w; return wait (&w); @}
+@end smallexample
+
+With this interface, @code{wait}'s implementation might look like this:
+
+@smallexample
+pid_t wait (wait_status_ptr_t p)
+@{
+ return waitpid (-1, p.__ip, 0);
+@}
+@end smallexample
+
+@item unused
+When attached to a type (including a @code{union} or a @code{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.
+
+@item deprecated
+@itemx deprecated (@var{msg})
+The @code{deprecated} attribute results in a warning if the type
+is used anywhere in the source file. This is useful when identifying
+types that are expected to be removed in a future version of a program.
+If possible, the warning also includes the location of the declaration
+of the deprecated type, to enable users to easily find further
+information about why the type is deprecated, or what they should do
+instead. Note that the warnings only occur for uses and then only
+if the type is being applied to an identifier that itself is not being
+declared as deprecated.
+
+@smallexample
+typedef int T1 __attribute__ ((deprecated));
+T1 x;
+typedef T1 T2;
+T2 y;
+typedef T1 T3 __attribute__ ((deprecated));
+T3 z __attribute__ ((deprecated));
+@end smallexample
+
+results in a warning on line 2 and 3 but not lines 4, 5, or 6. No
+warning is issued for line 4 because T2 is not explicitly
+deprecated. Line 5 has no warning because T3 is explicitly
+deprecated. Similarly for line 6. The optional msg
+argument, which must be a string, will be printed in the warning if
+present.
+
+The @code{deprecated} attribute can also be used for functions and
+variables (@pxref{Function Attributes}, @pxref{Variable Attributes}.)
+
+@item may_alias
+Accesses through pointers to types with this attribute are not subject
+to type-based alias analysis, but are instead assumed to be able to alias
+any other type of objects. In the context of 6.5/7 an lvalue expression
+dereferencing such a pointer is treated like having a character type.
+See @option{-fstrict-aliasing} for more information on aliasing issues.
+This extension exists to support some vector APIs, in which pointers to
+one vector type are permitted to alias pointers to a different vector type.
+
+Note that an object of a type with this attribute does not have any
+special semantics.
+
+Example of use:
+
+@smallexample
+typedef short __attribute__((__may_alias__)) short_a;
+
+int
+main (void)
+@{
+ int a = 0x12345678;
+ short_a *b = (short_a *) &a;
+
+ b[1] = 0;
+
+ if (a == 0x12345678)
+ abort();
+
+ exit(0);
+@}
+@end smallexample
+
+If you replaced @code{short_a} with @code{short} in the variable
+declaration, the above program would abort when compiled with
+@option{-fstrict-aliasing}, which is on by default at @option{-O2} or
+above in recent GCC versions.
+
+@item visibility
+In C++, attribute visibility (@pxref{Function Attributes}) can also be
+applied to class, struct, union and enum types. Unlike other type
+attributes, the attribute must appear between the initial keyword and
+the name of the type; it cannot appear after the body of the type.
+
+Note that the type visibility is applied to vague linkage entities
+associated with the class (vtable, typeinfo node, etc.). In
+particular, if a class is thrown as an exception in one shared object
+and caught in another, the class must have default visibility.
+Otherwise the two shared objects will be unable to use the same
+typeinfo node and exception handling will break.
+
+@end table
+
+@subsection ARM Type Attributes
+
+On those ARM targets that support @code{dllimport} (such as Symbian
+OS), you can use the @code{notshared} attribute to indicate that the
+virtual table and other similar data for a class should not be
+exported from a DLL@. For example:
+
+@smallexample
+class __declspec(notshared) C @{
+public:
+ __declspec(dllimport) C();
+ virtual void f();
+@}
+
+__declspec(dllexport)
+C::C() @{@}
+@end smallexample
+
+In this code, @code{C::C} is exported from the current DLL, but the
+virtual table for @code{C} is not exported. (You can use
+@code{__attribute__} instead of @code{__declspec} if you prefer, but
+most Symbian OS code uses @code{__declspec}.)
+
+@anchor{MeP Type Attributes}
+@subsection MeP Type Attributes
+
+Many of the MeP variable attributes may be applied to types as well.
+Specifically, the @code{based}, @code{tiny}, @code{near}, and
+@code{far} attributes may be applied to either. The @code{io} and
+@code{cb} attributes may not be applied to types.
+
+@anchor{i386 Type Attributes}
+@subsection i386 Type Attributes
+
+Two attributes are currently defined for i386 configurations:
+@code{ms_struct} and @code{gcc_struct}.
+
+@table @code
+
+@item ms_struct
+@itemx gcc_struct
+@cindex @code{ms_struct}
+@cindex @code{gcc_struct}
+
+If @code{packed} is used on a structure, or if bit-fields are used
+it may be that the Microsoft ABI packs them differently
+than GCC would normally pack them. Particularly when moving packed
+data between functions compiled with GCC and the native Microsoft compiler
+(either via function call or as data in a file), it may be necessary to access
+either format.
+
+Currently @option{-m[no-]ms-bitfields} is provided for the Microsoft Windows X86
+compilers to match the native Microsoft compiler.
+@end table
+
+To specify multiple attributes, separate them by commas within the
+double parentheses: for example, @samp{__attribute__ ((aligned (16),
+packed))}.
+
+@anchor{PowerPC Type Attributes}
+@subsection PowerPC Type Attributes
+
+Three attributes currently are defined for PowerPC configurations:
+@code{altivec}, @code{ms_struct} and @code{gcc_struct}.
+
+For full documentation of the @code{ms_struct} and @code{gcc_struct}
+attributes please see the documentation in @ref{i386 Type Attributes}.
+
+The @code{altivec} attribute allows one to declare AltiVec vector data
+types supported by the AltiVec Programming Interface Manual. The
+attribute requires an argument to specify one of three vector types:
+@code{vector__}, @code{pixel__} (always followed by unsigned short),
+and @code{bool__} (always followed by unsigned).
+
+@smallexample
+__attribute__((altivec(vector__)))
+__attribute__((altivec(pixel__))) unsigned short
+__attribute__((altivec(bool__))) unsigned
+@end smallexample
+
+These attributes mainly are intended to support the @code{__vector},
+@code{__pixel}, and @code{__bool} AltiVec keywords.
+
+@anchor{SPU Type Attributes}
+@subsection SPU Type Attributes
+
+The SPU supports the @code{spu_vector} attribute for types. This attribute
+allows one to declare vector data types supported by the Sony/Toshiba/IBM SPU
+Language Extensions Specification. It is intended to support the
+@code{__vector} keyword.
+
+@node Variable Attributes
+@section Specifying Attributes of Variables
+@cindex attribute of variables
+@cindex variable attributes
+
+The keyword @code{__attribute__} allows you to specify special
+attributes of variables or structure fields. This keyword is followed
+by an attribute specification inside double parentheses. Some
+attributes are currently defined generically for variables.
+Other attributes are defined for variables on particular target
+systems. Other attributes are available for functions
+(@pxref{Function Attributes}) and for types (@pxref{Type Attributes}).
+Other front ends might define more attributes
+(@pxref{C++ Extensions,,Extensions to the C++ Language}).
+
+You may also specify attributes with @samp{__} 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 @code{__aligned__} instead of @code{aligned}.
+
+@xref{Attribute Syntax}, for details of the exact syntax for using
+attributes.
+
+@table @code
+@cindex @code{aligned} attribute
+@item aligned (@var{alignment})
+This attribute specifies a minimum alignment for the variable or
+structure field, measured in bytes. For example, the declaration:
+
+@smallexample
+int x __attribute__ ((aligned (16))) = 0;
+@end smallexample
+
+@noindent
+causes the compiler to allocate the global variable @code{x} on a
+16-byte boundary. On a 68040, this could be used in conjunction with
+an @code{asm} expression to access the @code{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 @code{int} pair, you could write:
+
+@smallexample
+struct foo @{ int x[2] __attribute__ ((aligned (8))); @};
+@end smallexample
+
+@noindent
+This is an alternative to creating a union with a @code{double} member
+that forces the union to be double-word aligned.
+
+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
+default alignment for the target architecture you are compiling for.
+The default alignment is sufficient for all scalar types, but may not be
+enough for all vector types on a target which supports vector operations.
+The default alignment is fixed for a particular target ABI.
+
+Gcc also provides a target specific macro @code{__BIGGEST_ALIGNMENT__},
+which is the largest alignment ever used for any data type on the
+target machine you are compiling for. For example, you could write:
+
+@smallexample
+short array[3] __attribute__ ((aligned (__BIGGEST_ALIGNMENT__)));
+@end smallexample
+
+The compiler automatically sets the alignment for the declared
+variable or field to @code{__BIGGEST_ALIGNMENT__}. 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. Note that the value of @code{__BIGGEST_ALIGNMENT__}
+may change depending on command line options.
+
+When used on a struct, or struct member, the @code{aligned} attribute can
+only increase the alignment; in order to decrease it, the @code{packed}
+attribute must be specified as well. When used as part of a typedef, the
+@code{aligned} attribute can both increase and decrease alignment, and
+specifying the @code{packed} attribute will generate a warning.
+
+Note that the effectiveness of @code{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 @code{aligned(16)}
+in an @code{__attribute__} will still only provide you with 8 byte
+alignment. See your linker documentation for further information.
+
+The @code{aligned} attribute can also be used for functions
+(@pxref{Function Attributes}.)
+
+@item cleanup (@var{cleanup_function})
+@cindex @code{cleanup} attribute
+The @code{cleanup} attribute runs a function when the variable goes
+out of scope. This attribute can only be applied to auto function
+scope variables; it may not be applied to parameters or variables
+with static storage duration. The function must take one parameter,
+a pointer to a type compatible with the variable. The return value
+of the function (if any) is ignored.
+
+If @option{-fexceptions} is enabled, then @var{cleanup_function}
+will be run during the stack unwinding that happens during the
+processing of the exception. Note that the @code{cleanup} attribute
+does not allow the exception to be caught, only to perform an action.
+It is undefined what happens if @var{cleanup_function} does not
+return normally.
+
+@item common
+@itemx nocommon
+@cindex @code{common} attribute
+@cindex @code{nocommon} attribute
+@opindex fcommon
+@opindex fno-common
+The @code{common} attribute requests GCC to place a variable in
+``common'' storage. The @code{nocommon} attribute requests the
+opposite---to allocate space for it directly.
+
+These attributes override the default chosen by the
+@option{-fno-common} and @option{-fcommon} flags respectively.
+
+@item deprecated
+@itemx deprecated (@var{msg})
+@cindex @code{deprecated} attribute
+The @code{deprecated} attribute results in a warning if the variable
+is used anywhere in the source file. This is useful when identifying
+variables that are expected to be removed in a future version of a
+program. The warning also includes the location of the declaration
+of the deprecated variable, to enable users to easily find further
+information about why the variable is deprecated, or what they should
+do instead. Note that the warning only occurs for uses:
+
+@smallexample
+extern int old_var __attribute__ ((deprecated));
+extern int old_var;
+int new_fn () @{ return old_var; @}
+@end smallexample
+
+results in a warning on line 3 but not line 2. The optional msg
+argument, which must be a string, will be printed in the warning if
+present.
+
+The @code{deprecated} attribute can also be used for functions and
+types (@pxref{Function Attributes}, @pxref{Type Attributes}.)
+
+@item mode (@var{mode})
+@cindex @code{mode} attribute
+This attribute specifies the data type for the declaration---whichever
+type corresponds to the mode @var{mode}. This in effect lets you
+request an integer or floating point type according to its width.
+
+You may also specify a mode of @samp{byte} or @samp{__byte__} to
+indicate the mode corresponding to a one-byte integer, @samp{word} or
+@samp{__word__} for the mode of a one-word integer, and @samp{pointer}
+or @samp{__pointer__} for the mode used to represent pointers.
+
+@item packed
+@cindex @code{packed} attribute
+The @code{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
+@code{aligned} attribute.
+
+Here is a structure in which the field @code{x} is packed, so that it
+immediately follows @code{a}:
+
+@smallexample
+struct foo
+@{
+ char a;
+ int x[2] __attribute__ ((packed));
+@};
+@end smallexample
+
+@emph{Note:} The 4.1, 4.2 and 4.3 series of GCC ignore the
+@code{packed} attribute on bit-fields of type @code{char}. This has
+been fixed in GCC 4.4 but the change can lead to differences in the
+structure layout. See the documentation of
+@option{-Wpacked-bitfield-compat} for more information.
+
+@item section ("@var{section-name}")
+@cindex @code{section} variable attribute
+Normally, the compiler places the objects it generates in sections like
+@code{data} and @code{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 @code{section}
+attribute specifies that a variable (or function) lives in a particular
+section. For example, this small program uses several specific section names:
+
+@smallexample
+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")));
+
+main()
+@{
+ /* @r{Initialize stack pointer} */
+ init_sp (stack + sizeof (stack));
+
+ /* @r{Initialize initialized data} */
+ memcpy (&init_data, &data, &edata - &data);
+
+ /* @r{Turn on the serial ports} */
+ init_duart (&a);
+ init_duart (&b);
+@}
+@end smallexample
+
+@noindent
+Use the @code{section} attribute with
+@emph{global} variables and not @emph{local} variables,
+as shown in the example.
+
+You may use the @code{section} attribute with initialized or
+uninitialized global variables but the linker requires
+each object be defined once, with the exception that uninitialized
+variables tentatively go in the @code{common} (or @code{bss}) section
+and can be multiply ``defined''. Using the @code{section} attribute
+will change what section the variable goes into and may cause the
+linker to issue an error if an uninitialized variable has multiple
+definitions. You can force a variable to be initialized with the
+@option{-fno-common} flag or the @code{nocommon} attribute.
+
+Some file formats do not support arbitrary sections so the @code{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.
+
+@item shared
+@cindex @code{shared} variable attribute
+On Microsoft Windows, 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 @code{shared} and marking the section
+shareable:
+
+@smallexample
+int foo __attribute__((section ("shared"), shared)) = 0;
+
+int
+main()
+@{
+ /* @r{Read and write foo. All running
+ copies see the same value.} */
+ return 0;
+@}
+@end smallexample
+
+@noindent
+You may only use the @code{shared} attribute along with @code{section}
+attribute with a fully initialized global definition because of the way
+linkers work. See @code{section} attribute for more information.
+
+The @code{shared} attribute is only available on Microsoft Windows@.
+
+@item tls_model ("@var{tls_model}")
+@cindex @code{tls_model} attribute
+The @code{tls_model} attribute sets thread-local storage model
+(@pxref{Thread-Local}) of a particular @code{__thread} variable,
+overriding @option{-ftls-model=} command-line switch on a per-variable
+basis.
+The @var{tls_model} argument should be one of @code{global-dynamic},
+@code{local-dynamic}, @code{initial-exec} or @code{local-exec}.
+
+Not all targets support this attribute.
+
+@item 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.
+
+@item used
+This attribute, attached to a variable, means that the variable must be
+emitted even if it appears that the variable is not referenced.
+
+@item vector_size (@var{bytes})
+This attribute specifies the vector size for the variable, measured in
+bytes. For example, the declaration:
+
+@smallexample
+int foo __attribute__ ((vector_size (16)));
+@end smallexample
+
+@noindent
+causes the compiler to set the mode for @code{foo}, to be 16 bytes,
+divided into @code{int} sized units. Assuming a 32-bit int (a vector of
+4 units of 4 bytes), the corresponding mode of @code{foo} will be V4SI@.
+
+This attribute is only applicable to integral and float scalars,
+although arrays, pointers, and function return values are allowed in
+conjunction with this construct.
+
+Aggregates with this attribute are invalid, even if they are of the same
+size as a corresponding scalar. For example, the declaration:
+
+@smallexample
+struct S @{ int a; @};
+struct S __attribute__ ((vector_size (16))) foo;
+@end smallexample
+
+@noindent
+is invalid even if the size of the structure is the same as the size of
+the @code{int}.
+
+@item selectany
+The @code{selectany} attribute causes an initialized global variable to
+have link-once semantics. When multiple definitions of the variable are
+encountered by the linker, the first is selected and the remainder are
+discarded. Following usage by the Microsoft compiler, the linker is told
+@emph{not} to warn about size or content differences of the multiple
+definitions.
+
+Although the primary usage of this attribute is for POD types, the
+attribute can also be applied to global C++ objects that are initialized
+by a constructor. In this case, the static initialization and destruction
+code for the object is emitted in each translation defining the object,
+but the calls to the constructor and destructor are protected by a
+link-once guard variable.
+
+The @code{selectany} attribute is only available on Microsoft Windows
+targets. You can use @code{__declspec (selectany)} as a synonym for
+@code{__attribute__ ((selectany))} for compatibility with other
+compilers.
+
+@item weak
+The @code{weak} attribute is described in @ref{Function Attributes}.
+
+@item dllimport
+The @code{dllimport} attribute is described in @ref{Function Attributes}.
+
+@item dllexport
+The @code{dllexport} attribute is described in @ref{Function Attributes}.
+
+@end table
+
+@subsection Blackfin Variable Attributes
+
+Three attributes are currently defined for the Blackfin.
+
+@table @code
+@item l1_data
+@itemx l1_data_A
+@itemx l1_data_B
+@cindex @code{l1_data} variable attribute
+@cindex @code{l1_data_A} variable attribute
+@cindex @code{l1_data_B} variable attribute
+Use these attributes on the Blackfin to place the variable into L1 Data SRAM.
+Variables with @code{l1_data} attribute will be put into the specific section
+named @code{.l1.data}. Those with @code{l1_data_A} attribute will be put into
+the specific section named @code{.l1.data.A}. Those with @code{l1_data_B}
+attribute will be put into the specific section named @code{.l1.data.B}.
+
+@item l2
+@cindex @code{l2} variable attribute
+Use this attribute on the Blackfin to place the variable into L2 SRAM.
+Variables with @code{l2} attribute will be put into the specific section
+named @code{.l2.data}.
+@end table
+
+@subsection M32R/D Variable Attributes
+
+One attribute is currently defined for the M32R/D@.
+
+@table @code
+@item model (@var{model-name})
+@cindex variable addressability on the M32R/D
+Use this attribute on the M32R/D to set the addressability of an object.
+The identifier @var{model-name} is one of @code{small}, @code{medium},
+or @code{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 @code{ld24} instruction).
+
+Medium and large model objects may live anywhere in the 32-bit address space
+(the compiler will generate @code{seth/add3} instructions to load their
+addresses).
+@end table
+
+@anchor{MeP Variable Attributes}
+@subsection MeP Variable Attributes
+
+The MeP target has a number of addressing modes and busses. The
+@code{near} space spans the standard memory space's first 16 megabytes
+(24 bits). The @code{far} space spans the entire 32-bit memory space.
+The @code{based} space is a 128 byte region in the memory space which
+is addressed relative to the @code{$tp} register. The @code{tiny}
+space is a 65536 byte region relative to the @code{$gp} register. In
+addition to these memory regions, the MeP target has a separate 16-bit
+control bus which is specified with @code{cb} attributes.
+
+@table @code
+
+@item based
+Any variable with the @code{based} attribute will be assigned to the
+@code{.based} section, and will be accessed with relative to the
+@code{$tp} register.
+
+@item tiny
+Likewise, the @code{tiny} attribute assigned variables to the
+@code{.tiny} section, relative to the @code{$gp} register.
+
+@item near
+Variables with the @code{near} attribute are assumed to have addresses
+that fit in a 24-bit addressing mode. This is the default for large
+variables (@code{-mtiny=4} is the default) but this attribute can
+override @code{-mtiny=} for small variables, or override @code{-ml}.
+
+@item far
+Variables with the @code{far} attribute are addressed using a full
+32-bit address. Since this covers the entire memory space, this
+allows modules to make no assumptions about where variables might be
+stored.
+
+@item io
+@itemx io (@var{addr})
+Variables with the @code{io} attribute are used to address
+memory-mapped peripherals. If an address is specified, the variable
+is assigned that address, else it is not assigned an address (it is
+assumed some other module will assign an address). Example:
+
+@example
+int timer_count __attribute__((io(0x123)));
+@end example
+
+@item cb
+@itemx cb (@var{addr})
+Variables with the @code{cb} attribute are used to access the control
+bus, using special instructions. @code{addr} indicates the control bus
+address. Example:
+
+@example
+int cpu_clock __attribute__((cb(0x123)));
+@end example
+
+@end table
+
+@anchor{i386 Variable Attributes}
+@subsection i386 Variable Attributes
+
+Two attributes are currently defined for i386 configurations:
+@code{ms_struct} and @code{gcc_struct}
+
+@table @code
+@item ms_struct
+@itemx gcc_struct
+@cindex @code{ms_struct} attribute
+@cindex @code{gcc_struct} attribute
+
+If @code{packed} is used on a structure, or if bit-fields are used
+it may be that the Microsoft ABI packs them differently
+than GCC would normally pack them. Particularly when moving packed
+data between functions compiled with GCC and the native Microsoft compiler
+(either via function call or as data in a file), it may be necessary to access
+either format.
+
+Currently @option{-m[no-]ms-bitfields} is provided for the Microsoft Windows X86
+compilers to match the native Microsoft compiler.
+
+The Microsoft structure layout algorithm is fairly simple with the exception
+of the bitfield packing:
+
+The padding and alignment of members of structures and whether a bit field
+can straddle a storage-unit boundary
+
+@enumerate
+@item Structure members are stored sequentially in the order in which they are
+declared: the first member has the lowest memory address and the last member
+the highest.
+
+@item Every data object has an alignment-requirement. The alignment-requirement
+for all data except structures, unions, and arrays is either the size of the
+object or the current packing size (specified with either the aligned attribute
+or the pack pragma), whichever is less. For structures, unions, and arrays,
+the alignment-requirement is the largest alignment-requirement of its members.
+Every object is allocated an offset so that:
+
+offset % alignment-requirement == 0
+
+@item Adjacent bit fields are packed into the same 1-, 2-, or 4-byte allocation
+unit if the integral types are the same size and if the next bit field fits
+into the current allocation unit without crossing the boundary imposed by the
+common alignment requirements of the bit fields.
+@end enumerate
+
+Handling of zero-length bitfields:
+
+MSVC interprets zero-length bitfields in the following ways:
+
+@enumerate
+@item If a zero-length bitfield is inserted between two bitfields that would
+normally be coalesced, the bitfields will not be coalesced.
+
+For example:
+
+@smallexample
+struct
+ @{
+ unsigned long bf_1 : 12;
+ unsigned long : 0;
+ unsigned long bf_2 : 12;
+ @} t1;
+@end smallexample
+
+The size of @code{t1} would be 8 bytes with the zero-length bitfield. If the
+zero-length bitfield were removed, @code{t1}'s size would be 4 bytes.
+
+@item If a zero-length bitfield is inserted after a bitfield, @code{foo}, and the
+alignment of the zero-length bitfield is greater than the member that follows it,
+@code{bar}, @code{bar} will be aligned as the type of the zero-length bitfield.
+
+For example:
+
+@smallexample
+struct
+ @{
+ char foo : 4;
+ short : 0;
+ char bar;
+ @} t2;
+
+struct
+ @{
+ char foo : 4;
+ short : 0;
+ double bar;
+ @} t3;
+@end smallexample
+
+For @code{t2}, @code{bar} will be placed at offset 2, rather than offset 1.
+Accordingly, the size of @code{t2} will be 4. For @code{t3}, the zero-length
+bitfield will not affect the alignment of @code{bar} or, as a result, the size
+of the structure.
+
+Taking this into account, it is important to note the following:
+
+@enumerate
+@item If a zero-length bitfield follows a normal bitfield, the type of the
+zero-length bitfield may affect the alignment of the structure as whole. For
+example, @code{t2} has a size of 4 bytes, since the zero-length bitfield follows a
+normal bitfield, and is of type short.
+
+@item Even if a zero-length bitfield is not followed by a normal bitfield, it may
+still affect the alignment of the structure:
+
+@smallexample
+struct
+ @{
+ char foo : 6;
+ long : 0;
+ @} t4;
+@end smallexample
+
+Here, @code{t4} will take up 4 bytes.
+@end enumerate
+
+@item Zero-length bitfields following non-bitfield members are ignored:
+
+@smallexample
+struct
+ @{
+ char foo;
+ long : 0;
+ char bar;
+ @} t5;
+@end smallexample
+
+Here, @code{t5} will take up 2 bytes.
+@end enumerate
+@end table
+
+@subsection PowerPC Variable Attributes
+
+Three attributes currently are defined for PowerPC configurations:
+@code{altivec}, @code{ms_struct} and @code{gcc_struct}.
+
+For full documentation of the struct attributes please see the
+documentation in @ref{i386 Variable Attributes}.
+
+For documentation of @code{altivec} attribute please see the
+documentation in @ref{PowerPC Type Attributes}.
+
+@subsection SPU Variable Attributes
+
+The SPU supports the @code{spu_vector} attribute for variables. For
+documentation of this attribute please see the documentation in
+@ref{SPU Type Attributes}.
+
+@subsection Xstormy16 Variable Attributes
+
+One attribute is currently defined for xstormy16 configurations:
+@code{below100}.
+
+@table @code
+@item below100
+@cindex @code{below100} attribute
+
+If a variable has the @code{below100} attribute (@code{BELOW100} is
+allowed also), GCC will place the variable in the first 0x100 bytes of
+memory and use special opcodes to access it. Such variables will be
+placed in either the @code{.bss_below100} section or the
+@code{.data_below100} section.
+
+@end table
+
+@subsection AVR Variable Attributes
+
+@table @code
+@item progmem
+@cindex @code{progmem} variable attribute
+The @code{progmem} attribute is used on the AVR to place data in the Program
+Memory address space. The AVR is a Harvard Architecture processor and data
+normally resides in the Data Memory address space.
+@end table
+
@node Function Attributes
@section Declaring Attributes of Functions
@cindex function attributes
@@ -3862,294 +5158,6 @@
part of the grammar. @xref{Other Directives,,Miscellaneous
Preprocessing Directives, cpp, The GNU C Preprocessor}.
-@node Attribute Syntax
-@section Attribute Syntax
-@cindex attribute syntax
-
-This section describes the syntax with which @code{__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, @code{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.
-
-@xref{Function Attributes}, for details of the semantics of attributes
-applying to functions. @xref{Variable Attributes}, for details of the
-semantics of attributes applying to variables. @xref{Type Attributes},
-for details of the semantics of attributes applying to structure, union
-and enumerated types.
-
-An @dfn{attribute specifier} is of the form
-@code{__attribute__ ((@var{attribute-list}))}. An @dfn{attribute list}
-is a possibly empty comma-separated sequence of @dfn{attributes}, where
-each attribute is one of the following:
-
-@itemize @bullet
-@item
-Empty. Empty attributes are ignored.
-
-@item
-A word (which may be an identifier such as @code{unused}, or a reserved
-word such as @code{const}).
-
-@item
-A word, followed by, in parentheses, parameters for the attribute.
-These parameters take one of the following forms:
-
-@itemize @bullet
-@item
-An identifier. For example, @code{mode} attributes use this form.
-
-@item
-An identifier followed by a comma and a non-empty comma-separated list
-of expressions. For example, @code{format} attributes use this form.
-
-@item
-A possibly empty comma-separated list of expressions. For example,
-@code{format_arg} attributes use this form with the list being a single
-integer constant expression, and @code{alias} attributes use this form
-with the list being a single string constant.
-@end itemize
-@end itemize
-
-An @dfn{attribute specifier list} is a sequence of one or more attribute
-specifiers, not separated by any other tokens.
-
-In GNU C, an attribute specifier list may appear after the colon following a
-label, other than a @code{case} or @code{default} label. The only
-attribute it makes sense to use after a label is @code{unused}. This
-feature is intended for code generated by programs which contains labels
-that may be unused but which is compiled with @option{-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 @code{#ifdef} conditional. GNU C++ only permits
-attributes on labels if the attribute specifier is immediately
-followed by a semicolon (i.e., the label applies to an empty
-statement). If the semicolon is missing, C++ label attributes are
-ambiguous, as it is permissible for a declaration, which could begin
-with an attribute list, to be labelled in C++. Declarations cannot be
-labelled in C90 or C99, so the ambiguity does not arise there.
-
-An attribute specifier list may appear as part of a @code{struct},
-@code{union} or @code{enum} specifier. It may go either immediately
-after the @code{struct}, @code{union} or @code{enum} keyword, or after
-the closing brace. The former syntax is preferred.
-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.
-@c Otherwise, there would be the following problems: a shift/reduce
-@c conflict between attributes binding the struct/union/enum and
-@c binding to the list of specifiers/qualifiers; and "aligned"
-@c attributes could use sizeof for the structure, but the size could be
-@c changed later by "packed" attributes.
-
-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,
-@code{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
-@code{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.
-
-At present, the first parameter in a function prototype must have some
-type specifier which is not an attribute specifier; this resolves an
-ambiguity in the interpretation of @code{void f(int
-(__attribute__((foo)) x))}, but is subject to change. At present, if
-the parentheses of a function declarator contain only attributes then
-those attributes are ignored, rather than yielding an error or warning
-or implying a single parameter of type int, but this is subject to
-change.
-
-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
-
-@smallexample
-__attribute__((noreturn)) void d0 (void),
- __attribute__((format(printf, 1, 2))) d1 (const char *, ...),
- d2 (void);
-@end smallexample
-
-@noindent
-the @code{noreturn} attribute applies to all the functions
-declared; the @code{format} attribute only applies to @code{d1}.
-
-An attribute specifier list may appear immediately before the comma,
-@code{=} or semicolon terminating the declaration of an identifier other
-than a function definition. Such attribute specifiers apply
-to the declared object or function. Where an
-assembler name for an object or function is specified (@pxref{Asm
-Labels}), the attribute must follow the @code{asm}
-specification.
-
-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 @code{[]} 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 @code{*} 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 @code{T
-D1}, where @code{T} contains declaration specifiers that specify a type
-@var{Type} (such as @code{int}) and @code{D1} is a declarator that
-contains an identifier @var{ident}. The type specified for @var{ident}
-for derived declarators whose type does not include an attribute
-specifier is as in the ISO C standard.
-
-If @code{D1} has the form @code{( @var{attribute-specifier-list} D )},
-and the declaration @code{T D} specifies the type
-``@var{derived-declarator-type-list} @var{Type}'' for @var{ident}, then
-@code{T D1} specifies the type ``@var{derived-declarator-type-list}
-@var{attribute-specifier-list} @var{Type}'' for @var{ident}.
-
-If @code{D1} has the form @code{*
-@var{type-qualifier-and-attribute-specifier-list} D}, and the
-declaration @code{T D} specifies the type
-``@var{derived-declarator-type-list} @var{Type}'' for @var{ident}, then
-@code{T D1} specifies the type ``@var{derived-declarator-type-list}
-@var{type-qualifier-and-attribute-specifier-list} pointer to @var{Type}'' for
-@var{ident}.
-
-For example,
-
-@smallexample
-void (__attribute__((noreturn)) ****f) (void);
-@end smallexample
-
-@noindent
-specifies the type ``pointer to pointer to pointer to pointer to
-non-returning function returning @code{void}''. As another example,
-
-@smallexample
-char *__attribute__((aligned(8))) *f;
-@end smallexample
-
-@noindent
-specifies the type ``pointer to 8-byte-aligned pointer to @code{char}''.
-Note again that this does not work with most attributes; for example,
-the usage of @samp{aligned} and @samp{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.
-
-@node Function Prototypes
-@section Prototypes and Old-Style Function Definitions
-@cindex function prototype declarations
-@cindex old-style function definitions
-@cindex promotion of formal parameters
-
-GNU C extends ISO C to allow a function prototype to override a later
-old-style non-prototype definition. Consider the following example:
-
-@smallexample
-/* @r{Use prototypes unless the compiler is old-fashioned.} */
-#ifdef __STDC__
-#define P(x) x
-#else
-#define P(x) ()
-#endif
-
-/* @r{Prototype function declaration.} */
-int isroot P((uid_t));
-
-/* @r{Old-style function definition.} */
-int
-isroot (x) /* @r{??? lossage here ???} */
- uid_t x;
-@{
- return x == 0;
-@}
-@end smallexample
-
-Suppose the type @code{uid_t} happens to be @code{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 @code{int}, which does not
-match the prototype argument type of @code{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 @code{uid_t} type is @code{short}, @code{int}, or
-@code{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:
-
-@smallexample
-int isroot (uid_t);
-
-int
-isroot (uid_t x)
-@{
- return x == 0;
-@}
-@end smallexample
-
-@noindent
-GNU C++ does not support old-style function definitions, so this
-extension is irrelevant.
-
@node C++ Comments
@section C++ Style Comments
@cindex @code{//}
@@ -4180,1014 +5188,6 @@
You can use the sequence @samp{\e} in a string or character constant to
stand for the ASCII character @key{ESC}.
-@node Variable Attributes
-@section Specifying Attributes of Variables
-@cindex attribute of variables
-@cindex variable attributes
-
-The keyword @code{__attribute__} allows you to specify special
-attributes of variables or structure fields. This keyword is followed
-by an attribute specification inside double parentheses. Some
-attributes are currently defined generically for variables.
-Other attributes are defined for variables on particular target
-systems. Other attributes are available for functions
-(@pxref{Function Attributes}) and for types (@pxref{Type Attributes}).
-Other front ends might define more attributes
-(@pxref{C++ Extensions,,Extensions to the C++ Language}).
-
-You may also specify attributes with @samp{__} 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 @code{__aligned__} instead of @code{aligned}.
-
-@xref{Attribute Syntax}, for details of the exact syntax for using
-attributes.
-
-@table @code
-@cindex @code{aligned} attribute
-@item aligned (@var{alignment})
-This attribute specifies a minimum alignment for the variable or
-structure field, measured in bytes. For example, the declaration:
-
-@smallexample
-int x __attribute__ ((aligned (16))) = 0;
-@end smallexample
-
-@noindent
-causes the compiler to allocate the global variable @code{x} on a
-16-byte boundary. On a 68040, this could be used in conjunction with
-an @code{asm} expression to access the @code{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 @code{int} pair, you could write:
-
-@smallexample
-struct foo @{ int x[2] __attribute__ ((aligned (8))); @};
-@end smallexample
-
-@noindent
-This is an alternative to creating a union with a @code{double} member
-that forces the union to be double-word aligned.
-
-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
-default alignment for the target architecture you are compiling for.
-The default alignment is sufficient for all scalar types, but may not be
-enough for all vector types on a target which supports vector operations.
-The default alignment is fixed for a particular target ABI.
-
-Gcc also provides a target specific macro @code{__BIGGEST_ALIGNMENT__},
-which is the largest alignment ever used for any data type on the
-target machine you are compiling for. For example, you could write:
-
-@smallexample
-short array[3] __attribute__ ((aligned (__BIGGEST_ALIGNMENT__)));
-@end smallexample
-
-The compiler automatically sets the alignment for the declared
-variable or field to @code{__BIGGEST_ALIGNMENT__}. 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. Note that the value of @code{__BIGGEST_ALIGNMENT__}
-may change depending on command line options.
-
-When used on a struct, or struct member, the @code{aligned} attribute can
-only increase the alignment; in order to decrease it, the @code{packed}
-attribute must be specified as well. When used as part of a typedef, the
-@code{aligned} attribute can both increase and decrease alignment, and
-specifying the @code{packed} attribute will generate a warning.
-
-Note that the effectiveness of @code{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 @code{aligned(16)}
-in an @code{__attribute__} will still only provide you with 8 byte
-alignment. See your linker documentation for further information.
-
-The @code{aligned} attribute can also be used for functions
-(@pxref{Function Attributes}.)
-
-@item cleanup (@var{cleanup_function})
-@cindex @code{cleanup} attribute
-The @code{cleanup} attribute runs a function when the variable goes
-out of scope. This attribute can only be applied to auto function
-scope variables; it may not be applied to parameters or variables
-with static storage duration. The function must take one parameter,
-a pointer to a type compatible with the variable. The return value
-of the function (if any) is ignored.
-
-If @option{-fexceptions} is enabled, then @var{cleanup_function}
-will be run during the stack unwinding that happens during the
-processing of the exception. Note that the @code{cleanup} attribute
-does not allow the exception to be caught, only to perform an action.
-It is undefined what happens if @var{cleanup_function} does not
-return normally.
-
-@item common
-@itemx nocommon
-@cindex @code{common} attribute
-@cindex @code{nocommon} attribute
-@opindex fcommon
-@opindex fno-common
-The @code{common} attribute requests GCC to place a variable in
-``common'' storage. The @code{nocommon} attribute requests the
-opposite---to allocate space for it directly.
-
-These attributes override the default chosen by the
-@option{-fno-common} and @option{-fcommon} flags respectively.
-
-@item deprecated
-@itemx deprecated (@var{msg})
-@cindex @code{deprecated} attribute
-The @code{deprecated} attribute results in a warning if the variable
-is used anywhere in the source file. This is useful when identifying
-variables that are expected to be removed in a future version of a
-program. The warning also includes the location of the declaration
-of the deprecated variable, to enable users to easily find further
-information about why the variable is deprecated, or what they should
-do instead. Note that the warning only occurs for uses:
-
-@smallexample
-extern int old_var __attribute__ ((deprecated));
-extern int old_var;
-int new_fn () @{ return old_var; @}
-@end smallexample
-
-results in a warning on line 3 but not line 2. The optional msg
-argument, which must be a string, will be printed in the warning if
-present.
-
-The @code{deprecated} attribute can also be used for functions and
-types (@pxref{Function Attributes}, @pxref{Type Attributes}.)
-
-@item mode (@var{mode})
-@cindex @code{mode} attribute
-This attribute specifies the data type for the declaration---whichever
-type corresponds to the mode @var{mode}. This in effect lets you
-request an integer or floating point type according to its width.
-
-You may also specify a mode of @samp{byte} or @samp{__byte__} to
-indicate the mode corresponding to a one-byte integer, @samp{word} or
-@samp{__word__} for the mode of a one-word integer, and @samp{pointer}
-or @samp{__pointer__} for the mode used to represent pointers.
-
-@item packed
-@cindex @code{packed} attribute
-The @code{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
-@code{aligned} attribute.
-
-Here is a structure in which the field @code{x} is packed, so that it
-immediately follows @code{a}:
-
-@smallexample
-struct foo
-@{
- char a;
- int x[2] __attribute__ ((packed));
-@};
-@end smallexample
-
-@emph{Note:} The 4.1, 4.2 and 4.3 series of GCC ignore the
-@code{packed} attribute on bit-fields of type @code{char}. This has
-been fixed in GCC 4.4 but the change can lead to differences in the
-structure layout. See the documentation of
-@option{-Wpacked-bitfield-compat} for more information.
-
-@item section ("@var{section-name}")
-@cindex @code{section} variable attribute
-Normally, the compiler places the objects it generates in sections like
-@code{data} and @code{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 @code{section}
-attribute specifies that a variable (or function) lives in a particular
-section. For example, this small program uses several specific section names:
-
-@smallexample
-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")));
-
-main()
-@{
- /* @r{Initialize stack pointer} */
- init_sp (stack + sizeof (stack));
-
- /* @r{Initialize initialized data} */
- memcpy (&init_data, &data, &edata - &data);
-
- /* @r{Turn on the serial ports} */
- init_duart (&a);
- init_duart (&b);
-@}
-@end smallexample
-
-@noindent
-Use the @code{section} attribute with
-@emph{global} variables and not @emph{local} variables,
-as shown in the example.
-
-You may use the @code{section} attribute with initialized or
-uninitialized global variables but the linker requires
-each object be defined once, with the exception that uninitialized
-variables tentatively go in the @code{common} (or @code{bss}) section
-and can be multiply ``defined''. Using the @code{section} attribute
-will change what section the variable goes into and may cause the
-linker to issue an error if an uninitialized variable has multiple
-definitions. You can force a variable to be initialized with the
-@option{-fno-common} flag or the @code{nocommon} attribute.
-
-Some file formats do not support arbitrary sections so the @code{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.
-
-@item shared
-@cindex @code{shared} variable attribute
-On Microsoft Windows, 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 @code{shared} and marking the section
-shareable:
-
-@smallexample
-int foo __attribute__((section ("shared"), shared)) = 0;
-
-int
-main()
-@{
- /* @r{Read and write foo. All running
- copies see the same value.} */
- return 0;
-@}
-@end smallexample
-
-@noindent
-You may only use the @code{shared} attribute along with @code{section}
-attribute with a fully initialized global definition because of the way
-linkers work. See @code{section} attribute for more information.
-
-The @code{shared} attribute is only available on Microsoft Windows@.
-
-@item tls_model ("@var{tls_model}")
-@cindex @code{tls_model} attribute
-The @code{tls_model} attribute sets thread-local storage model
-(@pxref{Thread-Local}) of a particular @code{__thread} variable,
-overriding @option{-ftls-model=} command-line switch on a per-variable
-basis.
-The @var{tls_model} argument should be one of @code{global-dynamic},
-@code{local-dynamic}, @code{initial-exec} or @code{local-exec}.
-
-Not all targets support this attribute.
-
-@item 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.
-
-@item used
-This attribute, attached to a variable, means that the variable must be
-emitted even if it appears that the variable is not referenced.
-
-@item vector_size (@var{bytes})
-This attribute specifies the vector size for the variable, measured in
-bytes. For example, the declaration:
-
-@smallexample
-int foo __attribute__ ((vector_size (16)));
-@end smallexample
-
-@noindent
-causes the compiler to set the mode for @code{foo}, to be 16 bytes,
-divided into @code{int} sized units. Assuming a 32-bit int (a vector of
-4 units of 4 bytes), the corresponding mode of @code{foo} will be V4SI@.
-
-This attribute is only applicable to integral and float scalars,
-although arrays, pointers, and function return values are allowed in
-conjunction with this construct.
-
-Aggregates with this attribute are invalid, even if they are of the same
-size as a corresponding scalar. For example, the declaration:
-
-@smallexample
-struct S @{ int a; @};
-struct S __attribute__ ((vector_size (16))) foo;
-@end smallexample
-
-@noindent
-is invalid even if the size of the structure is the same as the size of
-the @code{int}.
-
-@item selectany
-The @code{selectany} attribute causes an initialized global variable to
-have link-once semantics. When multiple definitions of the variable are
-encountered by the linker, the first is selected and the remainder are
-discarded. Following usage by the Microsoft compiler, the linker is told
-@emph{not} to warn about size or content differences of the multiple
-definitions.
-
-Although the primary usage of this attribute is for POD types, the
-attribute can also be applied to global C++ objects that are initialized
-by a constructor. In this case, the static initialization and destruction
-code for the object is emitted in each translation defining the object,
-but the calls to the constructor and destructor are protected by a
-link-once guard variable.
-
-The @code{selectany} attribute is only available on Microsoft Windows
-targets. You can use @code{__declspec (selectany)} as a synonym for
-@code{__attribute__ ((selectany))} for compatibility with other
-compilers.
-
-@item weak
-The @code{weak} attribute is described in @ref{Function Attributes}.
-
-@item dllimport
-The @code{dllimport} attribute is described in @ref{Function Attributes}.
-
-@item dllexport
-The @code{dllexport} attribute is described in @ref{Function Attributes}.
-
-@end table
-
-@subsection Blackfin Variable Attributes
-
-Three attributes are currently defined for the Blackfin.
-
-@table @code
-@item l1_data
-@itemx l1_data_A
-@itemx l1_data_B
-@cindex @code{l1_data} variable attribute
-@cindex @code{l1_data_A} variable attribute
-@cindex @code{l1_data_B} variable attribute
-Use these attributes on the Blackfin to place the variable into L1 Data SRAM.
-Variables with @code{l1_data} attribute will be put into the specific section
-named @code{.l1.data}. Those with @code{l1_data_A} attribute will be put into
-the specific section named @code{.l1.data.A}. Those with @code{l1_data_B}
-attribute will be put into the specific section named @code{.l1.data.B}.
-
-@item l2
-@cindex @code{l2} variable attribute
-Use this attribute on the Blackfin to place the variable into L2 SRAM.
-Variables with @code{l2} attribute will be put into the specific section
-named @code{.l2.data}.
-@end table
-
-@subsection M32R/D Variable Attributes
-
-One attribute is currently defined for the M32R/D@.
-
-@table @code
-@item model (@var{model-name})
-@cindex variable addressability on the M32R/D
-Use this attribute on the M32R/D to set the addressability of an object.
-The identifier @var{model-name} is one of @code{small}, @code{medium},
-or @code{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 @code{ld24} instruction).
-
-Medium and large model objects may live anywhere in the 32-bit address space
-(the compiler will generate @code{seth/add3} instructions to load their
-addresses).
-@end table
-
-@anchor{MeP Variable Attributes}
-@subsection MeP Variable Attributes
-
-The MeP target has a number of addressing modes and busses. The
-@code{near} space spans the standard memory space's first 16 megabytes
-(24 bits). The @code{far} space spans the entire 32-bit memory space.
-The @code{based} space is a 128 byte region in the memory space which
-is addressed relative to the @code{$tp} register. The @code{tiny}
-space is a 65536 byte region relative to the @code{$gp} register. In
-addition to these memory regions, the MeP target has a separate 16-bit
-control bus which is specified with @code{cb} attributes.
-
-@table @code
-
-@item based
-Any variable with the @code{based} attribute will be assigned to the
-@code{.based} section, and will be accessed with relative to the
-@code{$tp} register.
-
-@item tiny
-Likewise, the @code{tiny} attribute assigned variables to the
-@code{.tiny} section, relative to the @code{$gp} register.
-
-@item near
-Variables with the @code{near} attribute are assumed to have addresses
-that fit in a 24-bit addressing mode. This is the default for large
-variables (@code{-mtiny=4} is the default) but this attribute can
-override @code{-mtiny=} for small variables, or override @code{-ml}.
-
-@item far
-Variables with the @code{far} attribute are addressed using a full
-32-bit address. Since this covers the entire memory space, this
-allows modules to make no assumptions about where variables might be
-stored.
-
-@item io
-@itemx io (@var{addr})
-Variables with the @code{io} attribute are used to address
-memory-mapped peripherals. If an address is specified, the variable
-is assigned that address, else it is not assigned an address (it is
-assumed some other module will assign an address). Example:
-
-@example
-int timer_count __attribute__((io(0x123)));
-@end example
-
-@item cb
-@itemx cb (@var{addr})
-Variables with the @code{cb} attribute are used to access the control
-bus, using special instructions. @code{addr} indicates the control bus
-address. Example:
-
-@example
-int cpu_clock __attribute__((cb(0x123)));
-@end example
-
-@end table
-
-@anchor{i386 Variable Attributes}
-@subsection i386 Variable Attributes
-
-Two attributes are currently defined for i386 configurations:
-@code{ms_struct} and @code{gcc_struct}
-
-@table @code
-@item ms_struct
-@itemx gcc_struct
-@cindex @code{ms_struct} attribute
-@cindex @code{gcc_struct} attribute
-
-If @code{packed} is used on a structure, or if bit-fields are used
-it may be that the Microsoft ABI packs them differently
-than GCC would normally pack them. Particularly when moving packed
-data between functions compiled with GCC and the native Microsoft compiler
-(either via function call or as data in a file), it may be necessary to access
-either format.
-
-Currently @option{-m[no-]ms-bitfields} is provided for the Microsoft Windows X86
-compilers to match the native Microsoft compiler.
-
-The Microsoft structure layout algorithm is fairly simple with the exception
-of the bitfield packing:
-
-The padding and alignment of members of structures and whether a bit field
-can straddle a storage-unit boundary
-
-@enumerate
-@item Structure members are stored sequentially in the order in which they are
-declared: the first member has the lowest memory address and the last member
-the highest.
-
-@item Every data object has an alignment-requirement. The alignment-requirement
-for all data except structures, unions, and arrays is either the size of the
-object or the current packing size (specified with either the aligned attribute
-or the pack pragma), whichever is less. For structures, unions, and arrays,
-the alignment-requirement is the largest alignment-requirement of its members.
-Every object is allocated an offset so that:
-
-offset % alignment-requirement == 0
-
-@item Adjacent bit fields are packed into the same 1-, 2-, or 4-byte allocation
-unit if the integral types are the same size and if the next bit field fits
-into the current allocation unit without crossing the boundary imposed by the
-common alignment requirements of the bit fields.
-@end enumerate
-
-Handling of zero-length bitfields:
-
-MSVC interprets zero-length bitfields in the following ways:
-
-@enumerate
-@item If a zero-length bitfield is inserted between two bitfields that would
-normally be coalesced, the bitfields will not be coalesced.
-
-For example:
-
-@smallexample
-struct
- @{
- unsigned long bf_1 : 12;
- unsigned long : 0;
- unsigned long bf_2 : 12;
- @} t1;
-@end smallexample
-
-The size of @code{t1} would be 8 bytes with the zero-length bitfield. If the
-zero-length bitfield were removed, @code{t1}'s size would be 4 bytes.
-
-@item If a zero-length bitfield is inserted after a bitfield, @code{foo}, and the
-alignment of the zero-length bitfield is greater than the member that follows it,
-@code{bar}, @code{bar} will be aligned as the type of the zero-length bitfield.
-
-For example:
-
-@smallexample
-struct
- @{
- char foo : 4;
- short : 0;
- char bar;
- @} t2;
-
-struct
- @{
- char foo : 4;
- short : 0;
- double bar;
- @} t3;
-@end smallexample
-
-For @code{t2}, @code{bar} will be placed at offset 2, rather than offset 1.
-Accordingly, the size of @code{t2} will be 4. For @code{t3}, the zero-length
-bitfield will not affect the alignment of @code{bar} or, as a result, the size
-of the structure.
-
-Taking this into account, it is important to note the following:
-
-@enumerate
-@item If a zero-length bitfield follows a normal bitfield, the type of the
-zero-length bitfield may affect the alignment of the structure as whole. For
-example, @code{t2} has a size of 4 bytes, since the zero-length bitfield follows a
-normal bitfield, and is of type short.
-
-@item Even if a zero-length bitfield is not followed by a normal bitfield, it may
-still affect the alignment of the structure:
-
-@smallexample
-struct
- @{
- char foo : 6;
- long : 0;
- @} t4;
-@end smallexample
-
-Here, @code{t4} will take up 4 bytes.
-@end enumerate
-
-@item Zero-length bitfields following non-bitfield members are ignored:
-
-@smallexample
-struct
- @{
- char foo;
- long : 0;
- char bar;
- @} t5;
-@end smallexample
-
-Here, @code{t5} will take up 2 bytes.
-@end enumerate
-@end table
-
-@subsection PowerPC Variable Attributes
-
-Three attributes currently are defined for PowerPC configurations:
-@code{altivec}, @code{ms_struct} and @code{gcc_struct}.
-
-For full documentation of the struct attributes please see the
-documentation in @ref{i386 Variable Attributes}.
-
-For documentation of @code{altivec} attribute please see the
-documentation in @ref{PowerPC Type Attributes}.
-
-@subsection SPU Variable Attributes
-
-The SPU supports the @code{spu_vector} attribute for variables. For
-documentation of this attribute please see the documentation in
-@ref{SPU Type Attributes}.
-
-@subsection Xstormy16 Variable Attributes
-
-One attribute is currently defined for xstormy16 configurations:
-@code{below100}.
-
-@table @code
-@item below100
-@cindex @code{below100} attribute
-
-If a variable has the @code{below100} attribute (@code{BELOW100} is
-allowed also), GCC will place the variable in the first 0x100 bytes of
-memory and use special opcodes to access it. Such variables will be
-placed in either the @code{.bss_below100} section or the
-@code{.data_below100} section.
-
-@end table
-
-@subsection AVR Variable Attributes
-
-@table @code
-@item progmem
-@cindex @code{progmem} variable attribute
-The @code{progmem} attribute is used on the AVR to place data in the Program
-Memory address space. The AVR is a Harvard Architecture processor and data
-normally resides in the Data Memory address space.
-@end table
-
-@node Type Attributes
-@section Specifying Attributes of Types
-@cindex attribute of types
-@cindex type attributes
-
-The keyword @code{__attribute__} allows you to specify special
-attributes of @code{struct} and @code{union} types when you define
-such types. This keyword is followed by an attribute specification
-inside double parentheses. Seven attributes are currently defined for
-types: @code{aligned}, @code{packed}, @code{transparent_union},
-@code{unused}, @code{deprecated}, @code{visibility}, and
-@code{may_alias}. Other attributes are defined for functions
-(@pxref{Function Attributes}) and for variables (@pxref{Variable
-Attributes}).
-
-You may also specify any one of these attributes with @samp{__}
-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 @code{__aligned__}
-instead of @code{aligned}.
-
-You may specify type attributes in an enum, struct or union type
-declaration or definition, or for other types in a @code{typedef}
-declaration.
-
-For an enum, struct or union type, you may specify attributes either
-between the enum, struct or union tag and the name of the type, or
-just past the closing curly brace of the @emph{definition}. The
-former syntax is preferred.
-
-@xref{Attribute Syntax}, for details of the exact syntax for using
-attributes.
-
-@table @code
-@cindex @code{aligned} attribute
-@item aligned (@var{alignment})
-This attribute specifies a minimum alignment (in bytes) for variables
-of the specified type. For example, the declarations:
-
-@smallexample
-struct S @{ short f[3]; @} __attribute__ ((aligned (8)));
-typedef int more_aligned_int __attribute__ ((aligned (8)));
-@end smallexample
-
-@noindent
-force the compiler to insure (as far as it can) that each variable whose
-type is @code{struct S} or @code{more_aligned_int} will be allocated and
-aligned @emph{at least} on a 8-byte boundary. On a SPARC, having all
-variables of type @code{struct S} aligned to 8-byte boundaries allows
-the compiler to use the @code{ldd} and @code{std} (doubleword load and
-store) instructions when copying one variable of type @code{struct S} to
-another, thus improving run-time efficiency.
-
-Note that the alignment of any given @code{struct} or @code{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 @code{struct} or @code{union} in question. This means that you @emph{can}
-effectively adjust the alignment of a @code{struct} or @code{union}
-type by attaching an @code{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 @code{struct} or @code{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 @code{struct}
-or @code{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:
-
-@smallexample
-struct S @{ short f[3]; @} __attribute__ ((aligned));
-@end smallexample
-
-Whenever you leave out the alignment factor in an @code{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 @code{short} is 2 bytes, then
-the size of the entire @code{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 @code{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 @code{aligned} attribute can only increase the alignment; but you
-can decrease it by specifying @code{packed} as well. See below.
-
-Note that the effectiveness of @code{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 @code{aligned(16)}
-in an @code{__attribute__} will still only provide you with 8 byte
-alignment. See your linker documentation for further information.
-
-@item packed
-This attribute, attached to @code{struct} or @code{union} type
-definition, specifies that each member (other than zero-width bitfields)
-of the structure or union is placed to minimize the memory required. When
-attached to an @code{enum} definition, it indicates that the smallest
-integral type should be used.
-
-@opindex fshort-enums
-Specifying this attribute for @code{struct} and @code{union} types is
-equivalent to specifying the @code{packed} attribute on each of the
-structure or union members. Specifying the @option{-fshort-enums}
-flag on the line is equivalent to specifying the @code{packed}
-attribute on all @code{enum} definitions.
-
-In the following example @code{struct my_packed_struct}'s members are
-packed closely together, but the internal layout of its @code{s} member
-is not packed---to do that, @code{struct my_unpacked_struct} would need to
-be packed too.
-
-@smallexample
-struct my_unpacked_struct
- @{
- char c;
- int i;
- @};
-
-struct __attribute__ ((__packed__)) my_packed_struct
- @{
- char c;
- int i;
- struct my_unpacked_struct s;
- @};
-@end smallexample
-
-You may only specify this attribute on the definition of an @code{enum},
-@code{struct} or @code{union}, not on a @code{typedef} which does not
-also define the enumerated type, structure or union.
-
-@item transparent_union
-This attribute, attached to a @code{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 @code{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 the 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
-@code{wait} function must accept either a value of type @code{int *} to
-comply with Posix, or a value of type @code{union wait *} to comply with
-the 4.1BSD interface. If @code{wait}'s parameter were @code{void *},
-@code{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, @code{<sys/wait.h>} might define the interface
-as follows:
-
-@smallexample
-typedef union __attribute__ ((__transparent_union__))
- @{
- int *__ip;
- union wait *__up;
- @} wait_status_ptr_t;
-
-pid_t wait (wait_status_ptr_t);
-@end smallexample
-
-This interface allows either @code{int *} or @code{union wait *}
-arguments to be passed, using the @code{int *} calling convention.
-The program can call @code{wait} with arguments of either type:
-
-@smallexample
-int w1 () @{ int w; return wait (&w); @}
-int w2 () @{ union wait w; return wait (&w); @}
-@end smallexample
-
-With this interface, @code{wait}'s implementation might look like this:
-
-@smallexample
-pid_t wait (wait_status_ptr_t p)
-@{
- return waitpid (-1, p.__ip, 0);
-@}
-@end smallexample
-
-@item unused
-When attached to a type (including a @code{union} or a @code{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.
-
-@item deprecated
-@itemx deprecated (@var{msg})
-The @code{deprecated} attribute results in a warning if the type
-is used anywhere in the source file. This is useful when identifying
-types that are expected to be removed in a future version of a program.
-If possible, the warning also includes the location of the declaration
-of the deprecated type, to enable users to easily find further
-information about why the type is deprecated, or what they should do
-instead. Note that the warnings only occur for uses and then only
-if the type is being applied to an identifier that itself is not being
-declared as deprecated.
-
-@smallexample
-typedef int T1 __attribute__ ((deprecated));
-T1 x;
-typedef T1 T2;
-T2 y;
-typedef T1 T3 __attribute__ ((deprecated));
-T3 z __attribute__ ((deprecated));
-@end smallexample
-
-results in a warning on line 2 and 3 but not lines 4, 5, or 6. No
-warning is issued for line 4 because T2 is not explicitly
-deprecated. Line 5 has no warning because T3 is explicitly
-deprecated. Similarly for line 6. The optional msg
-argument, which must be a string, will be printed in the warning if
-present.
-
-The @code{deprecated} attribute can also be used for functions and
-variables (@pxref{Function Attributes}, @pxref{Variable Attributes}.)
-
-@item may_alias
-Accesses through pointers to types with this attribute are not subject
-to type-based alias analysis, but are instead assumed to be able to alias
-any other type of objects. In the context of 6.5/7 an lvalue expression
-dereferencing such a pointer is treated like having a character type.
-See @option{-fstrict-aliasing} for more information on aliasing issues.
-This extension exists to support some vector APIs, in which pointers to
-one vector type are permitted to alias pointers to a different vector type.
-
-Note that an object of a type with this attribute does not have any
-special semantics.
-
-Example of use:
-
-@smallexample
-typedef short __attribute__((__may_alias__)) short_a;
-
-int
-main (void)
-@{
- int a = 0x12345678;
- short_a *b = (short_a *) &a;
-
- b[1] = 0;
-
- if (a == 0x12345678)
- abort();
-
- exit(0);
-@}
-@end smallexample
-
-If you replaced @code{short_a} with @code{short} in the variable
-declaration, the above program would abort when compiled with
-@option{-fstrict-aliasing}, which is on by default at @option{-O2} or
-above in recent GCC versions.
-
-@item visibility
-In C++, attribute visibility (@pxref{Function Attributes}) can also be
-applied to class, struct, union and enum types. Unlike other type
-attributes, the attribute must appear between the initial keyword and
-the name of the type; it cannot appear after the body of the type.
-
-Note that the type visibility is applied to vague linkage entities
-associated with the class (vtable, typeinfo node, etc.). In
-particular, if a class is thrown as an exception in one shared object
-and caught in another, the class must have default visibility.
-Otherwise the two shared objects will be unable to use the same
-typeinfo node and exception handling will break.
-
-@end table
-
-@subsection ARM Type Attributes
-
-On those ARM targets that support @code{dllimport} (such as Symbian
-OS), you can use the @code{notshared} attribute to indicate that the
-virtual table and other similar data for a class should not be
-exported from a DLL@. For example:
-
-@smallexample
-class __declspec(notshared) C @{
-public:
- __declspec(dllimport) C();
- virtual void f();
-@}
-
-__declspec(dllexport)
-C::C() @{@}
-@end smallexample
-
-In this code, @code{C::C} is exported from the current DLL, but the
-virtual table for @code{C} is not exported. (You can use
-@code{__attribute__} instead of @code{__declspec} if you prefer, but
-most Symbian OS code uses @code{__declspec}.)
-
-@anchor{MeP Type Attributes}
-@subsection MeP Type Attributes
-
-Many of the MeP variable attributes may be applied to types as well.
-Specifically, the @code{based}, @code{tiny}, @code{near}, and
-@code{far} attributes may be applied to either. The @code{io} and
-@code{cb} attributes may not be applied to types.
-
-@anchor{i386 Type Attributes}
-@subsection i386 Type Attributes
-
-Two attributes are currently defined for i386 configurations:
-@code{ms_struct} and @code{gcc_struct}.
-
-@table @code
-
-@item ms_struct
-@itemx gcc_struct
-@cindex @code{ms_struct}
-@cindex @code{gcc_struct}
-
-If @code{packed} is used on a structure, or if bit-fields are used
-it may be that the Microsoft ABI packs them differently
-than GCC would normally pack them. Particularly when moving packed
-data between functions compiled with GCC and the native Microsoft compiler
-(either via function call or as data in a file), it may be necessary to access
-either format.
-
-Currently @option{-m[no-]ms-bitfields} is provided for the Microsoft Windows X86
-compilers to match the native Microsoft compiler.
-@end table
-
-To specify multiple attributes, separate them by commas within the
-double parentheses: for example, @samp{__attribute__ ((aligned (16),
-packed))}.
-
-@anchor{PowerPC Type Attributes}
-@subsection PowerPC Type Attributes
-
-Three attributes currently are defined for PowerPC configurations:
-@code{altivec}, @code{ms_struct} and @code{gcc_struct}.
-
-For full documentation of the @code{ms_struct} and @code{gcc_struct}
-attributes please see the documentation in @ref{i386 Type Attributes}.
-
-The @code{altivec} attribute allows one to declare AltiVec vector data
-types supported by the AltiVec Programming Interface Manual. The
-attribute requires an argument to specify one of three vector types:
-@code{vector__}, @code{pixel__} (always followed by unsigned short),
-and @code{bool__} (always followed by unsigned).
-
-@smallexample
-__attribute__((altivec(vector__)))
-__attribute__((altivec(pixel__))) unsigned short
-__attribute__((altivec(bool__))) unsigned
-@end smallexample
-
-These attributes mainly are intended to support the @code{__vector},
-@code{__pixel}, and @code{__bool} AltiVec keywords.
-
-@anchor{SPU Type Attributes}
-@subsection SPU Type Attributes
-
-The SPU supports the @code{spu_vector} attribute for types. This attribute
-allows one to declare vector data types supported by the Sony/Toshiba/IBM SPU
-Language Extensions Specification. It is intended to support the
-@code{__vector} keyword.
-
@node Alignment
@section Inquiring on Alignment of Types or Variables
@cindex alignment
--
1.7.4.18.g68fe8