GCC 4.2.0 release.

1 files changed, 3114 insertions, 1262 deletions

diff --git a/contrib/gcc/doc/extend.texi b/contrib/gcc/doc/extend.texi
index 4638645..0ba7c29 100644
--- a/contrib/gcc/doc/extend.texi
+++ b/contrib/gcc/doc/extend.texi
@@ -1,408 +1,9 @@
-@c Copyright (C) 1988,1989,1992,1993,1994,1996,1998,1999,2000,2001,2002,2003,2004
-@c Free Software Foundation, Inc.
+@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1996, 1998, 1999, 2000,
+@c 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
+
 @c This is part of the GCC manual.
 @c For copying conditions, see the file gcc.texi.
 
-@node C Implementation
-@chapter C Implementation-defined behavior
-@cindex implementation-defined behavior, C language
-
-A conforming implementation of ISO C is required to document its
-choice of behavior in each of the areas that are designated
-``implementation defined.''  The following lists all such areas,
-along with the section number from the ISO/IEC 9899:1999 standard.
-
-@menu
-* Translation implementation::
-* Environment implementation::
-* Identifiers implementation::
-* Characters implementation::
-* Integers implementation::
-* Floating point implementation::
-* Arrays and pointers implementation::
-* Hints implementation::
-* Structures unions enumerations and bit-fields implementation::
-* Qualifiers implementation::
-* Preprocessing directives implementation::
-* Library functions implementation::
-* Architecture implementation::
-* Locale-specific behavior implementation::
-@end menu
-
-@node Translation implementation
-@section Translation
-
-@itemize @bullet
-@item
-@cite{How a diagnostic is identified (3.10, 5.1.1.3).}
-
-Diagnostics consist of all the output sent to stderr by GCC.
-
-@item
-@cite{Whether each nonempty sequence of white-space characters other than
-new-line is retained or replaced by one space character in translation
-phase 3 (5.1.1.2).}
-@end itemize
-
-@node Environment implementation
-@section Environment
-
-The behavior of these points are dependent on the implementation
-of the C library, and are not defined by GCC itself.
-
-@node Identifiers implementation
-@section Identifiers
-
-@itemize @bullet
-@item
-@cite{Which additional multibyte characters may appear in identifiers
-and their correspondence to universal character names (6.4.2).}
-
-@item
-@cite{The number of significant initial characters in an identifier
-(5.2.4.1, 6.4.2).}
-
-For internal names, all characters are significant.  For external names,
-the number of significant characters are defined by the linker; for
-almost all targets, all characters are significant.
-
-@end itemize
-
-@node Characters implementation
-@section Characters
-
-@itemize @bullet
-@item
-@cite{The number of bits in a byte (3.6).}
-
-@item
-@cite{The values of the members of the execution character set (5.2.1).}
-
-@item
-@cite{The unique value of the member of the execution character set produced
-for each of the standard alphabetic escape sequences (5.2.2).}
-
-@item
-@cite{The value of a @code{char} object into which has been stored any
-character other than a member of the basic execution character set (6.2.5).}
-
-@item
-@cite{Which of @code{signed char} or @code{unsigned char} has the same range,
-representation, and behavior as ``plain'' @code{char} (6.2.5, 6.3.1.1).}
-
-@item
-@cite{The mapping of members of the source character set (in character
-constants and string literals) to members of the execution character
-set (6.4.4.4, 5.1.1.2).}
-
-@item
-@cite{The value of an integer character constant containing more than one
-character or containing a character or escape sequence that does not map
-to a single-byte execution character (6.4.4.4).}
-
-@item
-@cite{The value of a wide character constant containing more than one
-multibyte character, or containing a multibyte character or escape
-sequence not represented in the extended execution character set (6.4.4.4).}
-
-@item
-@cite{The current locale used to convert a wide character constant consisting
-of a single multibyte character that maps to a member of the extended
-execution character set into a corresponding wide character code (6.4.4.4).}
-
-@item
-@cite{The current locale used to convert a wide string literal into
-corresponding wide character codes (6.4.5).}
-
-@item
-@cite{The value of a string literal containing a multibyte character or escape
-sequence not represented in the execution character set (6.4.5).}
-@end itemize
-
-@node Integers implementation
-@section Integers
-
-@itemize @bullet
-@item
-@cite{Any extended integer types that exist in the implementation (6.2.5).}
-
-@item
-@cite{Whether signed integer types are represented using sign and magnitude,
-two's complement, or one's complement, and whether the extraordinary value
-is a trap representation or an ordinary value (6.2.6.2).}
-
-GCC supports only two's complement integer types, and all bit patterns
-are ordinary values.
-
-@item
-@cite{The rank of any extended integer type relative to another extended
-integer type with the same precision (6.3.1.1).}
-
-@item
-@cite{The result of, or the signal raised by, converting an integer to a
-signed integer type when the value cannot be represented in an object of
-that type (6.3.1.3).}
-
-@item
-@cite{The results of some bitwise operations on signed integers (6.5).}
-@end itemize
-
-@node Floating point implementation
-@section Floating point
-
-@itemize @bullet
-@item
-@cite{The accuracy of the floating-point operations and of the library
-functions in @code{<math.h>} and @code{<complex.h>} that return floating-point
-results (5.2.4.2.2).}
-
-@item
-@cite{The rounding behaviors characterized by non-standard values
-of @code{FLT_ROUNDS} @gol
-(5.2.4.2.2).}
-
-@item
-@cite{The evaluation methods characterized by non-standard negative
-values of @code{FLT_EVAL_METHOD} (5.2.4.2.2).}
-
-@item
-@cite{The direction of rounding when an integer is converted to a
-floating-point number that cannot exactly represent the original
-value (6.3.1.4).}
-
-@item
-@cite{The direction of rounding when a floating-point number is
-converted to a narrower floating-point number (6.3.1.5).}
-
-@item
-@cite{How the nearest representable value or the larger or smaller
-representable value immediately adjacent to the nearest representable
-value is chosen for certain floating constants (6.4.4.2).}
-
-@item
-@cite{Whether and how floating expressions are contracted when not
-disallowed by the @code{FP_CONTRACT} pragma (6.5).}
-
-@item
-@cite{The default state for the @code{FENV_ACCESS} pragma (7.6.1).}
-
-@item
-@cite{Additional floating-point exceptions, rounding modes, environments,
-and classifications, and their macro names (7.6, 7.12).}
-
-@item
-@cite{The default state for the @code{FP_CONTRACT} pragma (7.12.2).}
-
-@item
-@cite{Whether the ``inexact'' floating-point exception can be raised
-when the rounded result actually does equal the mathematical result
-in an IEC 60559 conformant implementation (F.9).}
-
-@item
-@cite{Whether the ``underflow'' (and ``inexact'') floating-point
-exception can be raised when a result is tiny but not inexact in an
-IEC 60559 conformant implementation (F.9).}
-
-@end itemize
-
-@node Arrays and pointers implementation
-@section Arrays and pointers
-
-@itemize @bullet
-@item
-@cite{The result of converting a pointer to an integer or
-vice versa (6.3.2.3).}
-
-A cast from pointer to integer discards most-significant bits if the
-pointer representation is larger than the integer type,
-sign-extends@footnote{Future versions of GCC may zero-extend, or use
-a target-defined @code{ptr_extend} pattern.  Do not rely on sign extension.}
-if the pointer representation is smaller than the integer type, otherwise
-the bits are unchanged.
-@c ??? We've always claimed that pointers were unsigned entities.
-@c Shouldn't we therefore be doing zero-extension?  If so, the bug
-@c is in convert_to_integer, where we call type_for_size and request
-@c a signed integral type.  On the other hand, it might be most useful
-@c for the target if we extend according to POINTERS_EXTEND_UNSIGNED.
-
-A cast from integer to pointer discards most-significant bits if the
-pointer representation is smaller than the integer type, extends according
-to the signedness of the integer type if the pointer representation
-is larger than the integer type, otherwise the bits are unchanged.
-
-When casting from pointer to integer and back again, the resulting
-pointer must reference the same object as the original pointer, otherwise
-the behavior is undefined.  That is, one may not use integer arithmetic to
-avoid the undefined behavior of pointer arithmetic as proscribed in 6.5.6/8.
-
-@item
-@cite{The size of the result of subtracting two pointers to elements
-of the same array (6.5.6).}
-
-@end itemize
-
-@node Hints implementation
-@section Hints
-
-@itemize @bullet
-@item
-@cite{The extent to which suggestions made by using the @code{register}
-storage-class specifier are effective (6.7.1).}
-
-The @code{register} specifier affects code generation only in these ways:
-
-@itemize @bullet
-@item
-When used as part of the register variable extension, see
-@ref{Explicit Reg Vars}.
-
-@item
-When @option{-O0} is in use, the compiler allocates distinct stack
-memory for all variables that do not have the @code{register}
-storage-class specifier; if @code{register} is specified, the variable
-may have a shorter lifespan than the code would indicate and may never
-be placed in memory.
-
-@item
-On some rare x86 targets, @code{setjmp} doesn't save the registers in
-all circumstances.  In those cases, GCC doesn't allocate any variables
-in registers unless they are marked @code{register}.
-
-@end itemize
-
-@item
-@cite{The extent to which suggestions made by using the inline function
-specifier are effective (6.7.4).}
-
-GCC will not inline any functions if the @option{-fno-inline} option is
-used or if @option{-O0} is used.  Otherwise, GCC may still be unable to
-inline a function for many reasons; the @option{-Winline} option may be
-used to determine if a function has not been inlined and why not.
-
-@end itemize
-
-@node Structures unions enumerations and bit-fields implementation
-@section Structures, unions, enumerations, and bit-fields
-
-@itemize @bullet
-@item
-@cite{Whether a ``plain'' int bit-field is treated as a @code{signed int}
-bit-field or as an @code{unsigned int} bit-field (6.7.2, 6.7.2.1).}
-
-@item
-@cite{Allowable bit-field types other than @code{_Bool}, @code{signed int},
-and @code{unsigned int} (6.7.2.1).}
-
-@item
-@cite{Whether a bit-field can straddle a storage-unit boundary (6.7.2.1).}
-
-@item
-@cite{The order of allocation of bit-fields within a unit (6.7.2.1).}
-
-@item
-@cite{The alignment of non-bit-field members of structures (6.7.2.1).}
-
-@item
-@cite{The integer type compatible with each enumerated type (6.7.2.2).}
-
-@end itemize
-
-@node Qualifiers implementation
-@section Qualifiers
-
-@itemize @bullet
-@item
-@cite{What constitutes an access to an object that has volatile-qualified
-type (6.7.3).}
-
-@end itemize
-
-@node Preprocessing directives implementation
-@section Preprocessing directives
-
-@itemize @bullet
-@item
-@cite{How sequences in both forms of header names are mapped to headers
-or external source file names (6.4.7).}
-
-@item
-@cite{Whether the value of a character constant in a constant expression
-that controls conditional inclusion matches the value of the same character
-constant in the execution character set (6.10.1).}
-
-@item
-@cite{Whether the value of a single-character character constant in a
-constant expression that controls conditional inclusion may have a
-negative value (6.10.1).}
-
-@item
-@cite{The places that are searched for an included @samp{<>} delimited
-header, and how the places are specified or the header is
-identified (6.10.2).}
-
-@item
-@cite{How the named source file is searched for in an included @samp{""}
-delimited header (6.10.2).}
-
-@item
-@cite{The method by which preprocessing tokens (possibly resulting from
-macro expansion) in a @code{#include} directive are combined into a header
-name (6.10.2).}
-
-@item
-@cite{The nesting limit for @code{#include} processing (6.10.2).}
-
-GCC imposes a limit of 200 nested @code{#include}s.
-
-@item
-@cite{Whether the @samp{#} operator inserts a @samp{\} character before
-the @samp{\} character that begins a universal character name in a
-character constant or string literal (6.10.3.2).}
-
-@item
-@cite{The behavior on each recognized non-@code{STDC #pragma}
-directive (6.10.6).}
-
-@item
-@cite{The definitions for @code{__DATE__} and @code{__TIME__} when
-respectively, the date and time of translation are not available (6.10.8).}
-
-If the date and time are not available, @code{__DATE__} expands to
-@code{@w{"??? ?? ????"}} and @code{__TIME__} expands to
-@code{"??:??:??"}.
-
-@end itemize
-
-@node Library functions implementation
-@section Library functions
-
-The behavior of these points are dependent on the implementation
-of the C library, and are not defined by GCC itself.
-
-@node Architecture implementation
-@section Architecture
-
-@itemize @bullet
-@item
-@cite{The values or expressions assigned to the macros specified in the
-headers @code{<float.h>}, @code{<limits.h>}, and @code{<stdint.h>}
-(5.2.4.2, 7.18.2, 7.18.3).}
-
-@item
-@cite{The number, order, and encoding of bytes in any object
-(when not explicitly specified in this International Standard) (6.2.6.1).}
-
-@item
-@cite{The value of the result of the sizeof operator (6.5.3.4).}
-
-@end itemize
-
-@node Locale-specific behavior implementation
-@section Locale-specific behavior
-
-The behavior of these points are dependent on the implementation
-of the C library, and are not defined by GCC itself.
-
 @node C Extensions
 @chapter Extensions to the C Language Family
 @cindex extensions, C language
@@ -429,10 +30,10 @@ extensions, accepted by GCC in C89 mode and in C++.
 * Nested Functions::    As in Algol and Pascal, lexical scoping of functions.
 * Constructing Calls::	Dispatching a call to another function.
 * Typeof::              @code{typeof}: referring to the type of an expression.
-* Lvalues::             Using @samp{?:}, @samp{,} and casts in lvalues.
 * Conditionals::        Omitting the middle operand of a @samp{?:} expression.
 * Long Long::		Double-word integers---@code{long long int}.
 * Complex::             Data types for complex numbers.
+* Decimal Float::       Decimal Floating Types. 
 * Hex Floats::          Hexadecimal floating-point constants.
 * Zero Length::         Zero-length arrays.
 * Variable Length::     Arrays whose length is computed at run time.
@@ -470,8 +71,13 @@ extensions, accepted by GCC in C89 mode and in C++.
 			 function.
 * Return Address::      Getting the return or frame address of a function.
 * Vector Extensions::   Using vector instructions through built-in functions.
+* Offsetof::            Special syntax for implementing @code{offsetof}.
+* Atomic Builtins::	Built-in functions for atomic memory access.
+* Object Size Checking:: Built-in functions for limited buffer overflow
+                        checking.
 * Other Builtins::      Other built-in functions.
 * Target Builtins::     Built-in functions specific to particular targets.
+* Target Format Checks:: Format checks specific to particular targets.
 * Pragmas::             Pragmas accepted by GCC.
 * Unnamed Fields::      Unnamed struct/union fields within structs/unions.
 * Thread-Local::        Per-thread variables.
@@ -541,7 +147,7 @@ must use @code{typeof} (@pxref{Typeof}).
 
 In G++, the result value of a statement expression undergoes array and
 function pointer decay, and is returned by value to the enclosing
-expression. For instance, if @code{A} is a class, then
+expression.  For instance, if @code{A} is a class, then
 
 @smallexample
         A a;
@@ -586,13 +192,36 @@ work with C++.  (Note that some versions of the GNU C Library contained
 header files using statement-expression that lead to precisely this
 bug.)
 
+Jumping into a statement expression with @code{goto} or using a
+@code{switch} statement outside the statement expression with a
+@code{case} or @code{default} label inside the statement expression is
+not permitted.  Jumping into a statement expression with a computed
+@code{goto} (@pxref{Labels as Values}) yields undefined behavior.
+Jumping out of a statement expression is permitted, but if the
+statement expression is part of a larger expression then it is
+unspecified which other subexpressions of that expression have been
+evaluated except where the language definition requires certain
+subexpressions to be evaluated before or after the statement
+expression.  In any case, as with a function call the evaluation of a
+statement expression is not interleaved with the evaluation of other
+parts of the containing expression.  For example,
+
+@smallexample
+  foo (), ((@{ bar1 (); goto a; 0; @}) + bar2 ()), baz();
+@end smallexample
+
+@noindent
+will call @code{foo} and @code{bar1} and will not call @code{baz} but
+may or may not call @code{bar2}.  If @code{bar2} is called, it will be
+called after @code{foo} and before @code{bar1}
+
 @node Local Labels
 @section Locally Declared Labels
 @cindex local labels
 @cindex macros, local labels
 
 GCC allows you to declare @dfn{local labels} in any nested block
-scope. A local label is just like an ordinary label, but you can
+scope.  A local label is just like an ordinary label, but you can
 only reference it (with a @code{goto} statement, or by taking its
 address) within the block in which it was declared.
 
@@ -780,8 +409,8 @@ bar (int *array, int offset, int size)
 @end smallexample
 
 Nested function definitions are permitted within functions in the places
-where variable definitions are allowed; that is, in any block, before
-the first statement in the block.
+where variable definitions are allowed; that is, in any block, mixed
+with the other declarations and statements in the block.
 
 It is possible to call the nested function from outside the scope of its
 name by storing its address or passing the address to another function:
@@ -848,8 +477,8 @@ bar (int *array, int offset, int size)
 @end group
 @end smallexample
 
-A nested function always has internal linkage.  Declaring one with
-@code{extern} is erroneous.  If you need to declare the nested function
+A nested function always has no linkage.  Declaring one with
+@code{extern} or @code{static} is erroneous.  If you need to declare the nested function
 before its definition, use @code{auto} (which is otherwise meaningless
 for function declarations).
 
@@ -1060,94 +689,6 @@ typedef typeof(@var{expr}) @var{T};
 @noindent
 This will work with all versions of GCC@.
 
-@node Lvalues
-@section Generalized Lvalues
-@cindex compound expressions as lvalues
-@cindex expressions, compound, as lvalues
-@cindex conditional expressions as lvalues
-@cindex expressions, conditional, as lvalues
-@cindex casts as lvalues
-@cindex generalized lvalues
-@cindex lvalues, generalized
-@cindex extensions, @code{?:}
-@cindex @code{?:} extensions
-
-Compound expressions, conditional expressions and casts are allowed as
-lvalues provided their operands are lvalues.  This means that you can take
-their addresses or store values into them.  All these extensions are
-deprecated.
-
-Standard C++ allows compound expressions and conditional expressions
-as lvalues, and permits casts to reference type, so use of this
-extension is not supported for C++ code.
-
-For example, a compound expression can be assigned, provided the last
-expression in the sequence is an lvalue.  These two expressions are
-equivalent:
-
-@smallexample
-(a, b) += 5
-a, (b += 5)
-@end smallexample
-
-Similarly, the address of the compound expression can be taken.  These two
-expressions are equivalent:
-
-@smallexample
-&(a, b)
-a, &b
-@end smallexample
-
-A conditional expression is a valid lvalue if its type is not void and the
-true and false branches are both valid lvalues.  For example, these two
-expressions are equivalent:
-
-@smallexample
-(a ? b : c) = 5
-(a ? b = 5 : (c = 5))
-@end smallexample
-
-A cast is a valid lvalue if its operand is an lvalue.  This extension
-is deprecated.  A simple
-assignment whose left-hand side is a cast works by converting the
-right-hand side first to the specified type, then to the type of the
-inner left-hand side expression.  After this is stored, the value is
-converted back to the specified type to become the value of the
-assignment.  Thus, if @code{a} has type @code{char *}, the following two
-expressions are equivalent:
-
-@smallexample
-(int)a = 5
-(int)(a = (char *)(int)5)
-@end smallexample
-
-An assignment-with-arithmetic operation such as @samp{+=} applied to a cast
-performs the arithmetic using the type resulting from the cast, and then
-continues as in the previous case.  Therefore, these two expressions are
-equivalent:
-
-@smallexample
-(int)a += 5
-(int)(a = (char *)(int) ((int)a + 5))
-@end smallexample
-
-You cannot take the address of an lvalue cast, because the use of its
-address would not work out coherently.  Suppose that @code{&(int)f} were
-permitted, where @code{f} has type @code{float}.  Then the following
-statement would try to store an integer bit-pattern where a floating
-point number belongs:
-
-@smallexample
-*&(int)f = 1;
-@end smallexample
-
-This is quite different from what @code{(int)f = 1} would do---that
-would convert 1 to floating point and store it.  Rather than cause this
-inconsistency, we think it is better to prohibit use of @samp{&} on a cast.
-
-If you really do want an @code{int *} pointer with the address of
-@code{f}, you can simply write @code{(int *)&f}.
-
 @node Conditionals
 @section Conditionals with Omitted Operands
 @cindex conditional expressions, extensions
@@ -1274,6 +815,58 @@ If the variable's actual name is @code{foo}, the two fictitious
 variables are named @code{foo$real} and @code{foo$imag}.  You can
 examine and set these two fictitious variables with your debugger.
 
+@node Decimal Float
+@section Decimal Floating Types
+@cindex decimal floating types
+@cindex @code{_Decimal32} data type
+@cindex @code{_Decimal64} data type
+@cindex @code{_Decimal128} data type
+@cindex @code{df} integer suffix
+@cindex @code{dd} integer suffix
+@cindex @code{dl} integer suffix
+@cindex @code{DF} integer suffix
+@cindex @code{DD} integer suffix
+@cindex @code{DL} integer suffix
+
+As an extension, the GNU C compiler supports decimal floating types as
+defined in the N1176 draft of ISO/IEC WDTR24732.  Support for decimal
+floating types in GCC will evolve as the draft technical report changes.
+Calling conventions for any target might also change.  Not all targets
+support decimal floating types.
+
+The decimal floating types are @code{_Decimal32}, @code{_Decimal64}, and
+@code{_Decimal128}.  They use a radix of ten, unlike the floating types
+@code{float}, @code{double}, and @code{long double} whose radix is not
+specified by the C standard but is usually two.
+
+Support for decimal floating types includes the arithmetic operators
+add, subtract, multiply, divide; unary arithmetic operators;
+relational operators; equality operators; and conversions to and from
+integer and other floating types.  Use a suffix @samp{df} or
+@samp{DF} in a literal constant of type @code{_Decimal32}, @samp{dd}
+or @samp{DD} for @code{_Decimal64}, and @samp{dl} or @samp{DL} for
+@code{_Decimal128}.
+
+GCC support of decimal float as specified by the draft technical report
+is incomplete:
+
+@itemize @bullet
+@item
+Translation time data type (TTDT) is not supported.
+
+@item
+Characteristics of decimal floating types are defined in header file
+@file{decfloat.h} rather than @file{float.h}.
+
+@item
+When the value of a decimal floating type cannot be represented in the
+integer type to which it is being converted, the result is undefined
+rather than the result value specified by the draft technical report.
+@end itemize
+
+Types @code{_Decimal32}, @code{_Decimal64}, and @code{_Decimal128}
+are supported by the DWARF2 debug information format.
+
 @node Hex Floats
 @section Hex Floats
 @cindex hex floats
@@ -1697,7 +1290,7 @@ As a GNU extension, GCC allows initialization of objects with static storage
 duration by compound literals (which is not possible in ISO C99, because
 the initializer is not a constant).
 It is handled as if the object was initialized only with the bracket
-enclosed list if compound literal's and object types match.
+enclosed list if the types of the compound literal and the object match.
 The initializer list of the compound literal must be constant.
 If the object being initialized has array type of unknown size, the size is
 determined by compound literal size.
@@ -1963,6 +1556,7 @@ the enclosing block.
 @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
@@ -1982,12 +1576,13 @@ 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{noreturn}, @code{noinline}, @code{always_inline},
-@code{pure}, @code{const}, @code{nothrow},
+@code{noreturn}, @code{returns_twice}, @code{noinline}, @code{always_inline},
+@code{flatten}, @code{pure}, @code{const}, @code{nothrow}, @code{sentinel},
 @code{format}, @code{format_arg}, @code{no_instrument_function},
 @code{section}, @code{constructor}, @code{destructor}, @code{used},
 @code{unused}, @code{deprecated}, @code{weak}, @code{malloc},
-@code{alias}, @code{warn_unused_result} and @code{nonnull}.  Several other
+@code{alias}, @code{warn_unused_result}, @code{nonnull},
+@code{gnu_inline} and @code{externally_visible}.  Several other
 attributes are defined for functions on particular target systems.  Other
 attributes, including @code{section} are supported for variables declarations
 (@pxref{Variable Attributes}) and for types (@pxref{Type Attributes}).
@@ -2001,95 +1596,91 @@ you may use @code{__noreturn__} instead of @code{noreturn}.
 attributes.
 
 @table @code
-@cindex @code{noreturn} function attribute
-@item noreturn
-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));
-
-void
-fatal (/* @r{@dots{}} */)
-@{
-  /* @r{@dots{}} */ /* @r{Print error message.} */ /* @r{@dots{}} */
-  exit (1);
-@}
-@end group
-@end smallexample
+@c Keep this table alphabetized by attribute name.  Treat _ as space.
 
-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.
-
-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}.
-
-The attribute @code{noreturn} is not implemented in GCC versions
-earlier than 2.5.  An alternative way to declare that a function does
-not return, which works in the current version and in some older
-versions, is as follows:
+@item alias ("@var{target}")
+@cindex @code{alias} attribute
+The @code{alias} attribute causes the declaration to be emitted as an
+alias for another symbol, which must be specified.  For instance,
 
 @smallexample
-typedef void voidfn ();
-
-volatile voidfn fatal;
+void __f () @{ /* @r{Do something.} */; @}
+void f () __attribute__ ((weak, alias ("__f")));
 @end smallexample
 
-This approach does not work in GNU C++.
+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.
 
-@cindex @code{noinline} function attribute
-@item noinline
-This function attribute prevents a function from being considered for
-inlining.
+Not all target machines support this attribute.
 
-@cindex @code{always_inline} function attribute
 @item always_inline
+@cindex @code{always_inline} function attribute
 Generally, functions are not inlined unless optimization is specified.
 For functions declared inline, this attribute inlines the function even
 if no optimization level was specified.
 
-@cindex @code{pure} function attribute
-@item pure
-Many functions have no effects except the return value and their
-return value depends only on the parameters and/or global variables.
-Such a function can be subject
-to common subexpression elimination and loop optimization just as an
-arithmetic operator would be.  These functions should be declared
-with the attribute @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.
+@item gnu_inline
+@cindex @code{gnu_inline} function attribute
+This attribute should be used with a function which is also declared
+with the @code{inline} keyword.  It directs GCC to treat the function
+as if it were defined in gnu89 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 will cause most calls to the
+function to be inlined.  If any uses of the function remain, they will
+refer to the single copy in the library.  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.
+
+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}.
+
+Note that since the first version of GCC to support C99 inline semantics
+is 4.3, earlier versions of GCC which accept this attribute effectively
+assume that it is always present, whether or not it is given explicitly.
+In versions prior to 4.3, the only effect of explicitly including it is
+to disable warnings about using inline functions in C99 mode.
+
+@cindex @code{flatten} function attribute
+@item flatten
+Generally, inlining into a function is limited.  For a function marked with
+this attribute, every call inside this function will be inlined, if possible.
+Whether the function itself is considered for inlining depends on its size and
+the current inlining parameters.  The @code{flatten} attribute only works
+reliably in unit-at-a-time mode.
 
-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 cdecl
+@cindex functions that do pop the argument stack on the 386
+@opindex mrtd
+On the Intel 386, the @code{cdecl} attribute causes the compiler to
+assume that the calling function will pop off the stack space used to
+pass arguments.  This is
+useful to override the effects of the @option{-mrtd} switch.
 
-The attribute @code{pure} is not implemented in GCC versions earlier
-than 2.96.
-@cindex @code{const} function attribute
 @item const
+@cindex @code{const} function attribute
 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 above, since function is not
+more strict class than the @code{pure} attribute below, since function is not
 allowed to read global memory.
 
 @cindex pointer arguments
@@ -2113,14 +1704,164 @@ extern const intfn square;
 This approach does not work in GNU C++ from 2.6.0 on, since the language
 specifies that the @samp{const} must be attached to the return value.
 
-@cindex @code{nothrow} function attribute
-@item nothrow
-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.  The @code{nothrow} attribute is not
-implemented in GCC versions earlier than 3.2.
+@item constructor
+@itemx destructor
+@cindex @code{constructor} function attribute
+@cindex @code{destructor} function attribute
+The @code{constructor} attribute causes the function to be called
+automatically before execution enters @code{main ()}.  Similarly, the
+@code{destructor} attribute causes the function to be called
+automatically after @code{main ()} has completed or @code{exit ()} has
+been called.  Functions with these attributes are useful for
+initializing data that will be used implicitly during the execution of
+the program.
+
+These attributes are not currently implemented for Objective-C@.
+
+@item deprecated
+@cindex @code{deprecated} attribute.
+The @code{deprecated} attribute results in a warning if the function
+is used anywhere in the source file.  This is useful when identifying
+functions that are expected to be removed in a future version of a
+program.  The warning also includes the location of the declaration
+of the deprecated function, to enable users to easily find further
+information about why the function is deprecated, or what they should
+do instead.  Note that the warnings only occurs for uses:
+
+@smallexample
+int old_fn () __attribute__ ((deprecated));
+int old_fn ();
+int (*fn_ptr)() = old_fn;
+@end smallexample
+
+results in a warning on line 3 but not line 2.
+
+The @code{deprecated} attribute can also be used for variables and
+types (@pxref{Variable Attributes}, @pxref{Type Attributes}.)
+
+@item dllexport
+@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.
+
+You can use @code{__declspec(dllexport)} as a synonym for
+@code{__attribute__ ((dllexport))} for compatibility with other
+compilers.
+
+On systems that support the @code{visibility} attribute, this
+attribute also implies ``default'' visibility, unless a
+@code{visibility} attribute is explicitly specified.  You should avoid
+the use of @code{dllexport} with ``hidden'' or ``internal''
+visibility; in the future GCC may issue an error for those cases.
+
+Currently, the @code{dllexport} attribute is ignored for inlined
+functions, unless the @option{-fkeep-inline-functions} flag has been
+used.  The attribute is also ignored for undefined symbols.
+
+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{__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} storage.  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.
+
+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
+dllimport'ed constructor or a non-inline, non-pure virtual function
+and, for either of those two conditions, the class also has a inline
+constructor or destructor and has a key function that is defined in
+the current translation unit.
+
+For Microsoft Windows based 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 was required on older
+versions of the GNU linker, but can now 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 function
+or variable marked as @code{dllimport} cannot be used as a constant
+address.  On Microsoft Windows targets, the attribute can be disabled
+for functions by setting the @option{-mnop-fun-dllimport} flag.
+
+@item eightbit_data
+@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 will generate more efficient code for certain operations
+on data in the eight bit data area.  Note the eight bit data area is limited to
+256 bytes of data.
+
+You must use GAS and GLD from GNU binutils version 2.7 or later for
+this attribute to work correctly.
+
+@item exception_handler
+@cindex exception handler functions on the Blackfin processor
+Use this attribute on the Blackfin to indicate that the specified function
+is an exception handler.  The compiler will generate function entry and
+exit sequences suitable for use in an exception handler when this
+attribute is present.
+
+@item far
+@cindex functions which handle memory bank switching
+On 68HC11 and 68HC12 the @code{far} attribute causes the compiler to
+use a calling convention that takes care of switching memory banks when
+entering and leaving a function.  This calling convention is also the
+default when using the @option{-mlong-calls} option.
+
+On 68HC12 the compiler will use the @code{call} and @code{rtc} instructions
+to call and return from a function.
+
+On 68HC11 the compiler will generate a sequence of instructions
+to invoke a board-specific routine to switch the memory bank and call the
+real function.  The board-specific routine simulates a @code{call}.
+At the end of a function, it will jump to a board-specific routine
+instead of using @code{rts}.  The board-specific return routine simulates
+the @code{rtc}.
+
+@item fastcall
+@cindex functions that pop the argument stack on the 386
+On the Intel 386, 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 will
+pop the arguments off the stack.  If the number of arguments is variable all
+arguments are pushed on the stack.
 
 @item format (@var{archetype}, @var{string-index}, @var{first-to-check})
 @cindex @code{format} function attribute
@@ -2162,10 +1903,11 @@ start with the third argument, so the correct parameters for the format
 attribute are 2 and 3.
 
 @opindex ffreestanding
+@opindex fno-builtin
 The @code{format} attribute allows you to identify your own functions
 which take format strings as arguments, so that GCC can check the
 calls to these functions for errors.  The compiler always (unless
-@option{-ffreestanding} is used) checks formats
+@option{-ffreestanding} or @option{-fno-builtin} is used) checks formats
 for the standard library functions @code{printf}, @code{fprintf},
 @code{sprintf}, @code{scanf}, @code{fscanf}, @code{sscanf}, @code{strftime},
 @code{vprintf}, @code{vfprintf} and @code{vsprintf} whenever such
@@ -2177,6 +1919,10 @@ standard modes, the X/Open function @code{strfmon} is also checked as
 are @code{printf_unlocked} and @code{fprintf_unlocked}.
 @xref{C Dialect Options,,Options Controlling C Dialect}.
 
+The target may provide additional types of format checks.
+@xref{Target Format Checks,,Format Checks Specific to Particular
+Target Machines}.
+
 @item format_arg (@var{string-index})
 @cindex @code{format_arg} function attribute
 @opindex Wformat-nonliteral
@@ -2218,9 +1964,167 @@ type function whose operands are a call to one of your own function.
 The compiler always treats @code{gettext}, @code{dgettext}, and
 @code{dcgettext} in this manner except when strict ISO C support is
 requested by @option{-ansi} or an appropriate @option{-std} option, or
-@option{-ffreestanding} is used.  @xref{C Dialect Options,,Options
+@option{-ffreestanding} or @option{-fno-builtin}
+is used.  @xref{C Dialect Options,,Options
 Controlling C Dialect}.
 
+@item function_vector
+@cindex calling functions through the function vector on the H8/300 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 will reduce code size, however;
+the function vector has a limited size (maximum 128 entries on the H8/300
+and 64 entries on the H8/300H and H8S) and shares space with the interrupt vector.
+
+You must use GAS and GLD from GNU binutils version 2.7 or later for
+this attribute to work correctly.
+
+@item interrupt
+@cindex interrupt handler functions
+Use this attribute on the ARM, AVR, C4x, CRX, M32C, M32R/D, MS1, and Xstormy16
+ports to indicate that the specified function is an interrupt handler.
+The compiler will generate function entry and exit sequences suitable
+for use in an interrupt handler when this attribute is present.
+
+Note, interrupt handlers for the Blackfin, m68k, H8/300, H8/300H, H8S, and
+SH processors can be specified via the @code{interrupt_handler} attribute.
+
+Note, on the AVR, interrupts will be enabled inside the function.
+
+Note, for the ARM, you can specify the kind of interrupt to be handled by
+adding an optional parameter to the interrupt attribute like this:
+
+@smallexample
+void f () __attribute__ ((interrupt ("IRQ")));
+@end smallexample
+
+Permissible values for this parameter are: IRQ, FIQ, SWI, ABORT and UNDEF@.
+
+@item interrupt_handler
+@cindex interrupt handler functions on the Blackfin, m68k, H8/300 and SH processors
+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
+will generate function entry and exit sequences suitable for use in an
+interrupt handler when this attribute is present.
+
+@item kspisusp
+@cindex User stack pointer in interrupts on the Blackfin
+When used together with @code{interrupt_handler}, @code{exception_handler}
+or @code{nmi_handler}, code will be generated to load the stack pointer
+from the USP register in the function prologue.
+
+@item long_call/short_call
+@cindex indirect calls on ARM
+This attribute specifies how a particular function is called on
+ARM@.  Both attributes override the @option{-mlong-calls} (@pxref{ARM Options})
+command line switch and @code{#pragma long_calls} settings.  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.
+
+@item longcall/shortcall
+@cindex functions called via pointer on the RS/6000 and PowerPC
+On the Blackfin, RS/6000 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
+@cindex indirect calls on MIPS
+This attribute specifies how a particular function is called on MIPS@.
+The attribute overrides the @option{-mlong-calls} (@pxref{MIPS Options})
+command line switch.  This attribute causes the compiler to always call
+the function by first loading its address into a register, and then using
+the contents of that register.
+
+@item malloc
+@cindex @code{malloc} attribute
+The @code{malloc} attribute is used to tell the compiler that a function
+may be treated as if any non-@code{NULL} pointer it returns cannot
+alias any other pointer valid when the function returns.
+This will often improve optimization.
+Standard functions with this property include @code{malloc} and
+@code{calloc}.  @code{realloc}-like functions have this property as
+long as the old pointer is never referred to (including comparing it
+to the new pointer) after the function returns a non-@code{NULL}
+value.
+
+@item model (@var{model-name})
+@cindex function addressability on the M32R/D
+@cindex variable addressability on the IA-64
+
+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.
+
+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.
+
+Medium model objects may live anywhere in the 32-bit address space (the
+compiler will generate @code{seth/add3} instructions to load their addresses),
+and are callable with the @code{bl} instruction.
+
+Large model objects may live anywhere in the 32-bit address space (the
+compiler will generate @code{seth/add3} instructions to load their addresses),
+and may not be reachable with the @code{bl} instruction (the compiler will
+generate the much slower @code{seth/add3/jl} instruction sequence).
+
+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.
+
+@item naked
+@cindex function without a prologue/epilogue code
+Use this attribute on the ARM, AVR, C4x and IP2K ports to indicate that the
+specified function does not need prologue/epilogue sequences generated by
+the compiler.  It is up to the programmer to provide these sequences.
+
+@item near
+@cindex functions which do not handle memory bank switching on 68HC11/68HC12
+On 68HC11 and 68HC12 the @code{near} attribute causes the compiler to
+use the normal calling convention based on @code{jsr} and @code{rts}.
+This attribute can be used to cancel the effect of the @option{-mlong-calls}
+option.
+
+@item nesting
+@cindex Allow nesting in an interrupt handler on the Blackfin processor.
+Use this attribute together with @code{interrupt_handler},
+@code{exception_handler} or @code{nmi_handler} to indicate that the function
+entry code should enable nested interrupts or exceptions.
+
+@item nmi_handler
+@cindex NMI handler functions on the Blackfin processor
+Use this attribute on the Blackfin to indicate that the specified function
+is an NMI handler.  The compiler will generate function entry and
+exit sequences suitable for use in an NMI handler when this
+attribute is present.
+
+@item no_instrument_function
+@cindex @code{no_instrument_function} function attribute
+@opindex finstrument-functions
+If @option{-finstrument-functions} is given, profiling function calls will
+be generated at entry and exit of most user-compiled functions.
+Functions with this attribute will not be so instrumented.
+
+@item noinline
+@cindex @code{noinline} function attribute
+This function attribute prevents a function from being considered for
+inlining.
+
 @item nonnull (@var{arg-index}, @dots{})
 @cindex @code{nonnull} function attribute
 The @code{nonnull} attribute specifies that some function parameters should
@@ -2250,187 +2154,96 @@ my_memcpy (void *dest, const void *src, size_t len)
 	__attribute__((nonnull));
 @end smallexample
 
-@item no_instrument_function
-@cindex @code{no_instrument_function} function attribute
-@opindex finstrument-functions
-If @option{-finstrument-functions} is given, profiling function calls will
-be generated at entry and exit of most user-compiled functions.
-Functions with this attribute will not be so instrumented.
-
-@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:
-
-@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 constructor
-@itemx destructor
-@cindex @code{constructor} function attribute
-@cindex @code{destructor} function attribute
-The @code{constructor} attribute causes the function to be called
-automatically before execution enters @code{main ()}.  Similarly, the
-@code{destructor} attribute causes the function to be called
-automatically after @code{main ()} has completed or @code{exit ()} has
-been called.  Functions with these attributes are useful for
-initializing data that will be used implicitly during the execution of
-the program.
-
-These attributes are not currently implemented for Objective-C@.
-
-@cindex @code{unused} attribute.
-@item unused
-This attribute, attached to a function, means that the function is meant
-to be possibly unused.  GCC will not produce a warning for this
-function.
-
-@cindex @code{used} attribute.
-@item used
-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.
-
-@cindex @code{deprecated} attribute.
-@item deprecated
-The @code{deprecated} attribute results in a warning if the function
-is used anywhere in the source file.  This is useful when identifying
-functions that are expected to be removed in a future version of a
-program.  The warning also includes the location of the declaration
-of the deprecated function, to enable users to easily find further
-information about why the function is deprecated, or what they should
-do instead.  Note that the warnings only occurs for uses:
+@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
-int old_fn () __attribute__ ((deprecated));
-int old_fn ();
-int (*fn_ptr)() = old_fn;
-@end smallexample
-
-results in a warning on line 3 but not line 2.
-
-The @code{deprecated} attribute can also be used for variables and
-types (@pxref{Variable Attributes}, @pxref{Type Attributes}.)
-
-@item warn_unused_result
-@cindex @code{warn_unused_result} 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}.
+@group
+void fatal () __attribute__ ((noreturn));
 
-@smallexample
-int fn () __attribute__ ((warn_unused_result));
-int foo ()
+void
+fatal (/* @r{@dots{}} */)
 @{
-  if (fn () < 0) return -1;
-  fn ();
-  return 0;
+  /* @r{@dots{}} */ /* @r{Print error message.} */ /* @r{@dots{}} */
+  exit (1);
 @}
+@end group
 @end smallexample
 
-results in warning on line 5.
+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.
 
-@item weak
-@cindex @code{weak} 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 which can be overridden in user code, though it can
-also be used with non-function declarations.  Weak symbols are supported
-for ELF targets, and also for a.out targets when using the GNU assembler
-and linker.
+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 malloc
-@cindex @code{malloc} attribute
-The @code{malloc} attribute is used to tell the compiler that a function
-may be treated as if any non-@code{NULL} pointer it returns cannot
-alias any other pointer valid when the function returns.
-This will often improve optimization.
-Standard functions with this property include @code{malloc} and
-@code{calloc}.  @code{realloc}-like functions have this property as
-long as the old pointer is never referred to (including comparing it
-to the new pointer) after the function returns a non-@code{NULL}
-value.
+Do not assume that registers saved by the calling function are
+restored before calling the @code{noreturn} function.
 
-@item alias ("@var{target}")
-@cindex @code{alias} attribute
-The @code{alias} attribute causes the declaration to be emitted as an
-alias for another symbol, which must be specified.  For instance,
+It does not make sense for a @code{noreturn} function to have a return
+type other than @code{void}.
+
+The attribute @code{noreturn} is not implemented in GCC versions
+earlier than 2.5.  An alternative way to declare that a function does
+not return, which works in the current version and in some older
+versions, is as follows:
 
 @smallexample
-void __f () @{ /* @r{Do something.} */; @}
-void f () __attribute__ ((weak, alias ("__f")));
+typedef void voidfn ();
+
+volatile voidfn fatal;
 @end smallexample
 
-declares @samp{f} to be a weak alias for @samp{__f}.  In C++, the
-mangled name for the target must be used.
+This approach does not work in GNU C++.
 
-Not all target machines support this attribute.
+@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.  The @code{nothrow} attribute is not
+implemented in GCC versions earlier than 3.3.
 
-@item visibility ("@var{visibility_type}")
-@cindex @code{visibility} attribute
-The @code{visibility} attribute on ELF targets causes the declaration
-to be emitted with default, hidden, protected or internal visibility.
+@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,
 
 @smallexample
-void __attribute__ ((visibility ("protected")))
-f () @{ /* @r{Do something.} */; @}
-int i __attribute__ ((visibility ("hidden")));
+int square (int) __attribute__ ((pure));
 @end smallexample
 
-See the ELF gABI for complete details, but the short story is:
-
-@table @dfn
-@item default
-Default visibility is the normal case for ELF.  This value is
-available for the visibility attribute to override other options
-that may change the assumed visibility of symbols.
-
-@item hidden
-Hidden visibility indicates that the symbol will not be placed into
-the dynamic symbol table, so no other @dfn{module} (executable or
-shared library) can reference it directly.
-
-@item protected
-Protected visibility indicates that the symbol will be placed in the
-dynamic symbol table, but that references within the defining module
-will bind to the local symbol.  That is, the symbol cannot be overridden
-by another module.
+@noindent
+says that the hypothetical function @code{square} is safe to call
+fewer times than the program says.
 
-@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 the function is @emph{never}
-called from another module.  Note that hidden symbols, while they cannot
-be referenced directly by other modules, can be referenced indirectly via
-function pointers.  By indicating that a symbol 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.
-@end table
+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).
 
-Not all ELF targets support this attribute.
+The attribute @code{pure} is not implemented in GCC versions earlier
+than 2.96.
 
 @item regparm (@var{number})
 @cindex @code{regparm} attribute
 @cindex functions that are passed arguments in registers on the 386
 On the Intel 386, the @code{regparm} attribute causes the compiler to
-pass up to @var{number} integer arguments in registers EAX,
-EDX, and ECX instead of on the stack.  Functions that take a
-variable number of arguments will continue to be passed all of their
+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 will continue to be passed all of their
 arguments on the stack.
 
 Beware that on some ELF systems this attribute is unsuitable for
@@ -2443,89 +2256,103 @@ safe since the loaders there save all registers.  (Lazy binding can be
 disabled with the linker or the loader if desired, to avoid the
 problem.)
 
-@item stdcall
-@cindex functions that pop the argument stack on the 386
-On the Intel 386, the @code{stdcall} attribute causes the compiler to
-assume that the called function will pop off the stack space used to
-pass arguments, unless it takes a variable number of arguments.
-
-@item fastcall
-@cindex functions that pop the argument stack on the 386
-On the Intel 386, the @code{fastcall} attribute causes the compiler to
-pass the first two arguments in the registers ECX and EDX. Subsequent
-arguments are passed on the stack. The called function will pop the
-arguments off the stack. If the number of arguments is variable all
-arguments are pushed on the stack.
+@item sseregparm
+@cindex @code{sseregparm} attribute
+On the Intel 386 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 will continue to pass all of their
+floating point arguments on the stack.
+
+@item force_align_arg_pointer
+@cindex @code{force_align_arg_pointer} attribute
+On the Intel x86, the @code{force_align_arg_pointer} attribute may be
+applied to individual function definitions, generating an alternate
+prologue and epilogue that realigns the runtime stack.  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.  The alternate
+prologue and epilogue are slower and bigger than the regular ones, and
+the alternate prologue requires a scratch register; this lowers the
+number of registers available if used in conjunction with the
+@code{regparm} attribute.  The @code{force_align_arg_pointer}
+attribute is incompatible with nested functions; this is considered a
+hard error.
+
+@item returns_twice
+@cindex @code{returns_twice} attribute
+The @code{returns_twice} attribute tells the compiler that a function may
+return more than one time.  The compiler will ensure that all registers
+are dead before calling such a function and will emit 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 cdecl
-@cindex functions that do pop the argument stack on the 386
-@opindex mrtd
-On the Intel 386, the @code{cdecl} attribute causes the compiler to
-assume that the calling function will pop off the stack space used to
-pass arguments.  This is
-useful to override the effects of the @option{-mrtd} switch.
+@item saveall
+@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.
 
-@item longcall/shortcall
-@cindex functions called via pointer on the RS/6000 and PowerPC
-On the RS/6000 and PowerPC, the @code{longcall} attribute causes the
-compiler to always call this function via a pointer, just as it would if
-the @option{-mlongcall} option had been specified.  The @code{shortcall}
-attribute causes the compiler not to do this.  These attributes override
-both the @option{-mlongcall} switch and the @code{#pragma longcall}
-setting.
+@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:
 
-@xref{RS/6000 and PowerPC Options}, for more information on whether long
-calls are necessary.
+@smallexample
+extern void foobar (void) __attribute__ ((section ("bar")));
+@end smallexample
 
-@item long_call/short_call
-@cindex indirect calls on ARM
-This attribute specifies how a particular function is called on
-ARM@.  Both attributes override the @option{-mlong-calls} (@pxref{ARM Options})
-command line switch and @code{#pragma long_calls} settings.  The
-@code{long_call} attribute causes the compiler to always call the
-function by first loading its address into a register and then using the
-contents of that register.   The @code{short_call} attribute always places
-the offset to the function from the call site into the @samp{BL}
-instruction directly.
+@noindent
+puts the function @code{foobar} in the @code{bar} section.
 
-@item function_vector
-@cindex calling functions through the function vector on the H8/300 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 will reduce code size, however;
-the function vector has a limited size (maximum 128 entries on the H8/300
-and 64 entries on the H8/300H and H8S) and shares space with the interrupt vector.
+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 must use GAS and GLD from GNU binutils version 2.7 or later for
-this attribute to work correctly.
+@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.
 
-@item interrupt
-@cindex interrupt handler functions
-Use this attribute on the ARM, AVR, C4x, M32R/D and Xstormy16 ports to indicate
-that the specified function is an interrupt handler.  The compiler will
-generate function entry and exit sequences suitable for use in an
-interrupt handler when this attribute is present.
+@smallexample
+__attribute__ ((sentinel))
+is equivalent to
+__attribute__ ((sentinel(0)))
+@end smallexample
 
-Note, interrupt handlers for the m68k, H8/300, H8/300H, H8S, and SH processors
-can be specified via the @code{interrupt_handler} attribute.
+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.
 
-Note, on the AVR, interrupts will be enabled inside the function.
+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.
 
-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 warnings for missing or incorrect sentinels are enabled with
+@option{-Wformat}.
 
-@smallexample
-void f () __attribute__ ((interrupt ("IRQ")));
-@end smallexample
+@item short_call
+See long_call/short_call.
 
-Permissible values for this parameter are: IRQ, FIQ, SWI, ABORT and UNDEF@.
+@item shortcall
+See longcall/shortcall.
 
-@item interrupt_handler
-@cindex interrupt handler functions on the m68k, H8/300 and SH processors
-Use this attribute on the m68k, H8/300, H8/300H, H8S, and SH to indicate that
-the specified function is an interrupt handler.  The compiler will generate
-function entry and exit sequences suitable for use in an interrupt
-handler when this attribute is present.
+@item signal
+@cindex signal handler functions on the AVR processors
+Use this attribute on the AVR to indicate that the specified
+function is a signal handler.  The compiler will generate function
+entry and exit sequences suitable for use in a signal handler when this
+attribute is present.  Interrupts will be disabled inside the function.
 
 @item sp_switch
 Use this attribute on the SH to indicate an @code{interrupt_handler}
@@ -2539,21 +2366,11 @@ void f () __attribute__ ((interrupt_handler,
                           sp_switch ("alt_stack")));
 @end smallexample
 
-@item trap_exit
-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 eightbit_data
-@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 will generate more efficient code for certain operations
-on data in the eight bit data area.  Note the eight bit data area is limited to
-256 bytes of data.
-
-You must use GAS and GLD from GNU binutils version 2.7 or later for
-this attribute to work correctly.
+@item stdcall
+@cindex functions that pop the argument stack on the 386
+On the Intel 386, the @code{stdcall} attribute causes the compiler to
+assume that the called function will pop off the stack space used to
+pass arguments, unless it takes a variable number of arguments.
 
 @item tiny_data
 @cindex tiny data section on the H8/300H and H8S
@@ -2563,139 +2380,189 @@ The compiler will generate more efficient code for loads and stores
 on data in the tiny data section.  Note the tiny data area is limited to
 slightly under 32kbytes of data.
 
-@item saveall
-@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.
-
-@item signal
-@cindex signal handler functions on the AVR processors
-Use this attribute on the AVR to indicate that the specified
-function is a signal handler.  The compiler will generate function
-entry and exit sequences suitable for use in a signal handler when this
-attribute is present.  Interrupts will be disabled inside the function.
+@item trap_exit
+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 naked
-@cindex function without a prologue/epilogue code
-Use this attribute on the ARM, AVR, C4x and IP2K ports to indicate that the
-specified function does not need prologue/epilogue sequences generated by
-the compiler.  It is up to the programmer to provide these sequences.
+@item unused
+@cindex @code{unused} attribute.
+This attribute, attached to a function, means that the function is meant
+to be possibly unused.  GCC will not produce a warning for this
+function.
 
-@item model (@var{model-name})
-@cindex function addressability on the M32R/D
-@cindex variable addressability on the IA-64
+@item used
+@cindex @code{used} 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.
 
-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 visibility ("@var{visibility_type}")
+@cindex @code{visibility} 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.
 
-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.
+@smallexample
+void __attribute__ ((visibility ("protected")))
+f () @{ /* @r{Do something.} */; @}
+int i __attribute__ ((visibility ("hidden")));
+@end smallexample
 
-Medium model objects may live anywhere in the 32-bit address space (the
-compiler will generate @code{seth/add3} instructions to load their addresses),
-and are callable with the @code{bl} instruction.
+The possible values of @var{visibility_type} correspond to the
+visibility settings in the ELF gABI.
 
-Large model objects may live anywhere in the 32-bit address space (the
-compiler will generate @code{seth/add3} instructions to load their addresses),
-and may not be reachable with the @code{bl} instruction (the compiler will
-generate the much slower @code{seth/add3/jl} instruction sequence).
+@table @dfn
+@c keep this list of visibilities in alphabetical order.
 
-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.
+@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.
 
-@item far
-@cindex functions which handle memory bank switching
-On 68HC11 and 68HC12 the @code{far} attribute causes the compiler to
-use a calling convention that takes care of switching memory banks when
-entering and leaving a function.  This calling convention is also the
-default when using the @option{-mlong-calls} option.
+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 68HC12 the compiler will use the @code{call} and @code{rtc} instructions
-to call and return from a function.
+On Darwin, default visibility means that the declaration is visible to
+other modules.
 
-On 68HC11 the compiler will generate a sequence of instructions
-to invoke a board-specific routine to switch the memory bank and call the
-real function. The board-specific routine simulates a @code{call}.
-At the end of a function, it will jump to a board-specific routine
-instead of using @code{rts}. The board-specific return routine simulates
-the @code{rtc}.
+Default visibility corresponds to ``external linkage'' in the language.
 
-@item near
-@cindex functions which do not handle memory bank switching on 68HC11/68HC12
-On 68HC11 and 68HC12 the @code{near} attribute causes the compiler to
-use the normal calling convention based on @code{jsr} and @code{rts}.
-This attribute can be used to cancel the effect of the @option{-mlong-calls}
-option.
+@item hidden
+Hidden visibility indicates that the entity declared will have a new
+form of linkage, which we'll 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 dllimport
-@cindex @code{__declspec(dllimport)}
-On Microsoft Windows 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 Microsoft Windows dll library. The pointer name is formed by
-combining @code{_imp__} and the function or variable name. The attribute
-implies @code{extern} storage.
+@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.
 
-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}.
+@item protected
+Protected visibility is like default visibility except that it
+indicates that references within the defining module will bind to the
+definition in that module.  That is, the declared entity cannot be
+overridden by another module.
 
-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.
+@end table
 
-On cygwin, mingw and arm-pe targets, @code{__declspec(dllimport)} is
-recognized as a synonym for @code{__attribute__ ((dllimport))} for
-compatibility with other Microsoft Windows compilers.
+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 which
+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.
+
+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 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 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.
 
-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 was
-required on older versions of GNU ld, but can now be avoided by passing
-the @option{--enable-auto-import} switch to ld. As with functions, using
-the attribute for a variable eliminates a thunk in the dll.
+@item warn_unused_result
+@cindex @code{warn_unused_result} 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}.
 
-One drawback to using this attribute is that a pointer to a function or
-variable marked as dllimport cannot be used as a constant address. The
-attribute can be disabled for functions by setting the
-@option{-mnop-fun-dllimport} flag.
+@smallexample
+int fn () __attribute__ ((warn_unused_result));
+int foo ()
+@{
+  if (fn () < 0) return -1;
+  fn ();
+  return 0;
+@}
+@end smallexample
 
-@item dllexport
-@cindex @code{__declspec(dllexport)}
-On Microsoft Windows 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. The pointer name is
-formed by combining @code{_imp__} and the function or variable name.
-
-Currently, the @code{dllexport}attribute is ignored for inlined
-functions, but export can be forced by using the
-@option{-fkeep-inline-functions} flag. The attribute is also ignored for
-undefined symbols.
-
-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.
+results in warning on line 5.
 
-On cygwin, mingw and arm-pe targets, @code{__declspec(dllexport)} is
-recognized as a synonym for @code{__attribute__ ((dllexport))} for
-compatibility with other Microsoft Windows compilers.
+@item weak
+@cindex @code{weak} 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 which can be overridden in user code, though it can
+also be used with non-function declarations.  Weak symbols are supported
+for ELF targets, and also for a.out targets when using the GNU assembler
+and linker.
 
-Alternative methods for including the symbol in the dll's export table
-are to use a .def file with an @code{EXPORTS} section or, with GNU ld,
-using the @option{--export-all} linker flag.
+@item weakref
+@itemx weakref ("@var{target}")
+@cindex @code{weakref} 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}.
+
+@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
+
+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 the becomes a @code{weak}
+undefined symbol.  If it is directly referenced, however, then such
+strong references prevail, and a definition will be required for the
+symbol, not necessarily in the same translation unit.
+
+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.
+
+At present, a declaration to which @code{weakref} is attached can
+only be @code{static}.
+
+@item externally_visible
+@cindex @code{externally_visible} attribute.
+This attribute, attached to a global variable or function nullify
+effect of @option{-fwhole-program} command line option, so the object
+remain visible outside the current compilation unit
 
 @end table
 
