gcc-5-source 5.3.1-14ubuntu2 / usr / src / gcc-5 / debian / patches / gcc-linaro-doc.diff

# DP: Changes for the Linaro 5-2016.03 snapshot (documentation).

--- a/src/gcc/doc/extend.texi
+++ b/src/gcc/doc/extend.texi
@@ -2147,62 +2147,84 @@ the enclosing block.
 @section Declaring Attributes of Functions
 @cindex function attributes
 @cindex declaring attributes of functions
-@cindex functions that never return
-@cindex functions that return more than once
-@cindex functions that have no side effects
-@cindex functions in arbitrary sections
-@cindex functions that behave like malloc
 @cindex @code{volatile} applied to function
 @cindex @code{const} applied to function
-@cindex functions with @code{printf}, @code{scanf}, @code{strftime} or @code{strfmon} style arguments
-@cindex functions with non-null pointer arguments
-@cindex functions that are passed arguments in registers on x86-32
-@cindex functions that pop the argument stack on x86-32
-@cindex functions that do not pop the argument stack on x86-32
-@cindex functions that have different compilation options on x86-32
-@cindex functions that have different optimization options
-@cindex functions that are dynamically resolved
 
-In GNU C, you declare certain things about functions called in your program
-which help the compiler optimize function calls and check your code more
-carefully.
-
-The keyword @code{__attribute__} allows you to specify special
-attributes when making a declaration.  This keyword is followed by an
-attribute specification inside double parentheses.  The following
-attributes are currently defined for functions on all targets:
-@code{aligned}, @code{alloc_size}, @code{alloc_align}, @code{assume_aligned},
-@code{noreturn}, @code{returns_twice}, @code{noinline}, @code{noclone},
-@code{no_icf},
-@code{always_inline}, @code{flatten}, @code{pure}, @code{const},
-@code{nothrow}, @code{sentinel}, @code{format}, @code{format_arg},
-@code{no_instrument_function}, @code{no_split_stack},
-@code{section}, @code{constructor},
-@code{destructor}, @code{used}, @code{unused}, @code{deprecated},
-@code{weak}, @code{malloc}, @code{alias}, @code{ifunc},
-@code{warn_unused_result}, @code{nonnull},
-@code{returns_nonnull}, @code{gnu_inline},
-@code{externally_visible}, @code{hot}, @code{cold}, @code{artificial},
-@code{no_sanitize_address}, @code{no_address_safety_analysis},
-@code{no_sanitize_thread},
-@code{no_sanitize_undefined}, @code{no_reorder}, @code{bnd_legacy},
-@code{bnd_instrument}, @code{stack_protect},
-@code{error} and @code{warning}.
-Several other attributes are defined for functions on particular
-target systems.  Other attributes, including @code{section} are
-supported for variables declarations (@pxref{Variable Attributes}),
-labels (@pxref{Label Attributes})
-and for types (@pxref{Type Attributes}).
+In GNU C, you can use function attributes to declare certain things
+about functions called in your program which help the compiler
+optimize calls and check your code more carefully.  For example, you
+can use attributes to declare that a function never returns
+(@code{noreturn}), returns a value depending only on its arguments
+(@code{pure}), or has @code{printf}-style arguments (@code{format}).
+
+You can also use attributes to control memory placement, code
+generation options or call/return conventions within the function
+being annotated.  Many of these attributes are target-specific.  For
+example, many targets support attributes for defining interrupt
+handler functions, which typically must follow special register usage
+and return conventions.
+
+Function attributes are introduced by the @code{__attribute__} keyword
+on a declaration, followed by an attribute specification inside double
+parentheses.  You can specify multiple attributes in a declaration by
+separating them by commas within the double parentheses or by
+immediately following an attribute declaration with another attribute
+declaration.  @xref{Attribute Syntax}, for the exact rules on
+attribute syntax and placement.
+
+GCC also supports attributes on
+variable declarations (@pxref{Variable Attributes}),
+labels (@pxref{Label Attributes}),
+and types (@pxref{Type Attributes}).
+
+There is some overlap between the purposes of attributes and pragmas
+(@pxref{Pragmas,,Pragmas Accepted by GCC}).  It has been
+found convenient to use @code{__attribute__} to achieve a natural
+attachment of attributes to their corresponding declarations, whereas
+@code{#pragma} is of use for compatibility with other compilers
+or constructs that do not naturally form part of the grammar.
 
+In addition to the attributes documented here,
 GCC plugins may provide their own attributes.
 
-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{__noreturn__} instead of @code{noreturn}.
+@menu
+* Common Function Attributes::
+* AArch64 Function Attributes::
+* ARC Function Attributes::
+* ARM Function Attributes::
+* AVR Function Attributes::
+* Blackfin Function Attributes::
+* CR16 Function Attributes::
+* Epiphany Function Attributes::
+* H8/300 Function Attributes::
+* IA-64 Function Attributes::
+* M32C Function Attributes::
+* M32R/D Function Attributes::
+* m68k Function Attributes::
+* MCORE Function Attributes::
+* MeP Function Attributes::
+* MicroBlaze Function Attributes::
+* Microsoft Windows Function Attributes::
+* MIPS Function Attributes::
+* MSP430 Function Attributes::
+* NDS32 Function Attributes::
+* Nios II Function Attributes::
+* PowerPC Function Attributes::
+* RL78 Function Attributes::
+* RX Function Attributes::
+* S/390 Function Attributes::
+* SH Function Attributes::
+* SPU Function Attributes::
+* Symbian OS Function Attributes::
+* Visium Function Attributes::
+* x86 Function Attributes::
+* Xstormy16 Function Attributes::
+@end menu
 
-@xref{Attribute Syntax}, for details of the exact syntax for using
-attributes.
+@node Common Function Attributes
+@subsection Common Function Attributes
+
+The following attributes are supported on most targets.
 
 @table @code
 @c Keep this table alphabetized by attribute name.  Treat _ as space.
@@ -2222,7 +2244,8 @@ defines @samp{f} to be a weak alias for @samp{__f}.  In C++, the
 mangled name for the target must be used.  It is an error if @samp{__f}
 is not defined in the same translation unit.
 
-Not all target machines support this attribute.
+This attribute requires assembler and object file support,
+and may not be available on all targets.
 
 @item aligned (@var{alignment})
 @cindex @code{aligned} function attribute
@@ -2245,31 +2268,6 @@ further information.
 The @code{aligned} attribute can also be used for variables and fields
 (@pxref{Variable Attributes}.)
 
-@item alloc_size
-@cindex @code{alloc_size} function attribute
-The @code{alloc_size} attribute is used to tell the compiler that the
-function return value points to memory, where the size is given by
-one or two of the functions parameters.  GCC uses this
-information to improve the correctness of @code{__builtin_object_size}.
-
-The function parameter(s) denoting the allocated size are specified by
-one or two integer arguments supplied to the attribute.  The allocated size
-is either the value of the single function argument specified or the product
-of the two function arguments specified.  Argument numbering starts at
-one.
-
-For instance,
-
-@smallexample
-void* my_calloc(size_t, size_t) __attribute__((alloc_size(1,2)))
-void* my_realloc(void*, size_t) __attribute__((alloc_size(2)))
-@end smallexample
-
-@noindent
-declares that @code{my_calloc} returns memory of the size given by
-the product of parameter 1 and 2 and that @code{my_realloc} returns memory
-of the size given by parameter 2.
-
 @item alloc_align
 @cindex @code{alloc_align} function attribute
 The @code{alloc_align} attribute is used to tell the compiler that the
@@ -2291,24 +2289,30 @@ void* my_memalign(size_t, size_t) __attribute__((alloc_align(1)))
 declares that @code{my_memalign} returns memory with minimum alignment
 given by parameter 1.
 
-@item assume_aligned
-@cindex @code{assume_aligned} function attribute
-The @code{assume_aligned} attribute is used to tell the compiler that the
-function return value points to memory, where the returned pointer minimum
-alignment is given by the first argument.
-If the attribute has two arguments, the second argument is misalignment offset.
+@item alloc_size
+@cindex @code{alloc_size} function attribute
+The @code{alloc_size} attribute is used to tell the compiler that the
+function return value points to memory, where the size is given by
+one or two of the functions parameters.  GCC uses this
+information to improve the correctness of @code{__builtin_object_size}.
 
-For instance
+The function parameter(s) denoting the allocated size are specified by
+one or two integer arguments supplied to the attribute.  The allocated size
+is either the value of the single function argument specified or the product
+of the two function arguments specified.  Argument numbering starts at
+one.
+
+For instance,
 
 @smallexample
-void* my_alloc1(size_t) __attribute__((assume_aligned(16)))
-void* my_alloc2(size_t) __attribute__((assume_aligned(32, 8)))
+void* my_calloc(size_t, size_t) __attribute__((alloc_size(1,2)))
+void* my_realloc(void*, size_t) __attribute__((alloc_size(2)))
 @end smallexample
 
 @noindent
-declares that @code{my_alloc1} returns 16-byte aligned pointer and
-that @code{my_alloc2} returns a pointer whose value modulo 32 is equal
-to 8.
+declares that @code{my_calloc} returns memory of the size given by
+the product of parameter 1 and 2 and that @code{my_realloc} returns memory
+of the size given by parameter 2.
 
 @item always_inline
 @cindex @code{always_inline} function attribute
@@ -2320,44 +2324,6 @@ Note that if such a function is called indirectly the compiler may
 or may not inline it depending on optimization level and a failure
 to inline an indirect call may or may not be diagnosed.
 
-@item gnu_inline
-@cindex @code{gnu_inline} function attribute
-This attribute should be used with a function that is also declared
-with the @code{inline} keyword.  It directs GCC to treat the function
-as if it were defined in gnu90 mode even when compiling in C99 or
-gnu99 mode.
-
-If the function is declared @code{extern}, then this definition of the
-function is used only for inlining.  In no case is the function
-compiled as a standalone function, not even if you take its address
-explicitly.  Such an address becomes an external reference, as if you
-had only declared the function, and had not defined it.  This has
-almost the effect of a macro.  The way to use this is to put a
-function definition in a header file with this attribute, and put
-another copy of the function, without @code{extern}, in a library
-file.  The definition in the header file causes most calls to the
-function to be inlined.  If any uses of the function remain, they
-refer to the single copy in the library.  Note that the two
-definitions of the functions need not be precisely the same, although
-if they do not have the same effect your program may behave oddly.
-
-In C, if the function is neither @code{extern} nor @code{static}, then
-the function is compiled as a standalone function, as well as being
-inlined where possible.
-
-This is how GCC traditionally handled functions declared
-@code{inline}.  Since ISO C99 specifies a different semantics for
-@code{inline}, this function attribute is provided as a transition
-measure and as a useful feature in its own right.  This attribute is
-available in GCC 4.1.3 and later.  It is available if either of the
-preprocessor macros @code{__GNUC_GNU_INLINE__} or
-@code{__GNUC_STDC_INLINE__} are defined.  @xref{Inline,,An Inline
-Function is As Fast As a Macro}.
-
-In C++, this attribute does not depend on @code{extern} in any way,
-but it still requires the @code{inline} keyword to enable its special
-behavior.
-
 @item artificial
 @cindex @code{artificial} function attribute
 This attribute is useful for small inline wrappers that if possible
@@ -2366,54 +2332,56 @@ info format it either means marking the function as artificial
 or using the caller location for all instructions within the inlined
 body.
 
-@item bank_switch
-@cindex @code{bank_switch} function attribute, M32C
-When added to an interrupt handler with the M32C port, causes the
-prologue and epilogue to use bank switching to preserve the registers
-rather than saving them on the stack.
+@item assume_aligned
+@cindex @code{assume_aligned} function attribute
+The @code{assume_aligned} attribute is used to tell the compiler that the
+function return value points to memory, where the returned pointer minimum
+alignment is given by the first argument.
+If the attribute has two arguments, the second argument is misalignment offset.
 
-@item flatten
-@cindex @code{flatten} function attribute
-Generally, inlining into a function is limited.  For a function marked with
-this attribute, every call inside this function is inlined, if possible.
-Whether the function itself is considered for inlining depends on its size and
-the current inlining parameters.
+For instance
 
-@item error ("@var{message}")
-@cindex @code{error} function attribute
-If this attribute is used on a function declaration and a call to such a function
-is not eliminated through dead code elimination or other optimizations, an error
-that includes @var{message} is diagnosed.  This is useful
-for compile-time checking, especially together with @code{__builtin_constant_p}
-and inline functions where checking the inline function arguments is not
-possible through @code{extern char [(condition) ? 1 : -1];} tricks.
-While it is possible to leave the function undefined and thus invoke
-a link failure, when using this attribute the problem is diagnosed
-earlier and with exact location of the call even in presence of inline
-functions or when not emitting debugging information.
+@smallexample
+void* my_alloc1(size_t) __attribute__((assume_aligned(16)))
+void* my_alloc2(size_t) __attribute__((assume_aligned(32, 8)))
+@end smallexample
 
-@item warning ("@var{message}")
-@cindex @code{warning} function attribute
-If this attribute is used on a function declaration and a call to such a function
-is not eliminated through dead code elimination or other optimizations, a warning
-that includes @var{message} is diagnosed.  This is useful
-for compile-time checking, especially together with @code{__builtin_constant_p}
-and inline functions.  While it is possible to define the function with
-a message in @code{.gnu.warning*} section, when using this attribute the problem
-is diagnosed earlier and with exact location of the call even in presence
-of inline functions or when not emitting debugging information.
+@noindent
+declares that @code{my_alloc1} returns 16-byte aligned pointer and
+that @code{my_alloc2} returns a pointer whose value modulo 32 is equal
+to 8.
 
-@item cdecl
-@cindex @code{cdecl} function attribute, x86-32
-@cindex functions that do pop the argument stack on x86-32
-@opindex mrtd
-On the x86-32 targets, the @code{cdecl} attribute causes the compiler to
-assume that the calling function pops off the stack space used to
-pass arguments.  This is
-useful to override the effects of the @option{-mrtd} switch.
+@item bnd_instrument
+@cindex @code{bnd_instrument} function attribute
+The @code{bnd_instrument} attribute on functions is used to inform the
+compiler that the function should be instrumented when compiled
+with the @option{-fchkp-instrument-marked-only} option.
+
+@item bnd_legacy
+@cindex @code{bnd_legacy} function attribute
+@cindex Pointer Bounds Checker attributes
+The @code{bnd_legacy} attribute on functions is used to inform the
+compiler that the function should not be instrumented when compiled
+with the @option{-fcheck-pointer-bounds} option.
+
+@item cold
+@cindex @code{cold} function attribute
+The @code{cold} attribute on functions is used to inform the compiler that
+the function is unlikely to be executed.  The function is optimized for
+size rather than speed and on many targets it is placed into a special
+subsection of the text section so all cold functions appear close together,
+improving code locality of non-cold parts of program.  The paths leading
+to calls of cold functions within code are marked as unlikely by the branch
+prediction mechanism.  It is thus useful to mark functions used to handle
+unlikely conditions, such as @code{perror}, as cold to improve optimization
+of hot functions that do call marked functions in rare occasions.
+
+When profile feedback is available, via @option{-fprofile-use}, cold functions
+are automatically detected and this attribute is ignored.
 
 @item const
 @cindex @code{const} function attribute
+@cindex functions that have no side effects
 Many functions do not examine any values except their arguments, and
 have no effects except the return value.  Basically this is just slightly
 more strict class than the @code{pure} attribute below, since function is not
@@ -2477,184 +2445,62 @@ present.
 The @code{deprecated} attribute can also be used for variables and
 types (@pxref{Variable Attributes}, @pxref{Type Attributes}.)
 
-@item disinterrupt
-@cindex @code{disinterrupt} function attribute, Epiphany
-@cindex @code{disinterrupt} function attribute, MeP
-On Epiphany and MeP targets, this attribute causes the compiler to emit
-instructions to disable interrupts for the duration of the given
-function.
+@item error ("@var{message}")
+@itemx warning ("@var{message}")
+@cindex @code{error} function attribute
+@cindex @code{warning} function attribute
+If the @code{error} or @code{warning} attribute 
+is used on a function declaration and a call to such a function
+is not eliminated through dead code elimination or other optimizations, 
+an error or warning (respectively) that includes @var{message} is diagnosed.  
+This is useful
+for compile-time checking, especially together with @code{__builtin_constant_p}
+and inline functions where checking the inline function arguments is not
+possible through @code{extern char [(condition) ? 1 : -1];} tricks.
 
-@item dllexport
-@cindex @code{dllexport} function attribute
-@cindex @code{__declspec(dllexport)}
-On Microsoft Windows targets and Symbian OS targets the
-@code{dllexport} attribute causes the compiler to provide a global
-pointer to a pointer in a DLL, so that it can be referenced with the
-@code{dllimport} attribute.  On Microsoft Windows targets, the pointer
-name is formed by combining @code{_imp__} and the function or variable
-name.
+While it is possible to leave the function undefined and thus invoke
+a link failure (to define the function with
+a message in @code{.gnu.warning*} section),
+when using these attributes the problem is diagnosed
+earlier and with exact location of the call even in presence of inline
+functions or when not emitting debugging information.
 
-You can use @code{__declspec(dllexport)} as a synonym for
-@code{__attribute__ ((dllexport))} for compatibility with other
-compilers.
+@item externally_visible
+@cindex @code{externally_visible} function attribute
+This attribute, attached to a global variable or function, nullifies
+the effect of the @option{-fwhole-program} command-line option, so the
+object remains visible outside the current compilation unit.
 
-On systems that support the @code{visibility} attribute, this
-attribute also implies ``default'' visibility.  It is an error to
-explicitly specify any other visibility.
+If @option{-fwhole-program} is used together with @option{-flto} and 
+@command{gold} is used as the linker plugin, 
+@code{externally_visible} attributes are automatically added to functions 
+(not variable yet due to a current @command{gold} issue) 
+that are accessed outside of LTO objects according to resolution file
+produced by @command{gold}.
+For other linkers that cannot generate resolution file,
+explicit @code{externally_visible} attributes are still necessary.
 
-GCC's default behavior is to emit all inline functions with the
-@code{dllexport} attribute.  Since this can cause object file-size bloat,
-you can use @option{-fno-keep-inline-dllexport}, which tells GCC to
-ignore the attribute for inlined functions unless the 
-@option{-fkeep-inline-functions} flag is used instead.
+@item flatten
+@cindex @code{flatten} function attribute
+Generally, inlining into a function is limited.  For a function marked with
+this attribute, every call inside this function is inlined, if possible.
+Whether the function itself is considered for inlining depends on its size and
+the current inlining parameters.
 
-The attribute is ignored for undefined symbols.
+@item format (@var{archetype}, @var{string-index}, @var{first-to-check})
+@cindex @code{format} function attribute
+@cindex functions with @code{printf}, @code{scanf}, @code{strftime} or @code{strfmon} style arguments
+@opindex Wformat
+The @code{format} attribute specifies that a function takes @code{printf},
+@code{scanf}, @code{strftime} or @code{strfmon} style arguments that
+should be type-checked against a format string.  For example, the
+declaration:
 
-When applied to C++ classes, the attribute marks defined non-inlined
-member functions and static data members as exports.  Static consts
-initialized in-class are not marked unless they are also defined
-out-of-class.
-
-For Microsoft Windows targets there are alternative methods for
-including the symbol in the DLL's export table such as using a
-@file{.def} file with an @code{EXPORTS} section or, with GNU ld, using
-the @option{--export-all} linker flag.
-
-@item dllimport
-@cindex @code{dllimport} function attribute
-@cindex @code{__declspec(dllimport)}
-On Microsoft Windows and Symbian OS targets, the @code{dllimport}
-attribute causes the compiler to reference a function or variable via
-a global pointer to a pointer that is set up by the DLL exporting the
-symbol.  The attribute implies @code{extern}.  On Microsoft Windows
-targets, the pointer name is formed by combining @code{_imp__} and the
-function or variable name.
-
-You can use @code{__declspec(dllimport)} as a synonym for
-@code{__attribute__ ((dllimport))} for compatibility with other
-compilers.
-
-On systems that support the @code{visibility} attribute, this
-attribute also implies ``default'' visibility.  It is an error to
-explicitly specify any other visibility.
-
-Currently, the attribute is ignored for inlined functions.  If the
-attribute is applied to a symbol @emph{definition}, an error is reported.
-If a symbol previously declared @code{dllimport} is later defined, the
-attribute is ignored in subsequent references, and a warning is emitted.
-The attribute is also overridden by a subsequent declaration as
-@code{dllexport}.
-
-When applied to C++ classes, the attribute marks non-inlined
-member functions and static data members as imports.  However, the
-attribute is ignored for virtual methods to allow creation of vtables
-using thunks.
-
-On the SH Symbian OS target the @code{dllimport} attribute also has
-another affect---it can cause the vtable and run-time type information
-for a class to be exported.  This happens when the class has a
-dllimported constructor or a non-inline, non-pure virtual function
-and, for either of those two conditions, the class also has an inline
-constructor or destructor and has a key function that is defined in
-the current translation unit.
-
-For Microsoft Windows targets the use of the @code{dllimport}
-attribute on functions is not necessary, but provides a small
-performance benefit by eliminating a thunk in the DLL@.  The use of the
-@code{dllimport} attribute on imported variables can be avoided by passing the
-@option{--enable-auto-import} switch to the GNU linker.  As with
-functions, using the attribute for a variable eliminates a thunk in
-the DLL@.
-
-One drawback to using this attribute is that a pointer to a
-@emph{variable} marked as @code{dllimport} cannot be used as a constant
-address. However, a pointer to a @emph{function} with the
-@code{dllimport} attribute can be used as a constant initializer; in
-this case, the address of a stub function in the import lib is
-referenced.  On Microsoft Windows targets, the attribute can be disabled
-for functions by setting the @option{-mnop-fun-dllimport} flag.
-
-@item exception
-@cindex @code{exception} function attribute
-@cindex exception handler functions, NDS32
-Use this attribute on the NDS32 target to indicate that the specified function
-is an exception handler.  The compiler will generate corresponding sections
-for use in an exception handler.
-
-@item exception_handler
-@cindex @code{exception_handler} function attribute
-@cindex exception handler functions, Blackfin
-Use this attribute on the Blackfin to indicate that the specified function
-is an exception handler.  The compiler generates function entry and
-exit sequences suitable for use in an exception handler when this
-attribute is present.
-
-@item externally_visible
-@cindex @code{externally_visible} function attribute
-This attribute, attached to a global variable or function, nullifies
-the effect of the @option{-fwhole-program} command-line option, so the
-object remains visible outside the current compilation unit.
-
-If @option{-fwhole-program} is used together with @option{-flto} and 
-@command{gold} is used as the linker plugin, 
-@code{externally_visible} attributes are automatically added to functions 
-(not variable yet due to a current @command{gold} issue) 
-that are accessed outside of LTO objects according to resolution file
-produced by @command{gold}.
-For other linkers that cannot generate resolution file,
-explicit @code{externally_visible} attributes are still necessary.
-
-@item far
-@cindex @code{far} function attribute
-
-On MeP targets this causes the compiler to use a calling convention
-that assumes the called function is too far away for the built-in
-addressing modes.
-
-@item fast_interrupt
-@cindex @code{fast_interrupt} function attribute, M32C
-@cindex @code{fast_interrupt} function attribute, RX
-Use this attribute on the M32C and RX ports to indicate that the specified
-function is a fast interrupt handler.  This is just like the
-@code{interrupt} attribute, except that @code{freit} is used to return
-instead of @code{reit}.
-
-@item fastcall
-@cindex @code{fastcall} function attribute, x86-32
-@cindex functions that pop the argument stack on x86-32
-On x86-32 targets, the @code{fastcall} attribute causes the compiler to
-pass the first argument (if of integral type) in the register ECX and
-the second argument (if of integral type) in the register EDX@.  Subsequent
-and other typed arguments are passed on the stack.  The called function
-pops the arguments off the stack.  If the number of arguments is variable all
-arguments are pushed on the stack.
-
-@item thiscall
-@cindex @code{thiscall} function attribute, x86-32
-@cindex functions that pop the argument stack on x86-32
-On x86-32 targets, the @code{thiscall} attribute causes the compiler to
-pass the first argument (if of integral type) in the register ECX.
-Subsequent and other typed arguments are passed on the stack. The called
-function pops the arguments off the stack.
-If the number of arguments is variable all arguments are pushed on the
-stack.
-The @code{thiscall} attribute is intended for C++ non-static member functions.
-As a GCC extension, this calling convention can be used for C functions
-and for static member methods.
-
-@item format (@var{archetype}, @var{string-index}, @var{first-to-check})
-@cindex @code{format} function attribute
-@opindex Wformat
-The @code{format} attribute specifies that a function takes @code{printf},
-@code{scanf}, @code{strftime} or @code{strfmon} style arguments that
-should be type-checked against a format string.  For example, the
-declaration:
-
-@smallexample
-extern int
-my_printf (void *my_object, const char *my_format, ...)
-      __attribute__ ((format (printf, 2, 3)));
-@end smallexample
+@smallexample
+extern int
+my_printf (void *my_object, const char *my_format, ...)
+      __attribute__ ((format (printf, 2, 3)));
+@end smallexample
 
 @noindent
 causes the compiler to check the arguments in calls to @code{my_printf}
@@ -2771,72 +2617,59 @@ The target may also allow additional types in @code{format-arg} attributes.
 @xref{Target Format Checks,,Format Checks Specific to Particular
 Target Machines}.
 
-@item function_vector
-@cindex @code{function_vector} function attribute, H8/300
-@cindex @code{function_vector} function attribute, M16C/M32C
-@cindex @code{function_vector} function attribute, SH
-@cindex calling functions through the function vector on H8/300, M16C, M32C and SH2A processors
-Use this attribute on the H8/300, H8/300H, and H8S to indicate that the specified
-function should be called through the function vector.  Calling a
-function through the function vector reduces code size, however;
-the function vector has a limited size (maximum 128 entries on the H8/300
-and 64 entries on the H8/300H and H8S) and shares space with the interrupt vector.
-
-On SH2A targets, this attribute declares a function to be called using the
-TBR relative addressing mode.  The argument to this attribute is the entry
-number of the same function in a vector table containing all the TBR
-relative addressable functions.  For correct operation the TBR must be setup
-accordingly to point to the start of the vector table before any functions with
-this attribute are invoked.  Usually a good place to do the initialization is
-the startup routine.  The TBR relative vector table can have at max 256 function
-entries.  The jumps to these functions are generated using a SH2A specific,
-non delayed branch instruction JSR/N @@(disp8,TBR).  You must use GAS and GLD
-from GNU binutils version 2.7 or later for this attribute to work correctly.
-
-Please refer the example of M16C target, to see the use of this
-attribute while declaring a function,
-
-In an application, for a function being called once, this attribute
-saves at least 8 bytes of code; and if other successive calls are being
-made to the same function, it saves 2 bytes of code per each of these
-calls.
+@item gnu_inline
+@cindex @code{gnu_inline} function attribute
+This attribute should be used with a function that is also declared
+with the @code{inline} keyword.  It directs GCC to treat the function
+as if it were defined in gnu90 mode even when compiling in C99 or
+gnu99 mode.
 
-On M16C/M32C targets, the @code{function_vector} attribute declares a
-special page subroutine call function. Use of this attribute reduces
-the code size by 2 bytes for each call generated to the
-subroutine. The argument to the attribute is the vector number entry
-from the special page vector table which contains the 16 low-order
-bits of the subroutine's entry address. Each vector table has special
-page number (18 to 255) that is used in @code{jsrs} instructions.
-Jump addresses of the routines are generated by adding 0x0F0000 (in
-case of M16C targets) or 0xFF0000 (in case of M32C targets), to the
-2-byte addresses set in the vector table. Therefore you need to ensure
-that all the special page vector routines should get mapped within the
-address range 0x0F0000 to 0x0FFFFF (for M16C) and 0xFF0000 to 0xFFFFFF
-(for M32C).
+If the function is declared @code{extern}, then this definition of the
+function is used only for inlining.  In no case is the function
+compiled as a standalone function, not even if you take its address
+explicitly.  Such an address becomes an external reference, as if you
+had only declared the function, and had not defined it.  This has
+almost the effect of a macro.  The way to use this is to put a
+function definition in a header file with this attribute, and put
+another copy of the function, without @code{extern}, in a library
+file.  The definition in the header file causes most calls to the
+function to be inlined.  If any uses of the function remain, they
+refer to the single copy in the library.  Note that the two
+definitions of the functions need not be precisely the same, although
+if they do not have the same effect your program may behave oddly.
 
-In the following example 2 bytes are saved for each call to
-function @code{foo}.
+In C, if the function is neither @code{extern} nor @code{static}, then
+the function is compiled as a standalone function, as well as being
+inlined where possible.
 
-@smallexample
-void foo (void) __attribute__((function_vector(0x18)));
-void foo (void)
-@{
-@}
+This is how GCC traditionally handled functions declared
+@code{inline}.  Since ISO C99 specifies a different semantics for
+@code{inline}, this function attribute is provided as a transition
+measure and as a useful feature in its own right.  This attribute is
+available in GCC 4.1.3 and later.  It is available if either of the
+preprocessor macros @code{__GNUC_GNU_INLINE__} or
+@code{__GNUC_STDC_INLINE__} are defined.  @xref{Inline,,An Inline
+Function is As Fast As a Macro}.
 
-void bar (void)
-@{
-    foo();
-@}
-@end smallexample
+In C++, this attribute does not depend on @code{extern} in any way,
+but it still requires the @code{inline} keyword to enable its special
+behavior.
 
-If functions are defined in one file and are called in another file,
-then be sure to write this declaration in both files.
+@item hot
+@cindex @code{hot} function attribute
+The @code{hot} attribute on a function is used to inform the compiler that
+the function is a hot spot of the compiled program.  The function is
+optimized more aggressively and on many targets it is placed into a special
+subsection of the text section so all hot functions appear close together,
+improving locality.
 
-This attribute is ignored for R8C target.
+When profile feedback is available, via @option{-fprofile-use}, hot functions
+are automatically detected and this attribute is ignored.
 
 @item ifunc ("@var{resolver}")
 @cindex @code{ifunc} function attribute
+@cindex indirect functions
+@cindex functions that are dynamically resolved
 The @code{ifunc} attribute is used to mark a function as an indirect
 function using the STT_GNU_IFUNC symbol type extension to the ELF
 standard.  This allows the resolution of the symbol value to be
@@ -2883,324 +2716,753 @@ Indirect functions cannot be weak.  Binutils version 2.20.1 or higher
 and GNU C Library version 2.11.1 are required to use this feature.
 
 @item interrupt
-@cindex @code{interrupt} function attribute, ARC
-@cindex @code{interrupt} function attribute, ARM
-@cindex @code{interrupt} function attribute, AVR
-@cindex @code{interrupt} function attribute, CR16
-@cindex @code{interrupt} function attribute, Epiphany
-@cindex @code{interrupt} function attribute, M32C
-@cindex @code{interrupt} function attribute, M32R/D
-@cindex @code{interrupt} function attribute, m68k
-@cindex @code{interrupt} function attribute, MeP
-@cindex @code{interrupt} function attribute, MIPS
-@cindex @code{interrupt} function attribute, MSP430
-@cindex @code{interrupt} function attribute, NDS32
-@cindex @code{interrupt} function attribute, RL78
-@cindex @code{interrupt} function attribute, RX
-@cindex @code{interrupt} function attribute, Visium
-@cindex @code{interrupt} function attribute, Xstormy16
-Use this attribute on the ARC, ARM, AVR, CR16, Epiphany, M32C, M32R/D,
-m68k, MeP, MIPS, MSP430, NDS32, RL78, RX, Visium and Xstormy16 ports to indicate
-that the specified function is an interrupt handler.  The compiler generates
-function entry and exit sequences suitable for use in an interrupt handler
-when this attribute is present.  With Epiphany targets it may also generate
-a special section with code to initialize the interrupt vector table.
-
-Note, interrupt handlers for the Blackfin, H8/300, H8/300H, H8S, MicroBlaze,
-and SH processors can be specified via the @code{interrupt_handler} attribute.
+@itemx interrupt_handler
+Many GCC back ends support attributes to indicate that a function is
+an interrupt handler, which tells the compiler to generate function
+entry and exit sequences that differ from those from regular
+functions.  The exact syntax and behavior are target-specific;
+refer to the following subsections for details.
 
-Note, on the ARC, you must specify the kind of interrupt to be handled
-in a parameter to the interrupt attribute like this:
-
-@smallexample
-void f () __attribute__ ((interrupt ("ilink1")));
-@end smallexample
+@item leaf
+@cindex @code{leaf} function attribute
+Calls to external functions with this attribute must return to the current
+compilation unit only by return or by exception handling.  In particular, leaf
+functions are not allowed to call callback function passed to it from the current
+compilation unit or directly call functions exported by the unit or longjmp
+into the unit.  Leaf function might still call functions from other compilation
+units and thus they are not necessarily leaf in the sense that they contain no
+function calls at all.
 
-Permissible values for this parameter are: @w{@code{ilink1}} and
-@w{@code{ilink2}}.
+The attribute is intended for library functions to improve dataflow analysis.
+The compiler takes the hint that any data not escaping the current compilation unit can
+not be used or modified by the leaf function.  For example, the @code{sin} function
+is a leaf function, but @code{qsort} is not.
 
-Note, on the AVR, the hardware globally disables interrupts when an
-interrupt is executed.  The first instruction of an interrupt handler
-declared with this attribute is a @code{SEI} instruction to
-re-enable interrupts.  See also the @code{signal} function attribute
-that does not insert a @code{SEI} instruction.  If both @code{signal} and
-@code{interrupt} are specified for the same function, @code{signal}
-is silently ignored.
+Note that leaf functions might invoke signals and signal handlers might be
+defined in the current compilation unit and use static variables.  The only
+compliant way to write such a signal handler is to declare such variables
+@code{volatile}.
 
-Note, for the ARM, you can specify the kind of interrupt to be handled by
-adding an optional parameter to the interrupt attribute like this:
+The attribute has no effect on functions defined within the current compilation
+unit.  This is to allow easy merging of multiple compilation units into one,
+for example, by using the link-time optimization.  For this reason the
+attribute is not allowed on types to annotate indirect calls.
 
-@smallexample
-void f () __attribute__ ((interrupt ("IRQ")));
-@end smallexample
 
-@noindent
-Permissible values for this parameter are: @code{IRQ}, @code{FIQ},
-@code{SWI}, @code{ABORT} and @code{UNDEF}.
+@item malloc
+@cindex @code{malloc} function attribute
+@cindex functions that behave like malloc
+This tells the compiler that a function is @code{malloc}-like, i.e.,
+that the pointer @var{P} returned by the function cannot alias any
+other pointer valid when the function returns, and moreover no
+pointers to valid objects occur in any storage addressed by @var{P}.
 
-On ARMv7-M the interrupt type is ignored, and the attribute means the function
-may be called with a word-aligned stack pointer.
+Using this attribute can improve optimization.  Functions like
+@code{malloc} and @code{calloc} have this property because they return
+a pointer to uninitialized or zeroed-out storage.  However, functions
+like @code{realloc} do not have this property, as they can return a
+pointer to storage containing pointers.
 
-Note, for the MSP430 you can provide an argument to the interrupt
-attribute which specifies a name or number.  If the argument is a
-number it indicates the slot in the interrupt vector table (0 - 31) to
-which this handler should be assigned.  If the argument is a name it
-is treated as a symbolic name for the vector slot.  These names should
-match up with appropriate entries in the linker script.  By default
-the names @code{watchdog} for vector 26, @code{nmi} for vector 30 and
-@code{reset} for vector 31 are recognized.
+@item no_icf
+@cindex @code{no_icf} function attribute
+This function attribute prevents a functions from being merged with another
+semantically equivalent function.
+
+@item no_instrument_function
+@cindex @code{no_instrument_function} function attribute
+@opindex finstrument-functions
+If @option{-finstrument-functions} is given, profiling function calls are
+generated at entry and exit of most user-compiled functions.
+Functions with this attribute are not so instrumented.
 
-You can also use the following function attributes to modify how
-normal functions interact with interrupt functions:
+@item no_reorder
+@cindex @code{no_reorder} function attribute
+Do not reorder functions or variables marked @code{no_reorder}
+against each other or top level assembler statements the executable.
+The actual order in the program will depend on the linker command
+line. Static variables marked like this are also not removed.
+This has a similar effect
+as the @option{-fno-toplevel-reorder} option, but only applies to the
+marked symbols.
 
-@table @code
-@item critical
-@cindex @code{critical} function attribute, MSP430
-Critical functions disable interrupts upon entry and restore the
-previous interrupt state upon exit.  Critical functions cannot also
-have the @code{naked} or @code{reentrant} attributes.  They can have
-the @code{interrupt} attribute.
+@item no_sanitize_address
+@itemx no_address_safety_analysis
+@cindex @code{no_sanitize_address} function attribute
+The @code{no_sanitize_address} attribute on functions is used
+to inform the compiler that it should not instrument memory accesses
+in the function when compiling with the @option{-fsanitize=address} option.
+The @code{no_address_safety_analysis} is a deprecated alias of the
+@code{no_sanitize_address} attribute, new code should use
+@code{no_sanitize_address}.
 
-@item reentrant
-@cindex @code{reentrant} function attribute, MSP430
-Reentrant functions disable interrupts upon entry and enable them
-upon exit.  Reentrant functions cannot also have the @code{naked}
-or @code{critical} attributes.  They can have the @code{interrupt}
-attribute.
+@item no_sanitize_thread
+@cindex @code{no_sanitize_thread} function attribute
+The @code{no_sanitize_thread} attribute on functions is used
+to inform the compiler that it should not instrument memory accesses
+in the function when compiling with the @option{-fsanitize=thread} option.
 
-@item wakeup
-@cindex @code{wakeup} function attribute, MSP430
-This attribute only applies to interrupt functions.  It is silently
-ignored if applied to a non-interrupt function.  A wakeup interrupt
-function will rouse the processor from any low-power state that it
-might be in when the function exits.
+@item no_sanitize_undefined
+@cindex @code{no_sanitize_undefined} function attribute
+The @code{no_sanitize_undefined} attribute on functions is used
+to inform the compiler that it should not check for undefined behavior
+in the function when compiling with the @option{-fsanitize=undefined} option.
 
-@end table
+@item no_split_stack
+@cindex @code{no_split_stack} function attribute
+@opindex fsplit-stack
+If @option{-fsplit-stack} is given, functions have a small
+prologue which decides whether to split the stack.  Functions with the
+@code{no_split_stack} attribute do not have that prologue, and thus
+may run with only a small amount of stack space available.
 
-On Epiphany targets one or more optional parameters can be added like this:
+@item noclone
+@cindex @code{noclone} function attribute
+This function attribute prevents a function from being considered for
+cloning---a mechanism that produces specialized copies of functions
+and which is (currently) performed by interprocedural constant
+propagation.
 
+@item noinline
+@cindex @code{noinline} function attribute
+This function attribute prevents a function from being considered for
+inlining.
+@c Don't enumerate the optimizations by name here; we try to be
+@c future-compatible with this mechanism.
+If the function does not have side-effects, there are optimizations
+other than inlining that cause function calls to be optimized away,
+although the function call is live.  To keep such calls from being
+optimized away, put
 @smallexample
-void __attribute__ ((interrupt ("dma0, dma1"))) universal_dma_handler ();
+asm ("");
 @end smallexample
 
-Permissible values for these parameters are: @w{@code{reset}},
-@w{@code{software_exception}}, @w{@code{page_miss}},
-@w{@code{timer0}}, @w{@code{timer1}}, @w{@code{message}},
-@w{@code{dma0}}, @w{@code{dma1}}, @w{@code{wand}} and @w{@code{swi}}.
-Multiple parameters indicate that multiple entries in the interrupt
-vector table should be initialized for this function, i.e.@: for each
-parameter @w{@var{name}}, a jump to the function is emitted in
-the section @w{ivt_entry_@var{name}}.  The parameter(s) may be omitted
-entirely, in which case no interrupt vector table entry is provided.
-
-Note, on Epiphany targets, interrupts are enabled inside the function
-unless the @code{disinterrupt} attribute is also specified.
+@noindent
+(@pxref{Extended Asm}) in the called function, to serve as a special
+side-effect.
 
-On Epiphany targets, you can also use the following attribute to
-modify the behavior of an interrupt handler:
-@table @code
-@item forwarder_section
-@cindex @code{forwarder_section} function attribute, Epiphany
-The interrupt handler may be in external memory which cannot be
-reached by a branch instruction, so generate a local memory trampoline
-to transfer control.  The single parameter identifies the section where
-the trampoline is placed.
-@end table
+@item nonnull (@var{arg-index}, @dots{})
+@cindex @code{nonnull} function attribute
+@cindex functions with non-null pointer arguments
+The @code{nonnull} attribute specifies that some function parameters should
+be non-null pointers.  For instance, the declaration:
 
-The following examples are all valid uses of these attributes on
-Epiphany targets:
 @smallexample
-void __attribute__ ((interrupt)) universal_handler ();
-void __attribute__ ((interrupt ("dma1"))) dma1_handler ();
-void __attribute__ ((interrupt ("dma0, dma1"))) universal_dma_handler ();
-void __attribute__ ((interrupt ("timer0"), disinterrupt))
-  fast_timer_handler ();
-void __attribute__ ((interrupt ("dma0, dma1"), forwarder_section ("tramp")))
-  external_dma_handler ();
+extern void *
+my_memcpy (void *dest, const void *src, size_t len)
+        __attribute__((nonnull (1, 2)));
 @end smallexample
 
-On MIPS targets, you can use the following attributes to modify the behavior
-of an interrupt handler:
-@table @code
-@item use_shadow_register_set
-@cindex @code{use_shadow_register_set} function attribute, MIPS
-Assume that the handler uses a shadow register set, instead of
-the main general-purpose registers.
-
-@item keep_interrupts_masked
-@cindex @code{keep_interrupts_masked} function attribute, MIPS
-Keep interrupts masked for the whole function.  Without this attribute,
-GCC tries to reenable interrupts for as much of the function as it can.
+@noindent
+causes the compiler to check that, in calls to @code{my_memcpy},
+arguments @var{dest} and @var{src} are non-null.  If the compiler
+determines that a null pointer is passed in an argument slot marked
+as non-null, and the @option{-Wnonnull} option is enabled, a warning
+is issued.  The compiler may also choose to make optimizations based
+on the knowledge that certain function arguments will never be null.
 
-@item use_debug_exception_return
-@cindex @code{use_debug_exception_return} function attribute, MIPS
-Return using the @code{deret} instruction.  Interrupt handlers that don't
-have this attribute return using @code{eret} instead.
-@end table
+If no argument index list is given to the @code{nonnull} attribute,
+all pointer arguments are marked as non-null.  To illustrate, the
+following declaration is equivalent to the previous example:
 
-You can use any combination of these attributes, as shown below:
 @smallexample
-void __attribute__ ((interrupt)) v0 ();
-void __attribute__ ((interrupt, use_shadow_register_set)) v1 ();
-void __attribute__ ((interrupt, keep_interrupts_masked)) v2 ();
-void __attribute__ ((interrupt, use_debug_exception_return)) v3 ();
-void __attribute__ ((interrupt, use_shadow_register_set,
-                     keep_interrupts_masked)) v4 ();
-void __attribute__ ((interrupt, use_shadow_register_set,
-                     use_debug_exception_return)) v5 ();
-void __attribute__ ((interrupt, keep_interrupts_masked,
-                     use_debug_exception_return)) v6 ();
-void __attribute__ ((interrupt, use_shadow_register_set,
-                     keep_interrupts_masked,
-                     use_debug_exception_return)) v7 ();
+extern void *
+my_memcpy (void *dest, const void *src, size_t len)
+        __attribute__((nonnull));
 @end smallexample
 
-On NDS32 target, this attribute indicates that the specified function
-is an interrupt handler.  The compiler generates corresponding sections
-for use in an interrupt handler.  You can use the following attributes
-to modify the behavior:
-@table @code
-@item nested
-@cindex @code{nested} function attribute, NDS32
-This interrupt service routine is interruptible.
-@item not_nested
-@cindex @code{not_nested} function attribute, NDS32
-This interrupt service routine is not interruptible.
-@item nested_ready
-@cindex @code{nested_ready} function attribute, NDS32
-This interrupt service routine is interruptible after @code{PSW.GIE}
-(global interrupt enable) is set.  This allows interrupt service routine to
-finish some short critical code before enabling interrupts.
-@item save_all
-@cindex @code{save_all} function attribute, NDS32
-The system will help save all registers into stack before entering
-interrupt handler.
-@item partial_save
-@cindex @code{partial_save} function attribute, NDS32
-The system will help save caller registers into stack before entering
-interrupt handler.
-@end table
+@item noreturn
+@cindex @code{noreturn} function attribute
+@cindex functions that never return
+A few standard library functions, such as @code{abort} and @code{exit},
+cannot return.  GCC knows this automatically.  Some programs define
+their own functions that never return.  You can declare them
+@code{noreturn} to tell the compiler this fact.  For example,
 
-@cindex @code{brk_interrupt} function attribute, RL78
-On RL78, use @code{brk_interrupt} instead of @code{interrupt} for
-handlers intended to be used with the @code{BRK} opcode (i.e.@: those
-that must end with @code{RETB} instead of @code{RETI}).
+@smallexample
+@group
+void fatal () __attribute__ ((noreturn));
+
+void
+fatal (/* @r{@dots{}} */)
+@{
+  /* @r{@dots{}} */ /* @r{Print error message.} */ /* @r{@dots{}} */
+  exit (1);
+@}
+@end group
+@end smallexample
+
+The @code{noreturn} keyword tells the compiler to assume that
+@code{fatal} cannot return.  It can then optimize without regard to what
+would happen if @code{fatal} ever did return.  This makes slightly
+better code.  More importantly, it helps avoid spurious warnings of
+uninitialized variables.
+
+The @code{noreturn} keyword does not affect the exceptional path when that
+applies: a @code{noreturn}-marked function may still return to the caller
+by throwing an exception or calling @code{longjmp}.
+
+Do not assume that registers saved by the calling function are
+restored before calling the @code{noreturn} function.
+
+It does not make sense for a @code{noreturn} function to have a return
+type other than @code{void}.
+
+@item nothrow
+@cindex @code{nothrow} function attribute
+The @code{nothrow} attribute is used to inform the compiler that a
+function cannot throw an exception.  For example, most functions in
+the standard C library can be guaranteed not to throw an exception
+with the notable exceptions of @code{qsort} and @code{bsearch} that
+take function pointer arguments.
+
+@item noplt
+@cindex @code{noplt} function attribute
+The @code{noplt} attribute is the counterpart to option @option{-fno-plt} and
+does not use PLT for calls to functions marked with this attribute in position
+independent code. 
+
+@smallexample
+@group
+/* Externally defined function foo.  */
+int foo () __attribute__ ((noplt));
+
+int
+main (/* @r{@dots{}} */)
+@{
+  /* @r{@dots{}} */
+  foo ();
+  /* @r{@dots{}} */
+@}
+@end group
+@end smallexample
+
+The @code{noplt} attribute on function foo tells the compiler to assume that
+the function foo is externally defined and the call to foo must avoid the PLT
+in position independent code.
+
+Additionally, a few targets also convert calls to those functions that are
+marked to not use the PLT to use the GOT instead for non-position independent
+code.
+
+@item optimize
+@cindex @code{optimize} function attribute
+The @code{optimize} attribute is used to specify that a function is to
+be compiled with different optimization options than specified on the
+command line.  Arguments can either be numbers or strings.  Numbers
+are assumed to be an optimization level.  Strings that begin with
+@code{O} are assumed to be an optimization option, while other options
+are assumed to be used with a @code{-f} prefix.  You can also use the
+@samp{#pragma GCC optimize} pragma to set the optimization options
+that affect more than one function.
+@xref{Function Specific Option Pragmas}, for details about the
+@samp{#pragma GCC optimize} pragma.
+
+This can be used for instance to have frequently-executed functions
+compiled with more aggressive optimization options that produce faster
+and larger code, while other functions can be compiled with less
+aggressive options.
+
+@item pure
+@cindex @code{pure} function attribute
+@cindex functions that have no side effects
+Many functions have no effects except the return value and their
+return value depends only on the parameters and/or global variables.
+Such a function can be subject
+to common subexpression elimination and loop optimization just as an
+arithmetic operator would be.  These functions should be declared
+with the attribute @code{pure}.  For example,
+
+@smallexample
+int square (int) __attribute__ ((pure));
+@end smallexample
+
+@noindent
+says that the hypothetical function @code{square} is safe to call
+fewer times than the program says.
+
+Some of common examples of pure functions are @code{strlen} or @code{memcmp}.
+Interesting non-pure functions are functions with infinite loops or those
+depending on volatile memory or other system resource, that may change between
+two consecutive calls (such as @code{feof} in a multithreading environment).
+
+@item returns_nonnull
+@cindex @code{returns_nonnull} function attribute
+The @code{returns_nonnull} attribute specifies that the function
+return value should be a non-null pointer.  For instance, the declaration:
+
+@smallexample
+extern void *
+mymalloc (size_t len) __attribute__((returns_nonnull));
+@end smallexample
+
+@noindent
+lets the compiler optimize callers based on the knowledge
+that the return value will never be null.
+
+@item returns_twice
+@cindex @code{returns_twice} function attribute
+@cindex functions that return more than once
+The @code{returns_twice} attribute tells the compiler that a function may
+return more than one time.  The compiler ensures that all registers
+are dead before calling such a function and emits a warning about
+the variables that may be clobbered after the second return from the
+function.  Examples of such functions are @code{setjmp} and @code{vfork}.
+The @code{longjmp}-like counterpart of such function, if any, might need
+to be marked with the @code{noreturn} attribute.
+
+@item section ("@var{section-name}")
+@cindex @code{section} function attribute
+@cindex functions in arbitrary sections
+Normally, the compiler places the code it generates in the @code{text} section.
+Sometimes, however, you need additional sections, or you need certain
+particular functions to appear in special sections.  The @code{section}
+attribute specifies that a function lives in a particular section.
+For example, the declaration:
+
+@smallexample
+extern void foobar (void) __attribute__ ((section ("bar")));
+@end smallexample
+
+@noindent
+puts the function @code{foobar} in the @code{bar} section.
+
+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 sentinel
+@cindex @code{sentinel} function attribute
+This function attribute ensures that a parameter in a function call is
+an explicit @code{NULL}.  The attribute is only valid on variadic
+functions.  By default, the sentinel is located at position zero, the
+last parameter of the function call.  If an optional integer position
+argument P is supplied to the attribute, the sentinel must be located at
+position P counting backwards from the end of the argument list.
+
+@smallexample
+__attribute__ ((sentinel))
+is equivalent to
+__attribute__ ((sentinel(0)))
+@end smallexample
+
+The attribute is automatically set with a position of 0 for the built-in
+functions @code{execl} and @code{execlp}.  The built-in function
+@code{execle} has the attribute set with a position of 1.
+
+A valid @code{NULL} in this context is defined as zero with any pointer
+type.  If your system defines the @code{NULL} macro with an integer type
+then you need to add an explicit cast.  GCC replaces @code{stddef.h}
+with a copy that redefines NULL appropriately.
+
+The warnings for missing or incorrect sentinels are enabled with
+@option{-Wformat}.
+
+@item stack_protect
+@cindex @code{stack_protect} function attribute
+This function attribute make a stack protection of the function if 
+flags @option{fstack-protector} or @option{fstack-protector-strong}
+or @option{fstack-protector-explicit} are set.
+
+@item target (@var{options})
+@cindex @code{target} function attribute
+Multiple target back ends implement the @code{target} attribute
+to specify that a function is to
+be compiled with different target options than specified on the
+command line.  This can be used for instance to have functions
+compiled with a different ISA (instruction set architecture) than the
+default.  You can also use the @samp{#pragma GCC target} pragma to set
+more than one function to be compiled with specific target options.
+@xref{Function Specific Option Pragmas}, for details about the
+@samp{#pragma GCC target} pragma.
+
+For instance, on an x86, you could declare one function with the
+@code{target("sse4.1,arch=core2")} attribute and another with
+@code{target("sse4a,arch=amdfam10")}.  This is equivalent to
+compiling the first function with @option{-msse4.1} and
+@option{-march=core2} options, and the second function with
+@option{-msse4a} and @option{-march=amdfam10} options.  It is up to you
+to make sure that a function is only invoked on a machine that
+supports the particular ISA it is compiled for (for example by using
+@code{cpuid} on x86 to determine what feature bits and architecture
+family are used).
+
+@smallexample
+int core2_func (void) __attribute__ ((__target__ ("arch=core2")));
+int sse3_func (void) __attribute__ ((__target__ ("sse3")));
+@end smallexample
+
+You can either use multiple
+strings separated by commas to specify multiple options,
+or separate the options with a comma (@samp{,}) within a single string.
+
+The options supported are specific to each target; refer to @ref{x86
+Function Attributes}, @ref{PowerPC Function Attributes},
+@ref{ARM Function Attributes},and @ref{Nios II Function Attributes},
+for details.
+
+@item unused
+@cindex @code{unused} function attribute
+This attribute, attached to a function, means that the function is meant
+to be possibly unused.  GCC does not produce a warning for this
+function.
+
+@item used
+@cindex @code{used} function attribute
+This attribute, attached to a function, means that code must be emitted
+for the function even if it appears that the function is not referenced.
+This is useful, for example, when the function is referenced only in
+inline assembly.
+
+When applied to a member function of a C++ class template, the
+attribute also means that the function is instantiated if the
+class itself is instantiated.
+
+@item visibility ("@var{visibility_type}")
+@cindex @code{visibility} function attribute
+This attribute affects the linkage of the declaration to which it is attached.
+There are four supported @var{visibility_type} values: default,
+hidden, protected or internal visibility.
+
+@smallexample
+void __attribute__ ((visibility ("protected")))
+f () @{ /* @r{Do something.} */; @}
+int i __attribute__ ((visibility ("hidden")));
+@end smallexample
+
+The possible values of @var{visibility_type} correspond to the
+visibility settings in the ELF gABI.
+
+@table @code
+@c keep this list of visibilities in alphabetical order.
+
+@item default
+Default visibility is the normal case for the object file format.
+This value is available for the visibility attribute to override other
+options that may change the assumed visibility of entities.
+
+On ELF, default visibility means that the declaration is visible to other
+modules and, in shared libraries, means that the declared entity may be
+overridden.
+
+On Darwin, default visibility means that the declaration is visible to
+other modules.
+
+Default visibility corresponds to ``external linkage'' in the language.
+
+@item hidden
+Hidden visibility indicates that the entity declared has a new
+form of linkage, which we call ``hidden linkage''.  Two
+declarations of an object with hidden linkage refer to the same object
+if they are in the same shared object.
+
+@item internal
+Internal visibility is like hidden visibility, but with additional
+processor specific semantics.  Unless otherwise specified by the
+psABI, GCC defines internal visibility to mean that a function is
+@emph{never} called from another module.  Compare this with hidden
+functions which, while they cannot be referenced directly by other
+modules, can be referenced indirectly via function pointers.  By
+indicating that a function cannot be called from outside the module,
+GCC may for instance omit the load of a PIC register since it is known
+that the calling function loaded the correct value.
+
+@item protected
+Protected visibility is like default visibility except that it
+indicates that references within the defining module bind to the
+definition in that module.  That is, the declared entity cannot be
+overridden by another module.
+
+@end table
+
+All visibilities are supported on many, but not all, ELF targets
+(supported when the assembler supports the @samp{.visibility}
+pseudo-op).  Default visibility is supported everywhere.  Hidden
+visibility is supported on Darwin targets.
+
+The visibility attribute should be applied only to declarations that
+would otherwise have external linkage.  The attribute should be applied
+consistently, so that the same entity should not be declared with
+different settings of the attribute.
 
-On RX targets, you may specify one or more vector numbers as arguments
-to the attribute, as well as naming an alternate table name.
-Parameters are handled sequentially, so one handler can be assigned to
-multiple entries in multiple tables.  One may also pass the magic
-string @code{"$default"} which causes the function to be used for any
-unfilled slots in the current table.
+In C++, the visibility attribute applies to types as well as functions
+and objects, because in C++ types have linkage.  A class must not have
+greater visibility than its non-static data member types and bases,
+and class members default to the visibility of their class.  Also, a
+declaration without explicit visibility is limited to the visibility
+of its type.
+
+In C++, you can mark member functions and static member variables of a
+class with the visibility attribute.  This is useful if you know a
+particular method or static member variable should only be used from
+one shared object; then you can mark it hidden while the rest of the
+class has default visibility.  Care must be taken to avoid breaking
+the One Definition Rule; for example, it is usually not useful to mark
+an inline method as hidden without marking the whole class as hidden.
+
+A C++ namespace declaration can also have the visibility attribute.
 
-This example shows a simple assignment of a function to one vector in
-the default table (note that preprocessor macros may be used for
-chip-specific symbolic vector names):
 @smallexample
-void __attribute__ ((interrupt (5))) txd1_handler ();
+namespace nspace1 __attribute__ ((visibility ("protected")))
+@{ /* @r{Do something.} */; @}
 @end smallexample
 
-This example assigns a function to two slots in the default table
-(using preprocessor macros defined elsewhere) and makes it the default
-for the @code{dct} table:
+This attribute applies only to the particular namespace body, not to
+other definitions of the same namespace; it is equivalent to using
+@samp{#pragma GCC visibility} before and after the namespace
+definition (@pxref{Visibility Pragmas}).
+
+In C++, if a template argument has limited visibility, this
+restriction is implicitly propagated to the template instantiation.
+Otherwise, template instantiations and specializations default to the
+visibility of their template.
+
+If both the template and enclosing class have explicit visibility, the
+visibility from the template is used.
+
+@item warn_unused_result
+@cindex @code{warn_unused_result} function attribute
+The @code{warn_unused_result} attribute causes a warning to be emitted
+if a caller of the function with this attribute does not use its
+return value.  This is useful for functions where not checking
+the result is either a security problem or always a bug, such as
+@code{realloc}.
+
 @smallexample
-void __attribute__ ((interrupt (RXD1_VECT,RXD2_VECT,"dct","$default")))
-	txd1_handler ();
+int fn () __attribute__ ((warn_unused_result));
+int foo ()
+@{
+  if (fn () < 0) return -1;
+  fn ();
+  return 0;
+@}
 @end smallexample
 
-@item interrupt_handler
-@cindex @code{interrupt_handler} function attribute, Blackfin
-@cindex @code{interrupt_handler} function attribute, m68k
-@cindex @code{interrupt_handler} function attribute, H8/300
-@cindex @code{interrupt_handler} function attribute, SH
-Use this attribute on the Blackfin, m68k, H8/300, H8/300H, H8S, and SH to
-indicate that the specified function is an interrupt handler.  The compiler
-generates function entry and exit sequences suitable for use in an
-interrupt handler when this attribute is present.
+@noindent
+results in warning on line 5.
 
-@item interrupt_thread
-@cindex @code{interrupt_thread} function attribute, fido
-Use this attribute on fido, a subarchitecture of the m68k, to indicate
-that the specified function is an interrupt handler that is designed
-to run as a thread.  The compiler omits generate prologue/epilogue
-sequences and replaces the return instruction with a @code{sleep}
-instruction.  This attribute is available only on fido.
+@item weak
+@cindex @code{weak} function attribute
+The @code{weak} attribute causes the declaration to be emitted as a weak
+symbol rather than a global.  This is primarily useful in defining
+library functions that can be overridden in user code, though it can
+also be used with non-function declarations.  Weak symbols are supported
+for ELF targets, and also for a.out targets when using the GNU assembler
+and linker.
 
-@item isr
-@cindex @code{isr} function attribute, ARM
-Use this attribute on ARM to write Interrupt Service Routines. This is an
-alias to the @code{interrupt} attribute above.
+@item weakref
+@itemx weakref ("@var{target}")
+@cindex @code{weakref} function attribute
+The @code{weakref} attribute marks a declaration as a weak reference.
+Without arguments, it should be accompanied by an @code{alias} attribute
+naming the target symbol.  Optionally, the @var{target} may be given as
+an argument to @code{weakref} itself.  In either case, @code{weakref}
+implicitly marks the declaration as @code{weak}.  Without a
+@var{target}, given as an argument to @code{weakref} or to @code{alias},
+@code{weakref} is equivalent to @code{weak}.
 
-@item kspisusp
-@cindex @code{kspisusp} function attribute, Blackfin
-@cindex User stack pointer in interrupts on the Blackfin
-When used together with @code{interrupt_handler}, @code{exception_handler}
-or @code{nmi_handler}, code is generated to load the stack pointer
-from the USP register in the function prologue.
+@smallexample
+static int x() __attribute__ ((weakref ("y")));
+/* is equivalent to... */
+static int x() __attribute__ ((weak, weakref, alias ("y")));
+/* and to... */
+static int x() __attribute__ ((weakref));
+static int x() __attribute__ ((alias ("y")));
+@end smallexample
 
-@item l1_text
-@cindex @code{l1_text} function attribute, Blackfin
-This attribute specifies a function to be placed into L1 Instruction
-SRAM@. The function is put into a specific section named @code{.l1.text}.
-With @option{-mfdpic}, function calls with a such function as the callee
-or caller uses inlined PLT.
+A weak reference is an alias that does not by itself require a
+definition to be given for the target symbol.  If the target symbol is
+only referenced through weak references, then it becomes a @code{weak}
+undefined symbol.  If it is directly referenced, however, then such
+strong references prevail, and a definition is required for the
+symbol, not necessarily in the same translation unit.
 
-@item l2
-@cindex @code{l2} function attribute, Blackfin
-On the Blackfin, this attribute specifies a function to be placed into L2
-SRAM. The function is put into a specific section named
-@code{.l1.text}. With @option{-mfdpic}, callers of such functions use
-an inlined PLT.
+The effect is equivalent to moving all references to the alias to a
+separate translation unit, renaming the alias to the aliased symbol,
+declaring it as weak, compiling the two separate translation units and
+performing a reloadable link on them.
 
-@item leaf
-@cindex @code{leaf} function attribute
-Calls to external functions with this attribute must return to the current
-compilation unit only by return or by exception handling.  In particular, leaf
-functions are not allowed to call callback function passed to it from the current
-compilation unit or directly call functions exported by the unit or longjmp
-into the unit.  Leaf function might still call functions from other compilation
-units and thus they are not necessarily leaf in the sense that they contain no
-function calls at all.
+At present, a declaration to which @code{weakref} is attached can
+only be @code{static}.
 
-The attribute is intended for library functions to improve dataflow analysis.
-The compiler takes the hint that any data not escaping the current compilation unit can
-not be used or modified by the leaf function.  For example, the @code{sin} function
-is a leaf function, but @code{qsort} is not.
+@end table
 
-Note that leaf functions might invoke signals and signal handlers might be
-defined in the current compilation unit and use static variables.  The only
-compliant way to write such a signal handler is to declare such variables
-@code{volatile}.
+@c This is the end of the target-independent attribute table
 
-The attribute has no effect on functions defined within the current compilation
-unit.  This is to allow easy merging of multiple compilation units into one,
-for example, by using the link-time optimization.  For this reason the
-attribute is not allowed on types to annotate indirect calls.
+@node AArch64 Function Attributes
+@subsection AArch64 Function Attributes
+
+The following target-specific function attributes are available for the
+AArch64 target.  For the most part, these options mirror the behavior of
+similar command-line options (@pxref{AArch64 Options}), but on a
+per-function basis.
+
+@table @code
+@item general-regs-only
+@cindex @code{general-regs-only} function attribute, AArch64
+Indicates that no floating-point or Advanced SIMD registers should be
+used when generating code for this function.  If the function explicitly
+uses floating-point code, then the compiler gives an error.  This is
+the same behavior as that of the command-line option
+@option{-mgeneral-regs-only}.
+
+@item fix-cortex-a53-835769
+@cindex @code{fix-cortex-a53-835769} function attribute, AArch64
+Indicates that the workaround for the Cortex-A53 erratum 835769 should be
+applied to this function.  To explicitly disable the workaround for this
+function specify the negated form: @code{no-fix-cortex-a53-835769}.
+This corresponds to the behavior of the command line options
+@option{-mfix-cortex-a53-835769} and @option{-mno-fix-cortex-a53-835769}.
+
+@item cmodel=
+@cindex @code{cmodel=} function attribute, AArch64
+Indicates that code should be generated for a particular code model for
+this function.  The behavior and permissible arguments are the same as
+for the command line option @option{-mcmodel=}.
+
+@item strict-align
+@cindex @code{strict-align} function attribute, AArch64
+Indicates that the compiler should not assume that unaligned memory references
+are handled by the system.  The behavior is the same as for the command-line
+option @option{-mstrict-align}.
+
+@item omit-leaf-frame-pointer
+@cindex @code{omit-leaf-frame-pointer} function attribute, AArch64
+Indicates that the frame pointer should be omitted for a leaf function call.
+To keep the frame pointer, the inverse attribute
+@code{no-omit-leaf-frame-pointer} can be specified.  These attributes have
+the same behavior as the command-line options @option{-momit-leaf-frame-pointer}
+and @option{-mno-omit-leaf-frame-pointer}.
+
+@item tls-dialect=
+@cindex @code{tls-dialect=} function attribute, AArch64
+Specifies the TLS dialect to use for this function.  The behavior and
+permissible arguments are the same as for the command-line option
+@option{-mtls-dialect=}.
+
+@item arch=
+@cindex @code{arch=} function attribute, AArch64
+Specifies the architecture version and architectural extensions to use
+for this function.  The behavior and permissible arguments are the same as
+for the @option{-march=} command-line option.
+
+@item tune=
+@cindex @code{tune=} function attribute, AArch64
+Specifies the core for which to tune the performance of this function.
+The behavior and permissible arguments are the same as for the @option{-mtune=}
+command-line option.
+
+@item cpu=
+@cindex @code{cpu=} function attribute, AArch64
+Specifies the core for which to tune the performance of this function and also
+whose architectural features to use.  The behavior and valid arguments are the
+same as for the @option{-mcpu=} command-line option.
+
+@end table
+
+The above target attributes can be specified as follows:
+
+@smallexample
+__attribute__((target("@var{attr-string}")))
+int
+f (int a)
+@{
+  return a + 5;
+@}
+@end smallexample
+
+where @code{@var{attr-string}} is one of the attribute strings specified above.
+
+Additionally, the architectural extension string may be specified on its
+own.  This can be used to turn on and off particular architectural extensions
+without having to specify a particular architecture version or core.  Example:
+
+@smallexample
+__attribute__((target("+crc+nocrypto")))
+int
+foo (int a)
+@{
+  return a + 5;
+@}
+@end smallexample
+
+In this example @code{target("+crc+nocrypto")} enables the @code{crc}
+extension and disables the @code{crypto} extension for the function @code{foo}
+without modifying an existing @option{-march=} or @option{-mcpu} option.
+
+Multiple target function attributes can be specified by separating them with
+a comma.  For example:
+@smallexample
+__attribute__((target("arch=armv8-a+crc+crypto,tune=cortex-a53")))
+int
+foo (int a)
+@{
+  return a + 5;
+@}
+@end smallexample
+
+is valid and compiles function @code{foo} for ARMv8-A with @code{crc}
+and @code{crypto} extensions and tunes it for @code{cortex-a53}.
+
+@subsubsection Inlining rules
+Specifying target attributes on individual functions or performing link-time
+optimization across translation units compiled with different target options
+can affect function inlining rules:
+
+In particular, a caller function can inline a callee function only if the
+architectural features available to the callee are a subset of the features
+available to the caller.
+For example: A function @code{foo} compiled with @option{-march=armv8-a+crc},
+or tagged with the equivalent @code{arch=armv8-a+crc} attribute,
+can inline a function @code{bar} compiled with @option{-march=armv8-a+nocrc}
+because the all the architectural features that function @code{bar} requires
+are available to function @code{foo}.  Conversely, function @code{bar} cannot
+inline function @code{foo}.
+
+Additionally inlining a function compiled with @option{-mstrict-align} into a
+function compiled without @code{-mstrict-align} is not allowed.
+However, inlining a function compiled without @option{-mstrict-align} into a
+function compiled with @option{-mstrict-align} is allowed.
+
+Note that CPU tuning options and attributes such as the @option{-mcpu=},
+@option{-mtune=} do not inhibit inlining unless the CPU specified by the
+@option{-mcpu=} option or the @code{cpu=} attribute conflicts with the
+architectural feature rules specified above.
+
+@node ARC Function Attributes
+@subsection ARC Function Attributes
+
+These function attributes are supported by the ARC back end:
+
+@table @code
+@item interrupt
+@cindex @code{interrupt} function attribute, ARC
+Use this attribute to indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when this attribute is present.
+
+On the ARC, you must specify the kind of interrupt to be handled
+in a parameter to the interrupt attribute like this:
+
+@smallexample
+void f () __attribute__ ((interrupt ("ilink1")));
+@end smallexample
+
+Permissible values for this parameter are: @w{@code{ilink1}} and
+@w{@code{ilink2}}.
 
 @item long_call
 @itemx medium_call
 @itemx short_call
 @cindex @code{long_call} function attribute, ARC
-@cindex @code{long_call} function attribute, ARM
-@cindex @code{long_call} function attribute, Epiphany
 @cindex @code{medium_call} function attribute, ARC
 @cindex @code{short_call} function attribute, ARC
-@cindex @code{short_call} function attribute, ARM
-@cindex @code{short_call} function attribute, Epiphany
 @cindex indirect calls, ARC
-@cindex indirect calls, ARM
-@cindex indirect calls, Epiphany
-These attributes specify how a particular function is called on
-ARC, ARM and Epiphany - with @code{medium_call} being specific to ARC.
+These attributes specify how a particular function is called.
 These attributes override the
-@option{-mlong-calls} (@pxref{ARM Options} and @ref{ARC Options})
-and @option{-mmedium-calls} (@pxref{ARC Options})
-command-line switches and @code{#pragma long_calls} settings.  For ARM, the
-@code{long_call} attribute indicates that the function might be far
-away from the call site and require a different (more expensive)
-calling sequence.   The @code{short_call} attribute always places
-the offset to the function from the call site into the @samp{BL}
-instruction directly.
+@option{-mlong-calls} and @option{-mmedium-calls} (@pxref{ARC Options})
+command-line switches and @code{#pragma long_calls} settings.
 
 For ARC, a function marked with the @code{long_call} attribute is
 always called using register-indirect jump-and-link instructions,
@@ -3208,183 +3470,138 @@ thereby enabling the called function to be placed anywhere within the
 32-bit address space.  A function marked with the @code{medium_call}
 attribute will always be close enough to be called with an unconditional
 branch-and-link instruction, which has a 25-bit offset from
-the call site.  A function marked with the @code{short_call}
-attribute will always be close enough to be called with a conditional
-branch-and-link instruction, which has a 21-bit offset from
-the call site.
-
-@item longcall
-@itemx shortcall
-@cindex indirect calls, Blackfin
-@cindex indirect calls, PowerPC
-@cindex @code{longcall} function attribute, Blackfin
-@cindex @code{longcall} function attribute, PowerPC
-@cindex @code{shortcall} function attribute, Blackfin
-@cindex @code{shortcall} function attribute, PowerPC
-On Blackfin and PowerPC, the @code{longcall} attribute
-indicates that the function might be far away from the call site and
-require a different (more expensive) calling sequence.  The
-@code{shortcall} attribute indicates that the function is always close
-enough for the shorter calling sequence to be used.  These attributes
-override both the @option{-mlongcall} switch and, on the RS/6000 and
-PowerPC, the @code{#pragma longcall} setting.
-
-@xref{RS/6000 and PowerPC Options}, for more information on whether long
-calls are necessary.
-
-@item long_call
-@itemx near
-@itemx far
-@cindex indirect calls, MIPS
-@cindex @code{long_call} function attribute, MIPS
-@cindex @code{near} function attribute, MIPS
-@cindex @code{far} function attribute, MIPS
-These attributes specify how a particular function is called on MIPS@.
-The attributes override the @option{-mlong-calls} (@pxref{MIPS Options})
-command-line switch.  The @code{long_call} and @code{far} attributes are
-synonyms, and cause the compiler to always call
-the function by first loading its address into a register, and then using
-the contents of that register.  The @code{near} attribute has the opposite
-effect; it specifies that non-PIC calls should be made using the more
-efficient @code{jal} instruction.
+the call site.  A function marked with the @code{short_call}
+attribute will always be close enough to be called with a conditional
+branch-and-link instruction, which has a 21-bit offset from
+the call site.
+@end table
 
-@item malloc
-@cindex @code{malloc} function attribute
-This tells the compiler that a function is @code{malloc}-like, i.e.,
-that the pointer @var{P} returned by the function cannot alias any
-other pointer valid when the function returns, and moreover no
-pointers to valid objects occur in any storage addressed by @var{P}.
+@node ARM Function Attributes
+@subsection ARM Function Attributes
 
-Using this attribute can improve optimization.  Functions like
-@code{malloc} and @code{calloc} have this property because they return
-a pointer to uninitialized or zeroed-out storage.  However, functions
-like @code{realloc} do not have this property, as they can return a
-pointer to storage containing pointers.
+These function attributes are supported for ARM targets:
 
-@item mips16
-@itemx nomips16
-@cindex @code{mips16} function attribute, MIPS
-@cindex @code{nomips16} function attribute, MIPS
+@table @code
+@item interrupt
+@cindex @code{interrupt} function attribute, ARM
+Use this attribute to indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when this attribute is present.
 
-On MIPS targets, you can use the @code{mips16} and @code{nomips16}
-function attributes to locally select or turn off MIPS16 code generation.
-A function with the @code{mips16} attribute is emitted as MIPS16 code,
-while MIPS16 code generation is disabled for functions with the
-@code{nomips16} attribute.  These attributes override the
-@option{-mips16} and @option{-mno-mips16} options on the command line
-(@pxref{MIPS Options}).
+You can specify the kind of interrupt to be handled by
+adding an optional parameter to the interrupt attribute like this:
 
-When compiling files containing mixed MIPS16 and non-MIPS16 code, the
-preprocessor symbol @code{__mips16} reflects the setting on the command line,
-not that within individual functions.  Mixed MIPS16 and non-MIPS16 code
-may interact badly with some GCC extensions such as @code{__builtin_apply}
-(@pxref{Constructing Calls}).
+@smallexample
+void f () __attribute__ ((interrupt ("IRQ")));
+@end smallexample
 
-@item micromips, MIPS
-@itemx nomicromips, MIPS
-@cindex @code{micromips} function attribute
-@cindex @code{nomicromips} function attribute
+@noindent
+Permissible values for this parameter are: @code{IRQ}, @code{FIQ},
+@code{SWI}, @code{ABORT} and @code{UNDEF}.
 
-On MIPS targets, you can use the @code{micromips} and @code{nomicromips}
-function attributes to locally select or turn off microMIPS code generation.
-A function with the @code{micromips} attribute is emitted as microMIPS code,
-while microMIPS code generation is disabled for functions with the
-@code{nomicromips} attribute.  These attributes override the
-@option{-mmicromips} and @option{-mno-micromips} options on the command line
-(@pxref{MIPS Options}).
+On ARMv7-M the interrupt type is ignored, and the attribute means the function
+may be called with a word-aligned stack pointer.
 
-When compiling files containing mixed microMIPS and non-microMIPS code, the
-preprocessor symbol @code{__mips_micromips} reflects the setting on the
-command line,
-not that within individual functions.  Mixed microMIPS and non-microMIPS code
-may interact badly with some GCC extensions such as @code{__builtin_apply}
-(@pxref{Constructing Calls}).
+@item isr
+@cindex @code{isr} function attribute, ARM
+Use this attribute on ARM to write Interrupt Service Routines. This is an
+alias to the @code{interrupt} attribute above.
 
-@item model (@var{model-name})
-@cindex @code{model} function attribute, M32R/D
-@cindex function addressability on the M32R/D
+@item long_call
+@itemx short_call
+@cindex @code{long_call} function attribute, ARM
+@cindex @code{short_call} function attribute, ARM
+@cindex indirect calls, ARM
+These attributes specify how a particular function is called.
+These attributes override the
+@option{-mlong-calls} (@pxref{ARM Options})
+command-line switch and @code{#pragma long_calls} settings.  For ARM, the
+@code{long_call} attribute indicates that the function might be far
+away from the call site and require a different (more expensive)
+calling sequence.   The @code{short_call} attribute always places
+the offset to the function from the call site into the @samp{BL}
+instruction directly.
 
-On the M32R/D, use this attribute to set the addressability of an
-object, and of the code generated for a function.  The identifier
-@var{model-name} is one of @code{small}, @code{medium}, or
-@code{large}, representing each of the code models.
+@item naked
+@cindex @code{naked} function attribute, ARM
+This attribute allows the compiler to construct the
+requisite function declaration, while allowing the body of the
+function to be assembly code. The specified function will not have
+prologue/epilogue sequences generated by the compiler. Only basic
+@code{asm} statements can safely be included in naked functions
+(@pxref{Basic Asm}). While using extended @code{asm} or a mixture of
+basic @code{asm} and C code may appear to work, they cannot be
+depended upon to work reliably and are not supported.
 
-Small model objects live in the lower 16MB of memory (so that their
-addresses can be loaded with the @code{ld24} instruction), and are
-callable with the @code{bl} instruction.
+@item pcs
+@cindex @code{pcs} function attribute, ARM
 
-Medium model objects may live anywhere in the 32-bit address space (the
-compiler generates @code{seth/add3} instructions to load their addresses),
-and are callable with the @code{bl} instruction.
+The @code{pcs} attribute can be used to control the calling convention
+used for a function on ARM.  The attribute takes an argument that specifies
+the calling convention to use.
 
-Large model objects may live anywhere in the 32-bit address space (the
-compiler generates @code{seth/add3} instructions to load their addresses),
-and may not be reachable with the @code{bl} instruction (the compiler
-generates the much slower @code{seth/add3/jl} instruction sequence).
+When compiling using the AAPCS ABI (or a variant of it) then valid
+values for the argument are @code{"aapcs"} and @code{"aapcs-vfp"}.  In
+order to use a variant other than @code{"aapcs"} then the compiler must
+be permitted to use the appropriate co-processor registers (i.e., the
+VFP registers must be available in order to use @code{"aapcs-vfp"}).
+For example,
 
-@item ms_abi
-@itemx sysv_abi
-@cindex @code{ms_abi} function attribute, x86
-@cindex @code{sysv_abi} function attribute, x86
+@smallexample
+/* Argument passed in r0, and result returned in r0+r1.  */
+double f2d (float) __attribute__((pcs("aapcs")));
+@end smallexample
 
-On 32-bit and 64-bit x86 targets, you can use an ABI attribute
-to indicate which calling convention should be used for a function.  The
-@code{ms_abi} attribute tells the compiler to use the Microsoft ABI,
-while the @code{sysv_abi} attribute tells the compiler to use the ABI
-used on GNU/Linux and other systems.  The default is to use the Microsoft ABI
-when targeting Windows.  On all other systems, the default is the x86/AMD ABI.
+Variadic functions always use the @code{"aapcs"} calling convention and
+the compiler rejects attempts to specify an alternative.
 
-Note, the @code{ms_abi} attribute for Microsoft Windows 64-bit targets currently
-requires the @option{-maccumulate-outgoing-args} option.
+@item target (@var{options})
+@cindex @code{target} function attribute
+As discussed in @ref{Common Function Attributes}, this attribute 
+allows specification of target-specific compilation options.
 
-@item callee_pop_aggregate_return (@var{number})
-@cindex @code{callee_pop_aggregate_return} function attribute, x86
+On ARM, the following options are allowed:
 
-On x86-32 targets, you can use this attribute to control how
-aggregates are returned in memory.  If the caller is responsible for
-popping the hidden pointer together with the rest of the arguments, specify
-@var{number} equal to zero.  If callee is responsible for popping the
-hidden pointer, specify @var{number} equal to one.  
+@table @samp
+@item thumb
+@cindex @code{target("thumb")} function attribute, ARM
+Force code generation in the Thumb (T16/T32) ISA, depending on the
+architecture level.
+
+@item arm
+@cindex @code{target("arm")} function attribute, ARM
+Force code generation in the ARM (A32) ISA.
+@end table
 
-The default x86-32 ABI assumes that the callee pops the
-stack for hidden pointer.  However, on x86-32 Microsoft Windows targets,
-the compiler assumes that the
-caller pops the stack for hidden pointer.
+Functions from different modes can be inlined in the caller's mode.
 
-@item ms_hook_prologue
-@cindex @code{ms_hook_prologue} function attribute, x86
+@end table
 
-On 32-bit and 64-bit x86 targets, you can use
-this function attribute to make GCC generate the ``hot-patching'' function
-prologue used in Win32 API functions in Microsoft Windows XP Service Pack 2
-and newer.
+@node AVR Function Attributes
+@subsection AVR Function Attributes
 
-@item hotpatch (@var{halfwords-before-function-label},@var{halfwords-after-function-label})
-@cindex @code{hotpatch} function attribute, S/390
+These function attributes are supported by the AVR back end:
 
-On S/390 System z targets, you can use this function attribute to
-make GCC generate a ``hot-patching'' function prologue.  If the
-@option{-mhotpatch=} command-line option is used at the same time,
-the @code{hotpatch} attribute takes precedence.  The first of the
-two arguments specifies the number of halfwords to be added before
-the function label.  A second argument can be used to specify the
-number of halfwords to be added after the function label.  For
-both arguments the maximum allowed value is 1000000.
+@table @code
+@item interrupt
+@cindex @code{interrupt} function attribute, AVR
+Use this attribute to indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when this attribute is present.
 
-If both arguments are zero, hotpatching is disabled.
+On the AVR, the hardware globally disables interrupts when an
+interrupt is executed.  The first instruction of an interrupt handler
+declared with this attribute is a @code{SEI} instruction to
+re-enable interrupts.  See also the @code{signal} function attribute
+that does not insert a @code{SEI} instruction.  If both @code{signal} and
+@code{interrupt} are specified for the same function, @code{signal}
+is silently ignored.
 
 @item naked
-@cindex @code{naked} function attribute, ARM
 @cindex @code{naked} function attribute, AVR
-@cindex @code{naked} function attribute, MCORE
-@cindex @code{naked} function attribute, MSP430
-@cindex @code{naked} function attribute, NDS32
-@cindex @code{naked} function attribute, RL78
-@cindex @code{naked} function attribute, RX
-@cindex @code{naked} function attribute, SPU
-@cindex function without prologue/epilogue code
-This attribute is available on the ARM, AVR, MCORE, MSP430, NDS32,
-RL78, RX and SPU ports.  It allows the compiler to construct the
+This attribute allows the compiler to construct the
 requisite function declaration, while allowing the body of the
 function to be assembly code. The specified function will not have
 prologue/epilogue sequences generated by the compiler. Only basic
@@ -3393,12 +3610,108 @@ prologue/epilogue sequences generated by the compiler. Only basic
 basic @code{asm} and C code may appear to work, they cannot be
 depended upon to work reliably and are not supported.
 
-@item near
-@cindex @code{near} function attribute, MeP
-@cindex functions that do not handle memory bank switching on 68HC11/68HC12
-On MeP targets this attribute causes the compiler to assume the called
-function is close enough to use the normal calling convention,
-overriding the @option{-mtf} command-line option.
+@item OS_main
+@itemx OS_task
+@cindex @code{OS_main} function attribute, AVR
+@cindex @code{OS_task} function attribute, AVR
+On AVR, functions with the @code{OS_main} or @code{OS_task} attribute
+do not save/restore any call-saved register in their prologue/epilogue.
+
+The @code{OS_main} attribute can be used when there @emph{is
+guarantee} that interrupts are disabled at the time when the function
+is entered.  This saves resources when the stack pointer has to be
+changed to set up a frame for local variables.
+
+The @code{OS_task} attribute can be used when there is @emph{no
+guarantee} that interrupts are disabled at that time when the function
+is entered like for, e@.g@. task functions in a multi-threading operating
+system. In that case, changing the stack pointer register is
+guarded by save/clear/restore of the global interrupt enable flag.
+
+The differences to the @code{naked} function attribute are:
+@itemize @bullet
+@item @code{naked} functions do not have a return instruction whereas 
+@code{OS_main} and @code{OS_task} functions have a @code{RET} or
+@code{RETI} return instruction.
+@item @code{naked} functions do not set up a frame for local variables
+or a frame pointer whereas @code{OS_main} and @code{OS_task} do this
+as needed.
+@end itemize
+
+@item signal
+@cindex @code{signal} function attribute, AVR
+Use this attribute on the AVR to indicate that the specified
+function is an interrupt handler.  The compiler generates function
+entry and exit sequences suitable for use in an interrupt handler when this
+attribute is present.
+
+See also the @code{interrupt} function attribute. 
+
+The AVR hardware globally disables interrupts when an interrupt is executed.
+Interrupt handler functions defined with the @code{signal} attribute
+do not re-enable interrupts.  It is save to enable interrupts in a
+@code{signal} handler.  This ``save'' only applies to the code
+generated by the compiler and not to the IRQ layout of the
+application which is responsibility of the application.
+
+If both @code{signal} and @code{interrupt} are specified for the same
+function, @code{signal} is silently ignored.
+@end table
+
+@node Blackfin Function Attributes
+@subsection Blackfin Function Attributes
+
+These function attributes are supported by the Blackfin back end:
+
+@table @code
+
+@item exception_handler
+@cindex @code{exception_handler} function attribute
+@cindex exception handler functions, Blackfin
+Use this attribute on the Blackfin to indicate that the specified function
+is an exception handler.  The compiler generates function entry and
+exit sequences suitable for use in an exception handler when this
+attribute is present.
+
+@item interrupt_handler
+@cindex @code{interrupt_handler} function attribute, Blackfin
+Use this attribute to
+indicate that the specified function is an interrupt handler.  The compiler
+generates function entry and exit sequences suitable for use in an
+interrupt handler when this attribute is present.
+
+@item kspisusp
+@cindex @code{kspisusp} function attribute, Blackfin
+@cindex User stack pointer in interrupts on the Blackfin
+When used together with @code{interrupt_handler}, @code{exception_handler}
+or @code{nmi_handler}, code is generated to load the stack pointer
+from the USP register in the function prologue.
+
+@item l1_text
+@cindex @code{l1_text} function attribute, Blackfin
+This attribute specifies a function to be placed into L1 Instruction
+SRAM@. The function is put into a specific section named @code{.l1.text}.
+With @option{-mfdpic}, function calls with a such function as the callee
+or caller uses inlined PLT.
+
+@item l2
+@cindex @code{l2} function attribute, Blackfin
+This attribute specifies a function to be placed into L2
+SRAM. The function is put into a specific section named
+@code{.l2.text}. With @option{-mfdpic}, callers of such functions use
+an inlined PLT.
+
+@item longcall
+@itemx shortcall
+@cindex indirect calls, Blackfin
+@cindex @code{longcall} function attribute, Blackfin
+@cindex @code{shortcall} function attribute, Blackfin
+The @code{longcall} attribute
+indicates that the function might be far away from the call site and
+require a different (more expensive) calling sequence.  The
+@code{shortcall} attribute indicates that the function is always close
+enough for the shorter calling sequence to be used.  These attributes
+override the @option{-mlongcall} switch.
 
 @item nesting
 @cindex @code{nesting} function attribute, Blackfin
@@ -3415,410 +3728,349 @@ is an NMI handler.  The compiler generates function entry and
 exit sequences suitable for use in an NMI handler when this
 attribute is present.
 
-@item nocompression
-@cindex @code{nocompression} function attribute, MIPS
-On MIPS targets, you can use the @code{nocompression} function attribute
-to locally turn off MIPS16 and microMIPS code generation.  This attribute
-overrides the @option{-mips16} and @option{-mmicromips} options on the
-command line (@pxref{MIPS Options}).
-
-@item no_instrument_function
-@cindex @code{no_instrument_function} function attribute
-@opindex finstrument-functions
-If @option{-finstrument-functions} is given, profiling function calls are
-generated at entry and exit of most user-compiled functions.
-Functions with this attribute are not so instrumented.
-
-@item no_split_stack
-@cindex @code{no_split_stack} function attribute
-@opindex fsplit-stack
-If @option{-fsplit-stack} is given, functions have a small
-prologue which decides whether to split the stack.  Functions with the
-@code{no_split_stack} attribute do not have that prologue, and thus
-may run with only a small amount of stack space available.
+@item saveall
+@cindex @code{saveall} function attribute, Blackfin
+@cindex save all registers on the Blackfin
+Use this attribute to indicate that
+all registers except the stack pointer should be saved in the prologue
+regardless of whether they are used or not.
+@end table
 
-@item stack_protect
-@cindex @code{stack_protect} function attribute
-This function attribute make a stack protection of the function if 
-flags @option{fstack-protector} or @option{fstack-protector-strong}
-or @option{fstack-protector-explicit} are set.
+@node CR16 Function Attributes
+@subsection CR16 Function Attributes
 
-@item noinline
-@cindex @code{noinline} function attribute
-This function attribute prevents a function from being considered for
-inlining.
-@c Don't enumerate the optimizations by name here; we try to be
-@c future-compatible with this mechanism.
-If the function does not have side-effects, there are optimizations
-other than inlining that cause function calls to be optimized away,
-although the function call is live.  To keep such calls from being
-optimized away, put
-@smallexample
-asm ("");
-@end smallexample
+These function attributes are supported by the CR16 back end:
 
-@noindent
-(@pxref{Extended Asm}) in the called function, to serve as a special
-side-effect.
+@table @code
+@item interrupt
+@cindex @code{interrupt} function attribute, CR16
+Use this attribute to indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when this attribute is present.
+@end table
 
-@item noclone
-@cindex @code{noclone} function attribute
-This function attribute prevents a function from being considered for
-cloning---a mechanism that produces specialized copies of functions
-and which is (currently) performed by interprocedural constant
-propagation.
+@node Epiphany Function Attributes
+@subsection Epiphany Function Attributes
 
-@item no_icf
-@cindex @code{no_icf} function attribute
-This function attribute prevents a functions from being merged with another
-semantically equivalent function.
+These function attributes are supported by the Epiphany back end:
 
-@item nonnull (@var{arg-index}, @dots{})
-@cindex @code{nonnull} function attribute
-The @code{nonnull} attribute specifies that some function parameters should
-be non-null pointers.  For instance, the declaration:
+@table @code
+@item disinterrupt
+@cindex @code{disinterrupt} function attribute, Epiphany
+This attribute causes the compiler to emit
+instructions to disable interrupts for the duration of the given
+function.
 
-@smallexample
-extern void *
-my_memcpy (void *dest, const void *src, size_t len)
-        __attribute__((nonnull (1, 2)));
-@end smallexample
+@item forwarder_section
+@cindex @code{forwarder_section} function attribute, Epiphany
+This attribute modifies the behavior of an interrupt handler.
+The interrupt handler may be in external memory which cannot be
+reached by a branch instruction, so generate a local memory trampoline
+to transfer control.  The single parameter identifies the section where
+the trampoline is placed.
 
-@noindent
-causes the compiler to check that, in calls to @code{my_memcpy},
-arguments @var{dest} and @var{src} are non-null.  If the compiler
-determines that a null pointer is passed in an argument slot marked
-as non-null, and the @option{-Wnonnull} option is enabled, a warning
-is issued.  The compiler may also choose to make optimizations based
-on the knowledge that certain function arguments will never be null.
+@item interrupt
+@cindex @code{interrupt} function attribute, Epiphany
+Use this attribute to indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when this attribute is present.  It may also generate
+a special section with code to initialize the interrupt vector table.
 
-If no argument index list is given to the @code{nonnull} attribute,
-all pointer arguments are marked as non-null.  To illustrate, the
-following declaration is equivalent to the previous example:
+On Epiphany targets one or more optional parameters can be added like this:
 
 @smallexample
-extern void *
-my_memcpy (void *dest, const void *src, size_t len)
-        __attribute__((nonnull));
+void __attribute__ ((interrupt ("dma0, dma1"))) universal_dma_handler ();
 @end smallexample
 
-@item no_reorder
-@cindex @code{no_reorder} function attribute
-Do not reorder functions or variables marked @code{no_reorder}
-against each other or top level assembler statements the executable.
-The actual order in the program will depend on the linker command
-line. Static variables marked like this are also not removed.
-This has a similar effect
-as the @option{-fno-toplevel-reorder} option, but only applies to the
-marked symbols.
+Permissible values for these parameters are: @w{@code{reset}},
+@w{@code{software_exception}}, @w{@code{page_miss}},
+@w{@code{timer0}}, @w{@code{timer1}}, @w{@code{message}},
+@w{@code{dma0}}, @w{@code{dma1}}, @w{@code{wand}} and @w{@code{swi}}.
+Multiple parameters indicate that multiple entries in the interrupt
+vector table should be initialized for this function, i.e.@: for each
+parameter @w{@var{name}}, a jump to the function is emitted in
+the section @w{ivt_entry_@var{name}}.  The parameter(s) may be omitted
+entirely, in which case no interrupt vector table entry is provided.
 
-@item returns_nonnull
-@cindex @code{returns_nonnull} function attribute
-The @code{returns_nonnull} attribute specifies that the function
-return value should be a non-null pointer.  For instance, the declaration:
+Note that interrupts are enabled inside the function
+unless the @code{disinterrupt} attribute is also specified.
 
+The following examples are all valid uses of these attributes on
+Epiphany targets:
 @smallexample
-extern void *
-mymalloc (size_t len) __attribute__((returns_nonnull));
+void __attribute__ ((interrupt)) universal_handler ();
+void __attribute__ ((interrupt ("dma1"))) dma1_handler ();
+void __attribute__ ((interrupt ("dma0, dma1"))) 
+  universal_dma_handler ();
+void __attribute__ ((interrupt ("timer0"), disinterrupt))
+  fast_timer_handler ();
+void __attribute__ ((interrupt ("dma0, dma1"), 
+                     forwarder_section ("tramp")))
+  external_dma_handler ();
 @end smallexample
 
-@noindent
-lets the compiler optimize callers based on the knowledge
-that the return value will never be null.
+@item long_call
+@itemx short_call
+@cindex @code{long_call} function attribute, Epiphany
+@cindex @code{short_call} function attribute, Epiphany
+@cindex indirect calls, Epiphany
+These attributes specify how a particular function is called.
+These attributes override the
+@option{-mlong-calls} (@pxref{Adapteva Epiphany Options})
+command-line switch and @code{#pragma long_calls} settings.
+@end table
 
-@item noreturn
-@cindex @code{noreturn} function attribute
-A few standard library functions, such as @code{abort} and @code{exit},
-cannot return.  GCC knows this automatically.  Some programs define
-their own functions that never return.  You can declare them
-@code{noreturn} to tell the compiler this fact.  For example,
 
-@smallexample
-@group
-void fatal () __attribute__ ((noreturn));
+@node H8/300 Function Attributes
+@subsection H8/300 Function Attributes
 
-void
-fatal (/* @r{@dots{}} */)
-@{
-  /* @r{@dots{}} */ /* @r{Print error message.} */ /* @r{@dots{}} */
-  exit (1);
-@}
-@end group
-@end smallexample
+These function attributes are available for H8/300 targets:
 
-The @code{noreturn} keyword tells the compiler to assume that
-@code{fatal} cannot return.  It can then optimize without regard to what
-would happen if @code{fatal} ever did return.  This makes slightly
-better code.  More importantly, it helps avoid spurious warnings of
-uninitialized variables.
+@table @code
+@item function_vector
+@cindex @code{function_vector} function attribute, H8/300
+Use this attribute on the H8/300, H8/300H, and H8S to indicate 
+that the specified function should be called through the function vector.
+Calling a function through the function vector reduces code size; however,
+the function vector has a limited size (maximum 128 entries on the H8/300
+and 64 entries on the H8/300H and H8S)
+and shares space with the interrupt vector.
 
-The @code{noreturn} keyword does not affect the exceptional path when that
-applies: a @code{noreturn}-marked function may still return to the caller
-by throwing an exception or calling @code{longjmp}.
+@item interrupt_handler
+@cindex @code{interrupt_handler} function attribute, H8/300
+Use this attribute on the H8/300, H8/300H, and H8S to
+indicate that the specified function is an interrupt handler.  The compiler
+generates function entry and exit sequences suitable for use in an
+interrupt handler when this attribute is present.
 
-Do not assume that registers saved by the calling function are
-restored before calling the @code{noreturn} function.
+@item saveall
+@cindex @code{saveall} function attribute, H8/300
+@cindex save all registers on the H8/300, H8/300H, and H8S
+Use this attribute on the H8/300, H8/300H, and H8S to indicate that
+all registers except the stack pointer should be saved in the prologue
+regardless of whether they are used or not.
+@end table
 
-It does not make sense for a @code{noreturn} function to have a return
-type other than @code{void}.
+@node IA-64 Function Attributes
+@subsection IA-64 Function Attributes
 
-@item nothrow
-@cindex @code{nothrow} function attribute
-The @code{nothrow} attribute is used to inform the compiler that a
-function cannot throw an exception.  For example, most functions in
-the standard C library can be guaranteed not to throw an exception
-with the notable exceptions of @code{qsort} and @code{bsearch} that
-take function pointer arguments.
+These function attributes are supported on IA-64 targets:
 
-@item nosave_low_regs
-@cindex @code{nosave_low_regs} function attribute, SH
-Use this attribute on SH targets to indicate that an @code{interrupt_handler}
-function should not save and restore registers R0..R7.  This can be used on SH3*
-and SH4* targets that have a second R0..R7 register bank for non-reentrant
-interrupt handlers.
+@table @code
+@item syscall_linkage
+@cindex @code{syscall_linkage} function attribute, IA-64
+This attribute is used to modify the IA-64 calling convention by marking
+all input registers as live at all function exits.  This makes it possible
+to restart a system call after an interrupt without having to save/restore
+the input registers.  This also prevents kernel data from leaking into
+application code.
 
-@item optimize
-@cindex @code{optimize} function attribute
-The @code{optimize} attribute is used to specify that a function is to
-be compiled with different optimization options than specified on the
-command line.  Arguments can either be numbers or strings.  Numbers
-are assumed to be an optimization level.  Strings that begin with
-@code{O} are assumed to be an optimization option, while other options
-are assumed to be used with a @code{-f} prefix.  You can also use the
-@samp{#pragma GCC optimize} pragma to set the optimization options
-that affect more than one function.
-@xref{Function Specific Option Pragmas}, for details about the
-@samp{#pragma GCC optimize} pragma.
+@item version_id
+@cindex @code{version_id} function attribute, IA-64
+This IA-64 HP-UX attribute, attached to a global variable or function, renames a
+symbol to contain a version string, thus allowing for function level
+versioning.  HP-UX system header files may use function level versioning
+for some system calls.
 
-This can be used for instance to have frequently-executed functions
-compiled with more aggressive optimization options that produce faster
-and larger code, while other functions can be compiled with less
-aggressive options.
+@smallexample
+extern int foo () __attribute__((version_id ("20040821")));
+@end smallexample
 
-@item OS_main
-@itemx OS_task
-@cindex @code{OS_main} function attribute, AVR
-@cindex @code{OS_task} function attribute, AVR
-On AVR, functions with the @code{OS_main} or @code{OS_task} attribute
-do not save/restore any call-saved register in their prologue/epilogue.
+@noindent
+Calls to @code{foo} are mapped to calls to @code{foo@{20040821@}}.
+@end table
 
-The @code{OS_main} attribute can be used when there @emph{is
-guarantee} that interrupts are disabled at the time when the function
-is entered.  This saves resources when the stack pointer has to be
-changed to set up a frame for local variables.
+@node M32C Function Attributes
+@subsection M32C Function Attributes
 
-The @code{OS_task} attribute can be used when there is @emph{no
-guarantee} that interrupts are disabled at that time when the function
-is entered like for, e@.g@. task functions in a multi-threading operating
-system. In that case, changing the stack pointer register is
-guarded by save/clear/restore of the global interrupt enable flag.
+These function attributes are supported by the M32C back end:
 
-The differences to the @code{naked} function attribute are:
-@itemize @bullet
-@item @code{naked} functions do not have a return instruction whereas 
-@code{OS_main} and @code{OS_task} functions have a @code{RET} or
-@code{RETI} return instruction.
-@item @code{naked} functions do not set up a frame for local variables
-or a frame pointer whereas @code{OS_main} and @code{OS_task} do this
-as needed.
-@end itemize
+@table @code
+@item bank_switch
+@cindex @code{bank_switch} function attribute, M32C
+When added to an interrupt handler with the M32C port, causes the
+prologue and epilogue to use bank switching to preserve the registers
+rather than saving them on the stack.
 
-@item pcs
-@cindex @code{pcs} function attribute, ARM
+@item fast_interrupt
+@cindex @code{fast_interrupt} function attribute, M32C
+Use this attribute on the M32C port to indicate that the specified
+function is a fast interrupt handler.  This is just like the
+@code{interrupt} attribute, except that @code{freit} is used to return
+instead of @code{reit}.
 
-The @code{pcs} attribute can be used to control the calling convention
-used for a function on ARM.  The attribute takes an argument that specifies
-the calling convention to use.
+@item function_vector
+@cindex @code{function_vector} function attribute, M16C/M32C
+On M16C/M32C targets, the @code{function_vector} attribute declares a
+special page subroutine call function. Use of this attribute reduces
+the code size by 2 bytes for each call generated to the
+subroutine. The argument to the attribute is the vector number entry
+from the special page vector table which contains the 16 low-order
+bits of the subroutine's entry address. Each vector table has special
+page number (18 to 255) that is used in @code{jsrs} instructions.
+Jump addresses of the routines are generated by adding 0x0F0000 (in
+case of M16C targets) or 0xFF0000 (in case of M32C targets), to the
+2-byte addresses set in the vector table. Therefore you need to ensure
+that all the special page vector routines should get mapped within the
+address range 0x0F0000 to 0x0FFFFF (for M16C) and 0xFF0000 to 0xFFFFFF
+(for M32C).
 
-When compiling using the AAPCS ABI (or a variant of it) then valid
-values for the argument are @code{"aapcs"} and @code{"aapcs-vfp"}.  In
-order to use a variant other than @code{"aapcs"} then the compiler must
-be permitted to use the appropriate co-processor registers (i.e., the
-VFP registers must be available in order to use @code{"aapcs-vfp"}).
-For example,
+In the following example 2 bytes are saved for each call to
+function @code{foo}.
 
 @smallexample
-/* Argument passed in r0, and result returned in r0+r1.  */
-double f2d (float) __attribute__((pcs("aapcs")));
+void foo (void) __attribute__((function_vector(0x18)));
+void foo (void)
+@{
+@}
+
+void bar (void)
+@{
+    foo();
+@}
 @end smallexample
 
-Variadic functions always use the @code{"aapcs"} calling convention and
-the compiler rejects attempts to specify an alternative.
+If functions are defined in one file and are called in another file,
+then be sure to write this declaration in both files.
 
-@item pure
-@cindex @code{pure} function attribute
-Many functions have no effects except the return value and their
-return value depends only on the parameters and/or global variables.
-Such a function can be subject
-to common subexpression elimination and loop optimization just as an
-arithmetic operator would be.  These functions should be declared
-with the attribute @code{pure}.  For example,
+This attribute is ignored for R8C target.
 
-@smallexample
-int square (int) __attribute__ ((pure));
-@end smallexample
+@item interrupt
+@cindex @code{interrupt} function attribute, M32C
+Use this attribute to indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when this attribute is present.
+@end table
 
-@noindent
-says that the hypothetical function @code{square} is safe to call
-fewer times than the program says.
+@node M32R/D Function Attributes
+@subsection M32R/D Function Attributes
 
-Some of common examples of pure functions are @code{strlen} or @code{memcmp}.
-Interesting non-pure functions are functions with infinite loops or those
-depending on volatile memory or other system resource, that may change between
-two consecutive calls (such as @code{feof} in a multithreading environment).
+These function attributes are supported by the M32R/D back end:
 
-@item hot
-@cindex @code{hot} function attribute
-The @code{hot} attribute on a function is used to inform the compiler that
-the function is a hot spot of the compiled program.  The function is
-optimized more aggressively and on many targets it is placed into a special
-subsection of the text section so all hot functions appear close together,
-improving locality.
+@table @code
+@item interrupt
+@cindex @code{interrupt} function attribute, M32R/D
+Use this attribute to indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when this attribute is present.
 
-When profile feedback is available, via @option{-fprofile-use}, hot functions
-are automatically detected and this attribute is ignored.
+@item model (@var{model-name})
+@cindex @code{model} function attribute, M32R/D
+@cindex function addressability on the M32R/D
 
-@item cold
-@cindex @code{cold} function attribute
-The @code{cold} attribute on functions is used to inform the compiler that
-the function is unlikely to be executed.  The function is optimized for
-size rather than speed and on many targets it is placed into a special
-subsection of the text section so all cold functions appear close together,
-improving code locality of non-cold parts of program.  The paths leading
-to calls of cold functions within code are marked as unlikely by the branch
-prediction mechanism.  It is thus useful to mark functions used to handle
-unlikely conditions, such as @code{perror}, as cold to improve optimization
-of hot functions that do call marked functions in rare occasions.
+On the M32R/D, use this attribute to set the addressability of an
+object, and of the code generated for a function.  The identifier
+@var{model-name} is one of @code{small}, @code{medium}, or
+@code{large}, representing each of the code models.
 
-When profile feedback is available, via @option{-fprofile-use}, cold functions
-are automatically detected and this attribute is ignored.
+Small model objects live in the lower 16MB of memory (so that their
+addresses can be loaded with the @code{ld24} instruction), and are
+callable with the @code{bl} instruction.
 
-@item no_sanitize_address
-@itemx no_address_safety_analysis
-@cindex @code{no_sanitize_address} function attribute
-The @code{no_sanitize_address} attribute on functions is used
-to inform the compiler that it should not instrument memory accesses
-in the function when compiling with the @option{-fsanitize=address} option.
-The @code{no_address_safety_analysis} is a deprecated alias of the
-@code{no_sanitize_address} attribute, new code should use
-@code{no_sanitize_address}.
+Medium model objects may live anywhere in the 32-bit address space (the
+compiler generates @code{seth/add3} instructions to load their addresses),
+and are callable with the @code{bl} instruction.
 
-@item no_sanitize_thread
-@cindex @code{no_sanitize_thread} function attribute
-The @code{no_sanitize_thread} attribute on functions is used
-to inform the compiler that it should not instrument memory accesses
-in the function when compiling with the @option{-fsanitize=thread} option.
+Large model objects may live anywhere in the 32-bit address space (the
+compiler generates @code{seth/add3} instructions to load their addresses),
+and may not be reachable with the @code{bl} instruction (the compiler
+generates the much slower @code{seth/add3/jl} instruction sequence).
+@end table
 
-@item no_sanitize_undefined
-@cindex @code{no_sanitize_undefined} function attribute
-The @code{no_sanitize_undefined} attribute on functions is used
-to inform the compiler that it should not check for undefined behavior
-in the function when compiling with the @option{-fsanitize=undefined} option.
+@node m68k Function Attributes
+@subsection m68k Function Attributes
 
-@item bnd_legacy
-@cindex @code{bnd_legacy} function attribute
-@cindex Pointer Bounds Checker attributes
-The @code{bnd_legacy} attribute on functions is used to inform the
-compiler that the function should not be instrumented when compiled
-with the @option{-fcheck-pointer-bounds} option.
+These function attributes are supported by the m68k back end:
 
-@item bnd_instrument
-@cindex @code{bnd_instrument} function attribute
-The @code{bnd_instrument} attribute on functions is used to inform the
-compiler that the function should be instrumented when compiled
-with the @option{-fchkp-instrument-marked-only} option.
+@table @code
+@item interrupt
+@itemx interrupt_handler
+@cindex @code{interrupt} function attribute, m68k
+@cindex @code{interrupt_handler} function attribute, m68k
+Use this attribute to
+indicate that the specified function is an interrupt handler.  The compiler
+generates function entry and exit sequences suitable for use in an
+interrupt handler when this attribute is present.  Either name may be used.
 
-@item regparm (@var{number})
-@cindex @code{regparm} function attribute, x86
-@cindex functions that are passed arguments in registers on x86-32
-On x86-32 targets, the @code{regparm} attribute causes the compiler to
-pass arguments number one to @var{number} if they are of integral type
-in registers EAX, EDX, and ECX instead of on the stack.  Functions that
-take a variable number of arguments continue to be passed all of their
-arguments on the stack.
+@item interrupt_thread
+@cindex @code{interrupt_thread} function attribute, fido
+Use this attribute on fido, a subarchitecture of the m68k, to indicate
+that the specified function is an interrupt handler that is designed
+to run as a thread.  The compiler omits generate prologue/epilogue
+sequences and replaces the return instruction with a @code{sleep}
+instruction.  This attribute is available only on fido.
+@end table
 
-Beware that on some ELF systems this attribute is unsuitable for
-global functions in shared libraries with lazy binding (which is the
-default).  Lazy binding sends the first call via resolving code in
-the loader, which might assume EAX, EDX and ECX can be clobbered, as
-per the standard calling conventions.  Solaris 8 is affected by this.
-Systems with the GNU C Library version 2.1 or higher
-and FreeBSD are believed to be
-safe since the loaders there save EAX, EDX and ECX.  (Lazy binding can be
-disabled with the linker or the loader if desired, to avoid the
-problem.)
+@node MCORE Function Attributes
+@subsection MCORE Function Attributes
+
+These function attributes are supported by the MCORE back end:
 
-@item reset
-@cindex @code{reset} function attribute, NDS32
-@cindex reset handler functions
-Use this attribute on the NDS32 target to indicate that the specified function
-is a reset handler.  The compiler will generate corresponding sections
-for use in a reset handler.  You can use the following attributes
-to provide extra exception handling:
 @table @code
-@item nmi
-@cindex @code{nmi} function attribute, NDS32
-Provide a user-defined function to handle NMI exception.
-@item warm
-@cindex @code{warm} function attribute, NDS32
-Provide a user-defined function to handle warm reset exception.
+@item naked
+@cindex @code{naked} function attribute, MCORE
+This attribute allows the compiler to construct the
+requisite function declaration, while allowing the body of the
+function to be assembly code. The specified function will not have
+prologue/epilogue sequences generated by the compiler. Only basic
+@code{asm} statements can safely be included in naked functions
+(@pxref{Basic Asm}). While using extended @code{asm} or a mixture of
+basic @code{asm} and C code may appear to work, they cannot be
+depended upon to work reliably and are not supported.
 @end table
 
-@item sseregparm
-@cindex @code{sseregparm} function attribute, x86
-On x86-32 targets with SSE support, the @code{sseregparm} attribute
-causes the compiler to pass up to 3 floating-point arguments in
-SSE registers instead of on the stack.  Functions that take a
-variable number of arguments continue to pass all of their
-floating-point arguments on the stack.
+@node MeP Function Attributes
+@subsection MeP Function Attributes
 
-@item force_align_arg_pointer
-@cindex @code{force_align_arg_pointer} function attribute, x86
-On x86 targets, the @code{force_align_arg_pointer} attribute may be
-applied to individual function definitions, generating an alternate
-prologue and epilogue that realigns the run-time stack if necessary.
-This supports mixing legacy codes that run with a 4-byte aligned stack
-with modern codes that keep a 16-byte stack for SSE compatibility.
+These function attributes are supported by the MeP back end:
+
+@table @code
+@item disinterrupt
+@cindex @code{disinterrupt} function attribute, MeP
+On MeP targets, this attribute causes the compiler to emit
+instructions to disable interrupts for the duration of the given
+function.
 
-@item renesas
-@cindex @code{renesas} function attribute, SH
-On SH targets this attribute specifies that the function or struct follows the
-Renesas ABI.
+@item interrupt
+@cindex @code{interrupt} function attribute, MeP
+Use this attribute to indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when this attribute is present.
 
-@item resbank
-@cindex @code{resbank} function attribute, SH
-On the SH2A target, this attribute enables the high-speed register
-saving and restoration using a register bank for @code{interrupt_handler}
-routines.  Saving to the bank is performed automatically after the CPU
-accepts an interrupt that uses a register bank.
+@item near
+@cindex @code{near} function attribute, MeP
+This attribute causes the compiler to assume the called
+function is close enough to use the normal calling convention,
+overriding the @option{-mtf} command-line option.
 
-The nineteen 32-bit registers comprising general register R0 to R14,
-control register GBR, and system registers MACH, MACL, and PR and the
-vector table address offset are saved into a register bank.  Register
-banks are stacked in first-in last-out (FILO) sequence.  Restoration
-from the bank is executed by issuing a RESBANK instruction.
+@item far
+@cindex @code{far} function attribute, MeP
+On MeP targets this causes the compiler to use a calling convention
+that assumes the called function is too far away for the built-in
+addressing modes.
 
-@item returns_twice
-@cindex @code{returns_twice} function attribute
-The @code{returns_twice} attribute tells the compiler that a function may
-return more than one time.  The compiler ensures that all registers
-are dead before calling such a function and emits a warning about
-the variables that may be clobbered after the second return from the
-function.  Examples of such functions are @code{setjmp} and @code{vfork}.
-The @code{longjmp}-like counterpart of such function, if any, might need
-to be marked with the @code{noreturn} attribute.
+@item vliw
+@cindex @code{vliw} function attribute, MeP
+The @code{vliw} attribute tells the compiler to emit
+instructions in VLIW mode instead of core mode.  Note that this
+attribute is not allowed unless a VLIW coprocessor has been configured
+and enabled through command-line options.
+@end table
 
-@item saveall
-@cindex @code{saveall} function attribute, Blackfin
-@cindex @code{saveall} function attribute, H8/300
-@cindex save all registers on the Blackfin, H8/300, H8/300H, and H8S
-Use this attribute on the Blackfin, H8/300, H8/300H, and H8S to indicate that
-all registers except the stack pointer should be saved in the prologue
-regardless of whether they are used or not.
+@node MicroBlaze Function Attributes
+@subsection MicroBlaze Function Attributes
 
+These function attributes are supported on MicroBlaze targets:
+
+@table @code
 @item save_volatiles
 @cindex @code{save_volatiles} function attribute, MicroBlaze
-Use this attribute on the MicroBlaze to indicate that the function is
+Use this attribute to indicate that the function is
 an interrupt handler.  All volatile registers (in addition to non-volatile
 registers) are saved in the function prologue.  If the function is a leaf
 function, only volatiles used by the function are saved.  A normal function
@@ -3827,7 +4079,7 @@ return is generated instead of a return from interrupt.
 @item break_handler
 @cindex @code{break_handler} function attribute, MicroBlaze
 @cindex break handler functions
-Use this attribute on the MicroBlaze ports to indicate that
+Use this attribute to indicate that
 the specified function is a break handler.  The compiler generates function
 entry and exit sequences suitable for use in an break handler when this
 attribute is present. The return from @code{break_handler} is done through
@@ -3836,290 +4088,404 @@ the @code{rtbd} instead of @code{rtsd}.
 @smallexample
 void f () __attribute__ ((break_handler));
 @end smallexample
+@end table
 
-@item section ("@var{section-name}")
-@cindex @code{section} function attribute
-Normally, the compiler places the code it generates in the @code{text} section.
-Sometimes, however, you need additional sections, or you need certain
-particular functions to appear in special sections.  The @code{section}
-attribute specifies that a function lives in a particular section.
-For example, the declaration:
+@node Microsoft Windows Function Attributes
+@subsection Microsoft Windows Function Attributes
 
-@smallexample
-extern void foobar (void) __attribute__ ((section ("bar")));
-@end smallexample
+The following attributes are available on Microsoft Windows and Symbian OS
+targets.
 
-@noindent
-puts the function @code{foobar} in the @code{bar} section.
+@table @code
+@item dllexport
+@cindex @code{dllexport} function attribute
+@cindex @code{__declspec(dllexport)}
+On Microsoft Windows targets and Symbian OS targets the
+@code{dllexport} attribute causes the compiler to provide a global
+pointer to a pointer in a DLL, so that it can be referenced with the
+@code{dllimport} attribute.  On Microsoft Windows targets, the pointer
+name is formed by combining @code{_imp__} and the function or variable
+name.
 
-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.
+You can use @code{__declspec(dllexport)} as a synonym for
+@code{__attribute__ ((dllexport))} for compatibility with other
+compilers.
 
-@item sentinel
-@cindex @code{sentinel} function attribute
-This function attribute ensures that a parameter in a function call is
-an explicit @code{NULL}.  The attribute is only valid on variadic
-functions.  By default, the sentinel is located at position zero, the
-last parameter of the function call.  If an optional integer position
-argument P is supplied to the attribute, the sentinel must be located at
-position P counting backwards from the end of the argument list.
+On systems that support the @code{visibility} attribute, this
+attribute also implies ``default'' visibility.  It is an error to
+explicitly specify any other visibility.
 
-@smallexample
-__attribute__ ((sentinel))
-is equivalent to
-__attribute__ ((sentinel(0)))
-@end smallexample
+GCC's default behavior is to emit all inline functions with the
+@code{dllexport} attribute.  Since this can cause object file-size bloat,
+you can use @option{-fno-keep-inline-dllexport}, which tells GCC to
+ignore the attribute for inlined functions unless the 
+@option{-fkeep-inline-functions} flag is used instead.
 
-The attribute is automatically set with a position of 0 for the built-in
-functions @code{execl} and @code{execlp}.  The built-in function
-@code{execle} has the attribute set with a position of 1.
+The attribute is ignored for undefined symbols.
 
-A valid @code{NULL} in this context is defined as zero with any pointer
-type.  If your system defines the @code{NULL} macro with an integer type
-then you need to add an explicit cast.  GCC replaces @code{stddef.h}
-with a copy that redefines NULL appropriately.
+When applied to C++ classes, the attribute marks defined non-inlined
+member functions and static data members as exports.  Static consts
+initialized in-class are not marked unless they are also defined
+out-of-class.
 
-The warnings for missing or incorrect sentinels are enabled with
-@option{-Wformat}.
+For Microsoft Windows targets there are alternative methods for
+including the symbol in the DLL's export table such as using a
+@file{.def} file with an @code{EXPORTS} section or, with GNU ld, using
+the @option{--export-all} linker flag.
+
+@item dllimport
+@cindex @code{dllimport} function attribute
+@cindex @code{__declspec(dllimport)}
+On Microsoft Windows and Symbian OS targets, the @code{dllimport}
+attribute causes the compiler to reference a function or variable via
+a global pointer to a pointer that is set up by the DLL exporting the
+symbol.  The attribute implies @code{extern}.  On Microsoft Windows
+targets, the pointer name is formed by combining @code{_imp__} and the
+function or variable name.
 
-@item short_call
-See @code{long_call}.
+You can use @code{__declspec(dllimport)} as a synonym for
+@code{__attribute__ ((dllimport))} for compatibility with other
+compilers.
 
-@item shortcall
-See @code{longcall}.
+On systems that support the @code{visibility} attribute, this
+attribute also implies ``default'' visibility.  It is an error to
+explicitly specify any other visibility.
 
-@item signal
-@cindex @code{signal} function attribute, AVR
-Use this attribute on the AVR to indicate that the specified
-function is an interrupt handler.  The compiler generates function
-entry and exit sequences suitable for use in an interrupt handler when this
-attribute is present.
+Currently, the attribute is ignored for inlined functions.  If the
+attribute is applied to a symbol @emph{definition}, an error is reported.
+If a symbol previously declared @code{dllimport} is later defined, the
+attribute is ignored in subsequent references, and a warning is emitted.
+The attribute is also overridden by a subsequent declaration as
+@code{dllexport}.
 
-See also the @code{interrupt} function attribute. 
+When applied to C++ classes, the attribute marks non-inlined
+member functions and static data members as imports.  However, the
+attribute is ignored for virtual methods to allow creation of vtables
+using thunks.
 
-The AVR hardware globally disables interrupts when an interrupt is executed.
-Interrupt handler functions defined with the @code{signal} attribute
-do not re-enable interrupts.  It is save to enable interrupts in a
-@code{signal} handler.  This ``save'' only applies to the code
-generated by the compiler and not to the IRQ layout of the
-application which is responsibility of the application.
+On the SH Symbian OS target the @code{dllimport} attribute also has
+another affect---it can cause the vtable and run-time type information
+for a class to be exported.  This happens when the class has a
+dllimported constructor or a non-inline, non-pure virtual function
+and, for either of those two conditions, the class also has an inline
+constructor or destructor and has a key function that is defined in
+the current translation unit.
 
-If both @code{signal} and @code{interrupt} are specified for the same
-function, @code{signal} is silently ignored.
+For Microsoft Windows targets the use of the @code{dllimport}
+attribute on functions is not necessary, but provides a small
+performance benefit by eliminating a thunk in the DLL@.  The use of the
+@code{dllimport} attribute on imported variables can be avoided by passing the
+@option{--enable-auto-import} switch to the GNU linker.  As with
+functions, using the attribute for a variable eliminates a thunk in
+the DLL@.
 
-@item sp_switch
-@cindex @code{sp_switch} function attribute, SH
-Use this attribute on the SH to indicate an @code{interrupt_handler}
-function should switch to an alternate stack.  It expects a string
-argument that names a global variable holding the address of the
-alternate stack.
+One drawback to using this attribute is that a pointer to a
+@emph{variable} marked as @code{dllimport} cannot be used as a constant
+address. However, a pointer to a @emph{function} with the
+@code{dllimport} attribute can be used as a constant initializer; in
+this case, the address of a stub function in the import lib is
+referenced.  On Microsoft Windows targets, the attribute can be disabled
+for functions by setting the @option{-mnop-fun-dllimport} flag.
+@end table
 
-@smallexample
-void *alt_stack;
-void f () __attribute__ ((interrupt_handler,
-                          sp_switch ("alt_stack")));
-@end smallexample
+@node MIPS Function Attributes
+@subsection MIPS Function Attributes
 
-@item stdcall
-@cindex @code{stdcall} function attribute, x86-32
-@cindex functions that pop the argument stack on x86-32
-On x86-32 targets, the @code{stdcall} attribute causes the compiler to
-assume that the called function pops off the stack space used to
-pass arguments, unless it takes a variable number of arguments.
+These function attributes are supported by the MIPS back end:
 
-@item syscall_linkage
-@cindex @code{syscall_linkage} function attribute, IA-64
-This attribute is used to modify the IA-64 calling convention by marking
-all input registers as live at all function exits.  This makes it possible
-to restart a system call after an interrupt without having to save/restore
-the input registers.  This also prevents kernel data from leaking into
-application code.
+@table @code
+@item interrupt
+@cindex @code{interrupt} function attribute, MIPS
+Use this attribute to indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when this attribute is present.
 
-@item target
-@cindex @code{target} function attribute
-The @code{target} attribute is used to specify that a function is to
-be compiled with different target options than specified on the
-command line.  This can be used for instance to have functions
-compiled with a different ISA (instruction set architecture) than the
-default.  You can also use the @samp{#pragma GCC target} pragma to set
-more than one function to be compiled with specific target options.
-@xref{Function Specific Option Pragmas}, for details about the
-@samp{#pragma GCC target} pragma.
+You can use the following attributes to modify the behavior
+of an interrupt handler:
+@table @code
+@item use_shadow_register_set
+@cindex @code{use_shadow_register_set} function attribute, MIPS
+Assume that the handler uses a shadow register set, instead of
+the main general-purpose registers.
 
-For instance on an x86, you could compile one function with
-@code{target("sse4.1,arch=core2")} and another with
-@code{target("sse4a,arch=amdfam10")}.  This is equivalent to
-compiling the first function with @option{-msse4.1} and
-@option{-march=core2} options, and the second function with
-@option{-msse4a} and @option{-march=amdfam10} options.  It is up to the
-user to make sure that a function is only invoked on a machine that
-supports the particular ISA it is compiled for (for example by using
-@code{cpuid} on x86 to determine what feature bits and architecture
-family are used).
+@item keep_interrupts_masked
+@cindex @code{keep_interrupts_masked} function attribute, MIPS
+Keep interrupts masked for the whole function.  Without this attribute,
+GCC tries to reenable interrupts for as much of the function as it can.
+
+@item use_debug_exception_return
+@cindex @code{use_debug_exception_return} function attribute, MIPS
+Return using the @code{deret} instruction.  Interrupt handlers that don't
+have this attribute return using @code{eret} instead.
+@end table
 
+You can use any combination of these attributes, as shown below:
 @smallexample
-int core2_func (void) __attribute__ ((__target__ ("arch=core2")));
-int sse3_func (void) __attribute__ ((__target__ ("sse3")));
+void __attribute__ ((interrupt)) v0 ();
+void __attribute__ ((interrupt, use_shadow_register_set)) v1 ();
+void __attribute__ ((interrupt, keep_interrupts_masked)) v2 ();
+void __attribute__ ((interrupt, use_debug_exception_return)) v3 ();
+void __attribute__ ((interrupt, use_shadow_register_set,
+                     keep_interrupts_masked)) v4 ();
+void __attribute__ ((interrupt, use_shadow_register_set,
+                     use_debug_exception_return)) v5 ();
+void __attribute__ ((interrupt, keep_interrupts_masked,
+                     use_debug_exception_return)) v6 ();
+void __attribute__ ((interrupt, use_shadow_register_set,
+                     keep_interrupts_masked,
+                     use_debug_exception_return)) v7 ();
 @end smallexample
 
-You can either use multiple
-strings to specify multiple options, or separate the options
-with a comma (@samp{,}).
+@item long_call
+@itemx near
+@itemx far
+@cindex indirect calls, MIPS
+@cindex @code{long_call} function attribute, MIPS
+@cindex @code{near} function attribute, MIPS
+@cindex @code{far} function attribute, MIPS
+These attributes specify how a particular function is called on MIPS@.
+The attributes override the @option{-mlong-calls} (@pxref{MIPS Options})
+command-line switch.  The @code{long_call} and @code{far} attributes are
+synonyms, and cause the compiler to always call
+the function by first loading its address into a register, and then using
+the contents of that register.  The @code{near} attribute has the opposite
+effect; it specifies that non-PIC calls should be made using the more
+efficient @code{jal} instruction.
 
-The @code{target} attribute is presently implemented for
-x86, PowerPC, and Nios II targets only.
-The options supported are specific to each target.
+@item mips16
+@itemx nomips16
+@cindex @code{mips16} function attribute, MIPS
+@cindex @code{nomips16} function attribute, MIPS
 
-On the x86, the following options are allowed:
+On MIPS targets, you can use the @code{mips16} and @code{nomips16}
+function attributes to locally select or turn off MIPS16 code generation.
+A function with the @code{mips16} attribute is emitted as MIPS16 code,
+while MIPS16 code generation is disabled for functions with the
+@code{nomips16} attribute.  These attributes override the
+@option{-mips16} and @option{-mno-mips16} options on the command line
+(@pxref{MIPS Options}).
 
-@table @samp
-@item abm
-@itemx no-abm
-@cindex @code{target("abm")} function attribute, x86
-Enable/disable the generation of the advanced bit instructions.
+When compiling files containing mixed MIPS16 and non-MIPS16 code, the
+preprocessor symbol @code{__mips16} reflects the setting on the command line,
+not that within individual functions.  Mixed MIPS16 and non-MIPS16 code
+may interact badly with some GCC extensions such as @code{__builtin_apply}
+(@pxref{Constructing Calls}).
 
-@item aes
-@itemx no-aes
-@cindex @code{target("aes")} function attribute, x86
-Enable/disable the generation of the AES instructions.
+@item micromips, MIPS
+@itemx nomicromips, MIPS
+@cindex @code{micromips} function attribute
+@cindex @code{nomicromips} function attribute
 
-@item default
-@cindex @code{target("default")} function attribute, x86
-@xref{Function Multiversioning}, where it is used to specify the
-default function version.
+On MIPS targets, you can use the @code{micromips} and @code{nomicromips}
+function attributes to locally select or turn off microMIPS code generation.
+A function with the @code{micromips} attribute is emitted as microMIPS code,
+while microMIPS code generation is disabled for functions with the
+@code{nomicromips} attribute.  These attributes override the
+@option{-mmicromips} and @option{-mno-micromips} options on the command line
+(@pxref{MIPS Options}).
 
-@item mmx
-@itemx no-mmx
-@cindex @code{target("mmx")} function attribute, x86
-Enable/disable the generation of the MMX instructions.
+When compiling files containing mixed microMIPS and non-microMIPS code, the
+preprocessor symbol @code{__mips_micromips} reflects the setting on the
+command line,
+not that within individual functions.  Mixed microMIPS and non-microMIPS code
+may interact badly with some GCC extensions such as @code{__builtin_apply}
+(@pxref{Constructing Calls}).
 
-@item pclmul
-@itemx no-pclmul
-@cindex @code{target("pclmul")} function attribute, x86
-Enable/disable the generation of the PCLMUL instructions.
+@item nocompression
+@cindex @code{nocompression} function attribute, MIPS
+On MIPS targets, you can use the @code{nocompression} function attribute
+to locally turn off MIPS16 and microMIPS code generation.  This attribute
+overrides the @option{-mips16} and @option{-mmicromips} options on the
+command line (@pxref{MIPS Options}).
+@end table
 
-@item popcnt
-@itemx no-popcnt
-@cindex @code{target("popcnt")} function attribute, x86
-Enable/disable the generation of the POPCNT instruction.
+@node MSP430 Function Attributes
+@subsection MSP430 Function Attributes
 
-@item sse
-@itemx no-sse
-@cindex @code{target("sse")} function attribute, x86
-Enable/disable the generation of the SSE instructions.
+These function attributes are supported by the MSP430 back end:
 
-@item sse2
-@itemx no-sse2
-@cindex @code{target("sse2")} function attribute, x86
-Enable/disable the generation of the SSE2 instructions.
+@table @code
+@item critical
+@cindex @code{critical} function attribute, MSP430
+Critical functions disable interrupts upon entry and restore the
+previous interrupt state upon exit.  Critical functions cannot also
+have the @code{naked} or @code{reentrant} attributes.  They can have
+the @code{interrupt} attribute.
 
-@item sse3
-@itemx no-sse3
-@cindex @code{target("sse3")} function attribute, x86
-Enable/disable the generation of the SSE3 instructions.
+@item interrupt
+@cindex @code{interrupt} function attribute, MSP430
+Use this attribute to indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when this attribute is present.
 
-@item sse4
-@itemx no-sse4
-@cindex @code{target("sse4")} function attribute, x86
-Enable/disable the generation of the SSE4 instructions (both SSE4.1
-and SSE4.2).
+You can provide an argument to the interrupt
+attribute which specifies a name or number.  If the argument is a
+number it indicates the slot in the interrupt vector table (0 - 31) to
+which this handler should be assigned.  If the argument is a name it
+is treated as a symbolic name for the vector slot.  These names should
+match up with appropriate entries in the linker script.  By default
+the names @code{watchdog} for vector 26, @code{nmi} for vector 30 and
+@code{reset} for vector 31 are recognized.
 
-@item sse4.1
-@itemx no-sse4.1
-@cindex @code{target("sse4.1")} function attribute, x86
-Enable/disable the generation of the sse4.1 instructions.
+@item naked
+@cindex @code{naked} function attribute, MSP430
+This attribute allows the compiler to construct the
+requisite function declaration, while allowing the body of the
+function to be assembly code. The specified function will not have
+prologue/epilogue sequences generated by the compiler. Only basic
+@code{asm} statements can safely be included in naked functions
+(@pxref{Basic Asm}). While using extended @code{asm} or a mixture of
+basic @code{asm} and C code may appear to work, they cannot be
+depended upon to work reliably and are not supported.
 
-@item sse4.2
-@itemx no-sse4.2
-@cindex @code{target("sse4.2")} function attribute, x86
-Enable/disable the generation of the sse4.2 instructions.
+@item reentrant
+@cindex @code{reentrant} function attribute, MSP430
+Reentrant functions disable interrupts upon entry and enable them
+upon exit.  Reentrant functions cannot also have the @code{naked}
+or @code{critical} attributes.  They can have the @code{interrupt}
+attribute.
 
-@item sse4a
-@itemx no-sse4a
-@cindex @code{target("sse4a")} function attribute, x86
-Enable/disable the generation of the SSE4A instructions.
+@item wakeup
+@cindex @code{wakeup} function attribute, MSP430
+This attribute only applies to interrupt functions.  It is silently
+ignored if applied to a non-interrupt function.  A wakeup interrupt
+function will rouse the processor from any low-power state that it
+might be in when the function exits.
+@end table
 
-@item fma4
-@itemx no-fma4
-@cindex @code{target("fma4")} function attribute, x86
-Enable/disable the generation of the FMA4 instructions.
+@node NDS32 Function Attributes
+@subsection NDS32 Function Attributes
 
-@item xop
-@itemx no-xop
-@cindex @code{target("xop")} function attribute, x86
-Enable/disable the generation of the XOP instructions.
+These function attributes are supported by the NDS32 back end:
 
-@item lwp
-@itemx no-lwp
-@cindex @code{target("lwp")} function attribute, x86
-Enable/disable the generation of the LWP instructions.
+@table @code
+@item exception
+@cindex @code{exception} function attribute
+@cindex exception handler functions, NDS32
+Use this attribute on the NDS32 target to indicate that the specified function
+is an exception handler.  The compiler will generate corresponding sections
+for use in an exception handler.
 
-@item ssse3
-@itemx no-ssse3
-@cindex @code{target("ssse3")} function attribute, x86
-Enable/disable the generation of the SSSE3 instructions.
+@item interrupt
+@cindex @code{interrupt} function attribute, NDS32
+On NDS32 target, this attribute indicates that the specified function
+is an interrupt handler.  The compiler generates corresponding sections
+for use in an interrupt handler.  You can use the following attributes
+to modify the behavior:
+@table @code
+@item nested
+@cindex @code{nested} function attribute, NDS32
+This interrupt service routine is interruptible.
+@item not_nested
+@cindex @code{not_nested} function attribute, NDS32
+This interrupt service routine is not interruptible.
+@item nested_ready
+@cindex @code{nested_ready} function attribute, NDS32
+This interrupt service routine is interruptible after @code{PSW.GIE}
+(global interrupt enable) is set.  This allows interrupt service routine to
+finish some short critical code before enabling interrupts.
+@item save_all
+@cindex @code{save_all} function attribute, NDS32
+The system will help save all registers into stack before entering
+interrupt handler.
+@item partial_save
+@cindex @code{partial_save} function attribute, NDS32
+The system will help save caller registers into stack before entering
+interrupt handler.
+@end table
 
-@item cld
-@itemx no-cld
-@cindex @code{target("cld")} function attribute, x86
-Enable/disable the generation of the CLD before string moves.
+@item naked
+@cindex @code{naked} function attribute, NDS32
+This attribute allows the compiler to construct the
+requisite function declaration, while allowing the body of the
+function to be assembly code. The specified function will not have
+prologue/epilogue sequences generated by the compiler. Only basic
+@code{asm} statements can safely be included in naked functions
+(@pxref{Basic Asm}). While using extended @code{asm} or a mixture of
+basic @code{asm} and C code may appear to work, they cannot be
+depended upon to work reliably and are not supported.
 
-@item fancy-math-387
-@itemx no-fancy-math-387
-@cindex @code{target("fancy-math-387")} function attribute, x86
-Enable/disable the generation of the @code{sin}, @code{cos}, and
-@code{sqrt} instructions on the 387 floating-point unit.
+@item reset
+@cindex @code{reset} function attribute, NDS32
+@cindex reset handler functions
+Use this attribute on the NDS32 target to indicate that the specified function
+is a reset handler.  The compiler will generate corresponding sections
+for use in a reset handler.  You can use the following attributes
+to provide extra exception handling:
+@table @code
+@item nmi
+@cindex @code{nmi} function attribute, NDS32
+Provide a user-defined function to handle NMI exception.
+@item warm
+@cindex @code{warm} function attribute, NDS32
+Provide a user-defined function to handle warm reset exception.
+@end table
+@end table
 
-@item fused-madd
-@itemx no-fused-madd
-@cindex @code{target("fused-madd")} function attribute, x86
-Enable/disable the generation of the fused multiply/add instructions.
+@node Nios II Function Attributes
+@subsection Nios II Function Attributes
 
-@item ieee-fp
-@itemx no-ieee-fp
-@cindex @code{target("ieee-fp")} function attribute, x86
-Enable/disable the generation of floating point that depends on IEEE arithmetic.
+These function attributes are supported by the Nios II back end:
 
-@item inline-all-stringops
-@itemx no-inline-all-stringops
-@cindex @code{target("inline-all-stringops")} function attribute, x86
-Enable/disable inlining of string operations.
+@table @code
+@item target (@var{options})
+@cindex @code{target} function attribute
+As discussed in @ref{Common Function Attributes}, this attribute 
+allows specification of target-specific compilation options.
+
+When compiling for Nios II, the following options are allowed:
+
+@table @samp
+@item custom-@var{insn}=@var{N}
+@itemx no-custom-@var{insn}
+@cindex @code{target("custom-@var{insn}=@var{N}")} function attribute, Nios II
+@cindex @code{target("no-custom-@var{insn}")} function attribute, Nios II
+Each @samp{custom-@var{insn}=@var{N}} attribute locally enables use of a
+custom instruction with encoding @var{N} when generating code that uses 
+@var{insn}.  Similarly, @samp{no-custom-@var{insn}} locally inhibits use of
+the custom instruction @var{insn}.
+These target attributes correspond to the
+@option{-mcustom-@var{insn}=@var{N}} and @option{-mno-custom-@var{insn}}
+command-line options, and support the same set of @var{insn} keywords.
+@xref{Nios II Options}, for more information.
 
-@item inline-stringops-dynamically
-@itemx no-inline-stringops-dynamically
-@cindex @code{target("inline-stringops-dynamically")} function attribute, x86
-Enable/disable the generation of the inline code to do small string
-operations and calling the library routines for large operations.
+@item custom-fpu-cfg=@var{name}
+@cindex @code{target("custom-fpu-cfg=@var{name}")} function attribute, Nios II
+This attribute corresponds to the @option{-mcustom-fpu-cfg=@var{name}}
+command-line option, to select a predefined set of custom instructions
+named @var{name}.
+@xref{Nios II Options}, for more information.
+@end table
+@end table
 
-@item align-stringops
-@itemx no-align-stringops
-@cindex @code{target("align-stringops")} function attribute, x86
-Do/do not align destination of inlined string operations.
+@node PowerPC Function Attributes
+@subsection PowerPC Function Attributes
 
-@item recip
-@itemx no-recip
-@cindex @code{target("recip")} function attribute, x86
-Enable/disable the generation of RCPSS, RCPPS, RSQRTSS and RSQRTPS
-instructions followed an additional Newton-Raphson step instead of
-doing a floating-point division.
+These function attributes are supported by the PowerPC back end:
 
-@item arch=@var{ARCH}
-@cindex @code{target("arch=@var{ARCH}")} function attribute, x86
-Specify the architecture to generate code for in compiling the function.
+@table @code
+@item longcall
+@itemx shortcall
+@cindex indirect calls, PowerPC
+@cindex @code{longcall} function attribute, PowerPC
+@cindex @code{shortcall} function attribute, PowerPC
+The @code{longcall} attribute
+indicates that the function might be far away from the call site and
+require a different (more expensive) calling sequence.  The
+@code{shortcall} attribute indicates that the function is always close
+enough for the shorter calling sequence to be used.  These attributes
+override both the @option{-mlongcall} switch and
+the @code{#pragma longcall} setting.
 
-@item tune=@var{TUNE}
-@cindex @code{target("tune=@var{TUNE}")} function attribute, x86
-Specify the architecture to tune for in compiling the function.
+@xref{RS/6000 and PowerPC Options}, for more information on whether long
+calls are necessary.
 
-@item fpmath=@var{FPMATH}
-@cindex @code{target("fpmath=@var{FPMATH}")} function attribute, x86
-Specify which floating-point unit to use.  The
-@code{target("fpmath=sse,387")} option must be specified as
-@code{target("fpmath=sse+387")} because the comma would separate
-different options.
-@end table
+@item target (@var{options})
+@cindex @code{target} function attribute
+As discussed in @ref{Common Function Attributes}, this attribute 
+allows specification of target-specific compilation options.
 
 On the PowerPC, the following options are allowed:
 
@@ -4293,666 +4659,535 @@ compilation tunes for the @var{CPU} architecture, and not the
 default tuning specified on the command line.
 @end table
 
-When compiling for Nios II, the following options are allowed:
-
-@table @samp
-@item custom-@var{insn}=@var{N}
-@itemx no-custom-@var{insn}
-@cindex @code{target("custom-@var{insn}=@var{N}")} function attribute, Nios II
-@cindex @code{target("no-custom-@var{insn}")} function attribute, Nios II
-Each @samp{custom-@var{insn}=@var{N}} attribute locally enables use of a
-custom instruction with encoding @var{N} when generating code that uses 
-@var{insn}.  Similarly, @samp{no-custom-@var{insn}} locally inhibits use of
-the custom instruction @var{insn}.
-These target attributes correspond to the
-@option{-mcustom-@var{insn}=@var{N}} and @option{-mno-custom-@var{insn}}
-command-line options, and support the same set of @var{insn} keywords.
-@xref{Nios II Options}, for more information.
-
-@item custom-fpu-cfg=@var{name}
-@cindex @code{target("custom-fpu-cfg=@var{name}")} function attribute, Nios II
-This attribute corresponds to the @option{-mcustom-fpu-cfg=@var{name}}
-command-line option, to select a predefined set of custom instructions
-named @var{name}.
-@xref{Nios II Options}, for more information.
-@end table
-
-On the x86 and PowerPC back ends, the inliner does not inline a
+On the PowerPC, the inliner does not inline a
 function that has different target options than the caller, unless the
-callee has a subset of the target options of the caller.  For example
-a function declared with @code{target("sse3")} can inline a function
-with @code{target("sse2")}, since @code{-msse3} implies @code{-msse2}.
-
-@item trap_exit
-@cindex @code{trap_exit} function attribute, SH
-Use this attribute on the SH for an @code{interrupt_handler} to return using
-@code{trapa} instead of @code{rte}.  This attribute expects an integer
-argument specifying the trap number to be used.
-
-@item trapa_handler
-@cindex @code{trapa_handler} function attribute, SH
-On SH targets this function attribute is similar to @code{interrupt_handler}
-but it does not save and restore all registers.
-
-@item unused
-@cindex @code{unused} function attribute
-This attribute, attached to a function, means that the function is meant
-to be possibly unused.  GCC does not produce a warning for this
-function.
-
-@item used
-@cindex @code{used} function attribute
-This attribute, attached to a function, means that code must be emitted
-for the function even if it appears that the function is not referenced.
-This is useful, for example, when the function is referenced only in
-inline assembly.
-
-When applied to a member function of a C++ class template, the
-attribute also means that the function is instantiated if the
-class itself is instantiated.
-
-@item vector
-@cindex @code{vector} function attribute, RX
-This RX attribute is similar to the @code{interrupt} attribute, including its
-parameters, but does not make the function an interrupt-handler type
-function (i.e. it retains the normal C function calling ABI).  See the
-@code{interrupt} attribute for a description of its arguments.
-
-@item version_id
-@cindex @code{version_id} function attribute, IA-64
-This IA-64 HP-UX attribute, attached to a global variable or function, renames a
-symbol to contain a version string, thus allowing for function level
-versioning.  HP-UX system header files may use function level versioning
-for some system calls.
-
-@smallexample
-extern int foo () __attribute__((version_id ("20040821")));
-@end smallexample
-
-@noindent
-Calls to @var{foo} are mapped to calls to @var{foo@{20040821@}}.
-
-@item visibility ("@var{visibility_type}")
-@cindex @code{visibility} function attribute
-This attribute affects the linkage of the declaration to which it is attached.
-There are four supported @var{visibility_type} values: default,
-hidden, protected or internal visibility.
-
-@smallexample
-void __attribute__ ((visibility ("protected")))
-f () @{ /* @r{Do something.} */; @}
-int i __attribute__ ((visibility ("hidden")));
-@end smallexample
-
-The possible values of @var{visibility_type} correspond to the
-visibility settings in the ELF gABI.
-
-@table @dfn
-@c keep this list of visibilities in alphabetical order.
-
-@item default
-Default visibility is the normal case for the object file format.
-This value is available for the visibility attribute to override other
-options that may change the assumed visibility of entities.
-
-On ELF, default visibility means that the declaration is visible to other
-modules and, in shared libraries, means that the declared entity may be
-overridden.
-
-On Darwin, default visibility means that the declaration is visible to
-other modules.
-
-Default visibility corresponds to ``external linkage'' in the language.
-
-@item hidden
-Hidden visibility indicates that the entity declared has a new
-form of linkage, which we call ``hidden linkage''.  Two
-declarations of an object with hidden linkage refer to the same object
-if they are in the same shared object.
-
-@item internal
-Internal visibility is like hidden visibility, but with additional
-processor specific semantics.  Unless otherwise specified by the
-psABI, GCC defines internal visibility to mean that a function is
-@emph{never} called from another module.  Compare this with hidden
-functions which, while they cannot be referenced directly by other
-modules, can be referenced indirectly via function pointers.  By
-indicating that a function cannot be called from outside the module,
-GCC may for instance omit the load of a PIC register since it is known
-that the calling function loaded the correct value.
-
-@item protected
-Protected visibility is like default visibility except that it
-indicates that references within the defining module bind to the
-definition in that module.  That is, the declared entity cannot be
-overridden by another module.
-
+callee has a subset of the target options of the caller.
 @end table
 
-All visibilities are supported on many, but not all, ELF targets
-(supported when the assembler supports the @samp{.visibility}
-pseudo-op).  Default visibility is supported everywhere.  Hidden
-visibility is supported on Darwin targets.
-
-The visibility attribute should be applied only to declarations that
-would otherwise have external linkage.  The attribute should be applied
-consistently, so that the same entity should not be declared with
-different settings of the attribute.
+@node RL78 Function Attributes
+@subsection RL78 Function Attributes
 
-In C++, the visibility attribute applies to types as well as functions
-and objects, because in C++ types have linkage.  A class must not have
-greater visibility than its non-static data member types and bases,
-and class members default to the visibility of their class.  Also, a
-declaration without explicit visibility is limited to the visibility
-of its type.
+These function attributes are supported by the RL78 back end:
 
-In C++, you can mark member functions and static member variables of a
-class with the visibility attribute.  This is useful if you know a
-particular method or static member variable should only be used from
-one shared object; then you can mark it hidden while the rest of the
-class has default visibility.  Care must be taken to avoid breaking
-the One Definition Rule; for example, it is usually not useful to mark
-an inline method as hidden without marking the whole class as hidden.
+@table @code
+@item interrupt
+@itemx brk_interrupt
+@cindex @code{interrupt} function attribute, RL78
+@cindex @code{brk_interrupt} function attribute, RL78
+These attributes indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when this attribute is present.
 
-A C++ namespace declaration can also have the visibility attribute.
+Use @code{brk_interrupt} instead of @code{interrupt} for
+handlers intended to be used with the @code{BRK} opcode (i.e.@: those
+that must end with @code{RETB} instead of @code{RETI}).
 
-@smallexample
-namespace nspace1 __attribute__ ((visibility ("protected")))
-@{ /* @r{Do something.} */; @}
-@end smallexample
+@item naked
+@cindex @code{naked} function attribute, RL78
+This attribute allows the compiler to construct the
+requisite function declaration, while allowing the body of the
+function to be assembly code. The specified function will not have
+prologue/epilogue sequences generated by the compiler. Only basic
+@code{asm} statements can safely be included in naked functions
+(@pxref{Basic Asm}). While using extended @code{asm} or a mixture of
+basic @code{asm} and C code may appear to work, they cannot be
+depended upon to work reliably and are not supported.
+@end table
 
-This attribute applies only to the particular namespace body, not to
-other definitions of the same namespace; it is equivalent to using
-@samp{#pragma GCC visibility} before and after the namespace
-definition (@pxref{Visibility Pragmas}).
+@node RX Function Attributes
+@subsection RX Function Attributes
 
-In C++, if a template argument has limited visibility, this
-restriction is implicitly propagated to the template instantiation.
-Otherwise, template instantiations and specializations default to the
-visibility of their template.
+These function attributes are supported by the RX back end:
 
-If both the template and enclosing class have explicit visibility, the
-visibility from the template is used.
+@table @code
+@item fast_interrupt
+@cindex @code{fast_interrupt} function attribute, RX
+Use this attribute on the RX port to indicate that the specified
+function is a fast interrupt handler.  This is just like the
+@code{interrupt} attribute, except that @code{freit} is used to return
+instead of @code{reit}.
 
-@item vliw
-@cindex @code{vliw} function attribute, MeP
-On MeP, the @code{vliw} attribute tells the compiler to emit
-instructions in VLIW mode instead of core mode.  Note that this
-attribute is not allowed unless a VLIW coprocessor has been configured
-and enabled through command-line options.
+@item interrupt
+@cindex @code{interrupt} function attribute, RX
+Use this attribute to indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when this attribute is present.
 
-@item warn_unused_result
-@cindex @code{warn_unused_result} function attribute
-The @code{warn_unused_result} attribute causes a warning to be emitted
-if a caller of the function with this attribute does not use its
-return value.  This is useful for functions where not checking
-the result is either a security problem or always a bug, such as
-@code{realloc}.
+On RX targets, you may specify one or more vector numbers as arguments
+to the attribute, as well as naming an alternate table name.
+Parameters are handled sequentially, so one handler can be assigned to
+multiple entries in multiple tables.  One may also pass the magic
+string @code{"$default"} which causes the function to be used for any
+unfilled slots in the current table.
 
+This example shows a simple assignment of a function to one vector in
+the default table (note that preprocessor macros may be used for
+chip-specific symbolic vector names):
 @smallexample
-int fn () __attribute__ ((warn_unused_result));
-int foo ()
-@{
-  if (fn () < 0) return -1;
-  fn ();
-  return 0;
-@}
+void __attribute__ ((interrupt (5))) txd1_handler ();
 @end smallexample
 
-@noindent
-results in warning on line 5.
-
-@item weak
-@cindex @code{weak} function attribute
-The @code{weak} attribute causes the declaration to be emitted as a weak
-symbol rather than a global.  This is primarily useful in defining
-library functions that can be overridden in user code, though it can
-also be used with non-function declarations.  Weak symbols are supported
-for ELF targets, and also for a.out targets when using the GNU assembler
-and linker.
-
-@item weakref
-@itemx weakref ("@var{target}")
-@cindex @code{weakref} function attribute
-The @code{weakref} attribute marks a declaration as a weak reference.
-Without arguments, it should be accompanied by an @code{alias} attribute
-naming the target symbol.  Optionally, the @var{target} may be given as
-an argument to @code{weakref} itself.  In either case, @code{weakref}
-implicitly marks the declaration as @code{weak}.  Without a
-@var{target}, given as an argument to @code{weakref} or to @code{alias},
-@code{weakref} is equivalent to @code{weak}.
-
+This example assigns a function to two slots in the default table
+(using preprocessor macros defined elsewhere) and makes it the default
+for the @code{dct} table:
 @smallexample
-static int x() __attribute__ ((weakref ("y")));
-/* is equivalent to... */
-static int x() __attribute__ ((weak, weakref, alias ("y")));
-/* and to... */
-static int x() __attribute__ ((weakref));
-static int x() __attribute__ ((alias ("y")));
+void __attribute__ ((interrupt (RXD1_VECT,RXD2_VECT,"dct","$default")))
+	txd1_handler ();
 @end smallexample
 
-A weak reference is an alias that does not by itself require a
-definition to be given for the target symbol.  If the target symbol is
-only referenced through weak references, then it becomes a @code{weak}
-undefined symbol.  If it is directly referenced, however, then such
-strong references prevail, and a definition is required for the
-symbol, not necessarily in the same translation unit.
+@item naked
+@cindex @code{naked} function attribute, RX
+This attribute allows the compiler to construct the
+requisite function declaration, while allowing the body of the
+function to be assembly code. The specified function will not have
+prologue/epilogue sequences generated by the compiler. Only basic
+@code{asm} statements can safely be included in naked functions
+(@pxref{Basic Asm}). While using extended @code{asm} or a mixture of
+basic @code{asm} and C code may appear to work, they cannot be
+depended upon to work reliably and are not supported.
 
-The effect is equivalent to moving all references to the alias to a
-separate translation unit, renaming the alias to the aliased symbol,
-declaring it as weak, compiling the two separate translation units and
-performing a reloadable link on them.
+@item vector
+@cindex @code{vector} function attribute, RX
+This RX attribute is similar to the @code{interrupt} attribute, including its
+parameters, but does not make the function an interrupt-handler type
+function (i.e. it retains the normal C function calling ABI).  See the
+@code{interrupt} attribute for a description of its arguments.
+@end table
 
-At present, a declaration to which @code{weakref} is attached can
-only be @code{static}.
+@node S/390 Function Attributes
+@subsection S/390 Function Attributes
 
-@end table
+These function attributes are supported on the S/390:
 
-You can specify multiple attributes in a declaration by separating them
-by commas within the double parentheses or by immediately following an
-attribute declaration with another attribute declaration.
+@table @code
+@item hotpatch (@var{halfwords-before-function-label},@var{halfwords-after-function-label})
+@cindex @code{hotpatch} function attribute, S/390
 
-@cindex @code{#pragma}, reason for not using
-@cindex pragma, reason for not using
-Some people object to the @code{__attribute__} feature, suggesting that
-ISO C's @code{#pragma} should be used instead.  At the time
-@code{__attribute__} was designed, there were two reasons for not doing
-this.
+On S/390 System z targets, you can use this function attribute to
+make GCC generate a ``hot-patching'' function prologue.  If the
+@option{-mhotpatch=} command-line option is used at the same time,
+the @code{hotpatch} attribute takes precedence.  The first of the
+two arguments specifies the number of halfwords to be added before
+the function label.  A second argument can be used to specify the
+number of halfwords to be added after the function label.  For
+both arguments the maximum allowed value is 1000000.
 
-@enumerate
-@item
-It is impossible to generate @code{#pragma} commands from a macro.
+If both arguments are zero, hotpatching is disabled.
+@end table
 
-@item
-There is no telling what the same @code{#pragma} might mean in another
-compiler.
-@end enumerate
+@node SH Function Attributes
+@subsection SH Function Attributes
 
-These two reasons applied to almost any application that might have been
-proposed for @code{#pragma}.  It was basically a mistake to use
-@code{#pragma} for @emph{anything}.
+These function attributes are supported on the SH family of processors:
 
-The ISO C99 standard includes @code{_Pragma}, which now allows pragmas
-to be generated from macros.  In addition, a @code{#pragma GCC}
-namespace is now in use for GCC-specific pragmas.  However, it has been
-found convenient to use @code{__attribute__} to achieve a natural
-attachment of attributes to their corresponding declarations, whereas
-@code{#pragma GCC} is of use for constructs that do not naturally form
-part of the grammar.  @xref{Pragmas,,Pragmas Accepted by GCC}.
+@table @code
+@item function_vector
+@cindex @code{function_vector} function attribute, SH
+@cindex calling functions through the function vector on SH2A
+On SH2A targets, this attribute declares a function to be called using the
+TBR relative addressing mode.  The argument to this attribute is the entry
+number of the same function in a vector table containing all the TBR
+relative addressable functions.  For correct operation the TBR must be setup
+accordingly to point to the start of the vector table before any functions with
+this attribute are invoked.  Usually a good place to do the initialization is
+the startup routine.  The TBR relative vector table can have at max 256 function
+entries.  The jumps to these functions are generated using a SH2A specific,
+non delayed branch instruction JSR/N @@(disp8,TBR).  You must use GAS and GLD
+from GNU binutils version 2.7 or later for this attribute to work correctly.
 
-@node Label Attributes
-@section Label Attributes
-@cindex Label Attributes
+In an application, for a function being called once, this attribute
+saves at least 8 bytes of code; and if other successive calls are being
+made to the same function, it saves 2 bytes of code per each of these
+calls.
 
-GCC allows attributes to be set on C labels.  @xref{Attribute Syntax}, for 
-details of the exact syntax for using attributes.  Other attributes are 
-available for functions (@pxref{Function Attributes}), variables 
-(@pxref{Variable Attributes}) and for types (@pxref{Type Attributes}).
+@item interrupt_handler
+@cindex @code{interrupt_handler} function attribute, SH
+Use this attribute to
+indicate that the specified function is an interrupt handler.  The compiler
+generates function entry and exit sequences suitable for use in an
+interrupt handler when this attribute is present.
 
-This example uses the @code{cold} label attribute to indicate the 
-@code{ErrorHandling} branch is unlikely to be taken and that the
-@code{ErrorHandling} label is unused:
+@item nosave_low_regs
+@cindex @code{nosave_low_regs} function attribute, SH
+Use this attribute on SH targets to indicate that an @code{interrupt_handler}
+function should not save and restore registers R0..R7.  This can be used on SH3*
+and SH4* targets that have a second R0..R7 register bank for non-reentrant
+interrupt handlers.
 
-@smallexample
+@item renesas
+@cindex @code{renesas} function attribute, SH
+On SH targets this attribute specifies that the function or struct follows the
+Renesas ABI.
 
-   asm goto ("some asm" : : : : NoError);
+@item resbank
+@cindex @code{resbank} function attribute, SH
+On the SH2A target, this attribute enables the high-speed register
+saving and restoration using a register bank for @code{interrupt_handler}
+routines.  Saving to the bank is performed automatically after the CPU
+accepts an interrupt that uses a register bank.
 
-/* This branch (the fall-through from the asm) is less commonly used */
-ErrorHandling: 
-   __attribute__((cold, unused)); /* Semi-colon is required here */
-   printf("error\n");
-   return 0;
+The nineteen 32-bit registers comprising general register R0 to R14,
+control register GBR, and system registers MACH, MACL, and PR and the
+vector table address offset are saved into a register bank.  Register
+banks are stacked in first-in last-out (FILO) sequence.  Restoration
+from the bank is executed by issuing a RESBANK instruction.
 
-NoError:
-   printf("no error\n");
-   return 1;
+@item sp_switch
+@cindex @code{sp_switch} function attribute, SH
+Use this attribute on the SH to indicate an @code{interrupt_handler}
+function should switch to an alternate stack.  It expects a string
+argument that names a global variable holding the address of the
+alternate stack.
+
+@smallexample
+void *alt_stack;
+void f () __attribute__ ((interrupt_handler,
+                          sp_switch ("alt_stack")));
 @end smallexample
 
-@table @code
-@item unused
-@cindex @code{unused} label attribute
-This feature is intended for program-generated code that may contain 
-unused labels, but which is compiled with @option{-Wall}.  It is
-not normally 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.
+@item trap_exit
+@cindex @code{trap_exit} function attribute, SH
+Use this attribute on the SH for an @code{interrupt_handler} to return using
+@code{trapa} instead of @code{rte}.  This attribute expects an integer
+argument specifying the trap number to be used.
 
-@item hot
-@cindex @code{hot} label attribute
-The @code{hot} attribute on a label is used to inform the compiler that
-the path following the label is more likely than paths that are not so
-annotated.  This attribute is used in cases where @code{__builtin_expect}
-cannot be used, for instance with computed goto or @code{asm goto}.
+@item trapa_handler
+@cindex @code{trapa_handler} function attribute, SH
+On SH targets this function attribute is similar to @code{interrupt_handler}
+but it does not save and restore all registers.
+@end table
 
-@item cold
-@cindex @code{cold} label attribute
-The @code{cold} attribute on labels is used to inform the compiler that
-the path following the label is unlikely to be executed.  This attribute
-is used in cases where @code{__builtin_expect} cannot be used, for instance
-with computed goto or @code{asm goto}.
+@node SPU Function Attributes
+@subsection SPU Function Attributes
+
+These function attributes are supported by the SPU back end:
 
+@table @code
+@item naked
+@cindex @code{naked} function attribute, SPU
+This attribute allows the compiler to construct the
+requisite function declaration, while allowing the body of the
+function to be assembly code. The specified function will not have
+prologue/epilogue sequences generated by the compiler. Only basic
+@code{asm} statements can safely be included in naked functions
+(@pxref{Basic Asm}). While using extended @code{asm} or a mixture of
+basic @code{asm} and C code may appear to work, they cannot be
+depended upon to work reliably and are not supported.
 @end table
 
-@node Attribute Syntax
-@section Attribute Syntax
-@cindex attribute syntax
+@node Symbian OS Function Attributes
+@subsection Symbian OS Function Attributes
 
-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.
+@xref{Microsoft Windows Function Attributes}, for discussion of the
+@code{dllexport} and @code{dllimport} attributes.
 
-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.
+@node Visium Function Attributes
+@subsection Visium Function Attributes
 
-@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.
-@xref{Label Attributes}, for details of the semantics of attributes 
-applying to labels.
+These function attributes are supported by the Visium back end:
 
-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:
+@table @code
+@item interrupt
+@cindex @code{interrupt} function attribute, Visium
+Use this attribute to indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when this attribute is present.
+@end table
 
-@itemize @bullet
-@item
-Empty.  Empty attributes are ignored.
+@node x86 Function Attributes
+@subsection x86 Function Attributes
 
-@item
-A word (which may be an identifier such as @code{unused}, or a reserved
-word such as @code{const}).
+These function attributes are supported by the x86 back end:
 
-@item
-A word, followed by, in parentheses, parameters for the attribute.
-These parameters take one of the following forms:
+@table @code
+@item cdecl
+@cindex @code{cdecl} function attribute, x86-32
+@cindex functions that pop the argument stack on x86-32
+@opindex mrtd
+On the x86-32 targets, the @code{cdecl} attribute causes the compiler to
+assume that the calling function pops off the stack space used to
+pass arguments.  This is
+useful to override the effects of the @option{-mrtd} switch.
 
-@itemize @bullet
-@item
-An identifier.  For example, @code{mode} attributes use this form.
+@item fastcall
+@cindex @code{fastcall} function attribute, x86-32
+@cindex functions that pop the argument stack on x86-32
+On x86-32 targets, the @code{fastcall} attribute causes the compiler to
+pass the first argument (if of integral type) in the register ECX and
+the second argument (if of integral type) in the register EDX@.  Subsequent
+and other typed arguments are passed on the stack.  The called function
+pops the arguments off the stack.  If the number of arguments is variable all
+arguments are pushed on the stack.
 
-@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 thiscall
+@cindex @code{thiscall} function attribute, x86-32
+@cindex functions that pop the argument stack on x86-32
+On x86-32 targets, the @code{thiscall} attribute causes the compiler to
+pass the first argument (if of integral type) in the register ECX.
+Subsequent and other typed arguments are passed on the stack. The called
+function pops the arguments off the stack.
+If the number of arguments is variable all arguments are pushed on the
+stack.
+The @code{thiscall} attribute is intended for C++ non-static member functions.
+As a GCC extension, this calling convention can be used for C functions
+and for static member methods.
 
-@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
+@item ms_abi
+@itemx sysv_abi
+@cindex @code{ms_abi} function attribute, x86
+@cindex @code{sysv_abi} function attribute, x86
 
-An @dfn{attribute specifier list} is a sequence of one or more attribute
-specifiers, not separated by any other tokens.
+On 32-bit and 64-bit x86 targets, you can use an ABI attribute
+to indicate which calling convention should be used for a function.  The
+@code{ms_abi} attribute tells the compiler to use the Microsoft ABI,
+while the @code{sysv_abi} attribute tells the compiler to use the ABI
+used on GNU/Linux and other systems.  The default is to use the Microsoft ABI
+when targeting Windows.  On all other systems, the default is the x86/AMD ABI.
 
-@subsubheading Label Attributes
+Note, the @code{ms_abi} attribute for Microsoft Windows 64-bit targets currently
+requires the @option{-maccumulate-outgoing-args} option.
 
-In GNU C, an attribute specifier list may appear after the colon following a
-label, other than a @code{case} or @code{default} label.  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.
+@item callee_pop_aggregate_return (@var{number})
+@cindex @code{callee_pop_aggregate_return} function attribute, x86
 
-@subsubheading Type Attributes
+On x86-32 targets, you can use this attribute to control how
+aggregates are returned in memory.  If the caller is responsible for
+popping the hidden pointer together with the rest of the arguments, specify
+@var{number} equal to zero.  If callee is responsible for popping the
+hidden pointer, specify @var{number} equal to one.  
 
-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.
+The default x86-32 ABI assumes that the callee pops the
+stack for hidden pointer.  However, on x86-32 Microsoft Windows targets,
+the compiler assumes that the
+caller pops the stack for hidden pointer.
 
+@item ms_hook_prologue
+@cindex @code{ms_hook_prologue} function attribute, x86
 
-@subsubheading All other attributes
+On 32-bit and 64-bit x86 targets, you can use
+this function attribute to make GCC generate the ``hot-patching'' function
+prologue used in Win32 API functions in Microsoft Windows XP Service Pack 2
+and newer.
 
-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.
+@item regparm (@var{number})
+@cindex @code{regparm} function attribute, x86
+@cindex functions that are passed arguments in registers on x86-32
+On x86-32 targets, the @code{regparm} attribute causes the compiler to
+pass arguments number one to @var{number} if they are of integral type
+in registers EAX, EDX, and ECX instead of on the stack.  Functions that
+take a variable number of arguments continue to be passed all of their
+arguments on the stack.
 
-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.
+Beware that on some ELF systems this attribute is unsuitable for
+global functions in shared libraries with lazy binding (which is the
+default).  Lazy binding sends the first call via resolving code in
+the loader, which might assume EAX, EDX and ECX can be clobbered, as
+per the standard calling conventions.  Solaris 8 is affected by this.
+Systems with the GNU C Library version 2.1 or higher
+and FreeBSD are believed to be
+safe since the loaders there save EAX, EDX and ECX.  (Lazy binding can be
+disabled with the linker or the loader if desired, to avoid the
+problem.)
 
-At present, the first parameter in a function prototype must have some
-type specifier that 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.
+@item sseregparm
+@cindex @code{sseregparm} function attribute, x86
+On x86-32 targets with SSE support, the @code{sseregparm} attribute
+causes the compiler to pass up to 3 floating-point arguments in
+SSE registers instead of on the stack.  Functions that take a
+variable number of arguments continue to pass all of their
+floating-point arguments on the stack.
 
-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
+@item force_align_arg_pointer
+@cindex @code{force_align_arg_pointer} function attribute, x86
+On x86 targets, the @code{force_align_arg_pointer} attribute may be
+applied to individual function definitions, generating an alternate
+prologue and epilogue that realigns the run-time stack if necessary.
+This supports mixing legacy codes that run with a 4-byte aligned stack
+with modern codes that keep a 16-byte stack for SSE compatibility.
 
-@smallexample
-__attribute__((noreturn)) void d0 (void),
-    __attribute__((format(printf, 1, 2))) d1 (const char *, ...),
-     d2 (void);
-@end smallexample
+@item stdcall
+@cindex @code{stdcall} function attribute, x86-32
+@cindex functions that pop the argument stack on x86-32
+On x86-32 targets, the @code{stdcall} attribute causes the compiler to
+assume that the called function pops off the stack space used to
+pass arguments, unless it takes a variable number of arguments.
 
-@noindent
-the @code{noreturn} attribute applies to all the functions
-declared; the @code{format} attribute only applies to @code{d1}.
+@item target (@var{options})
+@cindex @code{target} function attribute
+As discussed in @ref{Common Function Attributes}, this attribute 
+allows specification of target-specific compilation options.
 
-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.
+On the x86, the following options are allowed:
+@table @samp
+@item abm
+@itemx no-abm
+@cindex @code{target("abm")} function attribute, x86
+Enable/disable the generation of the advanced bit instructions.
 
-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).
+@item aes
+@itemx no-aes
+@cindex @code{target("aes")} function attribute, x86
+Enable/disable the generation of the AES instructions.
 
-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.
+@item default
+@cindex @code{target("default")} function attribute, x86
+@xref{Function Multiversioning}, where it is used to specify the
+default function version.
 
-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 makes the
-most sense if you are familiar with the formal specification of
-declarators in the ISO C standard.
+@item mmx
+@itemx no-mmx
+@cindex @code{target("mmx")} function attribute, x86
+Enable/disable the generation of the MMX instructions.
 
-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.
+@item pclmul
+@itemx no-pclmul
+@cindex @code{target("pclmul")} function attribute, x86
+Enable/disable the generation of the PCLMUL instructions.
+
+@item popcnt
+@itemx no-popcnt
+@cindex @code{target("popcnt")} function attribute, x86
+Enable/disable the generation of the POPCNT instruction.
+
+@item sse
+@itemx no-sse
+@cindex @code{target("sse")} function attribute, x86
+Enable/disable the generation of the SSE instructions.
+
+@item sse2
+@itemx no-sse2
+@cindex @code{target("sse2")} function attribute, x86
+Enable/disable the generation of the SSE2 instructions.
 
-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}.
+@item sse3
+@itemx no-sse3
+@cindex @code{target("sse3")} function attribute, x86
+Enable/disable the generation of the SSE3 instructions.
 
-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}.
+@item sse4
+@itemx no-sse4
+@cindex @code{target("sse4")} function attribute, x86
+Enable/disable the generation of the SSE4 instructions (both SSE4.1
+and SSE4.2).
 
-For example,
+@item sse4.1
+@itemx no-sse4.1
+@cindex @code{target("sse4.1")} function attribute, x86
+Enable/disable the generation of the sse4.1 instructions.
 
-@smallexample
-void (__attribute__((noreturn)) ****f) (void);
-@end smallexample
+@item sse4.2
+@itemx no-sse4.2
+@cindex @code{target("sse4.2")} function attribute, x86
+Enable/disable the generation of the sse4.2 instructions.
 
-@noindent
-specifies the type ``pointer to pointer to pointer to pointer to
-non-returning function returning @code{void}''.  As another example,
+@item sse4a
+@itemx no-sse4a
+@cindex @code{target("sse4a")} function attribute, x86
+Enable/disable the generation of the SSE4A instructions.
 
-@smallexample
-char *__attribute__((aligned(8))) *f;
-@end smallexample
+@item fma4
+@itemx no-fma4
+@cindex @code{target("fma4")} function attribute, x86
+Enable/disable the generation of the FMA4 instructions.
 
-@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.
+@item xop
+@itemx no-xop
+@cindex @code{target("xop")} function attribute, x86
+Enable/disable the generation of the XOP instructions.
 
-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 is 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 is 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 is treated as
-applying to the function type, and such an attribute applied to an array
-element type is 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 is 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 is treated as applying
-to the function type.
+@item lwp
+@itemx no-lwp
+@cindex @code{target("lwp")} function attribute, x86
+Enable/disable the generation of the LWP instructions.
 
-@node Function Prototypes
-@section Prototypes and Old-Style Function Definitions
-@cindex function prototype declarations
-@cindex old-style function definitions
-@cindex promotion of formal parameters
+@item ssse3
+@itemx no-ssse3
+@cindex @code{target("ssse3")} function attribute, x86
+Enable/disable the generation of the SSSE3 instructions.
 
-GNU C extends ISO C to allow a function prototype to override a later
-old-style non-prototype definition.  Consider the following example:
+@item cld
+@itemx no-cld
+@cindex @code{target("cld")} function attribute, x86
+Enable/disable the generation of the CLD before string moves.
 
-@smallexample
-/* @r{Use prototypes unless the compiler is old-fashioned.}  */
-#ifdef __STDC__
-#define P(x) x
-#else
-#define P(x) ()
-#endif
+@item fancy-math-387
+@itemx no-fancy-math-387
+@cindex @code{target("fancy-math-387")} function attribute, x86
+Enable/disable the generation of the @code{sin}, @code{cos}, and
+@code{sqrt} instructions on the 387 floating-point unit.
 
-/* @r{Prototype function declaration.}  */
-int isroot P((uid_t));
+@item fused-madd
+@itemx no-fused-madd
+@cindex @code{target("fused-madd")} function attribute, x86
+Enable/disable the generation of the fused multiply/add instructions.
 
-/* @r{Old-style function definition.}  */
-int
-isroot (x)   /* @r{??? lossage here ???} */
-     uid_t x;
-@{
-  return x == 0;
-@}
-@end smallexample
+@item ieee-fp
+@itemx no-ieee-fp
+@cindex @code{target("ieee-fp")} function attribute, x86
+Enable/disable the generation of floating point that depends on IEEE arithmetic.
 
-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}.
+@item inline-all-stringops
+@itemx no-inline-all-stringops
+@cindex @code{target("inline-all-stringops")} function attribute, x86
+Enable/disable inlining of string operations.
 
-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:
+@item inline-stringops-dynamically
+@itemx no-inline-stringops-dynamically
+@cindex @code{target("inline-stringops-dynamically")} function attribute, x86
+Enable/disable the generation of the inline code to do small string
+operations and calling the library routines for large operations.
 
-@smallexample
-int isroot (uid_t);
+@item align-stringops
+@itemx no-align-stringops
+@cindex @code{target("align-stringops")} function attribute, x86
+Do/do not align destination of inlined string operations.
 
-int
-isroot (uid_t x)
-@{
-  return x == 0;
-@}
-@end smallexample
+@item recip
+@itemx no-recip
+@cindex @code{target("recip")} function attribute, x86
+Enable/disable the generation of RCPSS, RCPPS, RSQRTSS and RSQRTPS
+instructions followed an additional Newton-Raphson step instead of
+doing a floating-point division.
 
-@noindent
-GNU C++ does not support old-style function definitions, so this
-extension is irrelevant.
+@item arch=@var{ARCH}
+@cindex @code{target("arch=@var{ARCH}")} function attribute, x86
+Specify the architecture to generate code for in compiling the function.
 
-@node C++ Comments
-@section C++ Style Comments
-@cindex @code{//}
-@cindex C++ comments
-@cindex comments, C++ style
+@item tune=@var{TUNE}
+@cindex @code{target("tune=@var{TUNE}")} function attribute, x86
+Specify the architecture to tune for in compiling the function.
 
-In GNU C, you may use C++ style comments, which start with @samp{//} and
-continue until the end of the line.  Many other C implementations allow
-such comments, and they are included in the 1999 C standard.  However,
-C++ style comments are not recognized if you specify an @option{-std}
-option specifying a version of ISO C before C99, or @option{-ansi}
-(equivalent to @option{-std=c90}).
+@item fpmath=@var{FPMATH}
+@cindex @code{target("fpmath=@var{FPMATH}")} function attribute, x86
+Specify which floating-point unit to use.  You must specify the
+@code{target("fpmath=sse,387")} option as
+@code{target("fpmath=sse+387")} because the comma would separate
+different options.
+@end table
 
-@node Dollar Signs
-@section Dollar Signs in Identifier Names
-@cindex $
-@cindex dollar signs in identifier names
-@cindex identifier names, dollar signs in
+On the x86, the inliner does not inline a
+function that has different target options than the caller, unless the
+callee has a subset of the target options of the caller.  For example
+a function declared with @code{target("sse3")} can inline a function
+with @code{target("sse2")}, since @code{-msse3} implies @code{-msse2}.
+@end table
 
-In GNU C, you may normally use dollar signs in identifier names.
-This is because many traditional C implementations allow such identifiers.
-However, dollar signs in identifiers are not supported on a few target
-machines, typically because the target assembler does not allow them.
+@node Xstormy16 Function Attributes
+@subsection Xstormy16 Function Attributes
 
-@node Character Escapes
-@section The Character @key{ESC} in Constants
+These function attributes are supported by the Xstormy16 back end:
 
-You can use the sequence @samp{\e} in a string or character constant to
-stand for the ASCII character @key{ESC}.
+@table @code
+@item interrupt
+@cindex @code{interrupt} function attribute, Xstormy16
+Use this attribute to indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when this attribute is present.
+@end table
 
 @node Variable Attributes
 @section Specifying Attributes of Variables
@@ -4970,14 +5205,29 @@ 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.
 
+@menu
+* Common Variable Attributes::
+* AVR Variable Attributes::
+* Blackfin Variable Attributes::
+* H8/300 Variable Attributes::
+* IA-64 Variable Attributes::
+* M32R/D Variable Attributes::
+* MeP Variable Attributes::
+* Microsoft Windows Variable Attributes::
+* PowerPC Variable Attributes::
+* SPU Variable Attributes::
+* x86 Variable Attributes::
+* Xstormy16 Variable Attributes::
+@end menu
+
+@node Common Variable Attributes
+@subsection Common Variable Attributes
+
+The following attributes are supported on most targets.
+
 @table @code
 @cindex @code{aligned} variable attribute
 @item aligned (@var{alignment})
@@ -5046,7 +5296,7 @@ in an @code{__attribute__} still only provides 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}.)
+(@pxref{Common Function Attributes}.)
 
 @item cleanup (@var{cleanup_function})
 @cindex @code{cleanup} variable attribute
@@ -5100,7 +5350,8 @@ argument, which must be a string, is printed in the warning if
 present.
 
 The @code{deprecated} attribute can also be used for functions and
-types (@pxref{Function Attributes}, @pxref{Type Attributes}.)
+types (@pxref{Common Function Attributes},
+@pxref{Common Type Attributes}).
 
 @item mode (@var{mode})
 @cindex @code{mode} variable attribute
@@ -5171,47 +5422,20 @@ 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
-changes 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.
+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
+changes 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.
 
-The @code{shared} attribute is only available on Microsoft Windows@.
+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 tls_model ("@var{tls_model}")
 @cindex @code{tls_model} variable attribute
@@ -5258,17 +5482,280 @@ 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:
+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 weak
+@cindex @code{weak} variable attribute
+The @code{weak} attribute is described in
+@ref{Common Function Attributes}.
+
+@end table
+
+@node AVR Variable Attributes
+@subsection AVR Variable Attributes
+
+@table @code
+@item progmem
+@cindex @code{progmem} variable attribute, AVR
+The @code{progmem} attribute is used on the AVR to place read-only
+data in the non-volatile program memory (flash). The @code{progmem}
+attribute accomplishes this by putting respective variables into a
+section whose name starts with @code{.progmem}.
+
+This attribute works similar to the @code{section} attribute
+but adds additional checking. Notice that just like the
+@code{section} attribute, @code{progmem} affects the location
+of the data but not how this data is accessed.
+
+In order to read data located with the @code{progmem} attribute
+(inline) assembler must be used.
+@smallexample
+/* Use custom macros from @w{@uref{http://nongnu.org/avr-libc/user-manual/,AVR-LibC}} */
+#include <avr/pgmspace.h> 
+
+/* Locate var in flash memory */
+const int var[2] PROGMEM = @{ 1, 2 @};
+
+int read_var (int i)
+@{
+    /* Access var[] by accessor macro from avr/pgmspace.h */
+    return (int) pgm_read_word (& var[i]);
+@}
+@end smallexample
+
+AVR is a Harvard architecture processor and data and read-only data
+normally resides in the data memory (RAM).
+
+See also the @ref{AVR Named Address Spaces} section for
+an alternate way to locate and access data in flash memory.
+
+@item io
+@itemx io (@var{addr})
+@cindex @code{io} variable attribute, AVR
+Variables with the @code{io} attribute are used to address
+memory-mapped peripherals in the io address range.
+If an address is specified, the variable
+is assigned that address, and the value is interpreted as an
+address in the data address space.
+Example:
+
+@smallexample
+volatile int porta __attribute__((io (0x22)));
+@end smallexample
+
+The address specified in the address in the data address range.
+
+Otherwise, the variable it is not assigned an address, but the
+compiler will still use in/out instructions where applicable,
+assuming some other module assigns an address in the io address range.
+Example:
+
+@smallexample
+extern volatile int porta __attribute__((io));
+@end smallexample
+
+@item io_low
+@itemx io_low (@var{addr})
+@cindex @code{io_low} variable attribute, AVR
+This is like the @code{io} attribute, but additionally it informs the
+compiler that the object lies in the lower half of the I/O area,
+allowing the use of @code{cbi}, @code{sbi}, @code{sbic} and @code{sbis}
+instructions.
+
+@item address
+@itemx address (@var{addr})
+@cindex @code{address} variable attribute, AVR
+Variables with the @code{address} attribute are used to address
+memory-mapped peripherals that may lie outside the io address range.
+
+@smallexample
+volatile int porta __attribute__((address (0x600)));
+@end smallexample
+
+@end table
+
+@node Blackfin Variable Attributes
+@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, Blackfin
+@cindex @code{l1_data_A} variable attribute, Blackfin
+@cindex @code{l1_data_B} variable attribute, Blackfin
+Use these attributes on the Blackfin to place the variable into L1 Data SRAM.
+Variables with @code{l1_data} attribute are put into the specific section
+named @code{.l1.data}. Those with @code{l1_data_A} attribute are put into
+the specific section named @code{.l1.data.A}. Those with @code{l1_data_B}
+attribute are put into the specific section named @code{.l1.data.B}.
+
+@item l2
+@cindex @code{l2} variable attribute, Blackfin
+Use this attribute on the Blackfin to place the variable into L2 SRAM.
+Variables with @code{l2} attribute are put into the specific section
+named @code{.l2.data}.
+@end table
+
+@node H8/300 Variable Attributes
+@subsection H8/300 Variable Attributes
+
+These variable attributes are available for H8/300 targets:
+
+@table @code
+@item eightbit_data
+@cindex @code{eightbit_data} variable attribute, H8/300
+@cindex eight-bit data on the H8/300, H8/300H, and H8S
+Use this attribute on the H8/300, H8/300H, and H8S to indicate that the specified
+variable should be placed into the eight-bit data section.
+The compiler generates more efficient code for certain operations
+on data in the eight-bit data area.  Note the eight-bit data area is limited to
+256 bytes of data.
+
+You must use GAS and GLD from GNU binutils version 2.7 or later for
+this attribute to work correctly.
+
+@item tiny_data
+@cindex @code{tiny_data} variable attribute, H8/300
+@cindex tiny data section on the H8/300H and H8S
+Use this attribute on the H8/300H and H8S to indicate that the specified
+variable should be placed into the tiny data section.
+The compiler generates more efficient code for loads and stores
+on data in the tiny data section.  Note the tiny data area is limited to
+slightly under 32KB of data.
+
+@end table
+
+@node IA-64 Variable Attributes
+@subsection IA-64 Variable Attributes
+
+The IA-64 back end supports the following variable attribute:
+
+@table @code
+@item model (@var{model-name})
+@cindex @code{model} variable attribute, IA-64
+
+On IA-64, use this attribute to set the addressability of an object.
+At present, the only supported identifier for @var{model-name} is
+@code{small}, indicating addressability via ``small'' (22-bit)
+addresses (so that their addresses can be loaded with the @code{addl}
+instruction).  Caveat: such addressing is by definition not position
+independent and hence this attribute must not be used for objects
+defined by shared libraries.
+
+@end table
+
+@node M32R/D Variable Attributes
+@subsection M32R/D Variable Attributes
+
+One attribute is currently defined for the M32R/D@.
+
+@table @code
+@item model (@var{model-name})
+@cindex @code{model-name} variable attribute, M32R/D
+@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 generates @code{seth/add3} instructions to load their
+addresses).
+@end table
+
+@node 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 that
+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
+@cindex @code{based} variable attribute, MeP
+Any variable with the @code{based} attribute is assigned to the
+@code{.based} section, and is accessed with relative to the
+@code{$tp} register.
+
+@item tiny
+@cindex @code{tiny} variable attribute, MeP
+Likewise, the @code{tiny} attribute assigned variables to the
+@code{.tiny} section, relative to the @code{$gp} register.
+
+@item near
+@cindex @code{near} variable attribute, MeP
+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
+@cindex @code{far} variable attribute, MeP
+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
+@cindex @code{io} variable attribute, MeP
+@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 assigns an address).  Example:
+
+@smallexample
+int timer_count __attribute__((io(0x123)));
+@end smallexample
+
+@item cb
+@itemx cb (@var{addr})
+@cindex @code{cb} variable attribute, MeP
+Variables with the @code{cb} attribute are used to access the control
+bus, using special instructions.  @code{addr} indicates the control bus
+address.  Example:
 
 @smallexample
-struct S @{ int a; @};
-struct S  __attribute__ ((vector_size (16))) foo;
+int cpu_clock __attribute__((cb(0x123)));
 @end smallexample
 
-@noindent
-is invalid even if the size of the structure is the same as the size of
-the @code{int}.
+@end table
+
+@node Microsoft Windows Variable Attributes
+@subsection Microsoft Windows Variable Attributes
+
+You can use these attributes on Microsoft Windows targets.
+@ref{x86 Variable Attributes} for additional Windows compatibility
+attributes available on all x86 targets.
+
+@table @code
+@item dllimport
+@itemx dllexport
+@cindex @code{dllimport} variable attribute
+@cindex @code{dllexport} variable attribute
+The @code{dllimport} and @code{dllexport} attributes are described in
+@ref{Microsoft Windows Function Attributes}.
 
 @item selectany
 @cindex @code{selectany} variable attribute
@@ -5291,891 +5778,1062 @@ targets.  You can use @code{__declspec (selectany)} as a synonym for
 @code{__attribute__ ((selectany))} for compatibility with other
 compilers.
 
-@item weak
-@cindex @code{weak} variable attribute
-The @code{weak} attribute is described in @ref{Function Attributes}.
+@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:
 
-@item dllimport
-@cindex @code{dllimport} variable attribute
-The @code{dllimport} attribute is described in @ref{Function Attributes}.
+@smallexample
+int foo __attribute__((section ("shared"), shared)) = 0;
 
-@item dllexport
-@cindex @code{dllexport} variable attribute
-The @code{dllexport} attribute is described in @ref{Function Attributes}.
+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@.
 
 @end table
 
-@anchor{AVR Variable Attributes}
-@subsection AVR Variable Attributes
+@node PowerPC Variable Attributes
+@subsection PowerPC Variable Attributes
+
+Three attributes currently are defined for PowerPC configurations:
+@code{altivec}, @code{ms_struct} and @code{gcc_struct}.
+
+@cindex @code{ms_struct} variable attribute, PowerPC
+@cindex @code{gcc_struct} variable attribute, PowerPC
+For full documentation of the struct attributes please see the
+documentation in @ref{x86 Variable Attributes}.
+
+@cindex @code{altivec} variable attribute, PowerPC
+For documentation of @code{altivec} attribute please see the
+documentation in @ref{PowerPC Type Attributes}.
+
+@node SPU Variable Attributes
+@subsection SPU Variable Attributes
+
+@cindex @code{spu_vector} variable attribute, SPU
+The SPU supports the @code{spu_vector} attribute for variables.  For
+documentation of this attribute please see the documentation in
+@ref{SPU Type Attributes}.
+
+@node x86 Variable Attributes
+@subsection x86 Variable Attributes
+
+Two attributes are currently defined for x86 configurations:
+@code{ms_struct} and @code{gcc_struct}.
 
 @table @code
-@item progmem
-@cindex @code{progmem} variable attribute, AVR
-The @code{progmem} attribute is used on the AVR to place read-only
-data in the non-volatile program memory (flash). The @code{progmem}
-attribute accomplishes this by putting respective variables into a
-section whose name starts with @code{.progmem}.
+@item ms_struct
+@itemx gcc_struct
+@cindex @code{ms_struct} variable attribute, x86
+@cindex @code{gcc_struct} variable attribute, x86
 
-This attribute works similar to the @code{section} attribute
-but adds additional checking. Notice that just like the
-@code{section} attribute, @code{progmem} affects the location
-of the data but not how this data is accessed.
+If @code{packed} is used on a structure, or if bit-fields are used,
+it may be that the Microsoft ABI lays out the structure differently
+than the way GCC normally does.  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.
 
-In order to read data located with the @code{progmem} attribute
-(inline) assembler must be used.
-@smallexample
-/* Use custom macros from @w{@uref{http://nongnu.org/avr-libc/user-manual/,AVR-LibC}} */
-#include <avr/pgmspace.h> 
+Currently @option{-m[no-]ms-bitfields} is provided for the Microsoft Windows x86
+compilers to match the native Microsoft compiler.
 
-/* Locate var in flash memory */
-const int var[2] PROGMEM = @{ 1, 2 @};
+The Microsoft structure layout algorithm is fairly simple with the exception
+of the bit-field packing.  
+The padding and alignment of members of structures and whether a bit-field 
+can straddle a storage-unit boundary are determine by these rules:
 
-int read_var (int i)
-@{
-    /* Access var[] by accessor macro from avr/pgmspace.h */
-    return (int) pgm_read_word (& var[i]);
-@}
+@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
+@code{aligned} attribute or the @code{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:
+
+@smallexample
+offset % alignment_requirement == 0
 @end smallexample
 
-AVR is a Harvard architecture processor and data and read-only data
-normally resides in the data memory (RAM).
+@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
 
-See also the @ref{AVR Named Address Spaces} section for
-an alternate way to locate and access data in flash memory.
+MSVC interprets zero-length bit-fields in the following ways:
 
-@item io
-@itemx io (@var{addr})
-@cindex @code{io} variable attribute, AVR
-Variables with the @code{io} attribute are used to address
-memory-mapped peripherals in the io address range.
-If an address is specified, the variable
-is assigned that address, and the value is interpreted as an
-address in the data address space.
-Example:
+@enumerate
+@item If a zero-length bit-field is inserted between two bit-fields that
+are normally coalesced, the bit-fields are not coalesced.
+
+For example:
 
 @smallexample
-volatile int porta __attribute__((io (0x22)));
+struct
+ @{
+   unsigned long bf_1 : 12;
+   unsigned long : 0;
+   unsigned long bf_2 : 12;
+ @} t1;
 @end smallexample
 
-The address specified in the address in the data address range.
+@noindent
+The size of @code{t1} is 8 bytes with the zero-length bit-field.  If the
+zero-length bit-field were removed, @code{t1}'s size would be 4 bytes.
 
-Otherwise, the variable it is not assigned an address, but the
-compiler will still use in/out instructions where applicable,
-assuming some other module assigns an address in the io address range.
-Example:
+@item If a zero-length bit-field is inserted after a bit-field, @code{foo}, and the
+alignment of the zero-length bit-field is greater than the member that follows it,
+@code{bar}, @code{bar} is aligned as the type of the zero-length bit-field.
+
+For example:
 
 @smallexample
-extern volatile int porta __attribute__((io));
+struct
+ @{
+   char foo : 4;
+   short : 0;
+   char bar;
+ @} t2;
+
+struct
+ @{
+   char foo : 4;
+   short : 0;
+   double bar;
+ @} t3;
 @end smallexample
 
-@item io_low
-@itemx io_low (@var{addr})
-@cindex @code{io_low} variable attribute, AVR
-This is like the @code{io} attribute, but additionally it informs the
-compiler that the object lies in the lower half of the I/O area,
-allowing the use of @code{cbi}, @code{sbi}, @code{sbic} and @code{sbis}
-instructions.
+@noindent
+For @code{t2}, @code{bar} is placed at offset 2, rather than offset 1.
+Accordingly, the size of @code{t2} is 4.  For @code{t3}, the zero-length
+bit-field does not affect the alignment of @code{bar} or, as a result, the size
+of the structure.
 
-@item address
-@itemx address (@var{addr})
-@cindex @code{address} variable attribute, AVR
-Variables with the @code{address} attribute are used to address
-memory-mapped peripherals that may lie outside the io address range.
+Taking this into account, it is important to note the following:
+
+@enumerate
+@item If a zero-length bit-field follows a normal bit-field, the type of the
+zero-length bit-field may affect the alignment of the structure as whole. For
+example, @code{t2} has a size of 4 bytes, since the zero-length bit-field follows a
+normal bit-field, and is of type short.
+
+@item Even if a zero-length bit-field is not followed by a normal bit-field, it may
+still affect the alignment of the structure:
 
 @smallexample
-volatile int porta __attribute__((address (0x600)));
+struct
+ @{
+   char foo : 6;
+   long : 0;
+ @} t4;
 @end smallexample
 
-@end table
-
-@subsection Blackfin Variable Attributes
+@noindent
+Here, @code{t4} takes up 4 bytes.
+@end enumerate
 
-Three attributes are currently defined for the Blackfin.
+@item Zero-length bit-fields following non-bit-field members are ignored:
 
-@table @code
-@item l1_data
-@itemx l1_data_A
-@itemx l1_data_B
-@cindex @code{l1_data} variable attribute, Blackfin
-@cindex @code{l1_data_A} variable attribute, Blackfin
-@cindex @code{l1_data_B} variable attribute, Blackfin
-Use these attributes on the Blackfin to place the variable into L1 Data SRAM.
-Variables with @code{l1_data} attribute are put into the specific section
-named @code{.l1.data}. Those with @code{l1_data_A} attribute are put into
-the specific section named @code{.l1.data.A}. Those with @code{l1_data_B}
-attribute are put into the specific section named @code{.l1.data.B}.
+@smallexample
+struct
+ @{
+   char foo;
+   long : 0;
+   char bar;
+ @} t5;
+@end smallexample
 
-@item l2
-@cindex @code{l2} variable attribute, Blackfin
-Use this attribute on the Blackfin to place the variable into L2 SRAM.
-Variables with @code{l2} attribute are put into the specific section
-named @code{.l2.data}.
+@noindent
+Here, @code{t5} takes up 2 bytes.
+@end enumerate
 @end table
 
-@subsection H8/300 Variable Attributes
+@node Xstormy16 Variable Attributes
+@subsection Xstormy16 Variable Attributes
 
-These variable attributes are available for H8/300 targets:
+One attribute is currently defined for xstormy16 configurations:
+@code{below100}.
 
 @table @code
-@item eightbit_data
-@cindex @code{eightbit_data} variable attribute, H8/300
-@cindex eight-bit data on the H8/300, H8/300H, and H8S
-Use this attribute on the H8/300, H8/300H, and H8S to indicate that the specified
-variable should be placed into the eight-bit data section.
-The compiler generates more efficient code for certain operations
-on data in the eight-bit data area.  Note the eight-bit data area is limited to
-256 bytes of data.
-
-You must use GAS and GLD from GNU binutils version 2.7 or later for
-this attribute to work correctly.
+@item below100
+@cindex @code{below100} variable attribute, Xstormy16
 
-@item tiny_data
-@cindex @code{tiny_data} variable attribute, H8/300
-@cindex tiny data section on the H8/300H and H8S
-Use this attribute on the H8/300H and H8S to indicate that the specified
-variable should be placed into the tiny data section.
-The compiler generates more efficient code for loads and stores
-on data in the tiny data section.  Note the tiny data area is limited to
-slightly under 32KB of data.
+If a variable has the @code{below100} attribute (@code{BELOW100} is
+allowed also), GCC places the variable in the first 0x100 bytes of
+memory and use special opcodes to access it.  Such variables are
+placed in either the @code{.bss_below100} section or the
+@code{.data_below100} section.
 
 @end table
 
-@subsection IA-64 Variable Attributes
+@node Type Attributes
+@section Specifying Attributes of Types
+@cindex attribute of types
+@cindex type attributes
 
-The IA-64 back end supports the following variable attribute:
+The keyword @code{__attribute__} allows you to specify special
+attributes of types.  Some type attributes apply only to @code{struct}
+and @code{union} types, while others can apply to any type defined
+via a @code{typedef} declaration.  Other attributes are defined for
+functions (@pxref{Function Attributes}), labels (@pxref{Label 
+Attributes}) and for variables (@pxref{Variable Attributes}).
 
-@table @code
-@item model (@var{model-name})
-@cindex @code{model} variable attribute, IA-64
+The @code{__attribute__} keyword is followed by an attribute specification
+inside double parentheses.  
 
-On IA-64, use this attribute to set the addressability of an object.
-At present, the only supported identifier for @var{model-name} is
-@code{small}, indicating addressability via ``small'' (22-bit)
-addresses (so that their addresses can be loaded with the @code{addl}
-instruction).  Caveat: such addressing is by definition not position
-independent and hence this attribute must not be used for objects
-defined by shared libraries.
+You may specify type attributes in an enum, struct or union type
+declaration or definition by placing them immediately after the
+@code{struct}, @code{union} or @code{enum} keyword.  A less preferred
+syntax is to place them just past the closing curly brace of the
+definition.
 
-@end table
+You can also include type attributes in a @code{typedef} declaration.
+@xref{Attribute Syntax}, for details of the exact syntax for using
+attributes.
 
-@subsection M32R/D Variable Attributes
+@menu
+* Common Type Attributes::
+* ARM Type Attributes::
+* MeP Type Attributes::
+* PowerPC Type Attributes::
+* SPU Type Attributes::
+* x86 Type Attributes::
+@end menu
 
-One attribute is currently defined for the M32R/D@.
+@node Common Type Attributes
+@subsection Common Type Attributes
+
+The following type attributes are supported on most targets.
 
 @table @code
-@item model (@var{model-name})
-@cindex @code{model-name} variable attribute, M32R/D
-@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.
+@cindex @code{aligned} type attribute
+@item aligned (@var{alignment})
+This attribute specifies a minimum alignment (in bytes) for variables
+of the specified type.  For example, the declarations:
 
-Small model objects live in the lower 16MB of memory (so that their
-addresses can be loaded with the @code{ld24} instruction).
+@smallexample
+struct S @{ short f[3]; @} __attribute__ ((aligned (8)));
+typedef int more_aligned_int __attribute__ ((aligned (8)));
+@end smallexample
 
-Medium and large model objects may live anywhere in the 32-bit address space
-(the compiler generates @code{seth/add3} instructions to load their
-addresses).
-@end table
+@noindent
+force the compiler to ensure (as far as it can) that each variable whose
+type is @code{struct S} or @code{more_aligned_int} is 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.
 
-@anchor{MeP Variable Attributes}
-@subsection MeP Variable Attributes
+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.
 
-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 that
-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.
+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:
 
-@table @code
+@smallexample
+struct S @{ short f[3]; @} __attribute__ ((aligned));
+@end smallexample
 
-@item based
-@cindex @code{based} variable attribute, MeP
-Any variable with the @code{based} attribute is assigned to the
-@code{.based} section, and is accessed with relative to the
-@code{$tp} register.
+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 that 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 that have types that you have aligned
+this way.
 
-@item tiny
-@cindex @code{tiny} variable attribute, MeP
-Likewise, the @code{tiny} attribute assigned variables to the
-@code{.tiny} section, relative to the @code{$gp} register.
+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 that 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.
 
-@item near
-@cindex @code{near} variable attribute, MeP
-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}.
+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 also does 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 is often more efficient for
+efficiently-aligned types than for other types.
 
-@item far
-@cindex @code{far} variable attribute, MeP
-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.
+The @code{aligned} attribute can only increase the alignment; but you
+can decrease it by specifying @code{packed} as well.  See below.
 
-@item io
-@cindex @code{io} variable attribute, MeP
-@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 assigns an address).  Example:
+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__} still only provides you with 8-byte
+alignment.  See your linker documentation for further information.
+
+@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} needs to
+be packed too.
 
 @smallexample
-int timer_count __attribute__((io(0x123)));
+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
 
-@item cb
-@itemx cb (@var{addr})
-@cindex @code{cb} variable attribute, MeP
-Variables with the @code{cb} attribute are used to access the control
-bus, using special instructions.  @code{addr} indicates the control bus
-address.  Example:
+You may only specify this attribute on the definition of an @code{enum},
+@code{struct} or @code{union}, not on a @code{typedef} that does not
+also define the enumerated type, structure or union.
+
+@item bnd_variable_size
+@cindex @code{bnd_variable_size} type attribute
+@cindex Pointer Bounds Checker attributes
+When applied to a structure field, this attribute tells Pointer
+Bounds Checker that the size of this field should not be computed
+using static type information.  It may be used to mark variably-sized
+static array fields placed at the end of a structure.
+
+@smallexample
+struct S
+@{
+  int size;
+  char data[1];
+@}
+S *p = (S *)malloc (sizeof(S) + 100);
+p->data[10] = 0; //Bounds violation
+@end smallexample
+
+@noindent
+By using an attribute for the field we may avoid unwanted bound
+violation checks:
+
+@smallexample
+struct S
+@{
+  int size;
+  char data[1] __attribute__((bnd_variable_size));
+@}
+S *p = (S *)malloc (sizeof(S) + 100);
+p->data[10] = 0; //OK
+@end smallexample
+
+@item deprecated
+@itemx deprecated (@var{msg})
+@cindex @code{deprecated} type attribute
+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
-int cpu_clock __attribute__((cb(0x123)));
+typedef int T1 __attribute__ ((deprecated));
+T1 x;
+typedef T1 T2;
+T2 y;
+typedef T1 T3 __attribute__ ((deprecated));
+T3 z __attribute__ ((deprecated));
 @end smallexample
 
-@end table
-
-@subsection PowerPC Variable Attributes
+@noindent
+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 @var{msg}
+argument, which must be a string, is printed in the warning if
+present.
 
-Three attributes currently are defined for PowerPC configurations:
-@code{altivec}, @code{ms_struct} and @code{gcc_struct}.
+The @code{deprecated} attribute can also be used for functions and
+variables (@pxref{Function Attributes}, @pxref{Variable Attributes}.)
 
-@cindex @code{ms_struct} variable attribute, PowerPC
-@cindex @code{gcc_struct} variable attribute, PowerPC
-For full documentation of the struct attributes please see the
-documentation in @ref{x86 Variable Attributes}.
+@item designated_init
+@cindex @code{designated_init} type attribute
+This attribute may only be applied to structure types.  It indicates
+that any initialization of an object of this type must use designated
+initializers rather than positional initializers.  The intent of this
+attribute is to allow the programmer to indicate that a structure's
+layout may change, and that therefore relying on positional
+initialization will result in future breakage.
 
-@cindex @code{altivec} variable attribute, PowerPC
-For documentation of @code{altivec} attribute please see the
-documentation in @ref{PowerPC Type Attributes}.
+GCC emits warnings based on this attribute by default; use
+@option{-Wno-designated-init} to suppress them.
 
-@subsection SPU Variable Attributes
+@item may_alias
+@cindex @code{may_alias} type attribute
+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 section 6.5 paragraph 7 of the C99 standard,
+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.
 
-@cindex @code{spu_vector} variable attribute, SPU
-The SPU supports the @code{spu_vector} attribute for variables.  For
-documentation of this attribute please see the documentation in
-@ref{SPU Type Attributes}.
+Note that an object of a type with this attribute does not have any
+special semantics.
 
-@anchor{x86 Variable Attributes}
-@subsection x86 Variable Attributes
+Example of use:
 
-Two attributes are currently defined for x86 configurations:
-@code{ms_struct} and @code{gcc_struct}.
+@smallexample
+typedef short __attribute__((__may_alias__)) short_a;
 
-@table @code
-@item ms_struct
-@itemx gcc_struct
-@cindex @code{ms_struct} variable attribute, x86
-@cindex @code{gcc_struct} variable attribute, x86
+int
+main (void)
+@{
+  int a = 0x12345678;
+  short_a *b = (short_a *) &a;
 
-If @code{packed} is used on a structure, or if bit-fields are used,
-it may be that the Microsoft ABI lays out the structure differently
-than the way GCC normally does.  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.
+  b[1] = 0;
 
-Currently @option{-m[no-]ms-bitfields} is provided for the Microsoft Windows x86
-compilers to match the native Microsoft compiler.
+  if (a == 0x12345678)
+    abort();
 
-The Microsoft structure layout algorithm is fairly simple with the exception
-of the bit-field packing.  
-The padding and alignment of members of structures and whether a bit-field 
-can straddle a storage-unit boundary are determine by these rules:
+  exit(0);
+@}
+@end smallexample
 
-@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.
+@noindent
+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.
 
-@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
-@code{aligned} attribute or the @code{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:
+@item packed
+@cindex @code{packed} type attribute
+This attribute, attached to @code{struct} or @code{union} type
+definition, specifies that each member (other than zero-width bit-fields)
+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.
 
-@smallexample
-offset % alignment_requirement == 0
-@end smallexample
+@item transparent_union
+@cindex @code{transparent_union} type attribute
 
-@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
+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.
 
-MSVC interprets zero-length bit-fields in the following ways:
+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.
 
-@enumerate
-@item If a zero-length bit-field is inserted between two bit-fields that
-are normally coalesced, the bit-fields are not coalesced.
+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.
 
-For example:
+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
-struct
- @{
-   unsigned long bf_1 : 12;
-   unsigned long : 0;
-   unsigned long bf_2 : 12;
- @} t1;
+typedef union __attribute__ ((__transparent_union__))
+  @{
+    int *__ip;
+    union wait *__up;
+  @} wait_status_ptr_t;
+
+pid_t wait (wait_status_ptr_t);
 @end smallexample
 
 @noindent
-The size of @code{t1} is 8 bytes with the zero-length bit-field.  If the
-zero-length bit-field were removed, @code{t1}'s size would be 4 bytes.
-
-@item If a zero-length bit-field is inserted after a bit-field, @code{foo}, and the
-alignment of the zero-length bit-field is greater than the member that follows it,
-@code{bar}, @code{bar} is aligned as the type of the zero-length bit-field.
-
-For example:
+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
-struct
- @{
-   char foo : 4;
-   short : 0;
-   char bar;
- @} t2;
-
-struct
- @{
-   char foo : 4;
-   short : 0;
-   double bar;
- @} t3;
+int w1 () @{ int w; return wait (&w); @}
+int w2 () @{ union wait w; return wait (&w); @}
 @end smallexample
 
 @noindent
-For @code{t2}, @code{bar} is placed at offset 2, rather than offset 1.
-Accordingly, the size of @code{t2} is 4.  For @code{t3}, the zero-length
-bit-field does 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 bit-field follows a normal bit-field, the type of the
-zero-length bit-field may affect the alignment of the structure as whole. For
-example, @code{t2} has a size of 4 bytes, since the zero-length bit-field follows a
-normal bit-field, and is of type short.
-
-@item Even if a zero-length bit-field is not followed by a normal bit-field, it may
-still affect the alignment of the structure:
+With this interface, @code{wait}'s implementation might look like this:
 
 @smallexample
-struct
- @{
-   char foo : 6;
-   long : 0;
- @} t4;
+pid_t wait (wait_status_ptr_t p)
+@{
+  return waitpid (-1, p.__ip, 0);
+@}
 @end smallexample
 
-@noindent
-Here, @code{t4} takes up 4 bytes.
-@end enumerate
+@item unused
+@cindex @code{unused} type attribute
+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 does 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 Zero-length bit-fields following non-bit-field members are ignored:
+@item visibility
+@cindex @code{visibility} type attribute
+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.
 
-@smallexample
-struct
- @{
-   char foo;
-   long : 0;
-   char bar;
- @} t5;
-@end smallexample
+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 are unable to use the same
+typeinfo node and exception handling will break.
 
-@noindent
-Here, @code{t5} takes up 2 bytes.
-@end enumerate
 @end table
 
-@subsection Xstormy16 Variable Attributes
+To specify multiple attributes, separate them by commas within the
+double parentheses: for example, @samp{__attribute__ ((aligned (16),
+packed))}.
 
-One attribute is currently defined for xstormy16 configurations:
-@code{below100}.
+@node ARM Type Attributes
+@subsection ARM Type Attributes
 
-@table @code
-@item below100
-@cindex @code{below100} variable attribute, Xstormy16
+@cindex @code{notshared} type attribute, ARM
+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:
 
-If a variable has the @code{below100} attribute (@code{BELOW100} is
-allowed also), GCC places the variable in the first 0x100 bytes of
-memory and use special opcodes to access it.  Such variables are
-placed in either the @code{.bss_below100} section or the
-@code{.data_below100} section.
+@smallexample
+class __declspec(notshared) C @{
+public:
+  __declspec(dllimport) C();
+  virtual void f();
+@}
 
-@end table
+__declspec(dllexport)
+C::C() @{@}
+@end smallexample
 
-@node Type Attributes
-@section Specifying Attributes of Types
-@cindex attribute of types
-@cindex type attributes
+@noindent
+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}.)
 
-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.  Eight attributes are currently defined for
-types: @code{aligned}, @code{packed}, @code{transparent_union},
-@code{unused}, @code{deprecated}, @code{visibility}, @code{may_alias}
-and @code{bnd_variable_size}.  Other attributes are defined for
-functions (@pxref{Function Attributes}), labels (@pxref{Label 
-Attributes}) and for variables (@pxref{Variable Attributes}).
+@node MeP Type Attributes
+@subsection MeP Type 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}.
+@cindex @code{based} type attribute, MeP
+@cindex @code{tiny} type attribute, MeP
+@cindex @code{near} type attribute, MeP
+@cindex @code{far} type attribute, MeP
+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.
 
-You may specify type attributes in an enum, struct or union type
-declaration or definition, or for other types in a @code{typedef}
-declaration.
+@node PowerPC Type Attributes
+@subsection PowerPC Type Attributes
 
-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.
+Three attributes currently are defined for PowerPC configurations:
+@code{altivec}, @code{ms_struct} and @code{gcc_struct}.
 
-@xref{Attribute Syntax}, for details of the exact syntax for using
-attributes.
+@cindex @code{ms_struct} type attribute, PowerPC
+@cindex @code{gcc_struct} type attribute, PowerPC
+For full documentation of the @code{ms_struct} and @code{gcc_struct}
+attributes please see the documentation in @ref{x86 Type Attributes}.
 
-@table @code
-@cindex @code{aligned} type attribute
-@item aligned (@var{alignment})
-This attribute specifies a minimum alignment (in bytes) for variables
-of the specified type.  For example, the declarations:
+@cindex @code{altivec} type attribute, PowerPC
+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
-struct S @{ short f[3]; @} __attribute__ ((aligned (8)));
-typedef int more_aligned_int __attribute__ ((aligned (8)));
+__attribute__((altivec(vector__)))
+__attribute__((altivec(pixel__))) unsigned short
+__attribute__((altivec(bool__))) unsigned
 @end smallexample
 
-@noindent
-force the compiler to ensure (as far as it can) that each variable whose
-type is @code{struct S} or @code{more_aligned_int} is 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.
+These attributes mainly are intended to support the @code{__vector},
+@code{__pixel}, and @code{__bool} AltiVec keywords.
 
-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.
+@node SPU Type Attributes
+@subsection SPU Type Attributes
 
-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:
+@cindex @code{spu_vector} type attribute, SPU
+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.
 
-@smallexample
-struct S @{ short f[3]; @} __attribute__ ((aligned));
-@end smallexample
+@node x86 Type Attributes
+@subsection x86 Type Attributes
 
-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 that 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 that have types that you have aligned
-this way.
+Two attributes are currently defined for x86 configurations:
+@code{ms_struct} and @code{gcc_struct}.
 
-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 that 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.
+@table @code
 
-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 also does 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 is often more efficient for
-efficiently-aligned types than for other types.
+@item ms_struct
+@itemx gcc_struct
+@cindex @code{ms_struct} type attribute, x86
+@cindex @code{gcc_struct} type attribute, x86
 
-The @code{aligned} attribute can only increase the alignment; but you
-can decrease it by specifying @code{packed} as well.  See below.
+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 normally packs 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.
 
-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__} still only provides you with 8-byte
-alignment.  See your linker documentation for further information.
+Currently @option{-m[no-]ms-bitfields} is provided for the Microsoft Windows x86
+compilers to match the native Microsoft compiler.
+@end table
 
-@item packed
-@cindex @code{packed} type attribute
-This attribute, attached to @code{struct} or @code{union} type
-definition, specifies that each member (other than zero-width bit-fields)
-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.
+@node Label Attributes
+@section Label Attributes
+@cindex Label Attributes
 
-@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.
+GCC allows attributes to be set on C labels.  @xref{Attribute Syntax}, for 
+details of the exact syntax for using attributes.  Other attributes are 
+available for functions (@pxref{Function Attributes}), variables 
+(@pxref{Variable Attributes}) and for types (@pxref{Type Attributes}).
 
-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} needs to
-be packed too.
+This example uses the @code{cold} label attribute to indicate the 
+@code{ErrorHandling} branch is unlikely to be taken and that the
+@code{ErrorHandling} label is unused:
 
 @smallexample
-struct my_unpacked_struct
- @{
-    char c;
-    int i;
- @};
 
-struct __attribute__ ((__packed__)) my_packed_struct
-  @{
-     char c;
-     int  i;
-     struct my_unpacked_struct s;
-  @};
+   asm goto ("some asm" : : : : NoError);
+
+/* This branch (the fall-through from the asm) is less commonly used */
+ErrorHandling: 
+   __attribute__((cold, unused)); /* Semi-colon is required here */
+   printf("error\n");
+   return 0;
+
+NoError:
+   printf("no error\n");
+   return 1;
 @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} that does not
-also define the enumerated type, structure or union.
+@table @code
+@item unused
+@cindex @code{unused} label attribute
+This feature is intended for program-generated code that may contain 
+unused labels, but which is compiled with @option{-Wall}.  It is
+not normally 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.
 
-@item transparent_union
-@cindex @code{transparent_union} type attribute
+@item hot
+@cindex @code{hot} label attribute
+The @code{hot} attribute on a label is used to inform the compiler that
+the path following the label is more likely than paths that are not so
+annotated.  This attribute is used in cases where @code{__builtin_expect}
+cannot be used, for instance with computed goto or @code{asm goto}.
 
-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.
+@item cold
+@cindex @code{cold} label attribute
+The @code{cold} attribute on labels is used to inform the compiler that
+the path following the label is unlikely to be executed.  This attribute
+is used in cases where @code{__builtin_expect} cannot be used, for instance
+with computed goto or @code{asm goto}.
+
+@end table
+
+@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.
 
-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.
+@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.
+@xref{Label Attributes}, for details of the semantics of attributes 
+applying to labels.
 
-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.
+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:
 
-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:
+@itemize @bullet
+@item
+Empty.  Empty attributes are ignored.
 
-@smallexample
-typedef union __attribute__ ((__transparent_union__))
-  @{
-    int *__ip;
-    union wait *__up;
-  @} wait_status_ptr_t;
+@item
+An attribute name
+(which may be an identifier such as @code{unused}, or a reserved
+word such as @code{const}).
 
-pid_t wait (wait_status_ptr_t);
-@end smallexample
+@item
+An attribute name followed by a parenthesized list of
+parameters for the attribute.
+These parameters take one of the following forms:
 
-@noindent
-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:
+@itemize @bullet
+@item
+An identifier.  For example, @code{mode} attributes use this form.
 
-@smallexample
-int w1 () @{ int w; return wait (&w); @}
-int w2 () @{ union wait w; return wait (&w); @}
-@end smallexample
+@item
+An identifier followed by a comma and a non-empty comma-separated list
+of expressions.  For example, @code{format} attributes use this form.
 
-@noindent
-With this interface, @code{wait}'s implementation might look like this:
+@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
 
-@smallexample
-pid_t wait (wait_status_ptr_t p)
-@{
-  return waitpid (-1, p.__ip, 0);
-@}
-@end smallexample
+An @dfn{attribute specifier list} is a sequence of one or more attribute
+specifiers, not separated by any other tokens.
 
-@item unused
-@cindex @code{unused} type attribute
-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 does 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.
+You may optionally specify attribute names with @samp{__}
+preceding and following the name.
+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 the attribute name @code{__noreturn__} instead of @code{noreturn}.
 
-@item deprecated
-@itemx deprecated (@var{msg})
-@cindex @code{deprecated} type attribute
-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
+@subsubheading Label Attributes
 
-@noindent
-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 @var{msg}
-argument, which must be a string, is printed in the warning if
-present.
+In GNU C, an attribute specifier list may appear after the colon following a
+label, other than a @code{case} or @code{default} label.  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.
 
-The @code{deprecated} attribute can also be used for functions and
-variables (@pxref{Function Attributes}, @pxref{Variable Attributes}.)
+@subsubheading Type Attributes
 
-@item may_alias
-@cindex @code{may_alias} type attribute
-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 section 6.5 paragraph 7 of the C99 standard,
-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.
+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.
 
-Note that an object of a type with this attribute does not have any
-special semantics.
 
-Example of use:
+@subsubheading All other attributes
 
-@smallexample
-typedef short __attribute__((__may_alias__)) short_a;
+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.
 
-int
-main (void)
-@{
-  int a = 0x12345678;
-  short_a *b = (short_a *) &a;
+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.
 
-  b[1] = 0;
+At present, the first parameter in a function prototype must have some
+type specifier that 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.
 
-  if (a == 0x12345678)
-    abort();
+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
 
-  exit(0);
-@}
+@smallexample
+__attribute__((noreturn)) void d0 (void),
+    __attribute__((format(printf, 1, 2))) d1 (const char *, ...),
+     d2 (void);
 @end smallexample
 
 @noindent
-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.
+the @code{noreturn} attribute applies to all the functions
+declared; the @code{format} attribute only applies to @code{d1}.
 
-@item visibility
-@cindex @code{visibility} type attribute
-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.
+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.
 
-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 are unable to use the same
-typeinfo node and exception handling will break.
+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 makes the
+most sense if you are familiar with the formal specification of
+declarators in the ISO C standard.
 
-@item designated_init
-@cindex @code{designated_init} type attribute
-This attribute may only be applied to structure types.  It indicates
-that any initialization of an object of this type must use designated
-initializers rather than positional initializers.  The intent of this
-attribute is to allow the programmer to indicate that a structure's
-layout may change, and that therefore relying on positional
-initialization will result in future breakage.
+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.
 
-GCC emits warnings based on this attribute by default; use
-@option{-Wno-designated-init} to suppress them.
+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}.
 
-@item bnd_variable_size
-@cindex @code{bnd_variable_size} type attribute
-@cindex Pointer Bounds Checker attributes
-When applied to a structure field, this attribute tells Pointer
-Bounds Checker that the size of this field should not be computed
-using static type information.  It may be used to mark variably-sized
-static array fields placed at the end of a structure.
+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
-struct S
-@{
-  int size;
-  char data[1];
-@}
-S *p = (S *)malloc (sizeof(S) + 100);
-p->data[10] = 0; //Bounds violation
+void (__attribute__((noreturn)) ****f) (void);
 @end smallexample
 
 @noindent
-By using an attribute for the field we may avoid unwanted bound
-violation checks:
+specifies the type ``pointer to pointer to pointer to pointer to
+non-returning function returning @code{void}''.  As another example,
 
 @smallexample
-struct S
-@{
-  int size;
-  char data[1] __attribute__((bnd_variable_size));
-@}
-S *p = (S *)malloc (sizeof(S) + 100);
-p->data[10] = 0; //OK
+char *__attribute__((aligned(8))) *f;
 @end smallexample
 
-@end table
+@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.
 
-To specify multiple attributes, separate them by commas within the
-double parentheses: for example, @samp{__attribute__ ((aligned (16),
-packed))}.
+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 is 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 is 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 is treated as
+applying to the function type, and such an attribute applied to an array
+element type is 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 is 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 is treated as applying
+to the function type.
 
-@subsection ARM Type Attributes
+@node Function Prototypes
+@section Prototypes and Old-Style Function Definitions
+@cindex function prototype declarations
+@cindex old-style function definitions
+@cindex promotion of formal parameters
 
-@cindex @code{notshared} type attribute, ARM
-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:
+GNU C extends ISO C to allow a function prototype to override a later
+old-style non-prototype definition.  Consider the following example:
 
 @smallexample
-class __declspec(notshared) C @{
-public:
-  __declspec(dllimport) C();
-  virtual void f();
-@}
-
-__declspec(dllexport)
-C::C() @{@}
-@end smallexample
-
-@noindent
-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
-
-@cindex @code{based} type attribute, MeP
-@cindex @code{tiny} type attribute, MeP
-@cindex @code{near} type attribute, MeP
-@cindex @code{far} type attribute, MeP
-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.
+/* @r{Use prototypes unless the compiler is old-fashioned.}  */
+#ifdef __STDC__
+#define P(x) x
+#else
+#define P(x) ()
+#endif
 
-@anchor{PowerPC Type Attributes}
-@subsection PowerPC Type Attributes
+/* @r{Prototype function declaration.}  */
+int isroot P((uid_t));
 
-Three attributes currently are defined for PowerPC configurations:
-@code{altivec}, @code{ms_struct} and @code{gcc_struct}.
+/* @r{Old-style function definition.}  */
+int
+isroot (x)   /* @r{??? lossage here ???} */
+     uid_t x;
+@{
+  return x == 0;
+@}
+@end smallexample
 
-@cindex @code{ms_struct} type attribute, PowerPC
-@cindex @code{gcc_struct} type attribute, PowerPC
-For full documentation of the @code{ms_struct} and @code{gcc_struct}
-attributes please see the documentation in @ref{x86 Type Attributes}.
+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}.
 
-@cindex @code{altivec} type attribute, PowerPC
-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).
+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
-__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.
+int isroot (uid_t);
 
-@anchor{SPU Type Attributes}
-@subsection SPU Type Attributes
+int
+isroot (uid_t x)
+@{
+  return x == 0;
+@}
+@end smallexample
 
-@cindex @code{spu_vector} type attribute, SPU
-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.
+@noindent
+GNU C++ does not support old-style function definitions, so this
+extension is irrelevant.
 
-@anchor{x86 Type Attributes}
-@subsection x86 Type Attributes
+@node C++ Comments
+@section C++ Style Comments
+@cindex @code{//}
+@cindex C++ comments
+@cindex comments, C++ style
 
-Two attributes are currently defined for x86 configurations:
-@code{ms_struct} and @code{gcc_struct}.
+In GNU C, you may use C++ style comments, which start with @samp{//} and
+continue until the end of the line.  Many other C implementations allow
+such comments, and they are included in the 1999 C standard.  However,
+C++ style comments are not recognized if you specify an @option{-std}
+option specifying a version of ISO C before C99, or @option{-ansi}
+(equivalent to @option{-std=c90}).
 
-@table @code
+@node Dollar Signs
+@section Dollar Signs in Identifier Names
+@cindex $
+@cindex dollar signs in identifier names
+@cindex identifier names, dollar signs in
 
-@item ms_struct
-@itemx gcc_struct
-@cindex @code{ms_struct} type attribute, x86
-@cindex @code{gcc_struct} type attribute, x86
+In GNU C, you may normally use dollar signs in identifier names.
+This is because many traditional C implementations allow such identifiers.
+However, dollar signs in identifiers are not supported on a few target
+machines, typically because the target assembler does not allow them.
 
-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 normally packs 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.
+@node Character Escapes
+@section The Character @key{ESC} in Constants
 
-Currently @option{-m[no-]ms-bitfields} is provided for the Microsoft Windows x86
-compilers to match the native Microsoft compiler.
-@end table
+You can use the sequence @samp{\e} in a string or character constant to
+stand for the ASCII character @key{ESC}.
 
 @node Alignment
 @section Inquiring on Alignment of Types or Variables
@@ -8213,15 +8871,19 @@ identifier, or a sequence of member accesses and array references.
 The following built-in functions
 are intended to be compatible with those described
 in the @cite{Intel Itanium Processor-specific Application Binary Interface},
-section 7.4.  As such, they depart from the normal GCC practice of using
-the @samp{__builtin_} prefix, and further that they are overloaded such that
-they work on multiple types.
+section 7.4.  As such, they depart from normal GCC practice by not using
+the @samp{__builtin_} prefix and also by being overloaded so that they
+work on multiple types.
 
 The definition given in the Intel documentation allows only for the use of
-the types @code{int}, @code{long}, @code{long long} as well as their unsigned
+the types @code{int}, @code{long}, @code{long long} or their unsigned
 counterparts.  GCC allows any integral scalar or pointer type that is
 1, 2, 4 or 8 bytes in length.
 
+These functions are implemented in terms of the @samp{__atomic}
+builtins (@pxref{__atomic Builtins}).  They should not be used for new
+code which should use the @samp{__atomic} builtins instead.
+
 Not all operations are supported by all target processors.  If a particular
 operation cannot be implemented on the target processor, a warning is
 generated and a call to an external function is generated.  The external
@@ -8243,11 +8905,10 @@ after the operation.
 All of the routines are described in the Intel documentation to take
 ``an optional list of variables protected by the memory barrier''.  It's
 not clear what is meant by that; it could mean that @emph{only} the
-following variables are protected, or it could mean that these variables
-should in addition be protected.  At present GCC ignores this list and
-protects all variables that are globally accessible.  If in the future
-we make some use of this list, an empty list will continue to mean all
-globally accessible variables.
+listed variables are protected, or it could mean a list of additional
+variables to be protected.  The list is ignored by GCC which treats it as
+empty.  GCC interprets an empty list as meaning that all globally
+accessible variables should be protected.
 
 @table @code
 @item @var{type} __sync_fetch_and_add (@var{type} *ptr, @var{type} value, ...)
@@ -8350,45 +9011,47 @@ are not prevented from being speculated to before the barrier.
 @node __atomic Builtins
 @section Built-in Functions for Memory Model Aware Atomic Operations
 
-The following built-in functions approximately match the requirements for
-C++11 memory model. Many are similar to the @samp{__sync} prefixed built-in
-functions, but all also have a memory model parameter.  These are all
-identified by being prefixed with @samp{__atomic}, and most are overloaded
-such that they work with multiple types.
+The following built-in functions approximately match the requirements
+for C++11 concurrency and memory models.  They are all
+identified by being prefixed with @samp{__atomic} and most are
+overloaded so that they work with multiple types.
 
-GCC allows any integral scalar or pointer type that is 1, 2, 4, or 8
-bytes in length. 16-byte integral types are also allowed if
-@samp{__int128} (@pxref{__int128}) is supported by the architecture.
+These functions are intended to replace the legacy @samp{__sync}
+builtins.  The main difference is that the memory model to be used is a
+parameter to the functions.  New code should always use the
+@samp{__atomic} builtins rather than the @samp{__sync} builtins.
 
-Target architectures are encouraged to provide their own patterns for
-each of these built-in functions.  If no target is provided, the original 
-non-memory model set of @samp{__sync} atomic built-in functions are
-utilized, along with any required synchronization fences surrounding it in
-order to achieve the proper behavior.  Execution in this case is subject
-to the same restrictions as those built-in functions.
+Note that the @samp{__atomic} builtins assume that programs will
+conform to the C++11 model for concurrency.  In particular, they assume
+that programs are free of data races.  See the C++11 standard for
+detailed definitions.
 
-If there is no pattern or mechanism to provide a lock free instruction
-sequence, a call is made to an external routine with the same parameters
-to be resolved at run time.
+The @samp{__atomic} builtins can be used with any integral scalar or
+pointer type that is 1, 2, 4, or 8 bytes in length.  16-byte integral
+types are also allowed if @samp{__int128} (@pxref{__int128}) is
+supported by the architecture.
 
 The four non-arithmetic functions (load, store, exchange, and 
 compare_exchange) all have a generic version as well.  This generic
 version works on any data type.  If the data type size maps to one
 of the integral sizes that may have lock free support, the generic
-version utilizes the lock free built-in function.  Otherwise an
+version uses the lock free built-in function.  Otherwise an
 external call is left to be resolved at run time.  This external call is
 the same format with the addition of a @samp{size_t} parameter inserted
 as the first parameter indicating the size of the object being pointed to.
 All objects must be the same size.
 
 There are 6 different memory models that can be specified.  These map
-to the same names in the C++11 standard.  Refer there or to the
-@uref{http://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync,GCC wiki on
-atomic synchronization} for more detailed definitions.  These memory
-models integrate both barriers to code motion as well as synchronization
-requirements with other threads. These are listed in approximately
-ascending order of strength. It is also possible to use target specific
-flags for memory model flags, like Hardware Lock Elision.
+to the C++11 memory models with the same names, see the C++11 standard
+or the @uref{http://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync,GCC wiki
+on atomic synchronization} for detailed definitions.  Individual
+targets may also support additional memory models for use on specific
+architectures.  Refer to the target documentation for details of
+these.
+
+The memory models integrate both barriers to code motion as well as
+synchronization requirements with other threads.  They are listed here
+in approximately ascending order of strength.
 
 @table  @code
 @item __ATOMIC_RELAXED
@@ -8403,13 +9066,32 @@ semantic stores from another thread.
 Barrier to sinking of code and synchronizes with acquire (or stronger)
 semantic loads from another thread.
 @item __ATOMIC_ACQ_REL
-Full barrier in both directions and synchronizes with acquire loads and
+Barrier in both directions and synchronizes with acquire loads and
 release stores in another thread.
 @item __ATOMIC_SEQ_CST
-Full barrier in both directions and synchronizes with acquire loads and
+Barrier in both directions and synchronizes with acquire loads and
 release stores in all threads.
 @end table
 
+Note that the scope of a C++11 memory model depends on whether or not
+the function being called is a @emph{fence} (such as
+@samp{__atomic_thread_fence}).  In a fence, all memory accesses are
+subject to the restrictions of the memory model.  When the function is
+an operation on a location, the restrictions apply only to those
+memory accesses that could affect or that could depend on the
+location.
+
+Target architectures are encouraged to provide their own patterns for
+each of these built-in functions.  If no target is provided, the original
+non-memory model set of @samp{__sync} atomic built-in functions are
+used, along with any required synchronization fences surrounding it in
+order to achieve the proper behavior.  Execution in this case is subject
+to the same restrictions as those built-in functions.
+
+If there is no pattern or mechanism to provide a lock free instruction
+sequence, a call is made to an external routine with the same parameters
+to be resolved at run time.
+
 When implementing patterns for these built-in functions, the memory model
 parameter can be ignored as long as the pattern implements the most
 restrictive @code{__ATOMIC_SEQ_CST} model.  Any of the other memory models
@@ -8480,19 +9162,20 @@ of @code{*@var{ptr}} is copied into @code{*@var{ret}}.
 @deftypefn {Built-in Function} bool __atomic_compare_exchange_n (@var{type} *ptr, @var{type} *expected, @var{type} desired, bool weak, int success_memmodel, int failure_memmodel)
 This built-in function implements an atomic compare and exchange operation.
 This compares the contents of @code{*@var{ptr}} with the contents of
-@code{*@var{expected}} and if equal, writes @var{desired} into
-@code{*@var{ptr}}.  If they are not equal, the current contents of
+@code{*@var{expected}}. If equal, the operation is a @emph{read-modify-write}
+which writes @var{desired} into @code{*@var{ptr}}.  If they are not
+equal, the operation is a @emph{read} and the current contents of
 @code{*@var{ptr}} is written into @code{*@var{expected}}.  @var{weak} is true
 for weak compare_exchange, and false for the strong variation.  Many targets 
 only offer the strong variation and ignore the parameter.  When in doubt, use
 the strong variation.
 
 True is returned if @var{desired} is written into
-@code{*@var{ptr}} and the execution is considered to conform to the
+@code{*@var{ptr}} and the operation is considered to conform to the
 memory model specified by @var{success_memmodel}.  There are no
 restrictions on what memory model can be used here.
 
-False is returned otherwise, and the execution is considered to conform
+False is returned otherwise, and the operation is considered to conform
 to @var{failure_memmodel}. This memory model cannot be
 @code{__ATOMIC_RELEASE} nor @code{__ATOMIC_ACQ_REL}.  It also cannot be a
 stronger model than that specified by @var{success_memmodel}.
@@ -17455,6 +18138,7 @@ we do not recommend the use of pragmas; @xref{Function Attributes},
 for further explanation.
 
 @menu
+* AArch64 Pragmas::
 * ARM Pragmas::
 * M32C Pragmas::
 * MeP Pragmas::
@@ -17471,6 +18155,19 @@ for further explanation.
 * Loop-Specific Pragmas::
 @end menu
 
+@node AArch64 Pragmas
+@subsection AArch64 Pragmas
+
+The pragmas defined by the AArch64 target correspond to the AArch64
+target function attributes.  They can be specified as below:
+@smallexample
+#pragma GCC target("string")
+@end smallexample
+
+where @code{@var{string}} can be any string accepted as an AArch64 target
+attribute.  @xref{AArch64 Function Attributes}, for more details
+on the permissible values of @code{string}.
+
 @node ARM Pragmas
 @subsection ARM Pragmas
 
--- a/src/gcc/doc/install.texi
+++ b/src/gcc/doc/install.texi
@@ -1544,15 +1544,17 @@ their runtime libraries should be built.  For a list of valid values for
 @var{langN} you can issue the following command in the
 @file{gcc} directory of your GCC source tree:@*
 @smallexample
-grep language= */config-lang.in
+grep ^language= */config-lang.in
 @end smallexample
 Currently, you can use any of the following:
 @code{all}, @code{ada}, @code{c}, @code{c++}, @code{fortran},
-@code{go}, @code{java}, @code{objc}, @code{obj-c++}.
+@code{go}, @code{java}, @code{jit}, @code{lto}, @code{objc}, @code{obj-c++}.
 Building the Ada compiler has special requirements, see below.
 If you do not pass this flag, or specify the option @code{all}, then all
 default languages available in the @file{gcc} sub-tree will be configured.
-Ada, Go and Objective-C++ are not default languages; the rest are.
+Ada, Go, Jit, and Objective-C++ are not default languages.  LTO is not a
+default language, but is built by default because @option{--enable-lto} is
+enabled by default.  The other languages are default languages.
 
 @item --enable-stage1-languages=@var{lang1},@var{lang2},@dots{}
 Specify that a particular subset of compilers and their runtime
--- a/src/gcc/doc/invoke.texi
+++ b/src/gcc/doc/invoke.texi
@@ -510,6 +510,7 @@ Objective-C and Objective-C++ Dialects}.
 -mstrict-align @gol
 -momit-leaf-frame-pointer  -mno-omit-leaf-frame-pointer @gol
 -mtls-dialect=desc  -mtls-dialect=traditional @gol
+-mtls-size=@var{size} @gol
 -mfix-cortex-a53-835769  -mno-fix-cortex-a53-835769 @gol
 -mfix-cortex-a53-843419  -mno-fix-cortex-a53-843419 @gol
 -march=@var{name}  -mcpu=@var{name}  -mtune=@var{name}}
@@ -667,7 +668,7 @@ Objective-C and Objective-C++ Dialects}.
 -mcpu=@var{cpu}}
 
 @emph{GNU/Linux Options}
-@gccoptlist{-mglibc -muclibc -mbionic -mandroid @gol
+@gccoptlist{-mglibc -muclibc -mmusl -mbionic -mandroid @gol
 -tno-android-cc -tno-android-ld}
 
 @emph{H8/300 Options}
@@ -1123,7 +1124,7 @@ See S/390 and zSeries Options.
 -finstrument-functions-exclude-function-list=@var{sym},@var{sym},@dots{} @gol
 -finstrument-functions-exclude-file-list=@var{file},@var{file},@dots{} @gol
 -fno-common  -fno-ident @gol
--fpcc-struct-return  -fpic  -fPIC -fpie -fPIE @gol
+-fpcc-struct-return  -fpic  -fPIC -fpie -fPIE -fno-plt @gol
 -fno-jump-tables @gol
 -frecord-gcc-switches @gol
 -freg-struct-return  -fshort-enums @gol
@@ -7563,10 +7564,10 @@ that do not interfere with debugging. It should be the optimization
 level of choice for the standard edit-compile-debug cycle, offering
 a reasonable level of optimization while maintaining fast compilation
 and a good debugging experience.
+@end table
 
 If you use multiple @option{-O} options, with or without level numbers,
 the last such option is the one that is effective.
-@end table
 
 Options of the form @option{-f@var{flag}} specify machine-independent
 flags.  Most flags have both positive and negative forms; the negative
@@ -12263,7 +12264,9 @@ Generate big-endian code.  This is the default when GCC is configured for an
 
 @item -mgeneral-regs-only
 @opindex mgeneral-regs-only
-Generate code which uses only the general registers.
+Generate code which uses only the general-purpose registers.  This will prevent
+the compiler from using floating-point and Advanced SIMD registers but will not
+impose any restrictions on the assembler.
 
 @item -mlittle-endian
 @opindex mlittle-endian
@@ -12310,6 +12313,11 @@ of TLS variables.  This is the default.
 Use traditional TLS as the thread-local storage mechanism for dynamic accesses
 of TLS variables.
 
+@item -mtls-size=@var{size}
+@opindex mtls-size
+Specify bit size of immediate TLS offsets.  Valid values are 12, 24, 32, 48.
+This option depends on binutils higher than 2.25.
+
 @item -mfix-cortex-a53-835769
 @itemx -mno-fix-cortex-a53-835769
 @opindex mfix-cortex-a53-835769
@@ -12328,34 +12336,50 @@ corresponding flag to the linker.
 
 @item -march=@var{name}
 @opindex march
-Specify the name of the target architecture, optionally suffixed by one or
+Specify the name of the target architecture and, optionally, one or
 more feature modifiers.  This option has the form
-@option{-march=@var{arch}@r{@{}+@r{[}no@r{]}@var{feature}@r{@}*}}, where the
-only permissible value for @var{arch} is @samp{armv8-a}.  The permissible
-values for @var{feature} are documented in the sub-section below.
+@option{-march=@var{arch}@r{@{}+@r{[}no@r{]}@var{feature}@r{@}*}}.
 
-Where conflicting feature modifiers are specified, the right-most feature is
-used.
+The permissible values for @var{arch} are @samp{armv8-a},
+@samp{armv8.1-a} or @var{native}.
 
-GCC uses this name to determine what kind of instructions it can emit when
-generating assembly code.
+The value @samp{armv8.1-a} implies @samp{armv8-a} and enables compiler
+support for the ARMv8.1 architecture extension.  In particular, it
+enables the @samp{+crc} and @samp{+lse} features.
 
-Where @option{-march} is specified without either of @option{-mtune}
-or @option{-mcpu} also being specified, the code is tuned to perform
-well across a range of target processors implementing the target
-architecture.
+The value @samp{native} is available on native AArch64 GNU/Linux and
+causes the compiler to pick the architecture of the host system.  This
+option has no effect if the compiler is unable to recognize the
+architecture of the host system,
+
+The permissible values for @var{feature} are listed in the sub-section
+on @ref{aarch64-feature-modifiers,,@option{-march} and @option{-mcpu}
+Feature Modifiers}.  Where conflicting feature modifiers are
+specified, the right-most feature is used.
+
+GCC uses @var{name} to determine what kind of instructions it can emit
+when generating assembly code.  If @option{-march} is specified
+without either of @option{-mtune} or @option{-mcpu} also being
+specified, the code is tuned to perform well across a range of target
+processors implementing the target architecture.
 
 @item -mtune=@var{name}
 @opindex mtune
 Specify the name of the target processor for which GCC should tune the
 performance of the code.  Permissible values for this option are:
 @samp{generic}, @samp{cortex-a53}, @samp{cortex-a57}, @samp{cortex-a72},
-@samp{exynos-m1}, @samp{thunderx}, @samp{xgene1}.
+@samp{exynos-m1}, @samp{qdf24xx}, @samp{thunderx}, @samp{xgene1}.
 
 Additionally, this option can specify that GCC should tune the performance
 of the code for a big.LITTLE system.  Permissible values for this
 option are: @samp{cortex-a57.cortex-a53}, @samp{cortex-a72.cortex-a53}.
 
+Additionally on native AArch64 GNU/Linux systems the value
+@samp{native} is available.  This option causes the compiler to pick
+the architecture of and tune the performance of the code for the
+processor of the host system.  This option has no effect if the
+compiler is unable to recognize the architecture of the host system.
+
 Where none of @option{-mtune=}, @option{-mcpu=} or @option{-march=}
 are specified, the code is tuned to perform well across a range
 of target processors.
@@ -12364,45 +12388,78 @@ This option cannot be suffixed by feature modifiers.
 
 @item -mcpu=@var{name}
 @opindex mcpu
-Specify the name of the target processor, optionally suffixed by one or more
-feature modifiers.  This option has the form
-@option{-mcpu=@var{cpu}@r{@{}+@r{[}no@r{]}@var{feature}@r{@}*}}, where the
-permissible values for @var{cpu} are the same as those available for
-@option{-mtune}.
-
-The permissible values for @var{feature} are documented in the sub-section
-below.
-
-Where conflicting feature modifiers are specified, the right-most feature is
-used.
-
-GCC uses this name to determine what kind of instructions it can emit when
+Specify the name of the target processor, optionally suffixed by one
+or more feature modifiers.  This option has the form
+@option{-mcpu=@var{cpu}@r{@{}+@r{[}no@r{]}@var{feature}@r{@}*}}, where
+the permissible values for @var{cpu} are the same as those available
+for @option{-mtune}.  The permissible values for @var{feature} are
+documented in the sub-section on
+@ref{aarch64-feature-modifiers,,@option{-march} and @option{-mcpu}
+Feature Modifiers}.  Where conflicting feature modifiers are
+specified, the right-most feature is used.
+
+Additionally on native AArch64 GNU/Linux systems the value
+@samp{native} is available.  This option causes the compiler to tune
+the performance of the code for the processor of the host system.
+This option has no effect if the compiler is unable to recognize the
+architecture of the host system.
+
+GCC uses @var{name} to determine what kind of instructions it can emit when
 generating assembly code (as if by @option{-march}) and to determine
 the target processor for which to tune for performance (as if
 by @option{-mtune}).  Where this option is used in conjunction
 with @option{-march} or @option{-mtune}, those options take precedence
 over the appropriate part of this option.
+
+@item -moverride=@var{string}
+@opindex moverride
+Override tuning decisions made by the back-end in response to a
+@option{-mtune=} switch.  The syntax, semantics, and accepted values
+for @var{string} in this option are not guaranteed to be consistent
+across releases.
+
+This option is only intended to be useful when developing GCC.
+
+@item -mpc-relative-literal-loads
+@opindex mpcrelativeliteralloads
+Enable PC relative literal loads. If this option is used, literal
+pools are assumed to have a range of up to 1MiB and an appropriate
+instruction sequence is used. This option has no impact when used
+with @option{-mcmodel=tiny}.
+
 @end table
 
 @subsubsection @option{-march} and @option{-mcpu} Feature Modifiers
+@anchor{aarch64-feature-modifiers}
 @cindex @option{-march} feature modifiers
 @cindex @option{-mcpu} feature modifiers
-Feature modifiers used with @option{-march} and @option{-mcpu} can be one
-the following:
+Feature modifiers used with @option{-march} and @option{-mcpu} can be any of
+the following and their inverses @option{no@var{feature}}:
 
 @table @samp
 @item crc
-Enable CRC extension.
+Enable CRC extension.  This is on by default for
+@option{-march=armv8.1-a}.
 @item crypto
-Enable Crypto extension.  This implies Advanced SIMD is enabled.
+Enable Crypto extension.  This also enables Advanced SIMD and floating-point
+instructions.
 @item fp
-Enable floating-point instructions.
+Enable floating-point instructions.  This is on by default for all possible
+values for options @option{-march} and @option{-mcpu}.
 @item simd
-Enable Advanced SIMD instructions.  This implies floating-point instructions
-are enabled.  This is the default for all current possible values for options
-@option{-march} and @option{-mcpu=}.
+Enable Advanced SIMD instructions.  This also enables floating-point
+instructions.  This is on by default for all possible values for options
+@option{-march} and @option{-mcpu}.
+@item lse
+Enable Large System Extension instructions.  This is on by default for
+@option{-march=armv8.1-a}.
+
 @end table
 
+That is, @option{crypto} implies @option{simd} implies @option{fp}.
+Conversely, @option{nofp} (or equivalently, @option{-mgeneral-regs-only})
+implies @option{nosimd} implies @option{nocrypto}.
+
 @node Adapteva Epiphany Options
 @subsection Adapteva Epiphany Options
 
@@ -13173,10 +13230,10 @@ of the @option{-mcpu=} option.  Permissible names are: @samp{armv2},
 @samp{armv2a}, @samp{armv3}, @samp{armv3m}, @samp{armv4}, @samp{armv4t},
 @samp{armv5}, @samp{armv5t}, @samp{armv5e}, @samp{armv5te},
 @samp{armv6}, @samp{armv6j},
-@samp{armv6t2}, @samp{armv6z}, @samp{armv6zk}, @samp{armv6-m},
+@samp{armv6t2}, @samp{armv6z}, @samp{armv6kz}, @samp{armv6-m},
 @samp{armv7}, @samp{armv7-a}, @samp{armv7-r}, @samp{armv7-m}, @samp{armv7e-m},
-@samp{armv7ve}, @samp{armv8-a}, @samp{armv8-a+crc},
-@samp{iwmmxt}, @samp{iwmmxt2}, @samp{ep9312}.
+@samp{armv7ve}, @samp{armv8-a}, @samp{armv8-a+crc}, @samp{armv8.1-a},
+@samp{armv8.1-a+crc}, @samp{iwmmxt}, @samp{iwmmxt2}, @samp{ep9312}.
 
 @option{-march=armv7ve} is the armv7-a architecture with virtualization
 extensions.
@@ -13212,9 +13269,9 @@ Permissible names are: @samp{arm2}, @samp{arm250},
 @samp{arm10e}, @samp{arm1020e}, @samp{arm1022e},
 @samp{arm1136j-s}, @samp{arm1136jf-s}, @samp{mpcore}, @samp{mpcorenovfp},
 @samp{arm1156t2-s}, @samp{arm1156t2f-s}, @samp{arm1176jz-s}, @samp{arm1176jzf-s},
-@samp{cortex-a5}, @samp{cortex-a7}, @samp{cortex-a8}, @samp{cortex-a9},
-@samp{cortex-a12}, @samp{cortex-a15}, @samp{cortex-a53},
-@samp{cortex-a57}, @samp{cortex-a72},
+@samp{generic-armv7-a}, @samp{cortex-a5}, @samp{cortex-a7}, @samp{cortex-a8},
+@samp{cortex-a9}, @samp{cortex-a12}, @samp{cortex-a15}, @samp{cortex-a17},
+@samp{cortex-a53}, @samp{cortex-a57}, @samp{cortex-a72},
 @samp{cortex-r4},
 @samp{cortex-r4f}, @samp{cortex-r5}, @samp{cortex-r7}, @samp{cortex-m7},
 @samp{cortex-m4},
@@ -13226,6 +13283,7 @@ Permissible names are: @samp{arm2}, @samp{arm250},
 @samp{cortex-m0.small-multiply},
 @samp{cortex-m0plus.small-multiply},
 @samp{exynos-m1},
+@samp{qdf24xx},
 @samp{marvell-pj4},
 @samp{xscale}, @samp{iwmmxt}, @samp{iwmmxt2}, @samp{ep9312},
 @samp{fa526}, @samp{fa626},
@@ -13234,8 +13292,8 @@ Permissible names are: @samp{arm2}, @samp{arm250},
 
 Additionally, this option can specify that GCC should tune the performance
 of the code for a big.LITTLE system.  Permissible names are:
-@samp{cortex-a15.cortex-a7}, @samp{cortex-a57.cortex-a53},
-@samp{cortex-a72.cortex-a53}.
+@samp{cortex-a15.cortex-a7}, @samp{cortex-a17.cortex-a7},
+@samp{cortex-a57.cortex-a53}, @samp{cortex-a72.cortex-a53}.
 
 @option{-mtune=generic-@var{arch}} specifies that GCC should tune the
 performance for a blend of processors within architecture @var{arch}.
@@ -13278,7 +13336,7 @@ available on the target.  Permissible names are: @samp{vfp}, @samp{vfpv3},
 @samp{vfpv3xd-fp16}, @samp{neon}, @samp{neon-fp16}, @samp{vfpv4},
 @samp{vfpv4-d16}, @samp{fpv4-sp-d16}, @samp{neon-vfpv4},
 @samp{fpv5-d16}, @samp{fpv5-sp-d16},
-@samp{fp-armv8}, @samp{neon-fp-armv8}, and @samp{crypto-neon-fp-armv8}.
+@samp{fp-armv8}, @samp{neon-fp-armv8} and @samp{crypto-neon-fp-armv8}.
 
 If @option{-msoft-float} is specified this specifies the format of
 floating-point values.
@@ -13401,6 +13459,10 @@ that executes in ARM state, but the default can be changed by
 configuring GCC with the @option{--with-mode=}@var{state}
 configure option.
 
+You can also override the ARM and Thumb mode for each function
+by using the @code{target("thumb")} and @code{target("arm")} function attributes
+(@pxref{ARM Function Attributes}) or pragmas (@pxref{Function Specific Option Pragmas}).
+
 @item -mtpcs-frame
 @opindex mtpcs-frame
 Generate a stack frame that is compliant with the Thumb Procedure Call
@@ -13498,10 +13560,9 @@ off by default.
 @item -masm-syntax-unified
 @opindex masm-syntax-unified
 Assume inline assembler is using unified asm syntax.  The default is
-currently off which implies divided syntax.  Currently this option is
-available only for Thumb1 and has no effect on ARM state and Thumb2.
-However, this may change in future releases of GCC.  Divided syntax
-should be considered deprecated.
+currently off which implies divided syntax.  This option has no impact
+on Thumb2. However, this may change in future releases of GCC.
+Divided syntax should be considered deprecated.
 
 @item -mrestrict-it
 @opindex mrestrict-it
@@ -15329,13 +15390,19 @@ These @samp{-m} options are defined for GNU/Linux targets:
 @item -mglibc
 @opindex mglibc
 Use the GNU C library.  This is the default except
-on @samp{*-*-linux-*uclibc*} and @samp{*-*-linux-*android*} targets.
+on @samp{*-*-linux-*uclibc*}, @samp{*-*-linux-*musl*} and
+@samp{*-*-linux-*android*} targets.
 
 @item -muclibc
 @opindex muclibc
 Use uClibc C library.  This is the default on
 @samp{*-*-linux-*uclibc*} targets.
 
+@item -mmusl
+@opindex mmusl
+Use the musl C library.  This is the default on
+@samp{*-*-linux-*musl*} targets.
+
 @item -mbionic
 @opindex mbionic
 Use Bionic C library.  This is the default on
@@ -23596,7 +23663,7 @@ loader is not part of GCC; it is part of the operating system).  If
 the GOT size for the linked executable exceeds a machine-specific
 maximum size, you get an error message from the linker indicating that
 @option{-fpic} does not work; in that case, recompile with @option{-fPIC}
-instead.  (These maximums are 8k on the SPARC and 32k
+instead.  (These maximums are 8k on the SPARC, 28k on AArch64 and 32k
 on the m68k and RS/6000.  The x86 has no such limit.)
 
 Position-independent code requires special support, and therefore works
@@ -23611,7 +23678,7 @@ are defined to 1.
 @opindex fPIC
 If supported for the target machine, emit position-independent code,
 suitable for dynamic linking and avoiding any limit on the size of the
-global offset table.  This option makes a difference on the m68k,
+global offset table.  This option makes a difference on AArch64, m68k,
 PowerPC and SPARC@.
 
 Position-independent code requires special support, and therefore works
@@ -23633,6 +23700,24 @@ used during linking.
 @code{__pie__} and @code{__PIE__}.  The macros have the value 1
 for @option{-fpie} and 2 for @option{-fPIE}.
 
+@item -fno-plt
+@opindex fno-plt
+Do not use PLT for external function calls in position-independent code.
+Instead, load callee address at call site from GOT and branch to it.
+This leads to more efficient code by eliminating PLT stubs and exposing
+GOT load to optimizations.  On architectures such as 32-bit x86 where
+PLT stubs expect GOT pointer in a specific register, this gives more
+register allocation freedom to the compiler.  Lazy binding requires PLT:
+with @option{-fno-plt} all external symbols are resolved at load time.
+
+Alternatively, function attribute @code{noplt} can be used to avoid PLT
+for calls to specific external functions by marking those functions with
+this attribute.
+
+Additionally, a few targets also convert calls to those functions that are
+marked to not use the PLT to use the GOT instead for non-position independent
+code.
+
 @item -fno-jump-tables
 @opindex fno-jump-tables
 Do not use jump tables for switch statements even where it would be
--- a/src/gcc/doc/lto.texi
+++ b/src/gcc/doc/lto.texi
@@ -538,10 +538,6 @@ plugin obtains the symbol resolution information which specifies
 which symbols provided by the claimed objects are bound from the
 rest of a binary being linked.
 
-Currently, the linker plugin  works only in combination
-with the Gold linker, but a GNU ld implementation is under
-development.
-
 GCC is designed to be independent of the rest of the toolchain
 and aims to support linkers without plugin support.  For this
 reason it does not use the linker plugin by default.  Instead,
--- a/src/gcc/doc/match-and-simplify.texi
+++ b/src/gcc/doc/match-and-simplify.texi
@@ -39,7 +39,7 @@ APIs are introduced.
 @deftypefnx {GIMPLE function} tree gimple_simplify (enum tree_code, tree, tree, tree, tree, gimple_seq *, tree (*)(tree))
 @deftypefnx {GIMPLE function} tree gimple_simplify (enum built_in_function, tree, tree, gimple_seq *, tree (*)(tree))
 @deftypefnx {GIMPLE function} tree gimple_simplify (enum built_in_function, tree, tree, tree, gimple_seq *, tree (*)(tree))
-@deftypefnx {GIMPLE function} tree gimple_simplify (enum built_in_function, tree, tree, tree, gimple_seq *, tree (*)(tree))
+@deftypefnx {GIMPLE function} tree gimple_simplify (enum built_in_function, tree, tree, tree, tree, gimple_seq *, tree (*)(tree))
 The main GIMPLE API entry to the expression simplifications mimicing
 that of the GENERIC fold_@{unary,binary,ternary@} functions.
 @end deftypefn
@@ -64,6 +64,7 @@ Ontop of these a @code{fold_buildN}-like API for GIMPLE is introduced:
 @deftypefnx {GIMPLE function} tree gimple_build (gimple_seq *, location_t, enum tree_code, tree, tree, tree, tree, tree (*valueize) (tree) = NULL);
 @deftypefnx {GIMPLE function} tree gimple_build (gimple_seq *, location_t, enum built_in_function, tree, tree, tree (*valueize) (tree) = NULL);
 @deftypefnx {GIMPLE function} tree gimple_build (gimple_seq *, location_t, enum built_in_function, tree, tree, tree, tree (*valueize) (tree) = NULL);
+@deftypefnx {GIMPLE function} tree gimple_build (gimple_seq *, location_t, enum built_in_function, tree, tree, tree, tree, tree (*valueize) (tree) = NULL);
 @deftypefnx {GIMPLE function} tree gimple_convert (gimple_seq *, location_t, tree, tree);
 @end deftypefn
 
--- a/src/gcc/doc/md.texi
+++ b/src/gcc/doc/md.texi
@@ -4911,10 +4911,10 @@ is of a wider mode, is computed and added to operand 3. Operand 3 is of a mode
 equal or wider than the mode of the absolute difference. The result is placed
 in operand 0, which is of the same mode as operand 3.
 
-@cindex @code{ssum_widen@var{m3}} instruction pattern
-@item @samp{ssum_widen@var{m3}}
-@cindex @code{usum_widen@var{m3}} instruction pattern
-@itemx @samp{usum_widen@var{m3}}
+@cindex @code{widen_ssum@var{m3}} instruction pattern
+@item @samp{widen_ssum@var{m3}}
+@cindex @code{widen_usum@var{m3}} instruction pattern
+@itemx @samp{widen_usum@var{m3}}
 Operands 0 and 2 are of the same mode, which is wider than the mode of
 operand 1. Add operand 1 to operand 2 and place the widened result in
 operand 0. (This is used express accumulation of elements into an accumulator
--- a/src/gcc/doc/sourcebuild.texi
+++ b/src/gcc/doc/sourcebuild.texi
@@ -1549,7 +1549,12 @@ options.  Some multilibs may be incompatible with these options.
 @item arm_neon_fp16_ok
 @anchor{arm_neon_fp16_ok}
 ARM Target supports @code{-mfpu=neon-fp16 -mfloat-abi=softfp} or compatible
-options.  Some multilibs may be incompatible with these options.
+options, including @code{-mfp16-format=ieee} if necessary to obtain the
+@code{__fp16} type.  Some multilibs may be incompatible with these options.
+
+@item arm_neon_fp16_hw
+Test system supports executing Neon half-precision float instructions.
+(Implies previous.)
 
 @item arm_thumb1_ok
 ARM target generates Thumb-1 code for @code{-mthumb}.
@@ -1574,12 +1579,40 @@ Some multilibs may be incompatible with these options.
 ARM target supports @code{-mfpu=neon-fp-armv8 -mfloat-abi=softfp}.
 Some multilibs may be incompatible with these options.
 
+@item arm_v8_1a_neon_ok
+ARM target supports options to generate ARMv8.1 Adv.SIMD instructions.
+Some multilibs may be incompatible with these options.
+
+@item arm_v8_1a_neon_hw
+ARM target supports executing ARMv8.1 Adv.SIMD instructions.  Some
+multilibs may be incompatible with the options needed.  Implies
+arm_v8_1a_neon_ok.
+
 @item arm_prefer_ldrd_strd
 ARM target prefers @code{LDRD} and @code{STRD} instructions over
 @code{LDM} and @code{STM} instructions.
 
 @end table
 
+@subsubsection AArch64-specific attributes
+
+@table @code
+@item aarch64_tiny
+AArch64 target which generates instruction sequences for tiny memory model.
+@item aarch64_small
+AArch64 target which generates instruction sequences for small memory model.
+@item aarch64_large
+AArch64 target which generates instruction sequences for large memory model.
+@item aarch64_little_endian
+AArch64 target which generates instruction sequences for little endian.
+@item aarch64_big_endian
+AArch64 target which generates instruction sequences for big endian.
+@item aarch64_small_fpic
+Binutils installed on test system supports relocation types required by -fpic
+for AArch64 small memory model.
+
+@end table
+
 @subsubsection MIPS-specific attributes
 
 @table @code
@@ -1695,6 +1728,9 @@ Target supports FPU instructions.
 @item non_strict_align
 Target does not require strict alignment.
 
+@item sqrt_insn
+Target has a square root instruction that the compiler can generate.
+
 @item sse
 Target supports compiling @code{sse} instructions.
 
@@ -2013,7 +2049,7 @@ keyword}.
 @item arm_neon_fp16
 NEON and half-precision floating point support.  Only ARM targets
 support this feature, and only then in certain modes; see
-the @ref{arm_neon_ok,,arm_neon_fp16_ok effective target keyword}.
+the @ref{arm_neon_fp16_ok,,arm_neon_fp16_ok effective target keyword}.
 
 @item arm_vfp3
 arm vfp3 floating point support; see
@@ -2210,13 +2246,17 @@ Check branch and/or call counts, in addition to line counts, in
 
 @subsubsection Clean up generated test files
 
+Usually the test-framework removes files that were generated during
+testing. If a testcase, for example, uses any dumping mechanism to
+inspect a passes dump file, the testsuite recognized the dump option
+passed to the tool and schedules a final cleanup to remove these files.
+
+There are, however, following additional cleanup directives that can be
+used to annotate a testcase "manually".
 @table @code
 @item cleanup-coverage-files
 Removes coverage data files generated for this test.
 
-@item cleanup-ipa-dump @var{suffix}
-Removes IPA dump files generated for this test.
-
 @item cleanup-modules "@var{list-of-extra-modules}"
 Removes Fortran module files generated for this test, excluding the
 module names listed in keep-modules.
@@ -2251,21 +2291,23 @@ end module keep2
 ! @{ dg-final @{ keep-modules "" @} @} ! keep all
 @end smallexample
 
+@item dg-keep-saved-temps "@var{list-of-suffixes-not-to-delete}"
+Whitespace separated list of suffixes that should not be deleted
+automatically in a testcase that uses @option{-save-temps}.
+@smallexample
+// @{ dg-options "-save-temps -fpch-preprocess -I." @}
+int main() @{ return 0; @}
+// @{ dg-keep-saved-temps ".s" @} ! just keep assembler file
+// @{ dg-keep-saved-temps ".s" ".i" @} ! ... and .i
+// @{ dg-keep-saved-temps ".ii" ".o" @} ! or just .ii and .o
+@end smallexample
+
 @item cleanup-profile-file
 Removes profiling files generated for this test.
 
 @item cleanup-repo-files
 Removes files generated for this test for @option{-frepo}.
 
-@item cleanup-rtl-dump @var{suffix}
-Removes RTL dump files generated for this test.
-
-@item cleanup-saved-temps
-Removes files for the current test which were kept for @option{-save-temps}.
-
-@item cleanup-tree-dump @var{suffix}
-Removes tree dump files matching @var{suffix} which were generated for
-this test.
 @end table
 
 @node Ada Tests
--- a/src/gcc/doc/tm.texi
+++ b/src/gcc/doc/tm.texi
@@ -9800,7 +9800,7 @@ be documented in @file{extend.texi}.
 
 @deftypevr {Target Hook} {const struct attribute_spec *} TARGET_ATTRIBUTE_TABLE
 If defined, this target hook points to an array of @samp{struct
-attribute_spec} (defined in @file{tree.h}) specifying the machine
+attribute_spec} (defined in @file{tree-core.h}) specifying the machine
 specific attributes for this target and some of the restrictions on the
 entities to which these attributes are applied and the arguments they
 take.