@@ -2799,19 +2666,16 @@ feature is intended for code generated by programs which contains labels
 that may be unused but which is compiled with @option{-Wall}.  It would
 not normally be appropriate to use in it human-written code, though it
 could be useful in cases where the code that jumps to the label is
-contained within an @code{#ifdef} conditional. GNU C++ does not permit
+contained within an @code{#ifdef} conditional.  GNU C++ does not permit
 such placement of attribute lists, 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
+C++.  Declarations cannot be labelled in C90 or C99, so the ambiguity
 does not arise there.
 
 An attribute specifier list may appear as part of a @code{struct},
 @code{union} or @code{enum} specifier.  It may go either immediately
 after the @code{struct}, @code{union} or @code{enum} keyword, or after
-the closing brace.  It is ignored if the content of the structure, union
-or enumerated type is not defined in the specifier in which the
-attribute specifier list is used---that is, in usages such as
-@code{struct __attribute__((foo)) bar} with no following opening brace.
+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
@@ -2849,6 +2713,15 @@ declaration as a whole.  In the obsolescent usage where a type of
 specifiers and qualifiers may be an attribute specifier list with no
 other specifiers or qualifiers.
 
+At present, the first parameter in a function prototype must have some
+type specifier which is not an attribute specifier; this resolves an
+ambiguity in the interpretation of @code{void f(int
+(__attribute__((foo)) x))}, but is subject to change.  At present, if
+the parentheses of a function declarator contain only attributes then
+those attributes are ignored, rather than yielding an error or warning
+or implying a single parameter of type int, but this is subject to
+change.
+
 An attribute specifier list may appear immediately before a declarator
 (other than the first) in a comma-separated list of declarators in a
 declaration of more than one identifier using a single list of
@@ -2989,7 +2862,7 @@ int isroot P((uid_t));
 
 /* @r{Old-style function definition.}  */
 int
-isroot (x)   /* ??? lossage here ??? */
+isroot (x)   /* @r{??? lossage here ???} */
      uid_t x;
 @{
   return x == 0;
@@ -3196,7 +3069,7 @@ return normally.
 @opindex fno-common
 The @code{common} attribute requests GCC to place a variable in
 ``common'' storage.  The @code{nocommon} attribute requests the
-opposite -- to allocate space for it directly.
+opposite---to allocate space for it directly.
 
 These attributes override the default chosen by the
 @option{-fno-common} and @option{-fcommon} flags respectively.
@@ -3268,13 +3141,13 @@ int init_data __attribute__ ((section ("INITDATA"))) = 0;
 
 main()
 @{
-  /* Initialize stack pointer */
+  /* @r{Initialize stack pointer} */
   init_sp (stack + sizeof (stack));
 
-  /* Initialize initialized data */
+  /* @r{Initialize initialized data} */
   memcpy (&init_data, &data, &edata - &data);
 
-  /* Turn on the serial ports */
+  /* @r{Turn on the serial ports} */
   init_duart (&a);
   init_duart (&b);
 @}
@@ -3313,8 +3186,8 @@ int foo __attribute__((section ("shared"), shared)) = 0;
 int
 main()
 @{
-  /* Read and write foo.  All running
-     copies see the same value.  */
+  /* @r{Read and write foo.  All running
+     copies see the same value.}  */
   return 0;
 @}
 @end smallexample
@@ -3330,26 +3203,22 @@ The @code{shared} attribute is only available on Microsoft Windows@.
 @cindex @code{tls_model} attribute
 The @code{tls_model} attribute sets thread-local storage model
 (@pxref{Thread-Local}) of a particular @code{__thread} variable,
-overriding @code{-ftls-model=} command line switch on a per-variable
+overriding @option{-ftls-model=} command line switch on a per-variable
 basis.
 The @var{tls_model} argument should be one of @code{global-dynamic},
 @code{local-dynamic}, @code{initial-exec} or @code{local-exec}.
 
 Not all targets support this attribute.
 
-@item transparent_union
-This attribute, attached to a function parameter which is a union, means
-that the corresponding argument may have the type of any union member,
-but the argument is passed as if its type were that of the first union
-member.  For more details see @xref{Type Attributes}.  You can also use
-this attribute on a @code{typedef} for a union data type; then it
-applies to all function parameters with that type.
-
 @item unused
 This attribute, attached to a variable, means that the variable is meant
 to be possibly unused.  GCC will not produce a warning for this
 variable.
 
+@item used
+This attribute, attached to a variable, means that the variable must be
+emitted even if it appears that the variable is not referenced.
+
 @item vector_size (@var{bytes})
 This attribute specifies the vector size for the variable, measured in
 bytes.  For example, the declaration:
@@ -3379,20 +3248,40 @@ struct S  __attribute__ ((vector_size (16))) foo;
 is invalid even if the size of the structure is the same as the size of
 the @code{int}.
 
+@item selectany
+The @code{selectany} attribute causes an initialized global variable to
+have link-once semantics.  When multiple definitions of the variable are
+encountered by the linker, the first is selected and the remainder are
+discarded.  Following usage by the Microsoft compiler, the linker is told
+@emph{not} to warn about size or content differences of the multiple
+definitions.
+
+Although the primary usage of this attribute is for POD types, the
+attribute can also be applied to global C++ objects that are initialized
+by a constructor.  In this case, the static initialization and destruction
+code for the object is emitted in each translation defining the object,
+but the calls to the constructor and destructor are protected by a
+link-once guard variable.
+
+The @code{selectany} attribute is only available on Microsoft Windows
+targets.  You can use @code{__declspec (selectany)} as a synonym for
+@code{__attribute__ ((selectany))} for compatibility with other
+compilers.
+
 @item weak
 The @code{weak} attribute is described in @xref{Function Attributes}.
 
 @item dllimport
 The @code{dllimport} attribute is described in @xref{Function Attributes}.
 
-@item dlexport
+@item dllexport
 The @code{dllexport} attribute is described in @xref{Function Attributes}.
 
 @end table
 
 @subsection M32R/D Variable Attributes
 
-One attribute is currently defined for the M32R/D.
+One attribute is currently defined for the M32R/D@.
 
 @table @code
 @item model (@var{model-name})
@@ -3409,6 +3298,7 @@ Medium and large model objects may live anywhere in the 32-bit address space
 addresses).
 @end table
 
+@anchor{i386 Variable Attributes}
 @subsection i386 Variable Attributes
 
 Two attributes are currently defined for i386 configurations:
@@ -3429,6 +3319,145 @@ either format.
 
 Currently @option{-m[no-]ms-bitfields} is provided for the Microsoft Windows X86
 compilers to match the native Microsoft compiler.
+
+The Microsoft structure layout algorithm is fairly simple with the exception
+of the bitfield packing:
+
+The padding and alignment of members of structures and whether a bit field
+can straddle a storage-unit boundary
+
+@enumerate
+@item Structure members are stored sequentially in the order in which they are
+declared: the first member has the lowest memory address and the last member
+the highest.
+
+@item Every data object has an alignment-requirement. The alignment-requirement
+for all data except structures, unions, and arrays is either the size of the
+object or the current packing size (specified with either the aligned attribute
+or the pack pragma), whichever is less. For structures,  unions, and arrays,
+the alignment-requirement is the largest alignment-requirement of its members.
+Every object is allocated an offset so that:
+
+offset %  alignment-requirement == 0
+
+@item Adjacent bit fields are packed into the same 1-, 2-, or 4-byte allocation
+unit if the integral types are the same size and if the next bit field fits
+into the current allocation unit without crossing the boundary imposed by the
+common alignment requirements of the bit fields.
+@end enumerate
+
+Handling of zero-length bitfields:
+
+MSVC interprets zero-length bitfields in the following ways:
+
+@enumerate
+@item If a zero-length bitfield is inserted between two bitfields that would
+normally be coalesced, the bitfields will not be coalesced.
+
+For example:
+
+@smallexample
+struct
+ @{
+   unsigned long bf_1 : 12;
+   unsigned long : 0;
+   unsigned long bf_2 : 12;
+ @} t1;
+@end smallexample
+
+The size of @code{t1} would be 8 bytes with the zero-length bitfield.  If the
+zero-length bitfield were removed, @code{t1}'s size would be 4 bytes.
+
+@item If a zero-length bitfield is inserted after a bitfield, @code{foo}, and the
+alignment of the zero-length bitfield is greater than the member that follows it,
+@code{bar}, @code{bar} will be aligned as the type of the zero-length bitfield.
+
+For example:
+
+@smallexample
+struct
+ @{
+   char foo : 4;
+   short : 0;
+   char bar;
+ @} t2;
+
+struct
+ @{
+   char foo : 4;
+   short : 0;
+   double bar;
+ @} t3;
+@end smallexample
+
+For @code{t2}, @code{bar} will be placed at offset 2, rather than offset 1.
+Accordingly, the size of @code{t2} will be 4.  For @code{t3}, the zero-length
+bitfield will not affect the alignment of @code{bar} or, as a result, the size
+of the structure.
+
+Taking this into account, it is important to note the following:
+
+@enumerate
+@item If a zero-length bitfield follows a normal bitfield, the type of the
+zero-length bitfield may affect the alignment of the structure as whole. For
+example, @code{t2} has a size of 4 bytes, since the zero-length bitfield follows a
+normal bitfield, and is of type short.
+
+@item Even if a zero-length bitfield is not followed by a normal bitfield, it may
+still affect the alignment of the structure:
+
+@smallexample
+struct
+ @{
+   char foo : 6;
+   long : 0;
+ @} t4;
+@end smallexample
+
+Here, @code{t4} will take up 4 bytes.
+@end enumerate
+
+@item Zero-length bitfields following non-bitfield members are ignored:
+
+@smallexample
+struct
+ @{
+   char foo;
+   long : 0;
+   char bar;
+ @} t5;
+@end smallexample
+
+Here, @code{t5} will take up 2 bytes.
+@end enumerate
+@end table
+
+@subsection PowerPC Variable Attributes
+
+Three attributes currently are defined for PowerPC configurations:
+@code{altivec}, @code{ms_struct} and @code{gcc_struct}.
+
+For full documentation of the struct attributes please see the
+documentation in the @xref{i386 Variable Attributes}, section.
+
+For documentation of @code{altivec} attribute please see the
+documentation in the @xref{PowerPC Type Attributes}, section.
+
+@subsection Xstormy16 Variable Attributes
+
+One attribute is currently defined for xstormy16 configurations:
+@code{below100}
+
+@table @code
+@item below100
+@cindex @code{below100} attribute
+
+If a variable has the @code{below100} attribute (@code{BELOW100} is
+allowed also), GCC will place the variable in the first 0x100 bytes of
+memory and use special opcodes to access it.  Such variables will be
+placed in either the @code{.bss_below100} section or the
+@code{.data_below100} section.
+
 @end table
 
 @node Type Attributes
@@ -3437,13 +3466,14 @@ compilers to match the native Microsoft compiler.
 @cindex type attributes
 
 The keyword @code{__attribute__} allows you to specify special
-attributes of @code{struct} and @code{union} types when you define such
-types.  This keyword is followed by an attribute specification inside
-double parentheses.  Six attributes are currently defined for types:
-@code{aligned}, @code{packed}, @code{transparent_union}, @code{unused},
-@code{deprecated} and @code{may_alias}.  Other attributes are defined for
-functions (@pxref{Function Attributes}) and for variables
-(@pxref{Variable Attributes}).
+attributes of @code{struct} and @code{union} types when you define
+such types.  This keyword is followed by an attribute specification
+inside double parentheses.  Seven attributes are currently defined for
+types: @code{aligned}, @code{packed}, @code{transparent_union},
+@code{unused}, @code{deprecated}, @code{visibility}, and
+@code{may_alias}.  Other attributes are defined for functions
+(@pxref{Function Attributes}) and for variables (@pxref{Variable
+Attributes}).
 
 You may also specify any one of these attributes with @samp{__}
 preceding and following its keyword.  This allows you to use these
@@ -3451,14 +3481,13 @@ attributes in header files without being concerned about a possible
 macro of the same name.  For example, you may use @code{__aligned__}
 instead of @code{aligned}.
 
-You may specify the @code{aligned} and @code{transparent_union}
-attributes either in a @code{typedef} declaration or just past the
-closing curly brace of a complete enum, struct or union type
-@emph{definition} and the @code{packed} attribute only past the closing
-brace of a definition.
+You may specify type attributes either in a @code{typedef} declaration
+or in an enum, struct or union type declaration or definition.
 
-You may also specify attributes between the enum, struct or union
-tag and the name of the type rather than after the closing brace.
+For an enum, struct or union type, you may specify attributes either
+between the enum, struct or union tag and the name of the type, or
+just past the closing curly brace of the @emph{definition}.  The
+former syntax is preferred.
 
 @xref{Attribute Syntax}, for details of the exact syntax for using
 attributes.
@@ -3545,9 +3574,10 @@ alignment.  See your linker documentation for further information.
 
 @item packed
 This attribute, attached to @code{struct} or @code{union} type
-definition, specifies that each member 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.
+definition, specifies that each member (other than zero-width bitfields)
+of the structure or union is placed to minimize the memory required.  When
+attached to an @code{enum} definition, it indicates that the smallest
+integral type should be used.
 
 @opindex fshort-enums
 Specifying this attribute for @code{struct} and @code{union} types is
@@ -3558,7 +3588,7 @@ attribute on all @code{enum} definitions.
 
 In the following example @code{struct my_packed_struct}'s members are
 packed closely together, but the internal layout of its @code{s} member
-is not packed -- to do that, @code{struct my_unpacked_struct} would need to
+is not packed---to do that, @code{struct my_unpacked_struct} would need to
 be packed too.
 
 @smallexample
@@ -3568,7 +3598,7 @@ struct my_unpacked_struct
     int i;
  @};
 
-struct my_packed_struct __attribute__ ((__packed__))
+struct __attribute__ ((__packed__)) my_packed_struct
   @{
      char c;
      int  i;
@@ -3706,6 +3736,43 @@ declaration, the above program would abort when compiled with
 @option{-fstrict-aliasing}, which is on by default at @option{-O2} or
 above in recent GCC versions.
 
+@item visibility
+In C++, attribute visibility (@pxref{Function Attributes}) can also be
+applied to class, struct, union and enum types.  Unlike other type
+attributes, the attribute must appear between the initial keyword and
+the name of the type; it cannot appear after the body of the type.
+
+Note that the type visibility is applied to vague linkage entities
+associated with the class (vtable, typeinfo node, etc.).  In
+particular, if a class is thrown as an exception in one shared object
+and caught in another, the class must have default visibility.
+Otherwise the two shared objects will be unable to use the same
+typeinfo node and exception handling will break.
+
+@subsection ARM Type Attributes
+
+On those ARM targets that support @code{dllimport} (such as Symbian
+OS), you can use the @code{notshared} attribute to indicate that the
+virtual table and other similar data for a class should not be
+exported from a DLL@.  For example:
+
+@smallexample
+class __declspec(notshared) C @{
+public:
+  __declspec(dllimport) C();
+  virtual void f();
+@}
+
+__declspec(dllexport)
+C::C() @{@}
+@end smallexample
+
+In this code, @code{C::C} is exported from the current DLL, but the
+virtual table for @code{C} is not exported.  (You can use
+@code{__attribute__} instead of @code{__declspec} if you prefer, but
+most Symbian OS code uses @code{__declspec}.)
+
+@anchor{i386 Type Attributes}
 @subsection i386 Type Attributes
 
 Two attributes are currently defined for i386 configurations:
@@ -3731,6 +3798,30 @@ To specify multiple attributes, separate them by commas within the
 double parentheses: for example, @samp{__attribute__ ((aligned (16),
 packed))}.
 
+@anchor{PowerPC Type Attributes}
+@subsection PowerPC Type Attributes
+
+Three attributes currently are defined for PowerPC configurations:
+@code{altivec}, @code{ms_struct} and @code{gcc_struct}.
+
+For full documentation of the struct attributes please see the
+documentation in the @xref{i386 Type Attributes}, section.
+
+The @code{altivec} attribute allows one to declare AltiVec vector data
+types supported by the AltiVec Programming Interface Manual.  The
+attribute requires an argument to specify one of three vector types:
+@code{vector__}, @code{pixel__} (always followed by unsigned short),
+and @code{bool__} (always followed by unsigned).
+
+@smallexample
+__attribute__((altivec(vector__)))
+__attribute__((altivec(pixel__))) unsigned short
+__attribute__((altivec(bool__))) unsigned
+@end smallexample
+
+These attributes mainly are intended to support the @code{__vector},
+@code{__pixel}, and @code{__bool} AltiVec keywords.
+
 @node Inline
 @section An Inline Function is As Fast As a Macro
 @cindex inline functions
@@ -3751,7 +3842,15 @@ you don't use @option{-O}, no function is really inline.
 
 Inline functions are included in the ISO C99 standard, but there are
 currently substantial differences between what GCC implements and what
-the ISO C99 standard requires.
+the ISO C99 standard requires.  GCC will fully support C99 inline
+functions in version 4.3.  The traditional GCC handling of inline
+functions will still be available with @option{-std=gnu89},
+@option{-fgnu89-inline} or when @code{gnu_inline} attribute is present
+on all inline declarations.  The preprocessor macros
+@code{__GNUC_GNU_INLINE__} and @code{__GNUC_STDC_INLINE__} may be used
+to determine the handling of @code{inline} during a particular
+compilation (@pxref{Common Predefined Macros,,,cpp,The C
+Preprocessor}).
 
 To declare a function inline, use the @code{inline} keyword in its
 declaration, like this:
@@ -3827,18 +3926,21 @@ The definition in the header file will cause most calls to the function
 to be inlined.  If any uses of the function remain, they will refer to
 the single copy in the library.
 
-Since GCC eventually will implement ISO C99 semantics for
-inline functions, it is best to use @code{static inline} only
+Since GCC 4.3 will implement ISO C99 semantics for
+inline functions, it is simplest to use @code{static inline} only
 to guarantee compatibility.  (The
 existing semantics will remain available when @option{-std=gnu89} is
-specified, but eventually the default will be @option{-std=gnu99} and
-that will implement the C99 semantics, though it does not do so yet.)
+specified, but eventually the default will be @option{-std=gnu99};
+that will implement the C99 semantics, though it does not do so in
+versions of GCC before 4.3.  After the default changes, the existing
+semantics will still be available via the @option{-fgnu89-inline}
+option or the @code{gnu_inline} function attribute.)
 
 GCC does not inline any functions when not optimizing unless you specify
 the @samp{always_inline} attribute for the function, like this:
 
 @smallexample
-/* Prototype.  */
+/* @r{Prototype.}  */
 inline void foo (const char) __attribute__((always_inline));
 @end smallexample
 
@@ -3878,7 +3980,7 @@ template from the first output operand and another separates the last
 output operand from the first input, if any.  Commas separate the
 operands within each group.  The total number of operands is currently
 limited to 30; this limitation may be lifted in some future version of
-GCC.
+GCC@.
 
 If there are no output operands but there are input operands, you must
 place two consecutive colons surrounding the place where the output
@@ -3970,6 +4072,37 @@ asm ("cmoveq %1,%2,%[result]"
      : "r" (test), "r"(new), "[result]"(old));
 @end smallexample
 
+Sometimes you need to make an @code{asm} operand be a specific register,
+but there's no matching constraint letter for that register @emph{by
+itself}.  To force the operand into that register, use a local variable
+for the operand and specify the register in the variable declaration.
+@xref{Explicit Reg Vars}.  Then for the @code{asm} operand, use any
+register constraint letter that matches the register:
+
+@smallexample
+register int *p1 asm ("r0") = @dots{};
+register int *p2 asm ("r1") = @dots{};
+register int *result asm ("r0");
+asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
+@end smallexample
+
+@anchor{Example of asm with clobbered asm reg}
+In the above example, beware that a register that is call-clobbered by
+the target ABI will be overwritten by any function call in the
+assignment, including library calls for arithmetic operators.
+Assuming it is a call-clobbered register, this may happen to @code{r0}
+above by the assignment to @code{p2}.  If you have to use such a
+register, use temporary variables for expressions between the register
+assignment and use:
+
+@smallexample
+int t1 = @dots{};
+register int *p1 asm ("r0") = @dots{};
+register int *p2 asm ("r1") = t1;
+register int *result asm ("r0");
+asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
+@end smallexample
+
 Some instructions clobber specific hard registers.  To describe this,
 write a third colon after the input operands, followed by the names of
 the clobbered hard registers (given as strings).  Here is a realistic
@@ -3977,7 +4110,7 @@ example for the VAX:
 
 @smallexample
 asm volatile ("movc3 %0,%1,%2"
-              : /* no outputs */
+              : /* @r{no outputs} */
               : "g" (from), "g" (to), "g" (count)
               : "r0", "r1", "r2", "r3", "r4", "r5");
 @end smallexample
@@ -4020,13 +4153,13 @@ it as input or output but if this is not known, you should add
 @samp{memory}.  As an example, if you access ten bytes of a string, you
 can use a memory input like:
 
-@example
+@smallexample
 @{"m"( (@{ struct @{ char x[10]; @} *p = (void *)ptr ; *p; @}) )@}.
-@end example
+@end smallexample
 
 Note that in the following example the memory input is necessary,
 otherwise GCC might optimize the store to @code{x} away:
-@example
+@smallexample
 int foo ()
 @{
   int x = 42;
@@ -4034,9 +4167,9 @@ int foo ()
   int result;
   asm ("magic stuff accessing an 'int' pointed to by '%1'"
         "=&d" (r) : "a" (y), "m" (*y));
-  return result;     
+  return result;
 @}
-@end example
+@end smallexample
 
 You can put multiple assembler instructions together in a single
 @code{asm} template, separated by the characters normally used in assembly
@@ -4118,8 +4251,8 @@ if your instruction does have a side effect on a variable that otherwise
 appears not to change, the old value of the variable may be reused later
 if it happens to be found in a register.
 
-You can prevent an @code{asm} instruction from being deleted, moved
-significantly, or combined, by writing the keyword @code{volatile} after
+You can prevent an @code{asm} instruction from being deleted
+by writing the keyword @code{volatile} after
 the @code{asm}.  For example:
 
 @smallexample
@@ -4131,40 +4264,42 @@ the @code{asm}.  For example:
 @end smallexample
 
 @noindent
-If you write an @code{asm} instruction with no outputs, GCC will know
-the instruction has side-effects and will not delete the instruction or
-move it outside of loops.
-
 The @code{volatile} keyword indicates that the instruction has
 important side-effects.  GCC will not delete a volatile @code{asm} if
 it is reachable.  (The instruction can still be deleted if GCC can
 prove that control-flow will never reach the location of the
-instruction.)  In addition, GCC will not reschedule instructions
-across a volatile @code{asm} instruction.  For example:
+instruction.)  Note that even a volatile @code{asm} instruction
+can be moved relative to other code, including across jump
+instructions.  For example, on many targets there is a system
+register which can be set to control the rounding mode of
+floating point operations.  You might try
+setting it with a volatile @code{asm}, like this PowerPC example:
 
 @smallexample
-*(volatile int *)addr = foo;
-asm volatile ("eieio" : : );
+       asm volatile("mtfsf 255,%0" : : "f" (fpenv));
+       sum = x + y;
 @end smallexample
 
 @noindent
-Assume @code{addr} contains the address of a memory mapped device
-register.  The PowerPC @code{eieio} instruction (Enforce In-order
-Execution of I/O) tells the CPU to make sure that the store to that
-device register happens before it issues any other I/O@.
-
-Note that even a volatile @code{asm} instruction can be moved in ways
-that appear insignificant to the compiler, such as across jump
-instructions.  You can't expect a sequence of volatile @code{asm}
-instructions to remain perfectly consecutive.  If you want consecutive
-output, use a single @code{asm}.  Also, GCC will perform some
-optimizations across a volatile @code{asm} instruction; GCC does not
-``forget everything'' when it encounters a volatile @code{asm}
-instruction the way some other compilers do.
-
-An @code{asm} instruction without any operands or clobbers (an ``old
-style'' @code{asm}) will be treated identically to a volatile
-@code{asm} instruction.
+This will not work reliably, as the compiler may move the addition back
+before the volatile @code{asm}.  To make it work you need to add an
+artificial dependency to the @code{asm} referencing a variable in the code
+you don't want moved, for example:
+
+@smallexample
+    asm volatile ("mtfsf 255,%1" : "=X"(sum): "f"(fpenv));
+    sum = x + y;
+@end smallexample
+
+Similarly, you can't expect a
+sequence of volatile @code{asm} instructions to remain perfectly
+consecutive.  If you want consecutive output, use a single @code{asm}.
+Also, GCC will perform some optimizations across a volatile @code{asm}
+instruction; GCC does not ``forget everything'' when it encounters
+a volatile @code{asm} instruction the way some other compilers do.
+
+An @code{asm} instruction without any output operands will be treated
+identically to a volatile @code{asm} instruction.
 
 It is a natural idea to look for a way to give access to the condition
 code left by the assembler instruction.  However, when we attempted to
@@ -4363,7 +4498,9 @@ very often.
 
 @item
 Local register variables in specific registers do not reserve the
-registers.  The compiler's data flow analysis is capable of determining
+registers, except at the point where they are used as input or output
+operands in an @code{asm} statement and the @code{asm} statement itself is
+not deleted.  The compiler's data flow analysis is capable of determining
 where the specified registers contain live values, and where they are
 available for other uses.  Stores into local register variables may be deleted
 when they appear to be dead according to dataflow analysis.  References
@@ -4508,20 +4645,34 @@ example, some 68000 operating systems call this register @code{%a5}.
 
 Defining such a register variable does not reserve the register; it
 remains available for other uses in places where flow control determines
-the variable's value is not live.  However, these registers are made
-unavailable for use in the reload pass; excessive use of this feature
-leaves the compiler too few available registers to compile certain
-functions.
+the variable's value is not live.
 
 This option does not guarantee that GCC will generate code that has
 this variable in the register you specify at all times.  You may not
-code an explicit reference to this register in an @code{asm} statement
-and assume it will always refer to this variable.
+code an explicit reference to this register in the @emph{assembler
+instruction template} part of an @code{asm} statement and assume it will
+always refer to this variable.  However, using the variable as an
+@code{asm} @emph{operand} guarantees that the specified register is used
+for the operand.
 
 Stores into local register variables may be deleted when they appear to be dead
 according to dataflow analysis.  References to local register variables may
 be deleted or moved or simplified.
 
+As for global register variables, it's recommended that you choose a
+register which is normally saved and restored by function calls on
+your machine, so that library routines will not clobber it.  A common
+pitfall is to initialize multiple call-clobbered registers with
+arbitrary expressions, where a function call or library call for an
+arithmetic operator will overwrite a register value from a previous
+assignment, for example @code{r0} below:
+@smallexample
+register int *p1 asm ("r0") = @dots{};
+register int *p2 asm ("r1") = @dots{};
+@end smallexample
+In those cases, a solution is to use a temporary variable for
+each arbitrary expression.   @xref{Example of asm with clobbered asm reg}.
+
 @node Alternate Keywords
 @section Alternate Keywords
 @cindex alternate keywords
@@ -4671,7 +4822,7 @@ This function returns the return address of the current function, or of
 one of its callers.  The @var{level} argument is number of frames to
 scan up the call stack.  A value of @code{0} yields the return address
 of the current function, a value of @code{1} yields the return address
-of the caller of the current function, and so forth. When inlining
+of the caller of the current function, and so forth.  When inlining
 the expected behavior is that the function will return the address of
 the function that will be returned to.  To work around this behavior use
 the @code{noinline} function attribute.
@@ -4681,7 +4832,7 @@ The @var{level} argument must be a constant integer.
 On some machines it may be impossible to determine the return address of
 any function other than the current one; in such cases, or when the top
 of the stack has been reached, this function will return @code{0} or a
-random value. In addition, @code{__builtin_frame_address} may be used
+random value.  In addition, @code{__builtin_frame_address} may be used
 to determine if the top of the stack has been reached.
 
 This function should only be used with a nonzero argument for debugging
@@ -4725,30 +4876,24 @@ The first step in using these extensions is to provide the necessary data
 types.  This should be done using an appropriate @code{typedef}:
 
 @smallexample
-typedef int v4si __attribute__ ((mode(V4SI)));
+typedef int v4si __attribute__ ((vector_size (16)));
 @end smallexample
 
-The base type @code{int} is effectively ignored by the compiler, the
-actual properties of the new type @code{v4si} are defined by the
-@code{__attribute__}.  It defines the machine mode to be used; for vector
-types these have the form @code{V@var{n}@var{B}}; @var{n} should be the
-number of elements in the vector, and @var{B} should be the base mode of the
-individual elements.  The following can be used as base modes:
+The @code{int} type specifies the base type, while the attribute specifies
+the vector size for the variable, measured in bytes.  For example, the
+declaration above causes the compiler to set the mode for the @code{v4si}
+type to be 16 bytes wide and divided into @code{int} sized units.  For
+a 32-bit @code{int} this means a vector of 4 units of 4 bytes, and the
+corresponding mode of @code{foo} will be @acronym{V4SI}.
 
-@table @code
-@item QI
-An integer that is as wide as the smallest addressable unit, usually 8 bits.
-@item HI
-An integer, twice as wide as a QI mode integer, usually 16 bits.
-@item SI
-An integer, four times as wide as a QI mode integer, usually 32 bits.
-@item DI
-An integer, eight times as wide as a QI mode integer, usually 64 bits.
-@item SF
-A floating point value, as wide as a SI mode integer, usually 32 bits.
-@item DF
-A floating point value, as wide as a DI mode integer, usually 64 bits.
-@end table
+The @code{vector_size} attribute is only applicable to integral and
+float scalars, although arrays, pointers, and function return values
+are allowed in conjunction with this construct.
+
+All the basic integer types can be used as base types, both as signed
+and as unsigned: @code{char}, @code{short}, @code{int}, @code{long},
+@code{long long}.  In addition, @code{float} and @code{double} can be
+used to build floating-point vector types.
 
 Specifying a combination that is not valid for the current architecture
 will cause GCC to synthesize the instructions using a narrower mode.
@@ -4767,7 +4912,7 @@ added to the corresponding 4 elements in @var{b} and the resulting
 vector will be stored in @var{c}.
 
 @smallexample
-typedef int v4si __attribute__ ((mode(V4SI)));
+typedef int v4si __attribute__ ((vector_size (16)));
 
 v4si a, b, c;
 
@@ -4804,6 +4949,292 @@ v4si f (v4si a, v4si b, v4si c)
 
 @end smallexample
 
+@node Offsetof
+@section Offsetof
+@findex __builtin_offsetof
+
+GCC implements for both C and C++ a syntactic extension to implement
+the @code{offsetof} macro.
+
+@smallexample
+primary:
+	"__builtin_offsetof" "(" @code{typename} "," offsetof_member_designator ")"
+
+offsetof_member_designator:
+	  @code{identifier}
+	| offsetof_member_designator "." @code{identifier}
+	| offsetof_member_designator "[" @code{expr} "]"
+@end smallexample
+
+This extension is sufficient such that
+
+@smallexample
+#define offsetof(@var{type}, @var{member})  __builtin_offsetof (@var{type}, @var{member})
+@end smallexample
+
+is a suitable definition of the @code{offsetof} macro.  In C++, @var{type}
+may be dependent.  In either case, @var{member} may consist of a single
+identifier, or a sequence of member accesses and array references.
+
+@node Atomic Builtins
+@section Built-in functions for atomic memory access
+
+The following builtins 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 ``__builtin_'' prefix, and further that they are overloaded such 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
+counterparts.  GCC will allow any integral scalar or pointer type that is
+1, 2, 4 or 8 bytes in length.
+
+Not all operations are supported by all target processors.  If a particular
+operation cannot be implemented on the target processor, a warning will be
+generated and a call an external function will be generated.  The external
+function will carry the same name as the builtin, with an additional suffix
+@samp{_@var{n}} where @var{n} is the size of the data type.
+
+@c ??? Should we have a mechanism to suppress this warning?  This is almost
+@c useful for implementing the operation under the control of an external
+@c mutex.
+
+In most cases, these builtins are considered a @dfn{full barrier}.  That is,
+no memory operand will be moved across the operation, either forward or
+backward.  Further, instructions will be issued as necessary to prevent the
+processor from speculating loads across the operation and from queuing stores
+after the operation.
+
+All of the routines are 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 which 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.
+
+@table @code
+@item @var{type} __sync_fetch_and_add (@var{type} *ptr, @var{type} value, ...)
+@itemx @var{type} __sync_fetch_and_sub (@var{type} *ptr, @var{type} value, ...)
+@itemx @var{type} __sync_fetch_and_or (@var{type} *ptr, @var{type} value, ...)
+@itemx @var{type} __sync_fetch_and_and (@var{type} *ptr, @var{type} value, ...)
+@itemx @var{type} __sync_fetch_and_xor (@var{type} *ptr, @var{type} value, ...)
+@itemx @var{type} __sync_fetch_and_nand (@var{type} *ptr, @var{type} value, ...)
+@findex __sync_fetch_and_add
+@findex __sync_fetch_and_sub
+@findex __sync_fetch_and_or
+@findex __sync_fetch_and_and
+@findex __sync_fetch_and_xor
+@findex __sync_fetch_and_nand
+These builtins perform the operation suggested by the name, and
+returns the value that had previously been in memory.  That is,
+
+@smallexample
+@{ tmp = *ptr; *ptr @var{op}= value; return tmp; @}
+@{ tmp = *ptr; *ptr = ~tmp & value; return tmp; @}   // nand
+@end smallexample
+
+@item @var{type} __sync_add_and_fetch (@var{type} *ptr, @var{type} value, ...)
+@itemx @var{type} __sync_sub_and_fetch (@var{type} *ptr, @var{type} value, ...)
+@itemx @var{type} __sync_or_and_fetch (@var{type} *ptr, @var{type} value, ...)
+@itemx @var{type} __sync_and_and_fetch (@var{type} *ptr, @var{type} value, ...)
+@itemx @var{type} __sync_xor_and_fetch (@var{type} *ptr, @var{type} value, ...)
+@itemx @var{type} __sync_nand_and_fetch (@var{type} *ptr, @var{type} value, ...)
+@findex __sync_add_and_fetch
+@findex __sync_sub_and_fetch
+@findex __sync_or_and_fetch
+@findex __sync_and_and_fetch
+@findex __sync_xor_and_fetch
+@findex __sync_nand_and_fetch
+These builtins perform the operation suggested by the name, and
+return the new value.  That is,
+
+@smallexample
+@{ *ptr @var{op}= value; return *ptr; @}
+@{ *ptr = ~*ptr & value; return *ptr; @}   // nand
+@end smallexample
+
+@item bool __sync_bool_compare_and_swap (@var{type} *ptr, @var{type} oldval @var{type} newval, ...)
+@itemx @var{type} __sync_val_compare_and_swap (@var{type} *ptr, @var{type} oldval @var{type} newval, ...)
+@findex __sync_bool_compare_and_swap
+@findex __sync_val_compare_and_swap
+These builtins perform an atomic compare and swap.  That is, if the current
+value of @code{*@var{ptr}} is @var{oldval}, then write @var{newval} into
+@code{*@var{ptr}}.
+
+The ``bool'' version returns true if the comparison is successful and
+@var{newval} was written.  The ``val'' version returns the contents
+of @code{*@var{ptr}} before the operation.
+
+@item __sync_synchronize (...)
+@findex __sync_synchronize
+This builtin issues a full memory barrier.
+
+@item @var{type} __sync_lock_test_and_set (@var{type} *ptr, @var{type} value, ...)
+@findex __sync_lock_test_and_set
+This builtin, as described by Intel, is not a traditional test-and-set
+operation, but rather an atomic exchange operation.  It writes @var{value}
+into @code{*@var{ptr}}, and returns the previous contents of
+@code{*@var{ptr}}.
+
+Many targets have only minimal support for such locks, and do not support
+a full exchange operation.  In this case, a target may support reduced
+functionality here by which the @emph{only} valid value to store is the
+immediate constant 1.  The exact value actually stored in @code{*@var{ptr}}
+is implementation defined.
+
+This builtin is not a full barrier, but rather an @dfn{acquire barrier}.
+This means that references after the builtin cannot move to (or be
+speculated to) before the builtin, but previous memory stores may not
+be globally visible yet, and previous memory loads may not yet be
+satisfied.
+
+@item void __sync_lock_release (@var{type} *ptr, ...)
+@findex __sync_lock_release
+This builtin releases the lock acquired by @code{__sync_lock_test_and_set}.
+Normally this means writing the constant 0 to @code{*@var{ptr}}.
+
+This builtin is not a full barrier, but rather a @dfn{release barrier}.
+This means that all previous memory stores are globally visible, and all
+previous memory loads have been satisfied, but following memory reads
+are not prevented from being speculated to before the barrier.
+@end table
+
+@node Object Size Checking
+@section Object Size Checking Builtins
+@findex __builtin_object_size
+@findex __builtin___memcpy_chk
+@findex __builtin___mempcpy_chk
+@findex __builtin___memmove_chk
+@findex __builtin___memset_chk
+@findex __builtin___strcpy_chk
+@findex __builtin___stpcpy_chk
+@findex __builtin___strncpy_chk
+@findex __builtin___strcat_chk
+@findex __builtin___strncat_chk
+@findex __builtin___sprintf_chk
+@findex __builtin___snprintf_chk
+@findex __builtin___vsprintf_chk
+@findex __builtin___vsnprintf_chk
+@findex __builtin___printf_chk
+@findex __builtin___vprintf_chk
+@findex __builtin___fprintf_chk
+@findex __builtin___vfprintf_chk
+
+GCC implements a limited buffer overflow protection mechanism
+that can prevent some buffer overflow attacks.
+
+@deftypefn {Built-in Function} {size_t} __builtin_object_size (void * @var{ptr}, int @var{type})
+is a built-in construct that returns a constant number of bytes from
+@var{ptr} to the end of the object @var{ptr} pointer points to
+(if known at compile time).  @code{__builtin_object_size} never evaluates
+its arguments for side-effects.  If there are any side-effects in them, it
+returns @code{(size_t) -1} for @var{type} 0 or 1 and @code{(size_t) 0}
+for @var{type} 2 or 3.  If there are multiple objects @var{ptr} can
+point to and all of them are known at compile time, the returned number
+is the maximum of remaining byte counts in those objects if @var{type} & 2 is
+0 and minimum if nonzero.  If it is not possible to determine which objects
+@var{ptr} points to at compile time, @code{__builtin_object_size} should
+return @code{(size_t) -1} for @var{type} 0 or 1 and @code{(size_t) 0}
+for @var{type} 2 or 3.
+
+@var{type} is an integer constant from 0 to 3.  If the least significant
+bit is clear, objects are whole variables, if it is set, a closest
+surrounding subobject is considered the object a pointer points to.
+The second bit determines if maximum or minimum of remaining bytes
+is computed.
+
+@smallexample
+struct V @{ char buf1[10]; int b; char buf2[10]; @} var;
+char *p = &var.buf1[1], *q = &var.b;
+
+/* Here the object p points to is var.  */
+assert (__builtin_object_size (p, 0) == sizeof (var) - 1);
+/* The subobject p points to is var.buf1.  */
+assert (__builtin_object_size (p, 1) == sizeof (var.buf1) - 1);
+/* The object q points to is var.  */
+assert (__builtin_object_size (q, 0)
+	== (char *) (&var + 1) - (char *) &var.b);
+/* The subobject q points to is var.b.  */
+assert (__builtin_object_size (q, 1) == sizeof (var.b));
+@end smallexample
+@end deftypefn
+
+There are built-in functions added for many common string operation
+functions, e.g. for @code{memcpy} @code{__builtin___memcpy_chk}
+built-in is provided.  This built-in has an additional last argument,
+which is the number of bytes remaining in object the @var{dest}
+argument points to or @code{(size_t) -1} if the size is not known.
+
+The built-in functions are optimized into the normal string functions
+like @code{memcpy} if the last argument is @code{(size_t) -1} or if
+it is known at compile time that the destination object will not
+be overflown.  If the compiler can determine at compile time the
+object will be always overflown, it issues a warning.
+
+The intended use can be e.g.
+
+@smallexample
+#undef memcpy
+#define bos0(dest) __builtin_object_size (dest, 0)
+#define memcpy(dest, src, n) \
+  __builtin___memcpy_chk (dest, src, n, bos0 (dest))
+
+char *volatile p;
+char buf[10];
+/* It is unknown what object p points to, so this is optimized
+   into plain memcpy - no checking is possible.  */
+memcpy (p, "abcde", n);
+/* Destination is known and length too.  It is known at compile
+   time there will be no overflow.  */
+memcpy (&buf[5], "abcde", 5);
+/* Destination is known, but the length is not known at compile time.
+   This will result in __memcpy_chk call that can check for overflow
+   at runtime.  */
+memcpy (&buf[5], "abcde", n);
+/* Destination is known and it is known at compile time there will
+   be overflow.  There will be a warning and __memcpy_chk call that
+   will abort the program at runtime.  */
+memcpy (&buf[6], "abcde", 5);
+@end smallexample
+
+Such built-in functions are provided for @code{memcpy}, @code{mempcpy},
+@code{memmove}, @code{memset}, @code{strcpy}, @code{stpcpy}, @code{strncpy},
+@code{strcat} and @code{strncat}.
+
+There are also checking built-in functions for formatted output functions.
+@smallexample
+int __builtin___sprintf_chk (char *s, int flag, size_t os, const char *fmt, ...);
+int __builtin___snprintf_chk (char *s, size_t maxlen, int flag, size_t os,
+			      const char *fmt, ...);
+int __builtin___vsprintf_chk (char *s, int flag, size_t os, const char *fmt,
+			      va_list ap);
+int __builtin___vsnprintf_chk (char *s, size_t maxlen, int flag, size_t os,
+			       const char *fmt, va_list ap);
+@end smallexample
+
+The added @var{flag} argument is passed unchanged to @code{__sprintf_chk}
+etc. functions and can contain implementation specific flags on what
+additional security measures the checking function might take, such as
+handling @code{%n} differently.
+
+The @var{os} argument is the object size @var{s} points to, like in the
+other built-in functions.  There is a small difference in the behavior
+though, if @var{os} is @code{(size_t) -1}, the built-in functions are
+optimized into the non-checking functions only if @var{flag} is 0, otherwise
+the checking function is called with @var{os} argument set to
+@code{(size_t) -1}.
+
+In addition to this, there are checking built-in functions
+@code{__builtin___printf_chk}, @code{__builtin___vprintf_chk},
+@code{__builtin___fprintf_chk} and @code{__builtin___vfprintf_chk}.
+These have just one additional argument, @var{flag}, right before
+format string @var{fmt}.  If the compiler is able to optimize them to
+@code{fputc} etc. functions, it will, otherwise the checking function
+should be called and the @var{flag} argument passed to it.
+
 @node Other Builtins
 @section Other built-in functions provided by GCC
 @cindex built-in functions
@@ -4813,6 +5244,9 @@ v4si f (v4si a, v4si b, v4si c)
 @findex __builtin_islessequal
 @findex __builtin_islessgreater
 @findex __builtin_isunordered
+@findex __builtin_powi
+@findex __builtin_powif
+@findex __builtin_powil
 @findex _Exit
 @findex _exit
 @findex abort
@@ -4884,6 +5318,9 @@ v4si f (v4si a, v4si b, v4si c)
 @findex cimag
 @findex cimagf
 @findex cimagl
+@findex clog
+@findex clogf
+@findex clogl
 @findex conj
 @findex conjf
 @findex conjl
@@ -4986,6 +5423,31 @@ v4si f (v4si a, v4si b, v4si c)
 @findex ilogbl
 @findex imaxabs
 @findex index
+@findex isalnum
+@findex isalpha
+@findex isascii
+@findex isblank
+@findex iscntrl
+@findex isdigit
+@findex isgraph
+@findex islower
+@findex isprint
+@findex ispunct
+@findex isspace
+@findex isupper
+@findex iswalnum
+@findex iswalpha
+@findex iswblank
+@findex iswcntrl
+@findex iswdigit
+@findex iswgraph
+@findex iswlower
+@findex iswprint
+@findex iswpunct
+@findex iswspace
+@findex iswupper
+@findex iswxdigit
+@findex isxdigit
 @findex j0
 @findex j0f
 @findex j0l
@@ -5079,6 +5541,9 @@ v4si f (v4si a, v4si b, v4si c)
 @findex scalbn
 @findex scalbnf
 @findex scanfnl
+@findex signbit
+@findex signbitf
+@findex signbitl
 @findex significand
 @findex significandf
 @findex significandl
@@ -5098,6 +5563,8 @@ v4si f (v4si a, v4si b, v4si c)
 @findex sqrtl
 @findex sscanf
 @findex stpcpy
+@findex stpncpy
+@findex strcasecmp
 @findex strcat
 @findex strchr
 @findex strcmp
@@ -5107,9 +5574,11 @@ v4si f (v4si a, v4si b, v4si c)
 @findex strfmon
 @findex strftime
 @findex strlen
+@findex strncasecmp
 @findex strncat
 @findex strncmp
 @findex strncpy
+@findex strndup
 @findex strpbrk
 @findex strrchr
 @findex strspn
@@ -5123,6 +5592,11 @@ v4si f (v4si a, v4si b, v4si c)
 @findex tgamma
 @findex tgammaf
 @findex tgammal
+@findex toascii
+@findex tolower
+@findex toupper
+@findex towlower
+@findex towupper
 @findex trunc
 @findex truncf
 @findex truncl
@@ -5155,7 +5629,7 @@ The remaining functions are provided for optimization purposes.
 GCC includes built-in versions of many of the functions in the standard
 C library.  The versions prefixed with @code{__builtin_} will always be
 treated as having the same meaning as the C library function even if you
-specify the @option{-fno-builtin} option. (@pxref{C Dialect Options})
+specify the @option{-fno-builtin} option.  (@pxref{C Dialect Options})
 Many of these functions are only optimized in certain cases; if they are
 not optimized in a particular case, a call to the library function will
 be emitted.
@@ -5169,14 +5643,17 @@ Outside strict ISO C mode (@option{-ansi}, @option{-std=c89} or
 @code{drem}, @code{exp10f}, @code{exp10l}, @code{exp10}, @code{ffsll},
 @code{ffsl}, @code{ffs}, @code{fprintf_unlocked}, @code{fputs_unlocked},
 @code{gammaf}, @code{gammal}, @code{gamma}, @code{gettext},
-@code{index}, @code{j0f}, @code{j0l}, @code{j0}, @code{j1f}, @code{j1l},
-@code{j1}, @code{jnf}, @code{jnl}, @code{jn}, @code{mempcpy},
-@code{pow10f}, @code{pow10l}, @code{pow10}, @code{printf_unlocked},
-@code{rindex}, @code{scalbf}, @code{scalbl}, @code{scalb},
+@code{index}, @code{isascii}, @code{j0f}, @code{j0l}, @code{j0},
+@code{j1f}, @code{j1l}, @code{j1}, @code{jnf}, @code{jnl}, @code{jn},
+@code{mempcpy}, @code{pow10f}, @code{pow10l}, @code{pow10},
+@code{printf_unlocked}, @code{rindex}, @code{scalbf}, @code{scalbl},
+@code{scalb}, @code{signbit}, @code{signbitf}, @code{signbitl},
 @code{significandf}, @code{significandl}, @code{significand},
 @code{sincosf}, @code{sincosl}, @code{sincos}, @code{stpcpy},
-@code{strdup}, @code{strfmon}, @code{y0f}, @code{y0l}, @code{y0},
-@code{y1f}, @code{y1l}, @code{y1}, @code{ynf}, @code{ynl} and @code{yn}
+@code{stpncpy}, @code{strcasecmp}, @code{strdup}, @code{strfmon},
+@code{strncasecmp}, @code{strndup}, @code{toascii}, @code{y0f},
+@code{y0l}, @code{y0}, @code{y1f}, @code{y1l}, @code{y1}, @code{ynf},
+@code{ynl} and @code{yn}
 may be handled as built-in functions.
 All these functions have corresponding versions
 prefixed with @code{__builtin_}, which may be used even in strict C89
@@ -5193,36 +5670,35 @@ The ISO C99 functions
 @code{catanl}, @code{catan}, @code{cbrtf}, @code{cbrtl}, @code{cbrt},
 @code{ccosf}, @code{ccoshf}, @code{ccoshl}, @code{ccosh}, @code{ccosl},
 @code{ccos}, @code{cexpf}, @code{cexpl}, @code{cexp}, @code{cimagf},
-@code{cimagl}, @code{cimag},
-@code{conjf}, @code{conjl}, @code{conj}, @code{copysignf},
-@code{copysignl}, @code{copysign}, @code{cpowf}, @code{cpowl},
-@code{cpow}, @code{cprojf}, @code{cprojl}, @code{cproj}, @code{crealf},
-@code{creall}, @code{creal}, @code{csinf}, @code{csinhf}, @code{csinhl},
-@code{csinh}, @code{csinl}, @code{csin}, @code{csqrtf}, @code{csqrtl},
-@code{csqrt}, @code{ctanf}, @code{ctanhf}, @code{ctanhl}, @code{ctanh},
-@code{ctanl}, @code{ctan}, @code{erfcf}, @code{erfcl}, @code{erfc},
-@code{erff}, @code{erfl}, @code{erf}, @code{exp2f}, @code{exp2l},
-@code{exp2}, @code{expm1f}, @code{expm1l}, @code{expm1}, @code{fdimf},
-@code{fdiml}, @code{fdim}, @code{fmaf}, @code{fmal}, @code{fmaxf},
-@code{fmaxl}, @code{fmax}, @code{fma}, @code{fminf}, @code{fminl},
-@code{fmin}, @code{hypotf}, @code{hypotl}, @code{hypot}, @code{ilogbf},
-@code{ilogbl}, @code{ilogb}, @code{imaxabs}, @code{lgammaf},
-@code{lgammal}, @code{lgamma}, @code{llabs}, @code{llrintf},
-@code{llrintl}, @code{llrint}, @code{llroundf}, @code{llroundl},
-@code{llround}, @code{log1pf}, @code{log1pl}, @code{log1p},
-@code{log2f}, @code{log2l}, @code{log2}, @code{logbf}, @code{logbl},
-@code{logb}, @code{lrintf}, @code{lrintl}, @code{lrint}, @code{lroundf},
-@code{lroundl}, @code{lround}, @code{nearbyintf}, @code{nearbyintl},
-@code{nearbyint}, @code{nextafterf}, @code{nextafterl},
-@code{nextafter}, @code{nexttowardf}, @code{nexttowardl},
-@code{nexttoward}, @code{remainderf}, @code{remainderl},
-@code{remainder}, @code{remquof}, @code{remquol}, @code{remquo},
-@code{rintf}, @code{rintl}, @code{rint}, @code{roundf}, @code{roundl},
-@code{round}, @code{scalblnf}, @code{scalblnl}, @code{scalbln},
-@code{scalbnf}, @code{scalbnl}, @code{scalbn}, @code{snprintf},
-@code{tgammaf}, @code{tgammal}, @code{tgamma}, @code{truncf},
-@code{truncl}, @code{trunc}, @code{vfscanf}, @code{vscanf},
-@code{vsnprintf} and @code{vsscanf}
+@code{cimagl}, @code{cimag}, @code{clogf}, @code{clogl}, @code{clog},
+@code{conjf}, @code{conjl}, @code{conj}, @code{copysignf}, @code{copysignl},
+@code{copysign}, @code{cpowf}, @code{cpowl}, @code{cpow}, @code{cprojf},
+@code{cprojl}, @code{cproj}, @code{crealf}, @code{creall}, @code{creal},
+@code{csinf}, @code{csinhf}, @code{csinhl}, @code{csinh}, @code{csinl},
+@code{csin}, @code{csqrtf}, @code{csqrtl}, @code{csqrt}, @code{ctanf},
+@code{ctanhf}, @code{ctanhl}, @code{ctanh}, @code{ctanl}, @code{ctan},
+@code{erfcf}, @code{erfcl}, @code{erfc}, @code{erff}, @code{erfl},
+@code{erf}, @code{exp2f}, @code{exp2l}, @code{exp2}, @code{expm1f},
+@code{expm1l}, @code{expm1}, @code{fdimf}, @code{fdiml}, @code{fdim},
+@code{fmaf}, @code{fmal}, @code{fmaxf}, @code{fmaxl}, @code{fmax},
+@code{fma}, @code{fminf}, @code{fminl}, @code{fmin}, @code{hypotf},
+@code{hypotl}, @code{hypot}, @code{ilogbf}, @code{ilogbl}, @code{ilogb},
+@code{imaxabs}, @code{isblank}, @code{iswblank}, @code{lgammaf},
+@code{lgammal}, @code{lgamma}, @code{llabs}, @code{llrintf}, @code{llrintl},
+@code{llrint}, @code{llroundf}, @code{llroundl}, @code{llround},
+@code{log1pf}, @code{log1pl}, @code{log1p}, @code{log2f}, @code{log2l},
+@code{log2}, @code{logbf}, @code{logbl}, @code{logb}, @code{lrintf},
+@code{lrintl}, @code{lrint}, @code{lroundf}, @code{lroundl},
+@code{lround}, @code{nearbyintf}, @code{nearbyintl}, @code{nearbyint},
+@code{nextafterf}, @code{nextafterl}, @code{nextafter},
+@code{nexttowardf}, @code{nexttowardl}, @code{nexttoward},
+@code{remainderf}, @code{remainderl}, @code{remainder}, @code{remquof},
+@code{remquol}, @code{remquo}, @code{rintf}, @code{rintl}, @code{rint},
+@code{roundf}, @code{roundl}, @code{round}, @code{scalblnf},
+@code{scalblnl}, @code{scalbln}, @code{scalbnf}, @code{scalbnl},
+@code{scalbn}, @code{snprintf}, @code{tgammaf}, @code{tgammal},
+@code{tgamma}, @code{truncf}, @code{truncl}, @code{trunc},
+@code{vfscanf}, @code{vscanf}, @code{vsnprintf} and @code{vsscanf}
 are handled as built-in functions
 except in strict ISO C90 mode (@option{-ansi} or @option{-std=c89}).
 
@@ -5240,20 +5716,31 @@ that are recognized in any mode since ISO C90 reserves these names for
 the purpose to which ISO C99 puts them.  All these functions have
 corresponding versions prefixed with @code{__builtin_}.
 
+The ISO C94 functions
+@code{iswalnum}, @code{iswalpha}, @code{iswcntrl}, @code{iswdigit},
+@code{iswgraph}, @code{iswlower}, @code{iswprint}, @code{iswpunct},
+@code{iswspace}, @code{iswupper}, @code{iswxdigit}, @code{towlower} and
+@code{towupper}
+are handled as built-in functions
+except in strict ISO C90 mode (@option{-ansi} or @option{-std=c89}).
+
 The ISO C90 functions
 @code{abort}, @code{abs}, @code{acos}, @code{asin}, @code{atan2},
 @code{atan}, @code{calloc}, @code{ceil}, @code{cosh}, @code{cos},
 @code{exit}, @code{exp}, @code{fabs}, @code{floor}, @code{fmod},
-@code{fprintf}, @code{fputs}, @code{frexp}, @code{fscanf}, @code{labs},
-@code{ldexp}, @code{log10}, @code{log}, @code{malloc}, @code{memcmp},
-@code{memcpy}, @code{memset}, @code{modf}, @code{pow}, @code{printf},
-@code{putchar}, @code{puts}, @code{scanf}, @code{sinh}, @code{sin},
-@code{snprintf}, @code{sprintf}, @code{sqrt}, @code{sscanf},
-@code{strcat}, @code{strchr}, @code{strcmp}, @code{strcpy},
-@code{strcspn}, @code{strlen}, @code{strncat}, @code{strncmp},
-@code{strncpy}, @code{strpbrk}, @code{strrchr}, @code{strspn},
-@code{strstr}, @code{tanh}, @code{tan}, @code{vfprintf}, @code{vprintf}
-and @code{vsprintf}
+@code{fprintf}, @code{fputs}, @code{frexp}, @code{fscanf},
+@code{isalnum}, @code{isalpha}, @code{iscntrl}, @code{isdigit},
+@code{isgraph}, @code{islower}, @code{isprint}, @code{ispunct},
+@code{isspace}, @code{isupper}, @code{isxdigit}, @code{tolower},
+@code{toupper}, @code{labs}, @code{ldexp}, @code{log10}, @code{log},
+@code{malloc}, @code{memcmp}, @code{memcpy}, @code{memset}, @code{modf},
+@code{pow}, @code{printf}, @code{putchar}, @code{puts}, @code{scanf},
+@code{sinh}, @code{sin}, @code{snprintf}, @code{sprintf}, @code{sqrt},
+@code{sscanf}, @code{strcat}, @code{strchr}, @code{strcmp},
+@code{strcpy}, @code{strcspn}, @code{strlen}, @code{strncat},
+@code{strncmp}, @code{strncpy}, @code{strpbrk}, @code{strrchr},
+@code{strspn}, @code{strstr}, @code{tanh}, @code{tan}, @code{vfprintf},
+@code{vprintf} and @code{vsprintf}
 are all recognized as built-in functions unless
 @option{-fno-builtin} is specified (or @option{-fno-builtin-@var{function}}
 is specified for an individual function).  All of these functions have
@@ -5301,7 +5788,7 @@ depending on the arguments' types.  For example:
 @smallexample
 #define foo(x)                                                  \
   (@{                                                           \
-    typeof (x) tmp;                                             \
+    typeof (x) tmp = (x);                                       \
     if (__builtin_types_compatible_p (typeof (x), long double)) \
       tmp = foo_long_double (tmp);                              \
     else if (__builtin_types_compatible_p (typeof (x), double)) \
@@ -5314,7 +5801,7 @@ depending on the arguments' types.  For example:
   @})
 @end smallexample
 
-@emph{Note:} This construct is only available for C.
+@emph{Note:} This construct is only available for C@.
 
 @end deftypefn
 
@@ -5354,7 +5841,7 @@ Example:
       (void)0))
 @end smallexample
 
-@emph{Note:} This construct is only available for C.  Furthermore, the
+@emph{Note:} This construct is only available for C@.  Furthermore, the
 unused expression (@var{exp1} or @var{exp2} depending on the value of
 @var{const_exp}) may still generate syntax errors.  This may change in
 future revisions.
@@ -5505,11 +5992,23 @@ type is @code{long double}.
 @deftypefn {Built-in Function} double __builtin_inf (void)
 Similar to @code{__builtin_huge_val}, except a warning is generated
 if the target floating-point format does not support infinities.
-This function is suitable for implementing the ISO C99 macro @code{INFINITY}.
+@end deftypefn
+
+@deftypefn {Built-in Function} _Decimal32 __builtin_infd32 (void)
+Similar to @code{__builtin_inf}, except the return type is @code{_Decimal32}.
+@end deftypefn
+
+@deftypefn {Built-in Function} _Decimal64 __builtin_infd64 (void)
+Similar to @code{__builtin_inf}, except the return type is @code{_Decimal64}.
+@end deftypefn
+
+@deftypefn {Built-in Function} _Decimal128 __builtin_infd128 (void)
+Similar to @code{__builtin_inf}, except the return type is @code{_Decimal128}.
 @end deftypefn
 
 @deftypefn {Built-in Function} float __builtin_inff (void)
 Similar to @code{__builtin_inf}, except the return type is @code{float}.
+This function is suitable for implementing the ISO C99 macro @code{INFINITY}.
 @end deftypefn
 
 @deftypefn {Built-in Function} {long double} __builtin_infl (void)
@@ -5527,10 +6026,23 @@ leading @samp{0} or @samp{0x} prefixes.  The number parsed is placed
 in the significand such that the least significant bit of the number
 is at the least significant bit of the significand.  The number is
 truncated to fit the significand field provided.  The significand is
-forced to be a quiet NaN.
+forced to be a quiet NaN@.
 
-This function, if given a string literal, is evaluated early enough
-that it is considered a compile-time constant.
+This function, if given a string literal all of which would have been
+consumed by strtol, is evaluated early enough that it is considered a
+compile-time constant.
+@end deftypefn
+
+@deftypefn {Built-in Function} _Decimal32 __builtin_nand32 (const char *str)
+Similar to @code{__builtin_nan}, except the return type is @code{_Decimal32}.
+@end deftypefn
+
+@deftypefn {Built-in Function} _Decimal64 __builtin_nand64 (const char *str)
+Similar to @code{__builtin_nan}, except the return type is @code{_Decimal64}.
+@end deftypefn
+
+@deftypefn {Built-in Function} _Decimal128 __builtin_nand128 (const char *str)
+Similar to @code{__builtin_nan}, except the return type is @code{_Decimal128}.
 @end deftypefn
 
 @deftypefn {Built-in Function} float __builtin_nanf (const char *str)
@@ -5543,7 +6055,7 @@ Similar to @code{__builtin_nan}, except the return type is @code{long double}.
 
 @deftypefn {Built-in Function} double __builtin_nans (const char *str)
 Similar to @code{__builtin_nan}, except the significand is forced
-to be a signaling NaN.  The @code{nans} function is proposed by
+to be a signaling NaN@.  The @code{nans} function is proposed by
 @uref{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n965.htm,,WG14 N965}.
 @end deftypefn
 
@@ -5575,7 +6087,7 @@ Returns the number of 1-bits in @var{x}.
 @end deftypefn
 
 @deftypefn {Built-in Function} int __builtin_parity (unsigned int x)
-Returns the parity of @var{x}, i.@:e. the number of 1-bits in @var{x}
+Returns the parity of @var{x}, i.e.@: the number of 1-bits in @var{x}
 modulo 2.
 @end deftypefn
 
@@ -5629,6 +6141,21 @@ Similar to @code{__builtin_parity}, except the argument type is
 @code{unsigned long long}.
 @end deftypefn
 
+@deftypefn {Built-in Function} double __builtin_powi (double, int)
+Returns the first argument raised to the power of the second.  Unlike the
+@code{pow} function no guarantees about precision and rounding are made.
+@end deftypefn
+
+@deftypefn {Built-in Function} float __builtin_powif (float, int)
+Similar to @code{__builtin_powi}, except the argument and return types
+are @code{float}.
+@end deftypefn
+
+@deftypefn {Built-in Function} {long double} __builtin_powil (long double, int)
+Similar to @code{__builtin_powi}, except the argument and return types
+are @code{long double}.
+@end deftypefn
+
 
 @node Target Builtins
 @section Built-in Functions Specific to Particular Target Machines
@@ -5640,8 +6167,13 @@ instructions, but allow the compiler to schedule those calls.
 @menu
 * Alpha Built-in Functions::
 * ARM Built-in Functions::
+* Blackfin Built-in Functions::
+* FR-V Built-in Functions::
 * X86 Built-in Functions::
+* MIPS DSP Built-in Functions::
+* MIPS Paired-Single Support::
 * PowerPC AltiVec Built-in Functions::
+* SPARC VIS Built-in Functions::
 @end menu
 
 @node Alpha Built-in Functions
@@ -5873,12 +6405,460 @@ long long __builtin_arm_wxor (long long, long long)
 long long __builtin_arm_wzero ()
 @end smallexample
 
+@node Blackfin Built-in Functions
+@subsection Blackfin Built-in Functions
+
+Currently, there are two Blackfin-specific built-in functions.  These are
+used for generating @code{CSYNC} and @code{SSYNC} machine insns without
+using inline assembly; by using these built-in functions the compiler can
+automatically add workarounds for hardware errata involving these
+instructions.  These functions are named as follows:
+
+@smallexample
+void __builtin_bfin_csync (void)
+void __builtin_bfin_ssync (void)
+@end smallexample
+
+@node FR-V Built-in Functions
+@subsection FR-V Built-in Functions
+
+GCC provides many FR-V-specific built-in functions.  In general,
+these functions are intended to be compatible with those described
+by @cite{FR-V Family, Softune C/C++ Compiler Manual (V6), Fujitsu
+Semiconductor}.  The two exceptions are @code{__MDUNPACKH} and
+@code{__MBTOHE}, the gcc forms of which pass 128-bit values by
+pointer rather than by value.
+
+Most of the functions are named after specific FR-V instructions.
+Such functions are said to be ``directly mapped'' and are summarized
+here in tabular form.
+
+@menu
+* Argument Types::
+* Directly-mapped Integer Functions::
+* Directly-mapped Media Functions::
+* Raw read/write Functions::
+* Other Built-in Functions::
+@end menu
+
+@node Argument Types
+@subsubsection Argument Types
+
+The arguments to the built-in functions can be divided into three groups:
+register numbers, compile-time constants and run-time values.  In order
+to make this classification clear at a glance, the arguments and return
+values are given the following pseudo types:
+
+@multitable @columnfractions .20 .30 .15 .35
+@item Pseudo type @tab Real C type @tab Constant? @tab Description
+@item @code{uh} @tab @code{unsigned short} @tab No @tab an unsigned halfword
+@item @code{uw1} @tab @code{unsigned int} @tab No @tab an unsigned word
+@item @code{sw1} @tab @code{int} @tab No @tab a signed word
+@item @code{uw2} @tab @code{unsigned long long} @tab No
+@tab an unsigned doubleword
+@item @code{sw2} @tab @code{long long} @tab No @tab a signed doubleword
+@item @code{const} @tab @code{int} @tab Yes @tab an integer constant
+@item @code{acc} @tab @code{int} @tab Yes @tab an ACC register number
+@item @code{iacc} @tab @code{int} @tab Yes @tab an IACC register number
+@end multitable
+
+These pseudo types are not defined by GCC, they are simply a notational
+convenience used in this manual.
+
+Arguments of type @code{uh}, @code{uw1}, @code{sw1}, @code{uw2}
+and @code{sw2} are evaluated at run time.  They correspond to
+register operands in the underlying FR-V instructions.
+
+@code{const} arguments represent immediate operands in the underlying
+FR-V instructions.  They must be compile-time constants.
+
+@code{acc} arguments are evaluated at compile time and specify the number
+of an accumulator register.  For example, an @code{acc} argument of 2
+will select the ACC2 register.
+
+@code{iacc} arguments are similar to @code{acc} arguments but specify the
+number of an IACC register.  See @pxref{Other Built-in Functions}
+for more details.
+
+@node Directly-mapped Integer Functions
+@subsubsection Directly-mapped Integer Functions
+
+The functions listed below map directly to FR-V I-type instructions.
+
+@multitable @columnfractions .45 .32 .23
+@item Function prototype @tab Example usage @tab Assembly output
+@item @code{sw1 __ADDSS (sw1, sw1)}
+@tab @code{@var{c} = __ADDSS (@var{a}, @var{b})}
+@tab @code{ADDSS @var{a},@var{b},@var{c}}
+@item @code{sw1 __SCAN (sw1, sw1)}
+@tab @code{@var{c} = __SCAN (@var{a}, @var{b})}
+@tab @code{SCAN @var{a},@var{b},@var{c}}
+@item @code{sw1 __SCUTSS (sw1)}
+@tab @code{@var{b} = __SCUTSS (@var{a})}
+@tab @code{SCUTSS @var{a},@var{b}}
+@item @code{sw1 __SLASS (sw1, sw1)}
+@tab @code{@var{c} = __SLASS (@var{a}, @var{b})}
+@tab @code{SLASS @var{a},@var{b},@var{c}}
+@item @code{void __SMASS (sw1, sw1)}
+@tab @code{__SMASS (@var{a}, @var{b})}
+@tab @code{SMASS @var{a},@var{b}}
+@item @code{void __SMSSS (sw1, sw1)}
+@tab @code{__SMSSS (@var{a}, @var{b})}
+@tab @code{SMSSS @var{a},@var{b}}
+@item @code{void __SMU (sw1, sw1)}
+@tab @code{__SMU (@var{a}, @var{b})}
+@tab @code{SMU @var{a},@var{b}}
+@item @code{sw2 __SMUL (sw1, sw1)}
+@tab @code{@var{c} = __SMUL (@var{a}, @var{b})}
+@tab @code{SMUL @var{a},@var{b},@var{c}}
+@item @code{sw1 __SUBSS (sw1, sw1)}
+@tab @code{@var{c} = __SUBSS (@var{a}, @var{b})}
+@tab @code{SUBSS @var{a},@var{b},@var{c}}
+@item @code{uw2 __UMUL (uw1, uw1)}
+@tab @code{@var{c} = __UMUL (@var{a}, @var{b})}
+@tab @code{UMUL @var{a},@var{b},@var{c}}
+@end multitable
+
+@node Directly-mapped Media Functions
+@subsubsection Directly-mapped Media Functions
+
+The functions listed below map directly to FR-V M-type instructions.
+
+@multitable @columnfractions .45 .32 .23
+@item Function prototype @tab Example usage @tab Assembly output
+@item @code{uw1 __MABSHS (sw1)}
+@tab @code{@var{b} = __MABSHS (@var{a})}
+@tab @code{MABSHS @var{a},@var{b}}
+@item @code{void __MADDACCS (acc, acc)}
+@tab @code{__MADDACCS (@var{b}, @var{a})}
+@tab @code{MADDACCS @var{a},@var{b}}
+@item @code{sw1 __MADDHSS (sw1, sw1)}
+@tab @code{@var{c} = __MADDHSS (@var{a}, @var{b})}
+@tab @code{MADDHSS @var{a},@var{b},@var{c}}
+@item @code{uw1 __MADDHUS (uw1, uw1)}
+@tab @code{@var{c} = __MADDHUS (@var{a}, @var{b})}
+@tab @code{MADDHUS @var{a},@var{b},@var{c}}
+@item @code{uw1 __MAND (uw1, uw1)}
+@tab @code{@var{c} = __MAND (@var{a}, @var{b})}
+@tab @code{MAND @var{a},@var{b},@var{c}}
+@item @code{void __MASACCS (acc, acc)}
+@tab @code{__MASACCS (@var{b}, @var{a})}
+@tab @code{MASACCS @var{a},@var{b}}
+@item @code{uw1 __MAVEH (uw1, uw1)}
+@tab @code{@var{c} = __MAVEH (@var{a}, @var{b})}
+@tab @code{MAVEH @var{a},@var{b},@var{c}}
+@item @code{uw2 __MBTOH (uw1)}
+@tab @code{@var{b} = __MBTOH (@var{a})}
+@tab @code{MBTOH @var{a},@var{b}}
+@item @code{void __MBTOHE (uw1 *, uw1)}
+@tab @code{__MBTOHE (&@var{b}, @var{a})}
+@tab @code{MBTOHE @var{a},@var{b}}
+@item @code{void __MCLRACC (acc)}
+@tab @code{__MCLRACC (@var{a})}
+@tab @code{MCLRACC @var{a}}
+@item @code{void __MCLRACCA (void)}
+@tab @code{__MCLRACCA ()}
+@tab @code{MCLRACCA}
+@item @code{uw1 __Mcop1 (uw1, uw1)}
+@tab @code{@var{c} = __Mcop1 (@var{a}, @var{b})}
+@tab @code{Mcop1 @var{a},@var{b},@var{c}}
+@item @code{uw1 __Mcop2 (uw1, uw1)}
+@tab @code{@var{c} = __Mcop2 (@var{a}, @var{b})}
+@tab @code{Mcop2 @var{a},@var{b},@var{c}}
+@item @code{uw1 __MCPLHI (uw2, const)}
+@tab @code{@var{c} = __MCPLHI (@var{a}, @var{b})}
+@tab @code{MCPLHI @var{a},#@var{b},@var{c}}
+@item @code{uw1 __MCPLI (uw2, const)}
+@tab @code{@var{c} = __MCPLI (@var{a}, @var{b})}
+@tab @code{MCPLI @var{a},#@var{b},@var{c}}
+@item @code{void __MCPXIS (acc, sw1, sw1)}
+@tab @code{__MCPXIS (@var{c}, @var{a}, @var{b})}
+@tab @code{MCPXIS @var{a},@var{b},@var{c}}
+@item @code{void __MCPXIU (acc, uw1, uw1)}
+@tab @code{__MCPXIU (@var{c}, @var{a}, @var{b})}
+@tab @code{MCPXIU @var{a},@var{b},@var{c}}
+@item @code{void __MCPXRS (acc, sw1, sw1)}
+@tab @code{__MCPXRS (@var{c}, @var{a}, @var{b})}
+@tab @code{MCPXRS @var{a},@var{b},@var{c}}
+@item @code{void __MCPXRU (acc, uw1, uw1)}
+@tab @code{__MCPXRU (@var{c}, @var{a}, @var{b})}
+@tab @code{MCPXRU @var{a},@var{b},@var{c}}
+@item @code{uw1 __MCUT (acc, uw1)}
+@tab @code{@var{c} = __MCUT (@var{a}, @var{b})}
+@tab @code{MCUT @var{a},@var{b},@var{c}}
+@item @code{uw1 __MCUTSS (acc, sw1)}
+@tab @code{@var{c} = __MCUTSS (@var{a}, @var{b})}
+@tab @code{MCUTSS @var{a},@var{b},@var{c}}
+@item @code{void __MDADDACCS (acc, acc)}
+@tab @code{__MDADDACCS (@var{b}, @var{a})}
+@tab @code{MDADDACCS @var{a},@var{b}}
+@item @code{void __MDASACCS (acc, acc)}
+@tab @code{__MDASACCS (@var{b}, @var{a})}
+@tab @code{MDASACCS @var{a},@var{b}}
+@item @code{uw2 __MDCUTSSI (acc, const)}
+@tab @code{@var{c} = __MDCUTSSI (@var{a}, @var{b})}
+@tab @code{MDCUTSSI @var{a},#@var{b},@var{c}}
+@item @code{uw2 __MDPACKH (uw2, uw2)}
+@tab @code{@var{c} = __MDPACKH (@var{a}, @var{b})}
+@tab @code{MDPACKH @var{a},@var{b},@var{c}}
+@item @code{uw2 __MDROTLI (uw2, const)}
+@tab @code{@var{c} = __MDROTLI (@var{a}, @var{b})}
+@tab @code{MDROTLI @var{a},#@var{b},@var{c}}
+@item @code{void __MDSUBACCS (acc, acc)}
+@tab @code{__MDSUBACCS (@var{b}, @var{a})}
+@tab @code{MDSUBACCS @var{a},@var{b}}
+@item @code{void __MDUNPACKH (uw1 *, uw2)}
+@tab @code{__MDUNPACKH (&@var{b}, @var{a})}
+@tab @code{MDUNPACKH @var{a},@var{b}}
+@item @code{uw2 __MEXPDHD (uw1, const)}
+@tab @code{@var{c} = __MEXPDHD (@var{a}, @var{b})}
+@tab @code{MEXPDHD @var{a},#@var{b},@var{c}}
+@item @code{uw1 __MEXPDHW (uw1, const)}
+@tab @code{@var{c} = __MEXPDHW (@var{a}, @var{b})}
+@tab @code{MEXPDHW @var{a},#@var{b},@var{c}}
+@item @code{uw1 __MHDSETH (uw1, const)}
+@tab @code{@var{c} = __MHDSETH (@var{a}, @var{b})}
+@tab @code{MHDSETH @var{a},#@var{b},@var{c}}
+@item @code{sw1 __MHDSETS (const)}
+@tab @code{@var{b} = __MHDSETS (@var{a})}
+@tab @code{MHDSETS #@var{a},@var{b}}
+@item @code{uw1 __MHSETHIH (uw1, const)}
+@tab @code{@var{b} = __MHSETHIH (@var{b}, @var{a})}
+@tab @code{MHSETHIH #@var{a},@var{b}}
+@item @code{sw1 __MHSETHIS (sw1, const)}
+@tab @code{@var{b} = __MHSETHIS (@var{b}, @var{a})}
+@tab @code{MHSETHIS #@var{a},@var{b}}
+@item @code{uw1 __MHSETLOH (uw1, const)}
+@tab @code{@var{b} = __MHSETLOH (@var{b}, @var{a})}
+@tab @code{MHSETLOH #@var{a},@var{b}}
+@item @code{sw1 __MHSETLOS (sw1, const)}
+@tab @code{@var{b} = __MHSETLOS (@var{b}, @var{a})}
+@tab @code{MHSETLOS #@var{a},@var{b}}
+@item @code{uw1 __MHTOB (uw2)}
+@tab @code{@var{b} = __MHTOB (@var{a})}
+@tab @code{MHTOB @var{a},@var{b}}
+@item @code{void __MMACHS (acc, sw1, sw1)}
+@tab @code{__MMACHS (@var{c}, @var{a}, @var{b})}
+@tab @code{MMACHS @var{a},@var{b},@var{c}}
+@item @code{void __MMACHU (acc, uw1, uw1)}
+@tab @code{__MMACHU (@var{c}, @var{a}, @var{b})}
+@tab @code{MMACHU @var{a},@var{b},@var{c}}
+@item @code{void __MMRDHS (acc, sw1, sw1)}
+@tab @code{__MMRDHS (@var{c}, @var{a}, @var{b})}
+@tab @code{MMRDHS @var{a},@var{b},@var{c}}
+@item @code{void __MMRDHU (acc, uw1, uw1)}
+@tab @code{__MMRDHU (@var{c}, @var{a}, @var{b})}
+@tab @code{MMRDHU @var{a},@var{b},@var{c}}
+@item @code{void __MMULHS (acc, sw1, sw1)}
+@tab @code{__MMULHS (@var{c}, @var{a}, @var{b})}
+@tab @code{MMULHS @var{a},@var{b},@var{c}}
+@item @code{void __MMULHU (acc, uw1, uw1)}
+@tab @code{__MMULHU (@var{c}, @var{a}, @var{b})}
+@tab @code{MMULHU @var{a},@var{b},@var{c}}
+@item @code{void __MMULXHS (acc, sw1, sw1)}
+@tab @code{__MMULXHS (@var{c}, @var{a}, @var{b})}
+@tab @code{MMULXHS @var{a},@var{b},@var{c}}
+@item @code{void __MMULXHU (acc, uw1, uw1)}
+@tab @code{__MMULXHU (@var{c}, @var{a}, @var{b})}
+@tab @code{MMULXHU @var{a},@var{b},@var{c}}
+@item @code{uw1 __MNOT (uw1)}
+@tab @code{@var{b} = __MNOT (@var{a})}
+@tab @code{MNOT @var{a},@var{b}}
+@item @code{uw1 __MOR (uw1, uw1)}
+@tab @code{@var{c} = __MOR (@var{a}, @var{b})}
+@tab @code{MOR @var{a},@var{b},@var{c}}
+@item @code{uw1 __MPACKH (uh, uh)}
+@tab @code{@var{c} = __MPACKH (@var{a}, @var{b})}
+@tab @code{MPACKH @var{a},@var{b},@var{c}}
+@item @code{sw2 __MQADDHSS (sw2, sw2)}
+@tab @code{@var{c} = __MQADDHSS (@var{a}, @var{b})}
+@tab @code{MQADDHSS @var{a},@var{b},@var{c}}
+@item @code{uw2 __MQADDHUS (uw2, uw2)}
+@tab @code{@var{c} = __MQADDHUS (@var{a}, @var{b})}
+@tab @code{MQADDHUS @var{a},@var{b},@var{c}}
+@item @code{void __MQCPXIS (acc, sw2, sw2)}
+@tab @code{__MQCPXIS (@var{c}, @var{a}, @var{b})}
+@tab @code{MQCPXIS @var{a},@var{b},@var{c}}
+@item @code{void __MQCPXIU (acc, uw2, uw2)}
+@tab @code{__MQCPXIU (@var{c}, @var{a}, @var{b})}
+@tab @code{MQCPXIU @var{a},@var{b},@var{c}}
+@item @code{void __MQCPXRS (acc, sw2, sw2)}
+@tab @code{__MQCPXRS (@var{c}, @var{a}, @var{b})}
+@tab @code{MQCPXRS @var{a},@var{b},@var{c}}
+@item @code{void __MQCPXRU (acc, uw2, uw2)}
+@tab @code{__MQCPXRU (@var{c}, @var{a}, @var{b})}
+@tab @code{MQCPXRU @var{a},@var{b},@var{c}}
+@item @code{sw2 __MQLCLRHS (sw2, sw2)}
+@tab @code{@var{c} = __MQLCLRHS (@var{a}, @var{b})}
+@tab @code{MQLCLRHS @var{a},@var{b},@var{c}}
+@item @code{sw2 __MQLMTHS (sw2, sw2)}
+@tab @code{@var{c} = __MQLMTHS (@var{a}, @var{b})}
+@tab @code{MQLMTHS @var{a},@var{b},@var{c}}
+@item @code{void __MQMACHS (acc, sw2, sw2)}
+@tab @code{__MQMACHS (@var{c}, @var{a}, @var{b})}
+@tab @code{MQMACHS @var{a},@var{b},@var{c}}
+@item @code{void __MQMACHU (acc, uw2, uw2)}
+@tab @code{__MQMACHU (@var{c}, @var{a}, @var{b})}
+@tab @code{MQMACHU @var{a},@var{b},@var{c}}
+@item @code{void __MQMACXHS (acc, sw2, sw2)}
+@tab @code{__MQMACXHS (@var{c}, @var{a}, @var{b})}
+@tab @code{MQMACXHS @var{a},@var{b},@var{c}}
+@item @code{void __MQMULHS (acc, sw2, sw2)}
+@tab @code{__MQMULHS (@var{c}, @var{a}, @var{b})}
+@tab @code{MQMULHS @var{a},@var{b},@var{c}}
+@item @code{void __MQMULHU (acc, uw2, uw2)}
+@tab @code{__MQMULHU (@var{c}, @var{a}, @var{b})}
+@tab @code{MQMULHU @var{a},@var{b},@var{c}}
+@item @code{void __MQMULXHS (acc, sw2, sw2)}
+@tab @code{__MQMULXHS (@var{c}, @var{a}, @var{b})}
+@tab @code{MQMULXHS @var{a},@var{b},@var{c}}
+@item @code{void __MQMULXHU (acc, uw2, uw2)}
+@tab @code{__MQMULXHU (@var{c}, @var{a}, @var{b})}
+@tab @code{MQMULXHU @var{a},@var{b},@var{c}}
+@item @code{sw2 __MQSATHS (sw2, sw2)}
+@tab @code{@var{c} = __MQSATHS (@var{a}, @var{b})}
+@tab @code{MQSATHS @var{a},@var{b},@var{c}}
+@item @code{uw2 __MQSLLHI (uw2, int)}
+@tab @code{@var{c} = __MQSLLHI (@var{a}, @var{b})}
+@tab @code{MQSLLHI @var{a},@var{b},@var{c}}
+@item @code{sw2 __MQSRAHI (sw2, int)}
+@tab @code{@var{c} = __MQSRAHI (@var{a}, @var{b})}
+@tab @code{MQSRAHI @var{a},@var{b},@var{c}}
+@item @code{sw2 __MQSUBHSS (sw2, sw2)}
+@tab @code{@var{c} = __MQSUBHSS (@var{a}, @var{b})}
+@tab @code{MQSUBHSS @var{a},@var{b},@var{c}}
+@item @code{uw2 __MQSUBHUS (uw2, uw2)}
+@tab @code{@var{c} = __MQSUBHUS (@var{a}, @var{b})}
+@tab @code{MQSUBHUS @var{a},@var{b},@var{c}}
+@item @code{void __MQXMACHS (acc, sw2, sw2)}
+@tab @code{__MQXMACHS (@var{c}, @var{a}, @var{b})}
+@tab @code{MQXMACHS @var{a},@var{b},@var{c}}
+@item @code{void __MQXMACXHS (acc, sw2, sw2)}
+@tab @code{__MQXMACXHS (@var{c}, @var{a}, @var{b})}
+@tab @code{MQXMACXHS @var{a},@var{b},@var{c}}
+@item @code{uw1 __MRDACC (acc)}
+@tab @code{@var{b} = __MRDACC (@var{a})}
+@tab @code{MRDACC @var{a},@var{b}}
+@item @code{uw1 __MRDACCG (acc)}
+@tab @code{@var{b} = __MRDACCG (@var{a})}
+@tab @code{MRDACCG @var{a},@var{b}}
+@item @code{uw1 __MROTLI (uw1, const)}
+@tab @code{@var{c} = __MROTLI (@var{a}, @var{b})}
+@tab @code{MROTLI @var{a},#@var{b},@var{c}}
+@item @code{uw1 __MROTRI (uw1, const)}
+@tab @code{@var{c} = __MROTRI (@var{a}, @var{b})}
+@tab @code{MROTRI @var{a},#@var{b},@var{c}}
+@item @code{sw1 __MSATHS (sw1, sw1)}
+@tab @code{@var{c} = __MSATHS (@var{a}, @var{b})}
+@tab @code{MSATHS @var{a},@var{b},@var{c}}
+@item @code{uw1 __MSATHU (uw1, uw1)}
+@tab @code{@var{c} = __MSATHU (@var{a}, @var{b})}
+@tab @code{MSATHU @var{a},@var{b},@var{c}}
+@item @code{uw1 __MSLLHI (uw1, const)}
+@tab @code{@var{c} = __MSLLHI (@var{a}, @var{b})}
+@tab @code{MSLLHI @var{a},#@var{b},@var{c}}
+@item @code{sw1 __MSRAHI (sw1, const)}
+@tab @code{@var{c} = __MSRAHI (@var{a}, @var{b})}
+@tab @code{MSRAHI @var{a},#@var{b},@var{c}}
+@item @code{uw1 __MSRLHI (uw1, const)}
+@tab @code{@var{c} = __MSRLHI (@var{a}, @var{b})}
+@tab @code{MSRLHI @var{a},#@var{b},@var{c}}
+@item @code{void __MSUBACCS (acc, acc)}
+@tab @code{__MSUBACCS (@var{b}, @var{a})}
+@tab @code{MSUBACCS @var{a},@var{b}}
+@item @code{sw1 __MSUBHSS (sw1, sw1)}
+@tab @code{@var{c} = __MSUBHSS (@var{a}, @var{b})}
+@tab @code{MSUBHSS @var{a},@var{b},@var{c}}
+@item @code{uw1 __MSUBHUS (uw1, uw1)}
+@tab @code{@var{c} = __MSUBHUS (@var{a}, @var{b})}
+@tab @code{MSUBHUS @var{a},@var{b},@var{c}}
+@item @code{void __MTRAP (void)}
+@tab @code{__MTRAP ()}
+@tab @code{MTRAP}
+@item @code{uw2 __MUNPACKH (uw1)}
+@tab @code{@var{b} = __MUNPACKH (@var{a})}
+@tab @code{MUNPACKH @var{a},@var{b}}
+@item @code{uw1 __MWCUT (uw2, uw1)}
+@tab @code{@var{c} = __MWCUT (@var{a}, @var{b})}
+@tab @code{MWCUT @var{a},@var{b},@var{c}}
+@item @code{void __MWTACC (acc, uw1)}
+@tab @code{__MWTACC (@var{b}, @var{a})}
+@tab @code{MWTACC @var{a},@var{b}}
+@item @code{void __MWTACCG (acc, uw1)}
+@tab @code{__MWTACCG (@var{b}, @var{a})}
+@tab @code{MWTACCG @var{a},@var{b}}
+@item @code{uw1 __MXOR (uw1, uw1)}
+@tab @code{@var{c} = __MXOR (@var{a}, @var{b})}
+@tab @code{MXOR @var{a},@var{b},@var{c}}
+@end multitable
+
+@node Raw read/write Functions
+@subsubsection Raw read/write Functions
+
+This sections describes built-in functions related to read and write
+instructions to access memory.  These functions generate
+@code{membar} instructions to flush the I/O load and stores where
+appropriate, as described in Fujitsu's manual described above.
+
+@table @code
+
+@item unsigned char __builtin_read8 (void *@var{data})
+@item unsigned short __builtin_read16 (void *@var{data})
+@item unsigned long __builtin_read32 (void *@var{data})
+@item unsigned long long __builtin_read64 (void *@var{data})
+
+@item void __builtin_write8 (void *@var{data}, unsigned char @var{datum})
+@item void __builtin_write16 (void *@var{data}, unsigned short @var{datum})
+@item void __builtin_write32 (void *@var{data}, unsigned long @var{datum})
+@item void __builtin_write64 (void *@var{data}, unsigned long long @var{datum})
+@end table
+
+@node Other Built-in Functions
+@subsubsection Other Built-in Functions
+
+This section describes built-in functions that are not named after
+a specific FR-V instruction.
+
+@table @code
+@item sw2 __IACCreadll (iacc @var{reg})
+Return the full 64-bit value of IACC0@.  The @var{reg} argument is reserved
+for future expansion and must be 0.
+
+@item sw1 __IACCreadl (iacc @var{reg})
+Return the value of IACC0H if @var{reg} is 0 and IACC0L if @var{reg} is 1.
+Other values of @var{reg} are rejected as invalid.
+
+@item void __IACCsetll (iacc @var{reg}, sw2 @var{x})
+Set the full 64-bit value of IACC0 to @var{x}.  The @var{reg} argument
+is reserved for future expansion and must be 0.
+
+@item void __IACCsetl (iacc @var{reg}, sw1 @var{x})
+Set IACC0H to @var{x} if @var{reg} is 0 and IACC0L to @var{x} if @var{reg}
+is 1.  Other values of @var{reg} are rejected as invalid.
+
+@item void __data_prefetch0 (const void *@var{x})
+Use the @code{dcpl} instruction to load the contents of address @var{x}
+into the data cache.
+
+@item void __data_prefetch (const void *@var{x})
+Use the @code{nldub} instruction to load the contents of address @var{x}
+into the data cache.  The instruction will be issued in slot I1@.
+@end table
+
 @node X86 Built-in Functions
 @subsection X86 Built-in Functions
 
 These built-in functions are available for the i386 and x86-64 family
 of computers, depending on the command-line switches used.
 
+Note that, if you specify command-line switches such as @option{-msse},
+the compiler could use the extended instruction sets even if the built-ins
+are not used explicitly in the program.  For this reason, applications
+which perform runtime CPU detection must compile separate files for each
+supported architecture, using the appropriate flags.  In particular,
+the file containing the CPU detection code should be compiled without
+these options.
+
 The following machine modes are available for use with MMX built-in functions
 (@pxref{Vector Extensions}): @code{V2SI} for a vector of two 32-bit integers,
 @code{V4HI} for a vector of four 16-bit integers, and @code{V8QI} for a
@@ -6056,16 +7036,175 @@ Generates the @code{movhps} machine instruction as a store to memory.
 Generates the @code{movlps} machine instruction as a store to memory.
 @end table
 
+The following built-in functions are available when @option{-msse2} is used.
+All of them generate the machine instruction that is part of the name.
+
+@smallexample
+int __builtin_ia32_comisdeq (v2df, v2df)
+int __builtin_ia32_comisdlt (v2df, v2df)
+int __builtin_ia32_comisdle (v2df, v2df)
+int __builtin_ia32_comisdgt (v2df, v2df)
+int __builtin_ia32_comisdge (v2df, v2df)
+int __builtin_ia32_comisdneq (v2df, v2df)
+int __builtin_ia32_ucomisdeq (v2df, v2df)
+int __builtin_ia32_ucomisdlt (v2df, v2df)
+int __builtin_ia32_ucomisdle (v2df, v2df)
+int __builtin_ia32_ucomisdgt (v2df, v2df)
+int __builtin_ia32_ucomisdge (v2df, v2df)
+int __builtin_ia32_ucomisdneq (v2df, v2df)
+v2df __builtin_ia32_cmpeqpd (v2df, v2df)
+v2df __builtin_ia32_cmpltpd (v2df, v2df)
+v2df __builtin_ia32_cmplepd (v2df, v2df)
+v2df __builtin_ia32_cmpgtpd (v2df, v2df)
+v2df __builtin_ia32_cmpgepd (v2df, v2df)
+v2df __builtin_ia32_cmpunordpd (v2df, v2df)
+v2df __builtin_ia32_cmpneqpd (v2df, v2df)
+v2df __builtin_ia32_cmpnltpd (v2df, v2df)
+v2df __builtin_ia32_cmpnlepd (v2df, v2df)
+v2df __builtin_ia32_cmpngtpd (v2df, v2df)
+v2df __builtin_ia32_cmpngepd (v2df, v2df)
+v2df __builtin_ia32_cmpordpd (v2df, v2df)
+v2df __builtin_ia32_cmpeqsd (v2df, v2df)
+v2df __builtin_ia32_cmpltsd (v2df, v2df)
+v2df __builtin_ia32_cmplesd (v2df, v2df)
+v2df __builtin_ia32_cmpunordsd (v2df, v2df)
+v2df __builtin_ia32_cmpneqsd (v2df, v2df)
+v2df __builtin_ia32_cmpnltsd (v2df, v2df)
+v2df __builtin_ia32_cmpnlesd (v2df, v2df)
+v2df __builtin_ia32_cmpordsd (v2df, v2df)
+v2di __builtin_ia32_paddq (v2di, v2di)
+v2di __builtin_ia32_psubq (v2di, v2di)
+v2df __builtin_ia32_addpd (v2df, v2df)
+v2df __builtin_ia32_subpd (v2df, v2df)
+v2df __builtin_ia32_mulpd (v2df, v2df)
+v2df __builtin_ia32_divpd (v2df, v2df)
+v2df __builtin_ia32_addsd (v2df, v2df)
+v2df __builtin_ia32_subsd (v2df, v2df)
+v2df __builtin_ia32_mulsd (v2df, v2df)
+v2df __builtin_ia32_divsd (v2df, v2df)
+v2df __builtin_ia32_minpd (v2df, v2df)
+v2df __builtin_ia32_maxpd (v2df, v2df)
+v2df __builtin_ia32_minsd (v2df, v2df)
+v2df __builtin_ia32_maxsd (v2df, v2df)
+v2df __builtin_ia32_andpd (v2df, v2df)
+v2df __builtin_ia32_andnpd (v2df, v2df)
+v2df __builtin_ia32_orpd (v2df, v2df)
+v2df __builtin_ia32_xorpd (v2df, v2df)
+v2df __builtin_ia32_movsd (v2df, v2df)
+v2df __builtin_ia32_unpckhpd (v2df, v2df)
+v2df __builtin_ia32_unpcklpd (v2df, v2df)
+v16qi __builtin_ia32_paddb128 (v16qi, v16qi)
+v8hi __builtin_ia32_paddw128 (v8hi, v8hi)
+v4si __builtin_ia32_paddd128 (v4si, v4si)
+v2di __builtin_ia32_paddq128 (v2di, v2di)
+v16qi __builtin_ia32_psubb128 (v16qi, v16qi)
+v8hi __builtin_ia32_psubw128 (v8hi, v8hi)
+v4si __builtin_ia32_psubd128 (v4si, v4si)
+v2di __builtin_ia32_psubq128 (v2di, v2di)
+v8hi __builtin_ia32_pmullw128 (v8hi, v8hi)
+v8hi __builtin_ia32_pmulhw128 (v8hi, v8hi)
+v2di __builtin_ia32_pand128 (v2di, v2di)
+v2di __builtin_ia32_pandn128 (v2di, v2di)
+v2di __builtin_ia32_por128 (v2di, v2di)
+v2di __builtin_ia32_pxor128 (v2di, v2di)
+v16qi __builtin_ia32_pavgb128 (v16qi, v16qi)
+v8hi __builtin_ia32_pavgw128 (v8hi, v8hi)
+v16qi __builtin_ia32_pcmpeqb128 (v16qi, v16qi)
+v8hi __builtin_ia32_pcmpeqw128 (v8hi, v8hi)
+v4si __builtin_ia32_pcmpeqd128 (v4si, v4si)
+v16qi __builtin_ia32_pcmpgtb128 (v16qi, v16qi)
+v8hi __builtin_ia32_pcmpgtw128 (v8hi, v8hi)
+v4si __builtin_ia32_pcmpgtd128 (v4si, v4si)
+v16qi __builtin_ia32_pmaxub128 (v16qi, v16qi)
+v8hi __builtin_ia32_pmaxsw128 (v8hi, v8hi)
+v16qi __builtin_ia32_pminub128 (v16qi, v16qi)
+v8hi __builtin_ia32_pminsw128 (v8hi, v8hi)
+v16qi __builtin_ia32_punpckhbw128 (v16qi, v16qi)
+v8hi __builtin_ia32_punpckhwd128 (v8hi, v8hi)
+v4si __builtin_ia32_punpckhdq128 (v4si, v4si)
+v2di __builtin_ia32_punpckhqdq128 (v2di, v2di)
+v16qi __builtin_ia32_punpcklbw128 (v16qi, v16qi)
+v8hi __builtin_ia32_punpcklwd128 (v8hi, v8hi)
+v4si __builtin_ia32_punpckldq128 (v4si, v4si)
+v2di __builtin_ia32_punpcklqdq128 (v2di, v2di)
+v16qi __builtin_ia32_packsswb128 (v16qi, v16qi)
+v8hi __builtin_ia32_packssdw128 (v8hi, v8hi)
+v16qi __builtin_ia32_packuswb128 (v16qi, v16qi)
+v8hi __builtin_ia32_pmulhuw128 (v8hi, v8hi)
+void __builtin_ia32_maskmovdqu (v16qi, v16qi)
+v2df __builtin_ia32_loadupd (double *)
+void __builtin_ia32_storeupd (double *, v2df)
+v2df __builtin_ia32_loadhpd (v2df, double *)
+v2df __builtin_ia32_loadlpd (v2df, double *)
+int __builtin_ia32_movmskpd (v2df)
+int __builtin_ia32_pmovmskb128 (v16qi)
+void __builtin_ia32_movnti (int *, int)
+void __builtin_ia32_movntpd (double *, v2df)
+void __builtin_ia32_movntdq (v2df *, v2df)
+v4si __builtin_ia32_pshufd (v4si, int)
+v8hi __builtin_ia32_pshuflw (v8hi, int)
+v8hi __builtin_ia32_pshufhw (v8hi, int)
+v2di __builtin_ia32_psadbw128 (v16qi, v16qi)
+v2df __builtin_ia32_sqrtpd (v2df)
+v2df __builtin_ia32_sqrtsd (v2df)
+v2df __builtin_ia32_shufpd (v2df, v2df, int)
+v2df __builtin_ia32_cvtdq2pd (v4si)
+v4sf __builtin_ia32_cvtdq2ps (v4si)
+v4si __builtin_ia32_cvtpd2dq (v2df)
+v2si __builtin_ia32_cvtpd2pi (v2df)
+v4sf __builtin_ia32_cvtpd2ps (v2df)
+v4si __builtin_ia32_cvttpd2dq (v2df)
+v2si __builtin_ia32_cvttpd2pi (v2df)
+v2df __builtin_ia32_cvtpi2pd (v2si)
+int __builtin_ia32_cvtsd2si (v2df)
+int __builtin_ia32_cvttsd2si (v2df)
+long long __builtin_ia32_cvtsd2si64 (v2df)
+long long __builtin_ia32_cvttsd2si64 (v2df)
+v4si __builtin_ia32_cvtps2dq (v4sf)
+v2df __builtin_ia32_cvtps2pd (v4sf)
+v4si __builtin_ia32_cvttps2dq (v4sf)
+v2df __builtin_ia32_cvtsi2sd (v2df, int)
+v2df __builtin_ia32_cvtsi642sd (v2df, long long)
+v4sf __builtin_ia32_cvtsd2ss (v4sf, v2df)
+v2df __builtin_ia32_cvtss2sd (v2df, v4sf)
+void __builtin_ia32_clflush (const void *)
+void __builtin_ia32_lfence (void)
+void __builtin_ia32_mfence (void)
+v16qi __builtin_ia32_loaddqu (const char *)
+void __builtin_ia32_storedqu (char *, v16qi)
+unsigned long long __builtin_ia32_pmuludq (v2si, v2si)
+v2di __builtin_ia32_pmuludq128 (v4si, v4si)
+v8hi __builtin_ia32_psllw128 (v8hi, v2di)
+v4si __builtin_ia32_pslld128 (v4si, v2di)
+v2di __builtin_ia32_psllq128 (v4si, v2di)
+v8hi __builtin_ia32_psrlw128 (v8hi, v2di)
+v4si __builtin_ia32_psrld128 (v4si, v2di)
+v2di __builtin_ia32_psrlq128 (v2di, v2di)
+v8hi __builtin_ia32_psraw128 (v8hi, v2di)
+v4si __builtin_ia32_psrad128 (v4si, v2di)
+v2di __builtin_ia32_pslldqi128 (v2di, int)
+v8hi __builtin_ia32_psllwi128 (v8hi, int)
+v4si __builtin_ia32_pslldi128 (v4si, int)
+v2di __builtin_ia32_psllqi128 (v2di, int)
+v2di __builtin_ia32_psrldqi128 (v2di, int)
+v8hi __builtin_ia32_psrlwi128 (v8hi, int)
+v4si __builtin_ia32_psrldi128 (v4si, int)
+v2di __builtin_ia32_psrlqi128 (v2di, int)
+v8hi __builtin_ia32_psrawi128 (v8hi, int)
+v4si __builtin_ia32_psradi128 (v4si, int)
+v4si __builtin_ia32_pmaddwd128 (v8hi, v8hi)
+@end smallexample
+
 The following built-in functions are available when @option{-msse3} is used.
 All of them generate the machine instruction that is part of the name.
 
 @smallexample
 v2df __builtin_ia32_addsubpd (v2df, v2df)
-v2df __builtin_ia32_addsubps (v2df, v2df)
+v4sf __builtin_ia32_addsubps (v4sf, v4sf)
 v2df __builtin_ia32_haddpd (v2df, v2df)
-v2df __builtin_ia32_haddps (v2df, v2df)
+v4sf __builtin_ia32_haddps (v4sf, v4sf)
 v2df __builtin_ia32_hsubpd (v2df, v2df)
-v2df __builtin_ia32_hsubps (v2df, v2df)
+v4sf __builtin_ia32_hsubps (v4sf, v4sf)
 v16qi __builtin_ia32_lddqu (char const *)
 void __builtin_ia32_monitor (void *, unsigned int, unsigned int)
 v2df __builtin_ia32_movddup (v2df)
@@ -6120,6 +7259,523 @@ v2sf __builtin_ia32_pswapdsf (v2sf)
 v2si __builtin_ia32_pswapdsi (v2si)
 @end smallexample
 
+@node MIPS DSP Built-in Functions
+@subsection MIPS DSP Built-in Functions
+
+The MIPS DSP Application-Specific Extension (ASE) includes new
+instructions that are designed to improve the performance of DSP and
+media applications.  It provides instructions that operate on packed
+8-bit integer data, Q15 fractional data and Q31 fractional data.
+
+GCC supports MIPS DSP operations using both the generic
+vector extensions (@pxref{Vector Extensions}) and a collection of
+MIPS-specific built-in functions.  Both kinds of support are
+enabled by the @option{-mdsp} command-line option.
+
+At present, GCC only provides support for operations on 32-bit
+vectors.  The vector type associated with 8-bit integer data is
+usually called @code{v4i8} and the vector type associated with Q15 is
+usually called @code{v2q15}.  They can be defined in C as follows:
+
+@smallexample
+typedef char v4i8 __attribute__ ((vector_size(4)));
+typedef short v2q15 __attribute__ ((vector_size(4)));
+@end smallexample
+
+@code{v4i8} and @code{v2q15} values are initialized in the same way as
+aggregates.  For example:
+
+@smallexample
+v4i8 a = @{1, 2, 3, 4@};
+v4i8 b;
+b = (v4i8) @{5, 6, 7, 8@};
+
+v2q15 c = @{0x0fcb, 0x3a75@};
+v2q15 d;
+d = (v2q15) @{0.1234 * 0x1.0p15, 0.4567 * 0x1.0p15@};
+@end smallexample
+
+@emph{Note:} The CPU's endianness determines the order in which values
+are packed.  On little-endian targets, the first value is the least
+significant and the last value is the most significant.  The opposite
+order applies to big-endian targets.  For example, the code above will
+set the lowest byte of @code{a} to @code{1} on little-endian targets
+and @code{4} on big-endian targets.
+
+@emph{Note:} Q15 and Q31 values must be initialized with their integer
+representation.  As shown in this example, the integer representation
+of a Q15 value can be obtained by multiplying the fractional value by
+@code{0x1.0p15}.  The equivalent for Q31 values is to multiply by
+@code{0x1.0p31}.
+
+The table below lists the @code{v4i8} and @code{v2q15} operations for which
+hardware support exists.  @code{a} and @code{b} are @code{v4i8} values,
+and @code{c} and @code{d} are @code{v2q15} values.
+
+@multitable @columnfractions .50 .50
+@item C code @tab MIPS instruction
+@item @code{a + b} @tab @code{addu.qb}
+@item @code{c + d} @tab @code{addq.ph}
+@item @code{a - b} @tab @code{subu.qb}
+@item @code{c - d} @tab @code{subq.ph}
+@end multitable
+
+It is easier to describe the DSP built-in functions if we first define
+the following types:
+
+@smallexample
+typedef int q31;
+typedef int i32;
+typedef long long a64;
+@end smallexample
+
+@code{q31} and @code{i32} are actually the same as @code{int}, but we
+use @code{q31} to indicate a Q31 fractional value and @code{i32} to
+indicate a 32-bit integer value.  Similarly, @code{a64} is the same as
+@code{long long}, but we use @code{a64} to indicate values that will
+be placed in one of the four DSP accumulators (@code{$ac0},
+@code{$ac1}, @code{$ac2} or @code{$ac3}).
+
+Also, some built-in functions prefer or require immediate numbers as
+parameters, because the corresponding DSP instructions accept both immediate
+numbers and register operands, or accept immediate numbers only.  The
+immediate parameters are listed as follows.
+
+@smallexample
+imm0_7: 0 to 7.
+imm0_15: 0 to 15.
+imm0_31: 0 to 31.
+imm0_63: 0 to 63.
+imm0_255: 0 to 255.
+imm_n32_31: -32 to 31.
+imm_n512_511: -512 to 511.
+@end smallexample
+
+The following built-in functions map directly to a particular MIPS DSP
+instruction.  Please refer to the architecture specification
+for details on what each instruction does.
+
+@smallexample
+v2q15 __builtin_mips_addq_ph (v2q15, v2q15)
+v2q15 __builtin_mips_addq_s_ph (v2q15, v2q15)
+q31 __builtin_mips_addq_s_w (q31, q31)
+v4i8 __builtin_mips_addu_qb (v4i8, v4i8)
+v4i8 __builtin_mips_addu_s_qb (v4i8, v4i8)
+v2q15 __builtin_mips_subq_ph (v2q15, v2q15)
+v2q15 __builtin_mips_subq_s_ph (v2q15, v2q15)
+q31 __builtin_mips_subq_s_w (q31, q31)
+v4i8 __builtin_mips_subu_qb (v4i8, v4i8)
+v4i8 __builtin_mips_subu_s_qb (v4i8, v4i8)
+i32 __builtin_mips_addsc (i32, i32)
+i32 __builtin_mips_addwc (i32, i32)
+i32 __builtin_mips_modsub (i32, i32)
+i32 __builtin_mips_raddu_w_qb (v4i8)
+v2q15 __builtin_mips_absq_s_ph (v2q15)
+q31 __builtin_mips_absq_s_w (q31)
+v4i8 __builtin_mips_precrq_qb_ph (v2q15, v2q15)
+v2q15 __builtin_mips_precrq_ph_w (q31, q31)
+v2q15 __builtin_mips_precrq_rs_ph_w (q31, q31)
+v4i8 __builtin_mips_precrqu_s_qb_ph (v2q15, v2q15)
+q31 __builtin_mips_preceq_w_phl (v2q15)
+q31 __builtin_mips_preceq_w_phr (v2q15)
+v2q15 __builtin_mips_precequ_ph_qbl (v4i8)
+v2q15 __builtin_mips_precequ_ph_qbr (v4i8)
+v2q15 __builtin_mips_precequ_ph_qbla (v4i8)
+v2q15 __builtin_mips_precequ_ph_qbra (v4i8)
+v2q15 __builtin_mips_preceu_ph_qbl (v4i8)
+v2q15 __builtin_mips_preceu_ph_qbr (v4i8)
+v2q15 __builtin_mips_preceu_ph_qbla (v4i8)
+v2q15 __builtin_mips_preceu_ph_qbra (v4i8)
+v4i8 __builtin_mips_shll_qb (v4i8, imm0_7)
+v4i8 __builtin_mips_shll_qb (v4i8, i32)
+v2q15 __builtin_mips_shll_ph (v2q15, imm0_15)
+v2q15 __builtin_mips_shll_ph (v2q15, i32)
+v2q15 __builtin_mips_shll_s_ph (v2q15, imm0_15)
+v2q15 __builtin_mips_shll_s_ph (v2q15, i32)
+q31 __builtin_mips_shll_s_w (q31, imm0_31)
+q31 __builtin_mips_shll_s_w (q31, i32)
+v4i8 __builtin_mips_shrl_qb (v4i8, imm0_7)
+v4i8 __builtin_mips_shrl_qb (v4i8, i32)
+v2q15 __builtin_mips_shra_ph (v2q15, imm0_15)
+v2q15 __builtin_mips_shra_ph (v2q15, i32)
+v2q15 __builtin_mips_shra_r_ph (v2q15, imm0_15)
+v2q15 __builtin_mips_shra_r_ph (v2q15, i32)
+q31 __builtin_mips_shra_r_w (q31, imm0_31)
+q31 __builtin_mips_shra_r_w (q31, i32)
+v2q15 __builtin_mips_muleu_s_ph_qbl (v4i8, v2q15)
+v2q15 __builtin_mips_muleu_s_ph_qbr (v4i8, v2q15)
+v2q15 __builtin_mips_mulq_rs_ph (v2q15, v2q15)
+q31 __builtin_mips_muleq_s_w_phl (v2q15, v2q15)
+q31 __builtin_mips_muleq_s_w_phr (v2q15, v2q15)
+a64 __builtin_mips_dpau_h_qbl (a64, v4i8, v4i8)
+a64 __builtin_mips_dpau_h_qbr (a64, v4i8, v4i8)
+a64 __builtin_mips_dpsu_h_qbl (a64, v4i8, v4i8)
+a64 __builtin_mips_dpsu_h_qbr (a64, v4i8, v4i8)
+a64 __builtin_mips_dpaq_s_w_ph (a64, v2q15, v2q15)
+a64 __builtin_mips_dpaq_sa_l_w (a64, q31, q31)
+a64 __builtin_mips_dpsq_s_w_ph (a64, v2q15, v2q15)
+a64 __builtin_mips_dpsq_sa_l_w (a64, q31, q31)
+a64 __builtin_mips_mulsaq_s_w_ph (a64, v2q15, v2q15)
+a64 __builtin_mips_maq_s_w_phl (a64, v2q15, v2q15)
+a64 __builtin_mips_maq_s_w_phr (a64, v2q15, v2q15)
+a64 __builtin_mips_maq_sa_w_phl (a64, v2q15, v2q15)
+a64 __builtin_mips_maq_sa_w_phr (a64, v2q15, v2q15)
+i32 __builtin_mips_bitrev (i32)
+i32 __builtin_mips_insv (i32, i32)
+v4i8 __builtin_mips_repl_qb (imm0_255)
+v4i8 __builtin_mips_repl_qb (i32)
+v2q15 __builtin_mips_repl_ph (imm_n512_511)
+v2q15 __builtin_mips_repl_ph (i32)
+void __builtin_mips_cmpu_eq_qb (v4i8, v4i8)
+void __builtin_mips_cmpu_lt_qb (v4i8, v4i8)
+void __builtin_mips_cmpu_le_qb (v4i8, v4i8)
+i32 __builtin_mips_cmpgu_eq_qb (v4i8, v4i8)
+i32 __builtin_mips_cmpgu_lt_qb (v4i8, v4i8)
+i32 __builtin_mips_cmpgu_le_qb (v4i8, v4i8)
+void __builtin_mips_cmp_eq_ph (v2q15, v2q15)
+void __builtin_mips_cmp_lt_ph (v2q15, v2q15)
+void __builtin_mips_cmp_le_ph (v2q15, v2q15)
+v4i8 __builtin_mips_pick_qb (v4i8, v4i8)
+v2q15 __builtin_mips_pick_ph (v2q15, v2q15)
+v2q15 __builtin_mips_packrl_ph (v2q15, v2q15)
+i32 __builtin_mips_extr_w (a64, imm0_31)
+i32 __builtin_mips_extr_w (a64, i32)
+i32 __builtin_mips_extr_r_w (a64, imm0_31)
+i32 __builtin_mips_extr_s_h (a64, i32)
+i32 __builtin_mips_extr_rs_w (a64, imm0_31)
+i32 __builtin_mips_extr_rs_w (a64, i32)
+i32 __builtin_mips_extr_s_h (a64, imm0_31)
+i32 __builtin_mips_extr_r_w (a64, i32)
+i32 __builtin_mips_extp (a64, imm0_31)
+i32 __builtin_mips_extp (a64, i32)
+i32 __builtin_mips_extpdp (a64, imm0_31)
+i32 __builtin_mips_extpdp (a64, i32)
+a64 __builtin_mips_shilo (a64, imm_n32_31)
+a64 __builtin_mips_shilo (a64, i32)
+a64 __builtin_mips_mthlip (a64, i32)
+void __builtin_mips_wrdsp (i32, imm0_63)
+i32 __builtin_mips_rddsp (imm0_63)
+i32 __builtin_mips_lbux (void *, i32)
+i32 __builtin_mips_lhx (void *, i32)
+i32 __builtin_mips_lwx (void *, i32)
+i32 __builtin_mips_bposge32 (void)
+@end smallexample
+
+@node MIPS Paired-Single Support
+@subsection MIPS Paired-Single Support
+
+The MIPS64 architecture includes a number of instructions that
+operate on pairs of single-precision floating-point values.
+Each pair is packed into a 64-bit floating-point register,
+with one element being designated the ``upper half'' and
+the other being designated the ``lower half''.
+
+GCC supports paired-single operations using both the generic
+vector extensions (@pxref{Vector Extensions}) and a collection of
+MIPS-specific built-in functions.  Both kinds of support are
+enabled by the @option{-mpaired-single} command-line option.
+
+The vector type associated with paired-single values is usually
+called @code{v2sf}.  It can be defined in C as follows:
+
+@smallexample
+typedef float v2sf __attribute__ ((vector_size (8)));
+@end smallexample
+
+@code{v2sf} values are initialized in the same way as aggregates.
+For example:
+
+@smallexample
+v2sf a = @{1.5, 9.1@};
+v2sf b;
+float e, f;
+b = (v2sf) @{e, f@};
+@end smallexample
+
+@emph{Note:} The CPU's endianness determines which value is stored in
+the upper half of a register and which value is stored in the lower half.
+On little-endian targets, the first value is the lower one and the second
+value is the upper one.  The opposite order applies to big-endian targets.
+For example, the code above will set the lower half of @code{a} to
+@code{1.5} on little-endian targets and @code{9.1} on big-endian targets.
+
+@menu
+* Paired-Single Arithmetic::
+* Paired-Single Built-in Functions::
+* MIPS-3D Built-in Functions::
+@end menu
+
+@node Paired-Single Arithmetic
+@subsubsection Paired-Single Arithmetic
+
+The table below lists the @code{v2sf} operations for which hardware
+support exists.  @code{a}, @code{b} and @code{c} are @code{v2sf}
+values and @code{x} is an integral value.
+
+@multitable @columnfractions .50 .50
+@item C code @tab MIPS instruction
+@item @code{a + b} @tab @code{add.ps}
+@item @code{a - b} @tab @code{sub.ps}
+@item @code{-a} @tab @code{neg.ps}
+@item @code{a * b} @tab @code{mul.ps}
+@item @code{a * b + c} @tab @code{madd.ps}
+@item @code{a * b - c} @tab @code{msub.ps}
+@item @code{-(a * b + c)} @tab @code{nmadd.ps}
+@item @code{-(a * b - c)} @tab @code{nmsub.ps}
+@item @code{x ? a : b} @tab @code{movn.ps}/@code{movz.ps}
+@end multitable
+
+Note that the multiply-accumulate instructions can be disabled
+using the command-line option @code{-mno-fused-madd}.
+
+@node Paired-Single Built-in Functions
+@subsubsection Paired-Single Built-in Functions
+
+The following paired-single functions map directly to a particular
+MIPS instruction.  Please refer to the architecture specification
+for details on what each instruction does.
+
+@table @code
+@item v2sf __builtin_mips_pll_ps (v2sf, v2sf)
+Pair lower lower (@code{pll.ps}).
+
+@item v2sf __builtin_mips_pul_ps (v2sf, v2sf)
+Pair upper lower (@code{pul.ps}).
+
+@item v2sf __builtin_mips_plu_ps (v2sf, v2sf)
+Pair lower upper (@code{plu.ps}).
+
+@item v2sf __builtin_mips_puu_ps (v2sf, v2sf)
+Pair upper upper (@code{puu.ps}).
+
+@item v2sf __builtin_mips_cvt_ps_s (float, float)
+Convert pair to paired single (@code{cvt.ps.s}).
+
+@item float __builtin_mips_cvt_s_pl (v2sf)
+Convert pair lower to single (@code{cvt.s.pl}).
+
+@item float __builtin_mips_cvt_s_pu (v2sf)
+Convert pair upper to single (@code{cvt.s.pu}).
+
+@item v2sf __builtin_mips_abs_ps (v2sf)
+Absolute value (@code{abs.ps}).
+
+@item v2sf __builtin_mips_alnv_ps (v2sf, v2sf, int)
+Align variable (@code{alnv.ps}).
+
+@emph{Note:} The value of the third parameter must be 0 or 4
+modulo 8, otherwise the result will be unpredictable.  Please read the
+instruction description for details.
+@end table
+
+The following multi-instruction functions are also available.
+In each case, @var{cond} can be any of the 16 floating-point conditions:
+@code{f}, @code{un}, @code{eq}, @code{ueq}, @code{olt}, @code{ult},
+@code{ole}, @code{ule}, @code{sf}, @code{ngle}, @code{seq}, @code{ngl},
+@code{lt}, @code{nge}, @code{le} or @code{ngt}.
+
+@table @code
+@item v2sf __builtin_mips_movt_c_@var{cond}_ps (v2sf @var{a}, v2sf @var{b}, v2sf @var{c}, v2sf @var{d})
+@itemx v2sf __builtin_mips_movf_c_@var{cond}_ps (v2sf @var{a}, v2sf @var{b}, v2sf @var{c}, v2sf @var{d})
+Conditional move based on floating point comparison (@code{c.@var{cond}.ps},
+@code{movt.ps}/@code{movf.ps}).
+
+The @code{movt} functions return the value @var{x} computed by:
+
+@smallexample
+c.@var{cond}.ps @var{cc},@var{a},@var{b}
+mov.ps @var{x},@var{c}
+movt.ps @var{x},@var{d},@var{cc}
+@end smallexample
+
+The @code{movf} functions are similar but use @code{movf.ps} instead
+of @code{movt.ps}.
+
+@item int __builtin_mips_upper_c_@var{cond}_ps (v2sf @var{a}, v2sf @var{b})
+@itemx int __builtin_mips_lower_c_@var{cond}_ps (v2sf @var{a}, v2sf @var{b})
+Comparison of two paired-single values (@code{c.@var{cond}.ps},
+@code{bc1t}/@code{bc1f}).
+
+These functions compare @var{a} and @var{b} using @code{c.@var{cond}.ps}
+and return either the upper or lower half of the result.  For example:
+
+@smallexample
+v2sf a, b;
+if (__builtin_mips_upper_c_eq_ps (a, b))
+  upper_halves_are_equal ();
+else
+  upper_halves_are_unequal ();
+
+if (__builtin_mips_lower_c_eq_ps (a, b))
+  lower_halves_are_equal ();
+else
+  lower_halves_are_unequal ();
+@end smallexample
+@end table
+
+@node MIPS-3D Built-in Functions
+@subsubsection MIPS-3D Built-in Functions
+
+The MIPS-3D Application-Specific Extension (ASE) includes additional
+paired-single instructions that are designed to improve the performance
+of 3D graphics operations.  Support for these instructions is controlled
+by the @option{-mips3d} command-line option.
+
+The functions listed below map directly to a particular MIPS-3D
+instruction.  Please refer to the architecture specification for
+more details on what each instruction does.
+
+@table @code
+@item v2sf __builtin_mips_addr_ps (v2sf, v2sf)
+Reduction add (@code{addr.ps}).
+
+@item v2sf __builtin_mips_mulr_ps (v2sf, v2sf)
+Reduction multiply (@code{mulr.ps}).
+
+@item v2sf __builtin_mips_cvt_pw_ps (v2sf)
+Convert paired single to paired word (@code{cvt.pw.ps}).
+
+@item v2sf __builtin_mips_cvt_ps_pw (v2sf)
+Convert paired word to paired single (@code{cvt.ps.pw}).
+
+@item float __builtin_mips_recip1_s (float)
+@itemx double __builtin_mips_recip1_d (double)
+@itemx v2sf __builtin_mips_recip1_ps (v2sf)
+Reduced precision reciprocal (sequence step 1) (@code{recip1.@var{fmt}}).
+
+@item float __builtin_mips_recip2_s (float, float)
+@itemx double __builtin_mips_recip2_d (double, double)
+@itemx v2sf __builtin_mips_recip2_ps (v2sf, v2sf)
+Reduced precision reciprocal (sequence step 2) (@code{recip2.@var{fmt}}).
+
+@item float __builtin_mips_rsqrt1_s (float)
+@itemx double __builtin_mips_rsqrt1_d (double)
+@itemx v2sf __builtin_mips_rsqrt1_ps (v2sf)
+Reduced precision reciprocal square root (sequence step 1)
+(@code{rsqrt1.@var{fmt}}).
+
+@item float __builtin_mips_rsqrt2_s (float, float)
+@itemx double __builtin_mips_rsqrt2_d (double, double)
+@itemx v2sf __builtin_mips_rsqrt2_ps (v2sf, v2sf)
+Reduced precision reciprocal square root (sequence step 2)
+(@code{rsqrt2.@var{fmt}}).
+@end table
+
+The following multi-instruction functions are also available.
+In each case, @var{cond} can be any of the 16 floating-point conditions:
+@code{f}, @code{un}, @code{eq}, @code{ueq}, @code{olt}, @code{ult},
+@code{ole}, @code{ule}, @code{sf}, @code{ngle}, @code{seq},
+@code{ngl}, @code{lt}, @code{nge}, @code{le} or @code{ngt}.
+
+@table @code
+@item int __builtin_mips_cabs_@var{cond}_s (float @var{a}, float @var{b})
+@itemx int __builtin_mips_cabs_@var{cond}_d (double @var{a}, double @var{b})
+Absolute comparison of two scalar values (@code{cabs.@var{cond}.@var{fmt}},
+@code{bc1t}/@code{bc1f}).
+
+These functions compare @var{a} and @var{b} using @code{cabs.@var{cond}.s}
+or @code{cabs.@var{cond}.d} and return the result as a boolean value.
+For example:
+
+@smallexample
+float a, b;
+if (__builtin_mips_cabs_eq_s (a, b))
+  true ();
+else
+  false ();
+@end smallexample
+
+@item int __builtin_mips_upper_cabs_@var{cond}_ps (v2sf @var{a}, v2sf @var{b})
+@itemx int __builtin_mips_lower_cabs_@var{cond}_ps (v2sf @var{a}, v2sf @var{b})
+Absolute comparison of two paired-single values (@code{cabs.@var{cond}.ps},
+@code{bc1t}/@code{bc1f}).
+
+These functions compare @var{a} and @var{b} using @code{cabs.@var{cond}.ps}
+and return either the upper or lower half of the result.  For example:
+
+@smallexample
+v2sf a, b;
+if (__builtin_mips_upper_cabs_eq_ps (a, b))
+  upper_halves_are_equal ();
+else
+  upper_halves_are_unequal ();
+
+if (__builtin_mips_lower_cabs_eq_ps (a, b))
+  lower_halves_are_equal ();
+else
+  lower_halves_are_unequal ();
+@end smallexample
+
+@item v2sf __builtin_mips_movt_cabs_@var{cond}_ps (v2sf @var{a}, v2sf @var{b}, v2sf @var{c}, v2sf @var{d})
+@itemx v2sf __builtin_mips_movf_cabs_@var{cond}_ps (v2sf @var{a}, v2sf @var{b}, v2sf @var{c}, v2sf @var{d})
+Conditional move based on absolute comparison (@code{cabs.@var{cond}.ps},
+@code{movt.ps}/@code{movf.ps}).
+
+The @code{movt} functions return the value @var{x} computed by:
+
+@smallexample
+cabs.@var{cond}.ps @var{cc},@var{a},@var{b}
+mov.ps @var{x},@var{c}
+movt.ps @var{x},@var{d},@var{cc}
+@end smallexample
+
+The @code{movf} functions are similar but use @code{movf.ps} instead
+of @code{movt.ps}.
+
+@item int __builtin_mips_any_c_@var{cond}_ps (v2sf @var{a}, v2sf @var{b})
+@itemx int __builtin_mips_all_c_@var{cond}_ps (v2sf @var{a}, v2sf @var{b})
+@itemx int __builtin_mips_any_cabs_@var{cond}_ps (v2sf @var{a}, v2sf @var{b})
+@itemx int __builtin_mips_all_cabs_@var{cond}_ps (v2sf @var{a}, v2sf @var{b})
+Comparison of two paired-single values
+(@code{c.@var{cond}.ps}/@code{cabs.@var{cond}.ps},
+@code{bc1any2t}/@code{bc1any2f}).
+
+These functions compare @var{a} and @var{b} using @code{c.@var{cond}.ps}
+or @code{cabs.@var{cond}.ps}.  The @code{any} forms return true if either
+result is true and the @code{all} forms return true if both results are true.
+For example:
+
+@smallexample
+v2sf a, b;
+if (__builtin_mips_any_c_eq_ps (a, b))
+  one_is_true ();
+else
+  both_are_false ();
+
+if (__builtin_mips_all_c_eq_ps (a, b))
+  both_are_true ();
+else
+  one_is_false ();
+@end smallexample
+
+@item int __builtin_mips_any_c_@var{cond}_4s (v2sf @var{a}, v2sf @var{b}, v2sf @var{c}, v2sf @var{d})
+@itemx int __builtin_mips_all_c_@var{cond}_4s (v2sf @var{a}, v2sf @var{b}, v2sf @var{c}, v2sf @var{d})
+@itemx int __builtin_mips_any_cabs_@var{cond}_4s (v2sf @var{a}, v2sf @var{b}, v2sf @var{c}, v2sf @var{d})
+@itemx int __builtin_mips_all_cabs_@var{cond}_4s (v2sf @var{a}, v2sf @var{b}, v2sf @var{c}, v2sf @var{d})
+Comparison of four paired-single values
+(@code{c.@var{cond}.ps}/@code{cabs.@var{cond}.ps},
+@code{bc1any4t}/@code{bc1any4f}).
+
+These functions use @code{c.@var{cond}.ps} or @code{cabs.@var{cond}.ps}
+to compare @var{a} with @var{b} and to compare @var{c} with @var{d}.
+The @code{any} forms return true if any of the four results are true
+and the @code{all} forms return true if all four results are true.
+For example:
+
+@smallexample
+v2sf a, b, c, d;
+if (__builtin_mips_any_c_eq_4s (a, b, c, d))
+  some_are_true ();
+else
+  all_are_false ();
+
+if (__builtin_mips_all_c_eq_4s (a, b, c, d))
+  all_are_true ();
+else
+  some_are_false ();
+@end smallexample
+@end table
+
 @node PowerPC AltiVec Built-in Functions
 @subsection PowerPC AltiVec Built-in Functions
 
@@ -6159,16 +7815,17 @@ A vector initializer requires no cast if the vector constant is of the
 same type as the variable it is initializing.
 
 @item
-If @code{signed} or @code{unsigned} is omitted, the vector type defaults
-to @code{signed} for @code{vector int} or @code{vector short} and to
-@code{unsigned} for @code{vector char}.
-                                                                                
+If @code{signed} or @code{unsigned} is omitted, the signedness of the
+vector type is the default signedness of the base type.  The default
+varies depending on the operating system, so a portable program should
+always specify the signedness.
+
 @item
 Compiling with @option{-maltivec} adds keywords @code{__vector},
 @code{__pixel}, and @code{__bool}.  Macros @option{vector},
 @code{pixel}, and @code{bool} are defined in @code{<altivec.h>} and can
 be undefined.
-                                                                                
+
 @item
 GCC allows using a @code{typedef} name as the type specifier for a
 vector type.
@@ -8011,6 +9668,64 @@ int vec_any_numeric (vector float);
 int vec_any_out (vector float, vector float);
 @end smallexample
 
+@node SPARC VIS Built-in Functions
+@subsection SPARC VIS Built-in Functions
+
+GCC supports SIMD operations on the SPARC using both the generic vector
+extensions (@pxref{Vector Extensions}) as well as built-in functions for
+the SPARC Visual Instruction Set (VIS).  When you use the @option{-mvis}
+switch, the VIS extension is exposed as the following built-in functions:
+
+@smallexample
+typedef int v2si __attribute__ ((vector_size (8)));
+typedef short v4hi __attribute__ ((vector_size (8)));
+typedef short v2hi __attribute__ ((vector_size (4)));
+typedef char v8qi __attribute__ ((vector_size (8)));
+typedef char v4qi __attribute__ ((vector_size (4)));
+
+void * __builtin_vis_alignaddr (void *, long);
+int64_t __builtin_vis_faligndatadi (int64_t, int64_t);
+v2si __builtin_vis_faligndatav2si (v2si, v2si);
+v4hi __builtin_vis_faligndatav4hi (v4si, v4si);
+v8qi __builtin_vis_faligndatav8qi (v8qi, v8qi);
+
+v4hi __builtin_vis_fexpand (v4qi);
+
+v4hi __builtin_vis_fmul8x16 (v4qi, v4hi);
+v4hi __builtin_vis_fmul8x16au (v4qi, v4hi);
+v4hi __builtin_vis_fmul8x16al (v4qi, v4hi);
+v4hi __builtin_vis_fmul8sux16 (v8qi, v4hi);
+v4hi __builtin_vis_fmul8ulx16 (v8qi, v4hi);
+v2si __builtin_vis_fmuld8sux16 (v4qi, v2hi);
+v2si __builtin_vis_fmuld8ulx16 (v4qi, v2hi);
+
+v4qi __builtin_vis_fpack16 (v4hi);
+v8qi __builtin_vis_fpack32 (v2si, v2si);
+v2hi __builtin_vis_fpackfix (v2si);
+v8qi __builtin_vis_fpmerge (v4qi, v4qi);
+
+int64_t __builtin_vis_pdist (v8qi, v8qi, int64_t);
+@end smallexample
+
+@node Target Format Checks
+@section Format Checks Specific to Particular Target Machines
+
+For some target machines, GCC supports additional options to the
+format attribute
+(@pxref{Function Attributes,,Declaring Attributes of Functions}).
+
+@menu
+* Solaris Format Checks::
+@end menu
+
+@node Solaris Format Checks
+@subsection Solaris Format Checks
+
+Solaris targets support the @code{cmn_err} (or @code{__cmn_err__}) format
+check.  @code{cmn_err} accepts a subset of the standard @code{printf}
+conversions, and the two-argument @code{%b} conversion for displaying
+bit-fields.  See the Solaris man page for @code{cmn_err} for more information.
+
 @node Pragmas
 @section Pragmas Accepted by GCC
 @cindex pragmas
@@ -8023,10 +9738,15 @@ for further explanation.
 
 @menu
 * ARM Pragmas::
+* M32C Pragmas::
 * RS/6000 and PowerPC Pragmas::
 * Darwin Pragmas::
 * Solaris Pragmas::
-* Tru64 Pragmas::
+* Symbol-Renaming Pragmas::
+* Structure-Packing Pragmas::
+* Weak Pragmas::
+* Diagnostic Pragmas::
+* Visibility Pragmas::
 @end menu
 
 @node ARM Pragmas
@@ -8052,6 +9772,21 @@ Do not affect the @code{long_call} or @code{short_call} attributes of
 subsequent functions.
 @end table
 
+@node M32C Pragmas
+@subsection M32C Pragmas
+
+@table @code
+@item memregs @var{number}
+@cindex pragma, memregs
+Overrides the command line option @code{-memregs=} for the current
+file.  Use with care!  This pragma must be before any function in the
+file, and mixing different memregs values in different objects may
+make them incompatible.  This pragma is useful when a
+performance-critical function uses a memreg for temporary values,
+as it may allow you to reduce the number of memregs used.
+
+@end table
+
 @node RS/6000 and PowerPC Pragmas
 @subsection RS/6000 and PowerPC Pragmas
 
@@ -8075,8 +9810,6 @@ declarations.
 
 @c Describe c4x pragmas here.
 @c Describe h8300 pragmas here.
-@c Describe i370 pragmas here.
-@c Describe i960 pragmas here.
 @c Describe sh pragmas here.
 @c Describe v850 pragmas here.
 
@@ -8115,44 +9848,223 @@ anywhere within the variables' scopes.
 @node Solaris Pragmas
 @subsection Solaris Pragmas
 
-For compatibility with the SunPRO compiler, the following pragma
-is supported.
+The Solaris target supports @code{#pragma redefine_extname}
+(@pxref{Symbol-Renaming Pragmas}).  It also supports additional
+@code{#pragma} directives for compatibility with the system compiler.
 
 @table @code
-@item redefine_extname @var{oldname} @var{newname}
-@cindex pragma, redefine_extname
+@item align @var{alignment} (@var{variable} [, @var{variable}]...)
+@cindex pragma, align
+
+Increase the minimum alignment of each @var{variable} to @var{alignment}.
+This is the same as GCC's @code{aligned} attribute @pxref{Variable
+Attributes}).  Macro expansion occurs on the arguments to this pragma
+when compiling C and Objective-C.  It does not currently occur when
+compiling C++, but this is a bug which may be fixed in a future
+release.
+
+@item fini (@var{function} [, @var{function}]...)
+@cindex pragma, fini
+
+This pragma causes each listed @var{function} to be called after
+main, or during shared module unloading, by adding a call to the
+@code{.fini} section.
+
+@item init (@var{function} [, @var{function}]...)
+@cindex pragma, init
+
+This pragma causes each listed @var{function} to be called during
+initialization (before @code{main}) or during shared module loading, by
+adding a call to the @code{.init} section.
 
-This pragma gives the C function @var{oldname} the assembler label
-@var{newname}.  The pragma must appear before the function declaration.
-This pragma is equivalent to the asm labels extension (@pxref{Asm
-Labels}).  The preprocessor defines @code{__PRAGMA_REDEFINE_EXTNAME}
-if the pragma is available.
 @end table
 
-@node Tru64 Pragmas
-@subsection Tru64 Pragmas
+@node Symbol-Renaming Pragmas
+@subsection Symbol-Renaming Pragmas
 
-For compatibility with the Compaq C compiler, the following pragma
-is supported.
+For compatibility with the Solaris and Tru64 UNIX system headers, GCC
+supports two @code{#pragma} directives which change the name used in
+assembly for a given declaration.  These pragmas are only available on
+platforms whose system headers need them.  To get this effect on all
+platforms supported by GCC, use the asm labels extension (@pxref{Asm
+Labels}).
 
 @table @code
+@item redefine_extname @var{oldname} @var{newname}
+@cindex pragma, redefine_extname
+
+This pragma gives the C function @var{oldname} the assembly symbol
+@var{newname}.  The preprocessor macro @code{__PRAGMA_REDEFINE_EXTNAME}
+will be defined if this pragma is available (currently only on
+Solaris).
+
 @item extern_prefix @var{string}
 @cindex pragma, extern_prefix
 
-This pragma renames all subsequent function and variable declarations
-such that @var{string} is prepended to the name.  This effect may be
-terminated by using another @code{extern_prefix} pragma with the
-empty string.
+This pragma causes all subsequent external function and variable
+declarations to have @var{string} prepended to their assembly symbols.
+This effect may be terminated with another @code{extern_prefix} pragma
+whose argument is an empty string.  The preprocessor macro
+@code{__PRAGMA_EXTERN_PREFIX} will be defined if this pragma is
+available (currently only on Tru64 UNIX)@.
+@end table
+
+These pragmas and the asm labels extension interact in a complicated
+manner.  Here are some corner cases you may want to be aware of.
+
+@enumerate
+@item Both pragmas silently apply only to declarations with external
+linkage.  Asm labels do not have this restriction.
+
+@item In C++, both pragmas silently apply only to declarations with
+``C'' linkage.  Again, asm labels do not have this restriction.
+
+@item If any of the three ways of changing the assembly name of a
+declaration is applied to a declaration whose assembly name has
+already been determined (either by a previous use of one of these
+features, or because the compiler needed the assembly name in order to
+generate code), and the new name is different, a warning issues and
+the name does not change.
+
+@item The @var{oldname} used by @code{#pragma redefine_extname} is
+always the C-language name.
+
+@item If @code{#pragma extern_prefix} is in effect, and a declaration
+occurs with an asm label attached, the prefix is silently ignored for
+that declaration.
+
+@item If @code{#pragma extern_prefix} and @code{#pragma redefine_extname}
+apply to the same declaration, whichever triggered first wins, and a
+warning issues if they contradict each other.  (We would like to have
+@code{#pragma redefine_extname} always win, for consistency with asm
+labels, but if @code{#pragma extern_prefix} triggers first we have no
+way of knowing that that happened.)
+@end enumerate
+
+@node Structure-Packing Pragmas
+@subsection Structure-Packing Pragmas
+
+For compatibility with Win32, GCC supports a set of @code{#pragma}
+directives which change the maximum alignment of members of structures
+(other than zero-width bitfields), unions, and classes subsequently
+defined.  The @var{n} value below always is required to be a small power
+of two and specifies the new alignment in bytes.
+
+@enumerate
+@item @code{#pragma pack(@var{n})} simply sets the new alignment.
+@item @code{#pragma pack()} sets the alignment to the one that was in
+effect when compilation started (see also command line option
+@option{-fpack-struct[=<n>]} @pxref{Code Gen Options}).
+@item @code{#pragma pack(push[,@var{n}])} pushes the current alignment
+setting on an internal stack and then optionally sets the new alignment.
+@item @code{#pragma pack(pop)} restores the alignment setting to the one
+saved at the top of the internal stack (and removes that stack entry).
+Note that @code{#pragma pack([@var{n}])} does not influence this internal
+stack; thus it is possible to have @code{#pragma pack(push)} followed by
+multiple @code{#pragma pack(@var{n})} instances and finalized by a single
+@code{#pragma pack(pop)}.
+@end enumerate
+
+Some targets, e.g. i386 and powerpc, support the @code{ms_struct}
+@code{#pragma} which lays out a structure as the documented
+@code{__attribute__ ((ms_struct))}.
+@enumerate
+@item @code{#pragma ms_struct on} turns on the layout for structures
+declared.
+@item @code{#pragma ms_struct off} turns off the layout for structures
+declared.
+@item @code{#pragma ms_struct reset} goes back to the default layout.
+@end enumerate
+
+@node Weak Pragmas
+@subsection Weak Pragmas
+
+For compatibility with SVR4, GCC supports a set of @code{#pragma}
+directives for declaring symbols to be weak, and defining weak
+aliases.
+
+@table @code
+@item #pragma weak @var{symbol}
+@cindex pragma, weak
+This pragma declares @var{symbol} to be weak, as if the declaration
+had the attribute of the same name.  The pragma may appear before
+or after the declaration of @var{symbol}, but must appear before
+either its first use or its definition.  It is not an error for
+@var{symbol} to never be defined at all.
+
+@item #pragma weak @var{symbol1} = @var{symbol2}
+This pragma declares @var{symbol1} to be a weak alias of @var{symbol2}.
+It is an error if @var{symbol2} is not defined in the current
+translation unit.
+@end table
+
+@node Diagnostic Pragmas
+@subsection Diagnostic Pragmas
+
+GCC allows the user to selectively enable or disable certain types of
+diagnostics, and change the kind of the diagnostic.  For example, a
+project's policy might require that all sources compile with
+@option{-Werror} but certain files might have exceptions allowing
+specific types of warnings.  Or, a project might selectively enable
+diagnostics and treat them as errors depending on which preprocessor
+macros are defined.
+
+@table @code
+@item #pragma GCC diagnostic @var{kind} @var{option}
+@cindex pragma, diagnostic
+
+Modifies the disposition of a diagnostic.  Note that not all
+diagnostics are modifiable; at the moment only warnings (normally
+controlled by @samp{-W...}) can be controlled, and not all of them.
+Use @option{-fdiagnostics-show-option} to determine which diagnostics
+are controllable and which option controls them.
+
+@var{kind} is @samp{error} to treat this diagnostic as an error,
+@samp{warning} to treat it like a warning (even if @option{-Werror} is
+in effect), or @samp{ignored} if the diagnostic is to be ignored.
+@var{option} is a double quoted string which matches the command line
+option.
+
+@example
+#pragma GCC diagnostic warning "-Wformat"
+#pragma GCC diagnostic error "-Wformat"
+#pragma GCC diagnostic ignored "-Wformat"
+@end example
+
+Note that these pragmas override any command line options.  Also,
+while it is syntactically valid to put these pragmas anywhere in your
+sources, the only supported location for them is before any data or
+functions are defined.  Doing otherwise may result in unpredictable
+results depending on how the optimizer manages your sources.  If the
+same option is listed multiple times, the last one specified is the
+one that is in effect.  This pragma is not intended to be a general
+purpose replacement for command line options, but for implementing
+strict control over project policies.
+
+@end table
+
+@node Visibility Pragmas
+@subsection Visibility Pragmas
+
+@table @code
+@item #pragma GCC visibility push(@var{visibility})
+@itemx #pragma GCC visibility pop
+@cindex pragma, visibility
+
+This pragma allows the user to set the visibility for multiple
+declarations without having to give each a visibility attribute
+@xref{Function Attributes}, for more information about visibility and
+the attribute syntax.
+
+In C++, @samp{#pragma GCC visibility} affects only namespace-scope
+declarations.  Class members and template specializations are not
+affected; if you want to override the visibility for a particular
+member or instantiation, you must use an attribute.
 
-This pragma is similar in intent to to the asm labels extension
-(@pxref{Asm Labels}) in that the system programmer wants to change
-the assembly-level ABI without changing the source-level API.  The
-preprocessor defines @code{__PRAGMA_EXTERN_PREFIX} if the pragma is
-available.
 @end table
 
 @node Unnamed Fields
-@section Unnamed struct/union fields within structs/unions.
+@section Unnamed struct/union fields within structs/unions
 @cindex struct
 @cindex union
 
@@ -8192,6 +10104,15 @@ It is ambiguous which @code{a} is being referred to with @samp{foo.a}.
 Such constructs are not supported and must be avoided.  In the future,
 such constructs may be detected and treated as compilation errors.
 
+@opindex fms-extensions
+Unless @option{-fms-extensions} is used, the unnamed field must be a
+structure or union definition without a tag (for example, @samp{struct
+@{ int a; @};}).  If @option{-fms-extensions} is used, the field may
+also be a definition with a tag such as @samp{struct foo @{ int a;
+@};}, a reference to a previously defined structure or union such as
+@samp{struct foo;}, or a reference to a @code{typedef} name for a
+previously defined structure or union type.
+
 @node Thread-Local
 @section Thread-Local Storage
 @cindex Thread-Local Storage
@@ -8466,7 +10387,6 @@ test specifically for GNU C++ (@pxref{Common Predefined Macros,,
 Predefined Macros,cpp,The GNU C Preprocessor}).
 
 @menu
-* Min and Max::		C++ Minimum and maximum operators.
 * Volatiles::		What constitutes an access to a volatile object.
 * Restricted Pointers:: C99 restricted pointers and references.
 * Vague Linkage::       Where G++ puts inlines, vtables and such.
@@ -8477,58 +10397,12 @@ Predefined Macros,cpp,The GNU C Preprocessor}).
 * Bound member functions:: You can extract a function pointer to the
                         method denoted by a @samp{->*} or @samp{.*} expression.
 * C++ Attributes::      Variable, function, and type attributes for C++ only.
-* Strong Using::      Strong using-directives for namespace composition.
-* Offsetof::            Special syntax for implementing @code{offsetof}.
+* Namespace Association:: Strong using-directives for namespace association.
 * Java Exceptions::     Tweaking exception handling to work with Java.
 * Deprecated Features:: Things will disappear from g++.
 * Backwards Compatibility:: Compatibilities with earlier definitions of C++.
 @end menu
 
-@node Min and Max
-@section Minimum and Maximum Operators in C++
-
-It is very convenient to have operators which return the ``minimum'' or the
-``maximum'' of two arguments.  In GNU C++ (but not in GNU C),
-
-@table @code
-@item @var{a} <? @var{b}
-@findex <?
-@cindex minimum operator
-is the @dfn{minimum}, returning the smaller of the numeric values
-@var{a} and @var{b};
-
-@item @var{a} >? @var{b}
-@findex >?
-@cindex maximum operator
-is the @dfn{maximum}, returning the larger of the numeric values @var{a}
-and @var{b}.
-@end table
-
-These operations are not primitive in ordinary C++, since you can
-use a macro to return the minimum of two things in C++, as in the
-following example.
-
-@smallexample
-#define MIN(X,Y) ((X) < (Y) ? : (X) : (Y))
-@end smallexample
-
-@noindent
-You might then use @w{@samp{int min = MIN (i, j);}} to set @var{min} to
-the minimum value of variables @var{i} and @var{j}.
-
-However, side effects in @code{X} or @code{Y} may cause unintended
-behavior.  For example, @code{MIN (i++, j++)} will fail, incrementing
-the smaller counter twice.  The GNU C @code{typeof} extension allows you
-to write safe macros that avoid this kind of problem (@pxref{Typeof}).
-However, writing @code{MIN} and @code{MAX} as macros also forces you to
-use function-call notation for a fundamental arithmetic operation.
-Using GNU C++ extensions, you can write @w{@samp{int min = i <? j;}}
-instead.
-
-Since @code{<?} and @code{>?} are built into the compiler, they properly
-handle expressions with side-effects;  @w{@samp{int min = i++ <? j++;}}
-works correctly.
-
 @node Volatiles
 @section When is a Volatile Object Accessed?
 @cindex accessing volatiles
@@ -8538,11 +10412,10 @@ works correctly.
 
 Both the C and C++ standard have the concept of volatile objects.  These
 are normally accessed by pointers and used for accessing hardware.  The
-standards encourage compilers to refrain from optimizations
-concerning accesses to volatile objects that it might perform on
-non-volatile objects.  The C standard leaves it implementation defined
-as to what constitutes a volatile access.  The C++ standard omits to
-specify this, except to say that C++ should behave in a similar manner
+standards encourage compilers to refrain from optimizations concerning
+accesses to volatile objects.  The C standard leaves it implementation
+defined  as to what constitutes a volatile access.  The C++ standard omits
+to specify this, except to say that C++ should behave in a similar manner
 to C with respect to volatiles, where possible.  The minimum either
 standard specifies is that at a sequence point all previous accesses to
 volatile objects have stabilized and no subsequent accesses have
@@ -8552,55 +10425,28 @@ for accesses across a sequence point.  The use of volatiles does not
 allow you to violate the restriction on updating objects multiple times
 within a sequence point.
 
-In most expressions, it is intuitively obvious what is a read and what is
-a write.  For instance
+@xref{Qualifiers implementation, , Volatile qualifier and the C compiler}.
 
-@smallexample
-volatile int *dst = @var{somevalue};
-volatile int *src = @var{someothervalue};
-*dst = *src;
-@end smallexample
-
-@noindent
-will cause a read of the volatile object pointed to by @var{src} and stores the
-value into the volatile object pointed to by @var{dst}.  There is no
-guarantee that these reads and writes are atomic, especially for objects
-larger than @code{int}.
-
-Less obvious expressions are where something which looks like an access
-is used in a void context.  An example would be,
+The behavior differs slightly between C and C++ in the non-obvious cases:
 
 @smallexample
 volatile int *src = @var{somevalue};
 *src;
 @end smallexample
 
-With C, such expressions are rvalues, and as rvalues cause a read of
-the object, GCC interprets this as a read of the volatile being pointed
-to.  The C++ standard specifies that such expressions do not undergo
-lvalue to rvalue conversion, and that the type of the dereferenced
+With C, such expressions are rvalues, and GCC interprets this either as a
+read of the volatile object being pointed to or only as request to evaluate
+the side-effects.  The C++ standard specifies that such expressions do not
+undergo lvalue to rvalue conversion, and that the type of the dereferenced
 object may be incomplete.  The C++ standard does not specify explicitly
-that it is this lvalue to rvalue conversion which is responsible for
+that it is this lvalue to rvalue conversion which may be responsible for
 causing an access.  However, there is reason to believe that it is,
 because otherwise certain simple expressions become undefined.  However,
 because it would surprise most programmers, G++ treats dereferencing a
-pointer to volatile object of complete type in a void context as a read
-of the object.  When the object has incomplete type, G++ issues a
-warning.
-
-@smallexample
-struct S;
-struct T @{int m;@};
-volatile S *ptr1 = @var{somevalue};
-volatile T *ptr2 = @var{somevalue};
-*ptr1;
-*ptr2;
-@end smallexample
-
-In this example, a warning is issued for @code{*ptr1}, and @code{*ptr2}
-causes a read of the object pointed to.  If you wish to force an error on
-the first case, you must force a conversion to rvalue with, for instance
-a static cast, @code{static_cast<S>(*ptr1)}.
+pointer to volatile object of complete type when the value is unused as
+GCC would do for an equivalent type in C.  When the object has incomplete
+type, G++ issues a warning; if you wish to force an error, you must
+force a conversion to rvalue with, for instance, a static cast.
 
 When using a reference to volatile, G++ does not treat equivalent
 expressions as accesses to volatiles, but instead issues a warning that
@@ -8751,10 +10597,11 @@ translation unit.
 @emph{Note:} As of GCC 2.7.2, these @code{#pragma}s are not useful in
 most cases, because of COMDAT support and the ``key method'' heuristic
 mentioned in @ref{Vague Linkage}.  Using them can actually cause your
-program to grow due to unnecesary out-of-line copies of inline
-functions.  Currently the only benefit of these @code{#pragma}s is
-reduced duplication of debugging information, and that should be
-addressed soon on DWARF 2 targets with the use of COMDAT sections.
+program to grow due to unnecessary out-of-line copies of inline
+functions.  Currently (3.4) the only benefit of these
+@code{#pragma}s is reduced duplication of debugging information, and
+that should be addressed soon on DWARF 2 targets with the use of
+COMDAT groups.
 
 @table @code
 @item #pragma interface
@@ -9060,22 +10907,23 @@ interface table mechanism, instead of regular virtual table dispatch.
 
 @end table
 
-See also @xref{Strong Using}.
+See also @xref{Namespace Association}.
 
-@node Strong Using
-@section Strong Using
+@node Namespace Association
+@section Namespace Association
 
 @strong{Caution:} The semantics of this extension are not fully
 defined.  Users should refrain from using this extension as its
 semantics may change subtly over time.  It is possible that this
-extension wil be removed in future versions of G++.
+extension will be removed in future versions of G++.
 
 A using-directive with @code{__attribute ((strong))} is stronger
 than a normal using-directive in two ways:
 
 @itemize @bullet
 @item
-Templates from the used namespace can be specialized as though they were members of the using namespace.
+Templates from the used namespace can be specialized and explicitly
+instantiated as though they were members of the using namespace.
 
 @item
 The using namespace is considered an associated namespace of all
@@ -9083,6 +10931,9 @@ templates in the used namespace for purposes of argument-dependent
 name lookup.
 @end itemize
 
+The used namespace must be nested within the using namespace so that
+normal unqualified lookup works properly.
+
 This is useful for composing a namespace transparently from
 implementation namespaces.  For example:
 
@@ -9092,37 +10943,18 @@ namespace std @{
     template <class T> struct A @{ @};
   @}
   using namespace debug __attribute ((__strong__));
-  template <> struct A<int> @{ @};   // ok to specialize
+  template <> struct A<int> @{ @};   // @r{ok to specialize}
 
   template <class T> void f (A<T>);
 @}
 
 int main()
 @{
-  f (std::A<float>());             // lookup finds std::f
+  f (std::A<float>());             // @r{lookup finds} std::f
   f (std::A<int>());
 @}
 @end smallexample
 
-@node Offsetof
-@section Offsetof
-
-G++ uses a syntactic extension to implement the @code{offsetof} macro.
-
-In particular:
-
-@smallexample
-  __offsetof__ (expression)
-@end smallexample
-
-is equivalent to the parenthesized expression, except that the
-expression is considered an integral constant expression even if it
-contains certain operators that are not normally permitted in an
-integral constant expression.  Users should never use
-@code{__offsetof__} directly; the only valid use of
-@code{__offsetof__} is to implement the @code{offsetof} macro in
-@code{<stddef.h>}.
-
 @node Java Exceptions
 @section Java Exceptions
 
@@ -9135,7 +10967,7 @@ Sample problematic code is:
 
 @smallexample
   struct S @{ ~S(); @};
-  extern void bar();    // is written in Java, and may throw exceptions
+  extern void bar();    // @r{is written in Java, and may throw exceptions}
   void foo()
   @{
     S s;
@@ -9188,6 +11020,16 @@ parameters, as C++ demands.  This feature has been removed, except where
 it is required for backwards compatibility @xref{Backwards Compatibility}.
 @end table
 
+G++ allows a virtual function returning @samp{void *} to be overridden
+by one returning a different pointer type.  This extension to the
+covariant return type rules is now deprecated and will be removed from a
+future version.
+
+The G++ minimum and maximum operators (@samp{<?} and @samp{>?}) and
+their compound forms (@samp{<?=}) and @samp{>?=}) have been deprecated
+and will be removed in a future version.  Code using these operators
+should be modified to use @code{std::min} and @code{std::max} instead.
+
 The named return value extension has been deprecated, and is now
 removed from G++.
 
@@ -9200,10 +11042,20 @@ and are now removed from G++.
 The implicit typename extension has been deprecated and is now
 removed from G++.
 
-The use of default arguments in function pointers, function typedefs and
+The use of default arguments in function pointers, function typedefs
 and other places where they are not permitted by the standard is
 deprecated and will be removed from a future version of G++.
 
+G++ allows floating-point literals to appear in integral constant expressions,
+e.g. @samp{ enum E @{ e = int(2.2 * 3.7) @} }
+This extension is deprecated and will be removed from a future version.
+
+G++ allows static data members of const floating-point type to be declared
+with an initializer in a class definition. The standard only allows
+initializers for static members of const integral types and const
+enumeration types so this extension has been deprecated and will be removed
+from a future version.
+
 @node Backwards Compatibility
 @section Backwards Compatibility
 @cindex Backwards Compatibility