Imported from /home/lorry/working-area/delta_gcc-tarball/gcc-4.9.2.tar.bz2.gcc-4.9.2

1 files changed, 3316 insertions, 987 deletions

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 0887946a19..10ad6e4faf 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -1,6 +1,4 @@
-@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1996, 1998, 1999, 2000, 2001,
-@c 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
-@c Free Software Foundation, Inc.
+@c Copyright (C) 1988-2014 Free Software Foundation, Inc.
 
 @c This is part of the GCC manual.
 @c For copying conditions, see the file gcc.texi.
@@ -32,8 +30,8 @@ extensions, accepted by GCC in C90 mode and in C++.
 * Constructing Calls::  Dispatching a call to another function.
 * Typeof::              @code{typeof}: referring to the type of an expression.
 * Conditionals::        Omitting the middle operand of a @samp{?:} expression.
+* __int128::		128-bit integers---@code{__int128}.
 * Long Long::           Double-word integers---@code{long long int}.
-* __int128::			128-bit integers---@code{__int128}.
 * Complex::             Data types for complex numbers.
 * Floating Types::      Additional Floating Types.
 * Half-Precision::      Half-Precision Floating Point.
@@ -42,8 +40,8 @@ extensions, accepted by GCC in C90 mode and in C++.
 * Fixed-Point::         Fixed-Point Types.
 * Named Address Spaces::Named address spaces.
 * Zero Length::         Zero-length arrays.
-* Variable Length::     Arrays whose length is computed at run time.
 * Empty Structures::    Structures with no members.
+* Variable Length::     Arrays whose length is computed at run time.
 * Variadic Macros::     Macros with a variable number of arguments.
 * Escaped Newlines::    Slightly looser rules for escaped newlines.
 * Subscripting::        Any array can be subscripted, even if not an lvalue.
@@ -52,8 +50,8 @@ extensions, accepted by GCC in C90 mode and in C++.
 * Compound Literals::   Compound literals give structures, unions
                         or arrays as values.
 * Designated Inits::    Labeling elements of initializers.
-* Cast to Union::       Casting to union type from any member of the union.
 * Case Ranges::         `case 1 ... 9' and such.
+* Cast to Union::       Casting to union type from any member of the union.
 * Mixed Declarations::  Mixing declarations and code.
 * Function Attributes:: Declaring that functions have no side effects,
                         or that they can never return.
@@ -81,8 +79,10 @@ extensions, accepted by GCC in C90 mode and in C++.
 * Offsetof::            Special syntax for implementing @code{offsetof}.
 * __sync Builtins::     Legacy built-in functions for atomic memory access.
 * __atomic Builtins::   Atomic built-in functions with memory model.
+* x86 specific memory model extensions for transactional memory:: x86 memory models.
 * Object Size Checking:: Built-in functions for limited buffer overflow
                         checking.
+* Cilk Plus Builtins::  Built-in functions for the Cilk Plus language extension.
 * Other Builtins::      Other built-in functions.
 * Target Builtins::     Built-in functions specific to particular targets.
 * Target Format Checks:: Format checks specific to particular targets.
@@ -152,7 +152,7 @@ the value of an enumeration constant, the width of a bit-field, or
 the initial value of a static variable.
 
 If you don't know the type of the operand, you can still do this, but you
-must use @code{typeof} (@pxref{Typeof}).
+must use @code{typeof} or @code{__auto_type} (@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
@@ -165,17 +165,17 @@ expression.  For instance, if @code{A} is a class, then
 @end smallexample
 
 @noindent
-will construct a temporary @code{A} object to hold the result of the
-statement expression, and that will be used to invoke @code{Foo}.
-Therefore the @code{this} pointer observed by @code{Foo} will not be the
+constructs a temporary @code{A} object to hold the result of the
+statement expression, and that is used to invoke @code{Foo}.
+Therefore the @code{this} pointer observed by @code{Foo} is not the
 address of @code{a}.
 
-Any temporaries created within a statement within a statement expression
-will be destroyed at the statement's end.  This makes statement
+In a statement expression, any temporaries created within a statement
+are destroyed at that statement's end.  This makes statement
 expressions inside macros slightly different from function calls.  In
-the latter case temporaries introduced during argument evaluation will
-be destroyed at the end of the statement that includes the function
-call.  In the statement expression case they will be destroyed during
+the latter case temporaries introduced during argument evaluation are
+destroyed at the end of the statement that includes the function
+call.  In the statement expression case they are destroyed during
 the statement expression.  For instance,
 
 @smallexample
@@ -190,28 +190,28 @@ void foo ()
 @end smallexample
 
 @noindent
-will have different places where temporaries are destroyed.  For the
-@code{macro} case, the temporary @code{X} will be destroyed just after
+has different places where temporaries are destroyed.  For the
+@code{macro} case, the temporary @code{X} is destroyed just after
 the initialization of @code{b}.  In the @code{function} case that
-temporary will be destroyed when the function returns.
+temporary is destroyed when the function returns.
 
 These considerations mean that it is probably a bad idea to use
-statement-expressions of this form in header files that are designed to
+statement expressions of this form in header files that are designed to
 work with C++.  (Note that some versions of the GNU C Library contained
-header files using statement-expression that lead to precisely this
+header files using statement expressions 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.
+@code{goto} (@pxref{Labels as Values}) has 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
+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,
 
@@ -220,9 +220,9 @@ parts of the containing expression.  For example,
 @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}
+calls @code{foo} and @code{bar1} and does not call @code{baz} but
+may or may not call @code{bar2}.  If @code{bar2} is called, it is
+called after @code{foo} and before @code{bar1}.
 
 @node Local Labels
 @section Locally Declared Labels
@@ -232,7 +232,7 @@ called after @code{foo} and before @code{bar1}
 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
 only reference it (with a @code{goto} statement, or by taking its
-address) within the block in which it was declared.
+address) within the block in which it is declared.
 
 A local label declaration looks like this:
 
@@ -258,7 +258,7 @@ The local label feature is useful for complex macros.  If a macro
 contains nested loops, a @code{goto} can be useful for breaking out of
 them.  However, an ordinary label whose scope is the whole function
 cannot be used: if the macro can be expanded several times in one
-function, the label will be multiply defined in that function.  A
+function, the label is multiply defined in that function.  A
 local label avoids this problem.  For example:
 
 @smallexample
@@ -278,7 +278,7 @@ do @{                                              \
 @} while (0)
 @end smallexample
 
-This could also be written using a statement-expression:
+This could also be written using a statement expression:
 
 @smallexample
 #define SEARCH(array, target)                     \
@@ -333,12 +333,13 @@ goto *ptr;
 Any expression of type @code{void *} is allowed.
 
 One way of using these constants is in initializing a static array that
-will serve as a jump table:
+serves as a jump table:
 
 @smallexample
 static void *array[] = @{ &&foo, &&bar, &&hack @};
 @end smallexample
 
+@noindent
 Then you can select a label with indexing, like this:
 
 @smallexample
@@ -359,7 +360,7 @@ The labels within the interpreter function can be stored in the
 threaded code for super-fast dispatching.
 
 You may not use this mechanism to jump to code in a different function.
-If you do that, totally unpredictable things will happen.  The best way to
+If you do that, totally unpredictable things happen.  The best way to
 avoid this is to store the label address only in automatic variables and
 never pass it as an argument.
 
@@ -375,6 +376,8 @@ goto *(&&foo + array[i]);
 This is more friendly to code living in shared libraries, as it reduces
 the number of dynamic relocations that are needed, and by consequence,
 allows the data to be read-only.
+This alternative with label differences is not supported for the AVR target,
+please use the first approach for AVR programs.
 
 The @code{&&foo} expressions for the same label might have different
 values if the containing function is inlined or cloned.  If a program
@@ -390,9 +393,12 @@ variable initializer, inlining and cloning is forbidden.
 @cindex thunks
 
 A @dfn{nested function} is a function defined inside another function.
-(Nested functions are not supported for GNU C++.)  The nested function's
-name is local to the block where it is defined.  For example, here we
-define a nested function named @code{square}, and call it twice:
+Nested functions are supported as an extension in GNU C, but are not
+supported by GNU C++.
+
+The nested function's name is local to the block where it is defined.
+For example, here we define a nested function named @code{square}, and
+call it twice:
 
 @smallexample
 @group
@@ -448,8 +454,8 @@ But this technique works only so long as the containing function
 (@code{hack}, in this example) does not exit.
 
 If you try to call the nested function through its address after the
-containing function has exited, all hell will break loose.  If you try
-to call it after a containing scope level has exited, and if it refers
+containing function exits, all hell breaks loose.  If you try
+to call it after a containing scope level exits, and if it refers
 to some of the variables that are no longer in scope, you may be lucky,
 but it's not wise to take the risk.  If, however, the nested function
 does not refer to anything that has gone out of scope, you should be
@@ -461,9 +467,9 @@ called @dfn{trampolines}.  This technique was described in
 C++ Conference Proceedings, October 17-21, 1988).
 
 A nested function can jump to a label inherited from a containing
-function, provided the label was explicitly declared in the containing
+function, provided the label is explicitly declared in the containing
 function (@pxref{Local Labels}).  Such a jump returns instantly to the
-containing function, exiting the nested function which did the
+containing function, exiting the nested function that did the
 @code{goto} and any intermediate functions as well.  Here is an example:
 
 @smallexample
@@ -535,7 +541,7 @@ functions acting as mere forwarders for their arguments.
 
 @deftypefn {Built-in Function} {void *} __builtin_apply_args ()
 This built-in function returns a pointer to data
-describing how to perform a call with the same arguments as were passed
+describing how to perform a call with the same arguments as are passed
 to the current function.
 
 The function saves the arg pointer register, structure value address,
@@ -554,7 +560,7 @@ The value of @var{arguments} should be the value returned by
 of the stack argument data, in bytes.
 
 This function returns a pointer to data describing
-how to return whatever value was returned by @var{function}.  The data
+how to return whatever value is returned by @var{function}.  The data
 is saved in a block of memory allocated on the stack.
 
 It is not always simple to compute the proper value for @var{size}.  The
@@ -571,7 +577,7 @@ returned by @code{__builtin_apply}.
 
 @deftypefn {Built-in Function} {} __builtin_va_arg_pack ()
 This built-in function represents all anonymous arguments of an inline
-function.  It can be used only in inline functions which will be always
+function.  It can be used only in inline functions that are always
 inlined, never compiled as a separate function, such as those using
 @code{__attribute__ ((__always_inline__))} or
 @code{__attribute__ ((__gnu_inline__))} extern inline functions.
@@ -597,11 +603,11 @@ myprintf (FILE *f, const char *format, ...)
 
 @deftypefn {Built-in Function} {size_t} __builtin_va_arg_pack_len ()
 This built-in function returns the number of anonymous arguments of
-an inline function.  It can be used only in inline functions which
-will be always inlined, never compiled as a separate function, such
+an inline function.  It can be used only in inline functions that
+are always inlined, never compiled as a separate function, such
 as those using @code{__attribute__ ((__always_inline__))} or
 @code{__attribute__ ((__gnu_inline__))} extern inline functions.
-For example following will do link or runtime checking of open
+For example following does link- or run-time checking of open
 arguments for optimized code:
 @smallexample
 #ifdef __OPTIMIZE__
@@ -664,7 +670,7 @@ If you are writing a header file that must work when included in ISO C
 programs, write @code{__typeof__} instead of @code{typeof}.
 @xref{Alternate Keywords}.
 
-A @code{typeof}-construct can be used anywhere a typedef name could be
+A @code{typeof} construct can be used anywhere a typedef name can be
 used.  For example, you can use it in a declaration, in a cast, or inside
 of @code{sizeof} or @code{typeof}.
 
@@ -672,9 +678,10 @@ The operand of @code{typeof} is evaluated for its side effects if and
 only if it is an expression of variably modified type or the name of
 such a type.
 
-@code{typeof} is often useful in conjunction with the
-statements-within-expressions feature.  Here is how the two together can
-be used to define a safe ``maximum'' macro that operates on any
+@code{typeof} is often useful in conjunction with
+statement expressions (@pxref{Statement Exprs}).
+Here is how the two together can
+be used to define a safe ``maximum'' macro which operates on any
 arithmetic type and evaluates each of its arguments exactly once:
 
 @smallexample
@@ -749,8 +756,37 @@ Thus, @code{array (pointer (char), 4)} is the type of arrays of 4
 pointers to @code{char}.
 @end itemize
 
+In GNU C, but not GNU C++, you may also declare the type of a variable
+as @code{__auto_type}.  In that case, the declaration must declare
+only one variable, whose declarator must just be an identifier, the
+declaration must be initialized, and the type of the variable is
+determined by the initializer; the name of the variable is not in
+scope until after the initializer.  (In C++, you should use C++11
+@code{auto} for this purpose.)  Using @code{__auto_type}, the
+``maximum'' macro above could be written as:
+
+@smallexample
+#define max(a,b) \
+  (@{ __auto_type _a = (a); \
+      __auto_type _b = (b); \
+    _a > _b ? _a : _b; @})
+@end smallexample
+
+Using @code{__auto_type} instead of @code{typeof} has two advantages:
+
+@itemize @bullet
+@item Each argument to the macro appears only once in the expansion of
+the macro.  This prevents the size of the macro expansion growing
+exponentially when calls to such macros are nested inside arguments of
+such macros.
+
+@item If the argument to the macro has variably modified type, it is
+evaluated only once when using @code{__auto_type}, but twice if
+@code{typeof} is used.
+@end itemize
+
 @emph{Compatibility Note:} In addition to @code{typeof}, GCC 2 supported
-a more limited extension which permitted one to write
+a more limited extension that permitted one to write
 
 @smallexample
 typedef @var{T} = @var{expr};
@@ -759,7 +795,7 @@ typedef @var{T} = @var{expr};
 @noindent
 with the effect of declaring @var{T} to have the type of the expression
 @var{expr}.  This extension does not work with GCC 3 (versions between
-3.0 and 3.2 will crash; 3.2.1 and later give an error).  Code which
+3.0 and 3.2 crash; 3.2.1 and later give an error).  Code that
 relies on it should be rewritten to use @code{typeof}:
 
 @smallexample
@@ -767,7 +803,7 @@ typedef typeof(@var{expr}) @var{T};
 @end smallexample
 
 @noindent
-This will work with all versions of GCC@.
+This works with all versions of GCC@.
 
 @node Conditionals
 @section Conditionals with Omitted Operands
@@ -808,15 +844,15 @@ the middle operand uses the value already computed without the undesirable
 effects of recomputing it.
 
 @node __int128
-@section 128-bits integers
+@section 128-bit integers
 @cindex @code{__int128} data types
 
 As an extension the integer scalar type @code{__int128} is supported for
-targets having an integer mode wide enough to hold 128-bit.
+targets which have an integer mode wide enough to hold 128 bits.
 Simply write @code{__int128} for a signed 128-bit integer, or
 @code{unsigned __int128} for an unsigned 128-bit integer.  There is no
-support in GCC to express an integer constant of type @code{__int128}
-for targets having @code{long long} integer with less then 128 bit width.
+support in GCC for expressing an integer constant of type @code{__int128}
+for targets with @code{long long} integer less than 128 bits wide.
 
 @node Long Long
 @section Double-Word Integers
@@ -837,16 +873,16 @@ long int}, add the suffix @samp{ULL} to the integer.
 You can use these types in arithmetic like any other integer types.
 Addition, subtraction, and bitwise boolean operations on these types
 are open-coded on all types of machines.  Multiplication is open-coded
-if the machine supports fullword-to-doubleword a widening multiply
+if the machine supports a fullword-to-doubleword widening multiply
 instruction.  Division and shifts are open-coded only on machines that
 provide special support.  The operations that are not open-coded use
 special library routines that come with GCC@.
 
 There may be pitfalls when you use @code{long long} types for function
-arguments, unless you declare function prototypes.  If a function
+arguments without function prototypes.  If a function
 expects type @code{int} for its argument, and you pass a value of type
-@code{long long int}, confusion will result because the caller and the
-subroutine will disagree about the number of bytes for the argument.
+@code{long long int}, confusion results because the caller and the
+subroutine disagree about the number of bytes for the argument.
 Likewise, if the function expects @code{long long int} and you pass
 @code{int}.  The best way to avoid such problems is to use prototypes.
 
@@ -857,7 +893,7 @@ Likewise, if the function expects @code{long long int} and you pass
 @cindex @code{__complex__} keyword
 
 ISO C99 supports complex floating data types, and as an extension GCC
-supports them in C90 mode and in C++, and supports complex integer data
+supports them in C90 mode and in C++.  GCC also supports complex integer data
 types which are not part of ISO C99.  You can declare complex types
 using the keyword @code{_Complex}.  As an extension, the older GNU
 keyword @code{__complex__} is also supported.
@@ -875,7 +911,7 @@ has type @code{_Complex float} and @code{3i} has type
 @code{_Complex int}.  Such a constant always has a pure imaginary
 value, but you can form any complex value you like by adding one to a
 real constant.  This is a GNU extension; if you have an ISO C99
-conforming C library (such as GNU libc), and want to construct complex
+conforming C library (such as the GNU C Library), and want to construct complex
 constants of floating type, you should include @code{<complex.h>} and
 use the macros @code{I} or @code{_Complex_I} instead.
 
@@ -898,8 +934,8 @@ provided as built-in functions by GCC@.
 
 GCC can allocate complex automatic variables in a noncontiguous
 fashion; it's even possible for the real part to be in a register while
-the imaginary part is on the stack (or vice-versa).  Only the DWARF2
-debug info format can represent this, so use of DWARF2 is recommended.
+the imaginary part is on the stack (or vice versa).  Only the DWARF 2
+debug info format can represent this, so use of DWARF 2 is recommended.
 If you are using the stabs debug info format, GCC describes a noncontiguous
 complex variable as if it were two separate variables of noncomplex type.
 If the variable's actual name is @code{foo}, the two fictitious
@@ -916,9 +952,9 @@ examine and set these two fictitious variables with your debugger.
 @cindex @code{W} floating point suffix
 @cindex @code{Q} floating point suffix
 
-As an extension, the GNU C compiler supports additional floating
-types, @code{__float80} and @code{__float128} to support 80bit
-(@code{XFmode}) and 128 bit (@code{TFmode}) floating types.
+As an extension, GNU C supports additional floating
+types, @code{__float80} and @code{__float128} to support 80-bit
+(@code{XFmode}) and 128-bit (@code{TFmode}) floating types.
 Support for additional types includes the arithmetic operators:
 add, subtract, multiply, divide; unary arithmetic operators;
 relational operators; equality operators; and conversions to and from
@@ -933,8 +969,8 @@ typedef _Complex float __attribute__((mode(TC))) _Complex128;
 typedef _Complex float __attribute__((mode(XC))) _Complex80;
 @end smallexample
 
-Not all targets support additional floating point types.  @code{__float80}
-and @code{__float128} types are supported on i386, x86_64 and ia64 targets.
+Not all targets support additional floating-point types.  @code{__float80}
+and @code{__float128} types are supported on i386, x86_64 and IA-64 targets.
 The @code{__float128} type is supported on hppa HP-UX targets.
 
 @node Half-Precision
@@ -1000,7 +1036,7 @@ as library calls.
 @cindex @code{DD} integer suffix
 @cindex @code{DL} integer suffix
 
-As an extension, the GNU C compiler supports decimal floating types as
+As an extension, GNU C supports decimal floating types as
 defined in the N1312 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
@@ -1038,7 +1074,7 @@ the technical report.
 @end itemize
 
 Types @code{_Decimal32}, @code{_Decimal64}, and @code{_Decimal128}
-are supported by the DWARF2 debug information format.
+are supported by the DWARF 2 debug information format.
 
 @node Hex Floats
 @section Hex Floats
@@ -1051,7 +1087,7 @@ supports this in C90 mode (except in some cases when strictly
 conforming) and in C++.  In that format the
 @samp{0x} hex introducer and the @samp{p} or @samp{P} exponent field are
 mandatory.  The exponent is a decimal number that indicates the power of
-2 by which the significant part will be multiplied.  Thus @samp{0x1.f} is
+2 by which the significant part is multiplied.  Thus @samp{0x1.f} is
 @tex
 $1 {15\over16}$,
 @end tex
@@ -1106,7 +1142,7 @@ extension for floating-point constants of type @code{float}.
 @cindex @code{ULK} fixed-suffix
 @cindex @code{ULLK} fixed-suffix
 
-As an extension, the GNU C compiler supports fixed-point types as
+As an extension, GNU C supports fixed-point types as
 defined in the N1169 draft of ISO/IEC DTR 18037.  Support for fixed-point
 types in GCC will evolve as the draft technical report changes.
 Calling conventions for any target might also change.  Not all targets
@@ -1212,13 +1248,13 @@ is incomplete:
 Pragmas to control overflow and rounding behaviors are not implemented.
 @end itemize
 
-Fixed-point types are supported by the DWARF2 debug information format.
+Fixed-point types are supported by the DWARF 2 debug information format.
 
 @node Named Address Spaces
 @section Named Address Spaces
 @cindex Named Address Spaces
 
-As an extension, the GNU C compiler supports named address spaces as
+As an extension, GNU C supports named address spaces as
 defined in the N1275 draft of ISO/IEC DTR 18037.  Support for named
 address spaces in GCC will evolve as the draft technical report
 changes.  Calling conventions for any target might also change.  At
@@ -1246,15 +1282,15 @@ without using (inline) assembler code.
 @table @code
 @item __flash
 @cindex @code{__flash} AVR Named Address Spaces
-The @code{__flash} qualifier will locate data in the
-@code{.progmem.data} section. Data will be read using the @code{LPM}
+The @code{__flash} qualifier locates data in the
+@code{.progmem.data} section. Data is read using the @code{LPM}
 instruction. Pointers to this address space are 16 bits wide.
 
 @item __flash1
-@item __flash2
-@item __flash3
-@item __flash4
-@item __flash5
+@itemx __flash2
+@itemx __flash3
+@itemx __flash4
+@itemx __flash5
 @cindex @code{__flash1} AVR Named Address Spaces
 @cindex @code{__flash2} AVR Named Address Spaces
 @cindex @code{__flash3} AVR Named Address Spaces
@@ -1263,7 +1299,7 @@ instruction. Pointers to this address space are 16 bits wide.
 These are 16-bit address spaces locating data in section
 @code{.progmem@var{N}.data} where @var{N} refers to
 address space @code{__flash@var{N}}.
-The compiler will set the @code{RAMPZ} segment register approptiately 
+The compiler sets the @code{RAMPZ} segment register appropriately 
 before reading data by means of the @code{ELPM} instruction.
 
 @item __memx
@@ -1273,17 +1309,18 @@ If the high bit of the address is set, data is read from
 RAM using the lower two bytes as RAM address.
 If the high bit of the address is clear, data is read from flash
 with @code{RAMPZ} set according to the high byte of the address.
+@xref{AVR Built-in Functions,,@code{__builtin_avr_flash_segment}}.
 
-Objects in this address space will be located in @code{.progmemx.data}.
+Objects in this address space are located in @code{.progmemx.data}.
 @end table
 
 @b{Example}
 
-@example
+@smallexample
 char my_read (const __flash char ** p)
 @{
     /* p is a pointer to RAM that points to a pointer to flash.
-       The first indirection of p will read that flash pointer
+       The first indirection of p reads that flash pointer
        from RAM and the second indirection reads a char from this
        flash address.  */
 
@@ -1300,14 +1337,15 @@ int main (void)
    /* Return 17 by reading from flash memory */
    return array[array[i]];
 @}
-@end example
+@end smallexample
 
+@noindent
 For each named address space supported by avr-gcc there is an equally
 named but uppercase built-in macro defined. 
 The purpose is to facilitate testing if respective address space
 support is available or not:
 
-@example
+@smallexample
 #ifdef __FLASH
 const __flash int var = 1;
 
@@ -1325,29 +1363,31 @@ int read_var (void)
     return (int) pgm_read_word (&var);
 @}
 #endif /* __FLASH */
-@end example
+@end smallexample
 
-Notice that attribute @ref{AVR Variable Attributes,@code{progmem}}
+@noindent
+Notice that attribute @ref{AVR Variable Attributes,,@code{progmem}}
 locates data in flash but
-accesses to these data will read from generic address space, i.e.@:
+accesses to these data read from generic address space, i.e.@:
 from RAM,
 so that you need special accessors like @code{pgm_read_byte}
 from @w{@uref{http://nongnu.org/avr-libc/user-manual/,AVR-LibC}}
 together with attribute @code{progmem}.
 
+@noindent
 @b{Limitations and caveats}
 
 @itemize
 @item
 Reading across the 64@tie{}KiB section boundary of
 the @code{__flash} or @code{__flash@var{N}} address spaces
-will show undefined behaviour. The only address space that
+shows undefined behavior. The only address space that
 supports reading across the 64@tie{}KiB flash segment boundaries is
 @code{__memx}.
 
 @item
 If you use one of the @code{__flash@var{N}} address spaces
-you will have to arrange your linker skript to locate the
+you must arrange your linker script to locate the
 @code{.progmem@var{N}.data} sections according to your needs.
 
 @item
@@ -1361,27 +1401,26 @@ must not optimize away known values or insert them
 as immediates into operands of instructions.
 
 @item
-Code like the following is not yet supported because of missing
-support in avr-binutils,
-see @w{@uref{http://sourceware.org/PR13503,PR13503}}.
-@example
+The following code initializes a variable @code{pfoo}
+located in static storage with a 24-bit address:
+@smallexample
 extern const __memx char foo;
 const __memx void *pfoo = &foo;
-@end example
-The code will throw an assembler warning and the high byte of
-@code{pfoo} will be initialized with@tie{}@code{0}, i.e.@: the
-initialization will be as if @code{foo} was located in the first
-64@tie{}KiB chunk of flash.
+@end smallexample
+
+@noindent
+Such code requires at least binutils 2.23, see
+@w{@uref{http://sourceware.org/PR13503,PR13503}}.
 
 @end itemize
 
 @subsection M32C Named Address Spaces
 @cindex @code{__far} M32C Named Address Spaces
 
-On the M32C target, with the R8C and M16C cpu variants, variables
+On the M32C target, with the R8C and M16C CPU variants, variables
 qualified with @code{__far} are accessed using 32-bit addresses in
 order to access memory beyond the first 64@tie{}Ki bytes.  If
-@code{__far} is used with the M32CM or M32C cpu variants, it has no
+@code{__far} is used with the M32CM or M32C CPU variants, it has no
 effect.
 
 @subsection RL78 Named Address Spaces
@@ -1403,8 +1442,9 @@ belonging to another address space by qualifying the type with the
 extern int __ea i;
 @end smallexample
 
-When the variable @code{i} is accessed, the compiler will generate
-special code to access this variable.  It may use runtime library
+@noindent 
+The compiler generates special code to access the variable @code{i}.
+It may use runtime library
 support, or generate special machine instructions to access that address
 space.
 
@@ -1416,7 +1456,7 @@ space.
 @cindex flexible array members
 
 Zero-length arrays are allowed in GNU C@.  They are very useful as the
-last element of a structure which is really a header for a variable-length
+last element of a structure that is really a header for a variable-length
 object:
 
 @smallexample
@@ -1462,14 +1502,14 @@ initialized, as if they were flexible arrays.  In addition to those
 cases that were useful, it also allowed initializations in situations
 that would corrupt later data.  Non-empty initialization of zero-length
 arrays is now treated like any case where there are more initializer
-elements than the array holds, in that a suitable warning about "excess
-elements in array" is given, and the excess elements (all of them, in
+elements than the array holds, in that a suitable warning about ``excess
+elements in array'' is given, and the excess elements (all of them, in
 this case) are ignored.
 
 Instead GCC allows static initialization of flexible array members.
 This is equivalent to defining a new structure containing the original
 structure followed by an array of sufficient size to contain the data.
-I.e.@: in the following, @code{f1} is constructed as if it were declared
+E.g.@: in the following, @code{f1} is constructed as if it were declared
 like @code{f2}.
 
 @smallexample
@@ -1518,7 +1558,7 @@ struct empty @{
 @};
 @end smallexample
 
-The structure will have size zero.  In C++, empty structures are part
+The structure has size zero.  In C++, empty structures are part
 of the language.  G++ treats empty structures as if they had a single
 member of type @code{char}.
 
@@ -1532,7 +1572,8 @@ Variable-length automatic arrays are allowed in ISO C99, and as an
 extension GCC accepts them in C90 mode and in C++.  These arrays are
 declared like any other automatic arrays, but with a length that is not
 a constant expression.  The storage is allocated at the point of
-declaration and deallocated when the brace-level is exited.  For
+declaration and deallocated when the block scope containing the declaration
+exits.  For
 example:
 
 @smallexample
@@ -1553,6 +1594,18 @@ Jumping or breaking out of the scope of the array name deallocates the
 storage.  Jumping into the scope is not allowed; you get an error
 message for it.
 
+@cindex variable-length array in a structure
+As an extension, GCC accepts variable-length arrays as a member of
+a structure or a union.  For example:
+
+@smallexample
+void
+foo (int n)
+@{
+  struct S @{ int x[n]; @};
+@}
+@end smallexample
+
 @cindex @code{alloca} vs variable-length arrays
 You can use the function @code{alloca} to get an effect much like
 variable-length arrays.  The function @code{alloca} is available in
@@ -1564,7 +1617,7 @@ with @code{alloca} exists until the containing @emph{function} returns.
 The space for a variable-length array is deallocated as soon as the array
 name's scope ends.  (If you use both variable-length arrays and
 @code{alloca} in the same function, deallocation of a variable-length array
-will also deallocate anything more recently allocated with @code{alloca}.)
+also deallocates anything more recently allocated with @code{alloca}.)
 
 You can also use variable-length arrays as arguments to functions:
 
@@ -1619,6 +1672,7 @@ example:
 #define debug(format, ...) fprintf (stderr, format, __VA_ARGS__)
 @end smallexample
 
+@noindent
 Here @samp{@dots{}} is a @dfn{variable argument}.  In the invocation of
 such a macro, it represents the zero or more tokens until the closing
 parenthesis that ends the invocation, including any commas.  This set of
@@ -1633,6 +1687,7 @@ argument.  Here is an example:
 #define debug(format, args...) fprintf (stderr, format, args)
 @end smallexample
 
+@noindent
 This is in all ways equivalent to the ISO C example above, but arguably
 more readable and descriptive.
 
@@ -1660,6 +1715,7 @@ used with the token paste operator, @samp{##}.  If instead you write
 #define debug(format, ...) fprintf (stderr, format, ## __VA_ARGS__)
 @end smallexample
 
+@noindent
 and if the variable arguments are omitted or empty, the @samp{##}
 operator causes the preprocessor to remove the comma before it.  If you
 do provide some variable arguments in your macro invocation, GNU CPP
@@ -1692,7 +1748,7 @@ yet been replaced with spaces.
 In ISO C99, arrays that are not lvalues still decay to pointers, and
 may be subscripted, although they may not be modified or used after
 the next sequence point and the unary @samp{&} operator may not be
-applied to them.  As an extension, GCC allows such arrays to be
+applied to them.  As an extension, GNU C allows such arrays to be
 subscripted in C90 mode, though otherwise they do not decay to
 pointers outside C99 mode.  For example,
 this is valid in GNU C though not valid in C90:
@@ -1803,7 +1859,7 @@ to a cast.
 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
+It is handled as if the object is initialized only with the bracket
 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
@@ -1876,7 +1932,7 @@ int a[6] = @{ 0, 0, 15, 0, 29, 0 @};
 The index values must be constant expressions, even if the array being
 initialized is automatic.
 
-An alternative syntax for this which has been obsolete since GCC 2.5 but
+An alternative syntax for this that has been obsolete since GCC 2.5 but
 GCC still accepts is to write @samp{[@var{index}]} before the element
 value, with no @samp{=}.
 
@@ -1889,7 +1945,7 @@ int widths[] = @{ [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 @};
 @end smallexample
 
 @noindent
-If the value in it has side-effects, the side-effects will happen only once,
+If the value in it has side-effects, the side-effects happen only once,
 not for each initialized field by the range initializer.
 
 @noindent
@@ -1918,13 +1974,16 @@ is equivalent to
 struct point p = @{ xvalue, yvalue @};
 @end smallexample
 
-Another syntax which has the same meaning, obsolete since GCC 2.5, is
+Another syntax that has the same meaning, obsolete since GCC 2.5, is
 @samp{@var{fieldname}:}, as shown here:
 
 @smallexample
 struct point p = @{ y: yvalue, x: xvalue @};
 @end smallexample
 
+Omitted field members are implicitly initialized the same as objects
+that have static storage duration.
+
 @cindex designators
 The @samp{[@var{index}]} or @samp{.@var{fieldname}} is known as a
 @dfn{designator}.  You can also use a designator (or the obsolete colon
@@ -1938,9 +1997,9 @@ union foo f = @{ .d = 4 @};
 @end smallexample
 
 @noindent
-will convert 4 to a @code{double} to store it in the union using
+converts 4 to a @code{double} to store it in the union using
 the second element.  By contrast, casting 4 to type @code{union foo}
-would store it into the union as the integer @code{i}, since it is
+stores it into the union as the integer @code{i}, since it is
 an integer.  (@xref{Cast to Union}.)
 
 You can combine this technique of naming elements with ordinary C
@@ -1981,10 +2040,10 @@ struct point ptarray[10] = @{ [2].y = yv2, [2].x = xv2, [0].x = xv0 @};
 @end smallexample
 
 @noindent
-If the same field is initialized multiple times, it will have value from
+If the same field is initialized multiple times, it has the value from
 the last initialization.  If any such overridden initialization has
 side-effect, it is unspecified whether the side-effect happens or not.
-Currently, GCC will discard them and issue a warning.
+Currently, GCC discards them and issues a warning.
 
 @node Case Ranges
 @section Case Ranges
@@ -2031,7 +2090,7 @@ case 1...5:
 A cast to union type is similar to other casts, except that the type
 specified is a union type.  You can specify the type either with
 @code{union @var{tag}} or with a typedef name.  A cast to union is actually
-a constructor though, not a cast, and hence does not yield an lvalue like
+a constructor, not a cast, and hence does not yield an lvalue like
 normal casts.  (@xref{Compound Literals}.)
 
 The types that may be cast to the union type are those of the members
@@ -2071,7 +2130,7 @@ hack ((union foo) x);
 @cindex code, mixed with declarations
 
 ISO C99 and ISO C++ allow declarations and code to be freely mixed
-within compound statements.  As an extension, GCC also allows this in
+within compound statements.  As an extension, GNU C also allows this in
 C90 mode.  For example, you could do:
 
 @smallexample
@@ -2112,20 +2171,24 @@ The keyword @code{__attribute__} allows you to specify special
 attributes when making a declaration.  This keyword is followed by an
 attribute specification inside double parentheses.  The following
 attributes are currently defined for functions on all targets:
-@code{aligned}, @code{alloc_size}, @code{noreturn},
-@code{returns_twice}, @code{noinline}, @code{noclone},
+@code{aligned}, @code{alloc_size}, @code{alloc_align}, @code{assume_aligned},
+@code{noreturn}, @code{returns_twice}, @code{noinline}, @code{noclone},
 @code{always_inline}, @code{flatten}, @code{pure}, @code{const},
 @code{nothrow}, @code{sentinel}, @code{format}, @code{format_arg},
 @code{no_instrument_function}, @code{no_split_stack},
 @code{section}, @code{constructor},
 @code{destructor}, @code{used}, @code{unused}, @code{deprecated},
 @code{weak}, @code{malloc}, @code{alias}, @code{ifunc},
-@code{warn_unused_result}, @code{nonnull}, @code{gnu_inline},
+@code{warn_unused_result}, @code{nonnull},
+@code{returns_nonnull}, @code{gnu_inline},
 @code{externally_visible}, @code{hot}, @code{cold}, @code{artificial},
-@code{error} and @code{warning}.  Several other attributes are defined
-for functions on particular target systems.  Other attributes,
-including @code{section} are supported for variables declarations
-(@pxref{Variable Attributes}) and for types (@pxref{Type Attributes}).
+@code{no_sanitize_address}, @code{no_address_safety_analysis},
+@code{no_sanitize_undefined},
+@code{error} and @code{warning}.
+Several other attributes are defined for functions on particular
+target systems.  Other attributes, including @code{section} are
+supported for variables declarations (@pxref{Variable Attributes})
+and for types (@pxref{Type Attributes}).
 
 GCC plugins may provide their own attributes.
 
@@ -2150,6 +2213,7 @@ void __f () @{ /* @r{Do something.} */; @}
 void f () __attribute__ ((weak, alias ("__f")));
 @end smallexample
 
+@noindent
 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.
@@ -2163,7 +2227,7 @@ measured in bytes.
 
 You cannot use this attribute to decrease the alignment of a function,
 only to increase it.  However, when you explicitly specify a function
-alignment this will override the effect of the
+alignment this overrides the effect of the
 @option{-falign-functions} (@pxref{Optimize Options}) option for this
 function.
 
@@ -2194,22 +2258,63 @@ For instance,
 
 @smallexample
 void* my_calloc(size_t, size_t) __attribute__((alloc_size(1,2)))
-void my_realloc(void*, size_t) __attribute__((alloc_size(2)))
+void* my_realloc(void*, size_t) __attribute__((alloc_size(2)))
 @end smallexample
 
-declares that my_calloc will return memory of the size given by
-the product of parameter 1 and 2 and that my_realloc will return memory
+@noindent
+declares that @code{my_calloc} returns memory of the size given by
+the product of parameter 1 and 2 and that @code{my_realloc} returns memory
 of the size given by parameter 2.
 
+@item alloc_align
+@cindex @code{alloc_align} attribute
+The @code{alloc_align} attribute is used to tell the compiler that the
+function return value points to memory, where the returned pointer minimum
+alignment is given by one of the functions parameters.  GCC uses this
+information to improve pointer alignment analysis.
+
+The function parameter denoting the allocated alignment is specified by
+one integer argument, whose number is the argument of the attribute.
+Argument numbering starts at one.
+
+For instance,
+
+@smallexample
+void* my_memalign(size_t, size_t) __attribute__((alloc_align(1)))
+@end smallexample
+
+@noindent
+declares that @code{my_memalign} returns memory with minimum alignment
+given by parameter 1.
+
+@item assume_aligned
+@cindex @code{assume_aligned} attribute
+The @code{assume_aligned} attribute is used to tell the compiler that the
+function return value points to memory, where the returned pointer minimum
+alignment is given by the first argument.
+If the attribute has two arguments, the second argument is misalignment offset.
+
+For instance
+
+@smallexample
+void* my_alloc1(size_t) __attribute__((assume_aligned(16)))
+void* my_alloc2(size_t) __attribute__((assume_aligned(32, 8)))
+@end smallexample
+
+@noindent
+declares that @code{my_alloc1} returns 16-byte aligned pointer and
+that @code{my_alloc2} returns a pointer whose value modulo 32 is equal
+to 8.
+
 @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.
+if no optimization level is specified.
 
 @item gnu_inline
 @cindex @code{gnu_inline} function attribute
-This attribute should be used with a function which is also declared
+This attribute should be used with a function that is also declared
 with the @code{inline} keyword.  It directs GCC to treat the function
 as if it were defined in gnu90 mode even when compiling in C99 or
 gnu99 mode.
@@ -2222,8 +2327,8 @@ 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
+file.  The definition in the header file causes most calls to the
+function to be inlined.  If any uses of the function remain, they
 refer to the single copy in the library.  Note that the two
 definitions of the functions need not be precisely the same, although
 if they do not have the same effect your program may behave oddly.
@@ -2247,9 +2352,9 @@ behavior.
 
 @item artificial
 @cindex @code{artificial} function attribute
-This attribute is useful for small inline wrappers which if possible
-should appear during debugging as a unit, depending on the debug
-info format it will either mean marking the function as artificial
+This attribute is useful for small inline wrappers that if possible
+should appear during debugging as a unit.  Depending on the debug
+info format it either means marking the function as artificial
 or using the caller location for all instructions within the inlined
 body.
 
@@ -2262,7 +2367,7 @@ rather than saving them on the stack.
 @item flatten
 @cindex @code{flatten} function attribute
 Generally, inlining into a function is limited.  For a function marked with
-this attribute, every call inside this function will be inlined, if possible.
+this attribute, every call inside this function is inlined, if possible.
 Whether the function itself is considered for inlining depends on its size and
 the current inlining parameters.
 
@@ -2270,12 +2375,12 @@ the current inlining parameters.
 @cindex @code{error} function attribute
 If this attribute is used on a function declaration and a call to such a function
 is not eliminated through dead code elimination or other optimizations, an error
-which will include @var{message} will be diagnosed.  This is useful
-for compile time checking, especially together with @code{__builtin_constant_p}
+that includes @var{message} is diagnosed.  This is useful
+for compile-time checking, especially together with @code{__builtin_constant_p}
 and inline functions where checking the inline function arguments is not
 possible through @code{extern char [(condition) ? 1 : -1];} tricks.
 While it is possible to leave the function undefined and thus invoke
-a link failure, when using this attribute the problem will be diagnosed
+a link failure, when using this attribute the problem is diagnosed
 earlier and with exact location of the call even in presence of inline
 functions or when not emitting debugging information.
 
@@ -2283,18 +2388,18 @@ functions or when not emitting debugging information.
 @cindex @code{warning} function attribute
 If this attribute is used on a function declaration and a call to such a function
 is not eliminated through dead code elimination or other optimizations, a warning
-which will include @var{message} will be diagnosed.  This is useful
-for compile time checking, especially together with @code{__builtin_constant_p}
+that includes @var{message} is diagnosed.  This is useful
+for compile-time checking, especially together with @code{__builtin_constant_p}
 and inline functions.  While it is possible to define the function with
 a message in @code{.gnu.warning*} section, when using this attribute the problem
-will be diagnosed earlier and with exact location of the call even in presence
+is diagnosed earlier and with exact location of the call even in presence
 of inline functions or when not emitting debugging information.
 
 @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
+assume that the calling function pops off the stack space used to
 pass arguments.  This is
 useful to override the effects of the @option{-mrtd} switch.
 
@@ -2323,6 +2428,7 @@ typedef int intfn ();
 extern const intfn square;
 @end smallexample
 
+@noindent
 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.
 
@@ -2335,9 +2441,9 @@ specifies that the @samp{const} must be attached to the return value.
 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
+automatically after @code{main ()} completes or @code{exit ()} is
+called.  Functions with these attributes are useful for
+initializing data that is used implicitly during the execution of
 the program.
 
 You may provide an optional integer priority to control the order in
@@ -2369,8 +2475,9 @@ int old_fn ();
 int (*fn_ptr)() = old_fn;
 @end smallexample
 
-results in a warning on line 3 but not line 2.  The optional msg
-argument, which must be a string, will be printed in the warning if
+@noindent
+results in a warning on line 3 but not line 2.  The optional @var{msg}
+argument, which must be a string, is printed in the warning if
 present.
 
 The @code{deprecated} attribute can also be used for variables and
@@ -2401,9 +2508,9 @@ explicitly specify any other visibility.
 
 In previous versions of GCC, the @code{dllexport} attribute was ignored
 for inlined functions, unless the @option{-fkeep-inline-functions} flag
-had been used.  The default behaviour now is to emit all dllexported
+had been used.  The default behavior now is to emit all dllexported
 inline functions; however, this can cause object file-size bloat, in
-which case the old behaviour can be restored by using
+which case the old behavior can be restored by using
 @option{-fno-keep-inline-dllexport}.
 
 The attribute is also ignored for undefined symbols.
@@ -2450,12 +2557,12 @@ 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
+dllimported constructor or a non-inline, non-pure virtual function
 and, for either of those two conditions, the class also has an inline
 constructor or destructor and has a key function that is defined in
 the current translation unit.
 
-For Microsoft Windows based targets the use of the @code{dllimport}
+For Microsoft Windows targets the use of the @code{dllimport}
 attribute on functions is not necessary, but provides a small
 performance benefit by eliminating a thunk in the DLL@.  The use of the
 @code{dllimport} attribute on imported variables was required on older
@@ -2473,20 +2580,26 @@ referenced.  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
+@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
+variable should be placed into the eight-bit data section.
+The compiler generates more efficient code for certain operations
+on data in the eight-bit data area.  Note the eight-bit data area is limited to
 256 bytes of data.
 
 You must use GAS and GLD from GNU binutils version 2.7 or later for
 this attribute to work correctly.
 
+@item exception
+@cindex exception handler functions
+Use this attribute on the NDS32 target to indicate that the specified function
+is an exception handler.  The compiler will generate corresponding sections
+for use in an exception handler.
+
 @item exception_handler
 @cindex 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
+is an exception handler.  The compiler generates function entry and
 exit sequences suitable for use in an exception handler when this
 attribute is present.
 
@@ -2494,27 +2607,36 @@ attribute is present.
 @cindex @code{externally_visible} attribute.
 This attribute, attached to a global variable or function, nullifies
 the effect of the @option{-fwhole-program} command-line option, so the
-object remains visible outside the current compilation unit. If @option{-fwhole-program} is used together with @option{-flto} and @command{gold} is used as the linker plugin, @code{externally_visible} attributes are automatically added to functions (not variable yet due to a current @command{gold} issue) that are accessed outside of LTO objects according to resolution file produced by @command{gold}.  For other linkers that cannot generate resolution file, explicit @code{externally_visible} attributes are still necessary.
+object remains visible outside the current compilation unit.
+
+If @option{-fwhole-program} is used together with @option{-flto} and 
+@command{gold} is used as the linker plugin, 
+@code{externally_visible} attributes are automatically added to functions 
+(not variable yet due to a current @command{gold} issue) 
+that are accessed outside of LTO objects according to resolution file
+produced by @command{gold}.
+For other linkers that cannot generate resolution file,
+explicit @code{externally_visible} attributes are still necessary.
 
 @item far
-@cindex functions which handle memory bank switching
+@cindex functions that 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
+On 68HC12 the compiler uses the @code{call} and @code{rtc} instructions
 to call and return from a function.
 
-On 68HC11 the compiler will generate a sequence of instructions
+On 68HC11 the compiler generates 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
+At the end of a function, it jumps to a board-specific routine
 instead of using @code{rts}.  The board-specific return routine simulates
 the @code{rtc}.
 
 On MeP targets this causes the compiler to use a calling convention
-which assumes the called function is too far away for the built-in
+that assumes the called function is too far away for the built-in
 addressing modes.
 
 @item fast_interrupt
@@ -2529,8 +2651,8 @@ instead of @code{reit}.
 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
+and other typed arguments are passed on the stack.  The called function
+pops the arguments off the stack.  If the number of arguments is variable all
 arguments are pushed on the stack.
 
 @item thiscall
@@ -2538,18 +2660,18 @@ arguments are pushed on the stack.
 On the Intel 386, the @code{thiscall} attribute causes the compiler to
 pass the first argument (if of integral type) in the register ECX.
 Subsequent and other typed arguments are passed on the stack. The called
-function will pop the arguments off the stack.
+function pops the arguments off the stack.
 If the number of arguments is variable all arguments are pushed on the
 stack.
 The @code{thiscall} attribute is intended for C++ non-static member functions.
-As gcc extension this calling convention can be used for C-functions
+As a GCC extension, this calling convention can be used for C functions
 and for static member methods.
 
 @item format (@var{archetype}, @var{string-index}, @var{first-to-check})
 @cindex @code{format} function attribute
 @opindex Wformat
 The @code{format} attribute specifies that a function takes @code{printf},
-@code{scanf}, @code{strftime} or @code{strfmon} style arguments which
+@code{scanf}, @code{strftime} or @code{strfmon} style arguments that
 should be type-checked against a format string.  For example, the
 declaration:
 
@@ -2571,10 +2693,11 @@ interpreted, and should be @code{printf}, @code{scanf}, @code{strftime},
 @code{__scanf__}, @code{__strftime__} or @code{__strfmon__}.)  On
 MinGW targets, @code{ms_printf}, @code{ms_scanf}, and
 @code{ms_strftime} are also present.
-@var{archtype} values such as @code{printf} refer to the formats accepted
-by the system's C run-time library, while @code{gnu_} values always refer
+@var{archetype} values such as @code{printf} refer to the formats accepted
+by the system's C runtime library,
+while values prefixed with @samp{gnu_} always refer
 to the formats accepted by the GNU C Library.  On Microsoft Windows
-targets, @code{ms_} values refer to the formats accepted by the
+targets, values prefixed with @samp{ms_} refer to the formats accepted by the
 @file{msvcrt.dll} library.
 The parameter @var{string-index}
 specifies which argument is the format string argument (starting
@@ -2596,7 +2719,7 @@ 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
+that take format strings as arguments, so that GCC can check the
 calls to these functions for errors.  The compiler always (unless
 @option{-ffreestanding} or @option{-fno-builtin} is used) checks formats
 for the standard library functions @code{printf}, @code{fprintf},
@@ -2612,8 +2735,8 @@ are @code{printf_unlocked} and @code{fprintf_unlocked}.
 
 For Objective-C dialects, @code{NSString} (or @code{__NSString__}) is
 recognized in the same context.  Declarations including these format attributes
-will be parsed for correct syntax, however the result of checking of such format
-strings is not yet defined, and will not be carried out by this version of the
+are parsed for correct syntax, however the result of checking of such format
+strings is not yet defined, and is not carried out by this version of the
 compiler.
 
 The target may also provide additional types of format checks.
@@ -2654,8 +2777,8 @@ string argument (starting from one).  Since non-static C++ methods have
 an implicit @code{this} argument, the arguments of such methods should
 be counted from two.
 
-The @code{format-arg} attribute allows you to identify your own
-functions which modify format strings, so that GCC can check the
+The @code{format_arg} attribute allows you to identify your own
+functions that modify format strings, so that GCC can check the
 calls to @code{printf}, @code{scanf}, @code{strftime} or @code{strfmon}
 type function whose operands are a call to one of your own function.
 The compiler always treats @code{gettext}, @code{dgettext}, and
@@ -2677,28 +2800,27 @@ Target Machines}.
 @cindex calling functions through the function vector on H8/300, M16C, M32C and SH2A processors
 Use this attribute on the H8/300, H8/300H, and H8S to indicate that the specified
 function should be called through the function vector.  Calling a
-function through the function vector will reduce code size, however;
+function through the function vector reduces code size, however;
 the function vector has a limited size (maximum 128 entries on the H8/300
 and 64 entries on the H8/300H and H8S) and shares space with the interrupt vector.
 
-In SH2A target, this attribute declares a function to be called using the
+On SH2A targets, this attribute declares a function to be called using the
 TBR relative addressing mode.  The argument to this attribute is the entry
 number of the same function in a vector table containing all the TBR
-relative addressable functions.  For the successful jump, register TBR
-should contain the start address of this TBR relative vector table.
-In the startup routine of the user application, user needs to care of this
-TBR register initialization.  The TBR relative vector table can have at
-max 256 function entries.  The jumps to these functions will be generated
-using a SH2A specific, non delayed branch instruction JSR/N @@(disp8,TBR).
-You must use GAS and GLD from GNU binutils version 2.7 or later for
-this attribute to work correctly.
+relative addressable functions.  For correct operation the TBR must be setup
+accordingly to point to the start of the vector table before any functions with
+this attribute are invoked.  Usually a good place to do the initialization is
+the startup routine.  The TBR relative vector table can have at max 256 function
+entries.  The jumps to these functions are generated using a SH2A specific,
+non delayed branch instruction JSR/N @@(disp8,TBR).  You must use GAS and GLD
+from GNU binutils version 2.7 or later for this attribute to work correctly.
 
 Please refer the example of M16C target, to see the use of this
 attribute while declaring a function,
 
-In an application, for a function being called once, this attribute will
-save at least 8 bytes of code; and if other successive calls are being
-made to the same function, it will save 2 bytes of code per each of these
+In an application, for a function being called once, this attribute
+saves at least 8 bytes of code; and if other successive calls are being
+made to the same function, it saves 2 bytes of code per each of these
 calls.
 
 On M16C/M32C targets, the @code{function_vector} attribute declares a
@@ -2707,15 +2829,15 @@ the code size by 2 bytes for each call generated to the
 subroutine. The argument to the attribute is the vector number entry
 from the special page vector table which contains the 16 low-order
 bits of the subroutine's entry address. Each vector table has special
-page number (18 to 255) which are used in @code{jsrs} instruction.
+page number (18 to 255) that is used in @code{jsrs} instructions.
 Jump addresses of the routines are generated by adding 0x0F0000 (in
-case of M16C targets) or 0xFF0000 (in case of M32C targets), to the 2
-byte addresses set in the vector table. Therefore you need to ensure
+case of M16C targets) or 0xFF0000 (in case of M32C targets), to the
+2-byte addresses set in the vector table. Therefore you need to ensure
 that all the special page vector routines should get mapped within the
 address range 0x0F0000 to 0x0FFFFF (for M16C) and 0xFF0000 to 0xFFFFFF
 (for M32C).
 
-In the following example 2 bytes will be saved for each call to
+In the following example 2 bytes are saved for each call to
 function @code{foo}.
 
 @smallexample
@@ -2761,6 +2883,7 @@ static void (*resolve_memcpy (void)) (void)
 @}
 @end smallexample
 
+@noindent
 The exported header file declaring the function the user calls would
 contain:
 
@@ -2768,6 +2891,7 @@ contain:
 extern void *memcpy (void *, const void *, size_t);
 @end smallexample
 
+@noindent
 allowing the user to call this as a regular function, unaware of the
 implementation.  Finally, the indirect function needs to be defined in
 the same translation unit as the resolver function:
@@ -2782,9 +2906,10 @@ least version 2.20.1), and GNU C library (at least version 2.11.1).
 
 @item interrupt
 @cindex interrupt handler functions
-Use this attribute on the ARM, AVR, CR16, Epiphany, M32C, M32R/D, m68k, MeP, MIPS,
-RL78, RX and Xstormy16 ports to indicate that the specified function is an
-interrupt handler.  The compiler will generate function entry and exit
+Use this attribute on the ARC, ARM, AVR, CR16, Epiphany, M32C, M32R/D,
+m68k, MeP, MIPS, MSP430, RL78, RX and Xstormy16 ports to indicate that
+the specified function is an
+interrupt handler.  The compiler generates function entry and exit
 sequences suitable for use in an interrupt handler when this attribute
 is present.  With Epiphany targets it may also generate a special section with
 code to initialize the interrupt vector table.
@@ -2792,13 +2917,23 @@ code to initialize the interrupt vector table.
 Note, interrupt handlers for the Blackfin, H8/300, H8/300H, H8S, MicroBlaze,
 and SH processors can be specified via the @code{interrupt_handler} attribute.
 
+Note, on the ARC, you must specify the kind of interrupt to be handled
+in a parameter to the interrupt attribute like this:
+
+@smallexample
+void f () __attribute__ ((interrupt ("ilink1")));
+@end smallexample
+
+Permissible values for this parameter are: @w{@code{ilink1}} and
+@w{@code{ilink2}}.
+
 Note, on the AVR, the hardware globally disables interrupts when an
 interrupt is executed.  The first instruction of an interrupt handler
-declared with this attribute will be a @code{SEI} instruction to
+declared with this attribute is a @code{SEI} instruction to
 re-enable interrupts.  See also the @code{signal} function attribute
-that does not insert a @code{SEI} instuction.  If both @code{signal} and
+that does not insert a @code{SEI} instruction.  If both @code{signal} and
 @code{interrupt} are specified for the same function, @code{signal}
-will be silently ignored.
+is silently ignored.
 
 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:
@@ -2807,10 +2942,48 @@ adding an optional parameter to the interrupt attribute like this:
 void f () __attribute__ ((interrupt ("IRQ")));
 @end smallexample
 
-Permissible values for this parameter are: IRQ, FIQ, SWI, ABORT and UNDEF@.
+@noindent
+Permissible values for this parameter are: @code{IRQ}, @code{FIQ},
+@code{SWI}, @code{ABORT} and @code{UNDEF}.
 
 On ARMv7-M the interrupt type is ignored, and the attribute means the function
-may be called with a word aligned stack pointer.
+may be called with a word-aligned stack pointer.
+
+Note, for the MSP430 you can provide an argument to the interrupt
+attribute which specifies a name or number.  If the argument is a
+number it indicates the slot in the interrupt vector table (0 - 31) to
+which this handler should be assigned.  If the argument is a name it
+is treated as a symbolic name for the vector slot.  These names should
+match up with appropriate entries in the linker script.  By default
+the names @code{watchdog} for vector 26, @code{nmi} for vector 30 and
+@code{reset} for vector 31 are recognised.
+
+You can also use the following function attributes to modify how
+normal functions interact with interrupt functions:
+
+@table @code
+@item critical
+@cindex @code{critical} attribute
+Critical functions disable interrupts upon entry and restore the
+previous interrupt state upon exit.  Critical functions cannot also
+have the @code{naked} or @code{reentrant} attributes.  They can have
+the @code{interrupt} attribute.
+
+@item reentrant
+@cindex @code{reentrant} attribute
+Reentrant functions disable interrupts upon entry and enable them
+upon exit.  Reentrant functions cannot also have the @code{naked}
+or @code{critical} attributes.  They can have the @code{interrupt}
+attribute.
+
+@item wakeup
+@cindex @code{wakeup} attribute
+This attribute only applies to interrupt functions.  It is silently
+ignored if applied to a non-interrupt function.  A wakeup interrupt
+function will rouse the processor from any low-power state that it
+might be in when the function exits.
+
+@end table
 
 On Epiphany targets one or more optional parameters can be added like this:
 
@@ -2823,10 +2996,10 @@ Permissible values for these parameters are: @w{@code{reset}},
 @w{@code{timer0}}, @w{@code{timer1}}, @w{@code{message}},
 @w{@code{dma0}}, @w{@code{dma1}}, @w{@code{wand}} and @w{@code{swi}}.
 Multiple parameters indicate that multiple entries in the interrupt
-vector table should be initialized for this function, i.e. for each
-parameter @w{@var{name}}, a jump to the function will be emitted in
+vector table should be initialized for this function, i.e.@: for each
+parameter @w{@var{name}}, a jump to the function is emitted in
 the section @w{ivt_entry_@var{name}}.  The parameter(s) may be omitted
-entirely, in which case no interrupt vector table entry will be provided.
+entirely, in which case no interrupt vector table entry is provided.
 
 Note, on Epiphany targets, interrupts are enabled inside the function
 unless the @code{disinterrupt} attribute is also specified.
@@ -2839,7 +3012,7 @@ modify the behavior of an interrupt handler:
 The interrupt handler may be in external memory which cannot be
 reached by a branch instruction, so generate a local memory trampoline
 to transfer control.  The single parameter identifies the section where
-the trampoline will be placed.
+the trampoline is placed.
 @end table
 
 The following examples are all valid uses of these attributes on
@@ -2890,15 +3063,41 @@ void __attribute__ ((interrupt, use_shadow_register_set,
                      use_debug_exception_return)) v7 ();
 @end smallexample
 
+On NDS32 target, this attribute is to indicate that the specified function
+is an interrupt handler.  The compiler will generate corresponding sections
+for use in an interrupt handler.  You can use the following attributes
+to modify the behavior:
+@table @code
+@item nested
+@cindex @code{nested} attribute
+This interrupt service routine is interruptible.
+@item not_nested
+@cindex @code{not_nested} attribute
+This interrupt service routine is not interruptible.
+@item nested_ready
+@cindex @code{nested_ready} attribute
+This interrupt service routine is interruptible after @code{PSW.GIE}
+(global interrupt enable) is set.  This allows interrupt service routine to
+finish some short critical code before enabling interrupts.
+@item save_all
+@cindex @code{save_all} attribute
+The system will help save all registers into stack before entering
+interrupt handler.
+@item partial_save
+@cindex @code{partial_save} attribute
+The system will help save caller registers into stack before entering
+interrupt handler.
+@end table
+
 On RL78, use @code{brk_interrupt} instead of @code{interrupt} for
-handlers intended to be used with the @code{BRK} opcode (i.e.  those
+handlers intended to be used with the @code{BRK} opcode (i.e.@: those
 that must end with @code{RETB} instead of @code{RETI}).
 
 @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
+generates function entry and exit sequences suitable for use in an
 interrupt handler when this attribute is present.
 
 @item interrupt_thread
@@ -2917,21 +3116,21 @@ alias to the @code{interrupt} attribute above.
 @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
+or @code{nmi_handler}, code is generated to load the stack pointer
 from the USP register in the function prologue.
 
 @item l1_text
 @cindex @code{l1_text} function attribute
 This attribute specifies a function to be placed into L1 Instruction
-SRAM@. The function will be put into a specific section named @code{.l1.text}.
+SRAM@. The function is put into a specific section named @code{.l1.text}.
 With @option{-mfdpic}, function calls with a such function as the callee
-or caller will use inlined PLT.
+or caller uses inlined PLT.
 
 @item l2
 @cindex @code{l2} function attribute
 On the Blackfin, this attribute specifies a function to be placed into L2
-SRAM. The function will be put into a specific section named
-@code{.l1.text}. With @option{-mfdpic}, callers of such functions will use
+SRAM. The function is put into a specific section named
+@code{.l1.text}. With @option{-mfdpic}, callers of such functions use
 an inlined PLT.
 
 @item leaf
@@ -2956,21 +3155,36 @@ compliant way to write such a signal handler is to declare such variables
 
 The attribute has no effect on functions defined within the current compilation
 unit.  This is to allow easy merging of multiple compilation units into one,
-for example, by using the link time optimization.  For this reason the
+for example, by using the link-time optimization.  For this reason the
 attribute is not allowed on types to annotate indirect calls.
 
-@item long_call/short_call
+@item long_call/medium_call/short_call
+@cindex indirect calls on ARC
 @cindex indirect calls on ARM
-This attribute specifies how a particular function is called on
-ARM and Epiphany.  Both attributes override the
-@option{-mlong-calls} (@pxref{ARM Options})
-command-line switch and @code{#pragma long_calls} settings.  The
+@cindex indirect calls on Epiphany
+These attributes specify how a particular function is called on
+ARC, ARM and Epiphany - with @code{medium_call} being specific to ARC.
+These attributes override the
+@option{-mlong-calls} (@pxref{ARM Options} and @ref{ARC Options})
+and @option{-mmedium-calls} (@pxref{ARC Options})
+command-line switches and @code{#pragma long_calls} settings.  For ARM, the
 @code{long_call} attribute indicates that the function might be far
 away from the call site and require a different (more expensive)
 calling sequence.   The @code{short_call} attribute always places
 the offset to the function from the call site into the @samp{BL}
 instruction directly.
 
+For ARC, a function marked with the @code{long_call} attribute is
+always called using register-indirect jump-and-link instructions,
+thereby enabling the called function to be placed anywhere within the
+32-bit address space.  A function marked with the @code{medium_call}
+attribute will always be close enough to be called with an unconditional
+branch-and-link instruction, which has a 25-bit offset from
+the call site.  A function marked with the @code{short_call}
+attribute will always be close enough to be called with a conditional
+branch-and-link instruction, which has a 21-bit offset from
+the call site.
+
 @item longcall/shortcall
 @cindex functions called via pointer on the RS/6000 and PowerPC
 On the Blackfin, RS/6000 and PowerPC, the @code{longcall} attribute
@@ -3001,7 +3215,7 @@ 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 and that the memory
 has undefined content.
-This will often improve optimization.
+This often improves optimization.
 Standard functions with this property include @code{malloc} and
 @code{calloc}.  @code{realloc}-like functions do not have this
 property as the memory pointed to does not have undefined content.
@@ -3024,6 +3238,25 @@ not that within individual functions.  Mixed MIPS16 and non-MIPS16 code
 may interact badly with some GCC extensions such as @code{__builtin_apply}
 (@pxref{Constructing Calls}).
 
+@item micromips/nomicromips
+@cindex @code{micromips} attribute
+@cindex @code{nomicromips} attribute
+
+On MIPS targets, you can use the @code{micromips} and @code{nomicromips}
+function attributes to locally select or turn off microMIPS code generation.
+A function with the @code{micromips} attribute is emitted as microMIPS code,
+while microMIPS code generation is disabled for functions with the
+@code{nomicromips} attribute.  These attributes override the
+@option{-mmicromips} and @option{-mno-micromips} options on the command line
+(@pxref{MIPS Options}).
+
+When compiling files containing mixed microMIPS and non-microMIPS code, the
+preprocessor symbol @code{__mips_micromips} reflects the setting on the
+command line,
+not that within individual functions.  Mixed microMIPS and non-microMIPS code
+may interact badly with some GCC extensions such as @code{__builtin_apply}
+(@pxref{Constructing Calls}).
+
 @item model (@var{model-name})
 @cindex function addressability on the M32R/D
 @cindex variable addressability on the IA-64
@@ -3038,13 +3271,13 @@ 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),
+compiler generates @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).
+compiler generates @code{seth/add3} instructions to load their addresses),
+and may not be reachable with the @code{bl} instruction (the compiler
+generates the much slower @code{seth/add3/jl} instruction sequence).
 
 On IA-64, use this attribute to set the addressability of an object.
 At present, the only supported identifier for @var{model-name} is
@@ -3065,35 +3298,48 @@ while the @code{sysv_abi} attribute tells the compiler to use the ABI
 used on GNU/Linux and other systems.  The default is to use the Microsoft ABI
 when targeting Windows.  On all other systems, the default is the x86/AMD ABI.
 
-Note, the @code{ms_abi} attribute for Windows 64-bit targets currently
+Note, the @code{ms_abi} attribute for Microsoft Windows 64-bit targets currently
 requires the @option{-maccumulate-outgoing-args} option.
 
 @item callee_pop_aggregate_return (@var{number})
 @cindex @code{callee_pop_aggregate_return} attribute
 
-On 32-bit i?86-*-* targets, you can control by those attribute for
-aggregate return in memory, if the caller is responsible to pop the hidden
-pointer together with the rest of the arguments - @var{number} equal to
-zero -, or if the callee is responsible to pop hidden pointer - @var{number}
-equal to one.  The default i386 ABI assumes that the callee pops the
-stack for hidden pointer.
+On 32-bit i?86-*-* targets, you can use this attribute to control how
+aggregates are returned in memory.  If the caller is responsible for
+popping the hidden pointer together with the rest of the arguments, specify
+@var{number} equal to zero.  If callee is responsible for popping the
+hidden pointer, specify @var{number} equal to one.  
 
-Note, that on 32-bit i386 Windows targets the compiler assumes that the
+The default i386 ABI assumes that the callee pops the
+stack for hidden pointer.  However, on 32-bit i386 Microsoft Windows targets,
+the compiler assumes that the
 caller pops the stack for hidden pointer.
 
 @item ms_hook_prologue
 @cindex @code{ms_hook_prologue} attribute
 
-On 32 bit i[34567]86-*-* targets and 64 bit x86_64-*-* targets, you can use
-this function attribute to make gcc generate the "hot-patching" function
+On 32-bit i[34567]86-*-* targets and 64-bit x86_64-*-* targets, you can use
+this function attribute to make GCC generate the ``hot-patching'' function
 prologue used in Win32 API functions in Microsoft Windows XP Service Pack 2
 and newer.
 
+@item hotpatch [(@var{prologue-halfwords})]
+@cindex @code{hotpatch} attribute
+
+On S/390 System z targets, you can use this function attribute to
+make GCC generate a ``hot-patching'' function prologue.  The
+@code{hotpatch} has no effect on funtions that are explicitly
+inline.  If the @option{-mhotpatch} or @option{-mno-hotpatch}
+command-line option is used at the same time, the @code{hotpatch}
+attribute takes precedence.  If an argument is given, the maximum
+allowed value is 1000000.
+
 @item naked
 @cindex function without a prologue/epilogue code
-Use this attribute on the ARM, AVR, MCORE, RX and SPU 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. The
+Use this attribute on the ARM, AVR, MCORE, MSP430, NDS32, RL78, RX and SPU
+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. The
 only statements that can be safely included in naked functions are
 @code{asm} statements that do not have operands.  All other statements,
 including declarations of local variables, @code{if} statements, and so
@@ -3102,7 +3348,7 @@ body of an assembly function, while allowing the compiler to construct
 the requisite function declaration for the assembler.
 
 @item near
-@cindex functions which do not handle memory bank switching on 68HC11/68HC12
+@cindex functions that 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}
@@ -3110,7 +3356,7 @@ option.
 
 On MeP targets this attribute causes the compiler to assume the called
 function is close enough to use the normal calling convention,
-overriding the @code{-mtf} command line option.
+overriding the @option{-mtf} command-line option.
 
 @item nesting
 @cindex Allow nesting in an interrupt handler on the Blackfin processor.
@@ -3121,23 +3367,30 @@ 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
+is an NMI handler.  The compiler generates function entry and
 exit sequences suitable for use in an NMI handler when this
 attribute is present.
 
+@item nocompression
+@cindex @code{nocompression} attribute
+On MIPS targets, you can use the @code{nocompression} function attribute
+to locally turn off MIPS16 and microMIPS code generation.  This attribute
+overrides the @option{-mips16} and @option{-mmicromips} options on the
+command line (@pxref{MIPS Options}).
+
 @item no_instrument_function
 @cindex @code{no_instrument_function} function attribute
 @opindex finstrument-functions
-If @option{-finstrument-functions} is given, profiling function calls will
-be generated at entry and exit of most user-compiled functions.
-Functions with this attribute will not be so instrumented.
+If @option{-finstrument-functions} is given, profiling function calls are
+generated at entry and exit of most user-compiled functions.
+Functions with this attribute are not so instrumented.
 
 @item no_split_stack
 @cindex @code{no_split_stack} function attribute
 @opindex fsplit-stack
-If @option{-fsplit-stack} is given, functions will have a small
+If @option{-fsplit-stack} is given, functions have a small
 prologue which decides whether to split the stack.  Functions with the
-@code{no_split_stack} attribute will not have that prologue, and thus
+@code{no_split_stack} attribute do not have that prologue, and thus
 may run with only a small amount of stack space available.
 
 @item noinline
@@ -3147,19 +3400,21 @@ inlining.
 @c Don't enumerate the optimizations by name here; we try to be
 @c future-compatible with this mechanism.
 If the function does not have side-effects, there are optimizations
-other than inlining that causes function calls to be optimized away,
+other than inlining that cause function calls to be optimized away,
 although the function call is live.  To keep such calls from being
 optimized away, put
 @smallexample
 asm ("");
 @end smallexample
+
+@noindent
 (@pxref{Extended Asm}) in the called function, to serve as a special
 side-effect.
 
 @item noclone
 @cindex @code{noclone} function attribute
 This function attribute prevents a function from being considered for
-cloning - a mechanism which produces specialized copies of functions
+cloning---a mechanism that produces specialized copies of functions
 and which is (currently) performed by interprocedural constant
 propagation.
 
@@ -3180,7 +3435,7 @@ arguments @var{dest} and @var{src} are non-null.  If the compiler
 determines that a null pointer is passed in an argument slot marked
 as non-null, and the @option{-Wnonnull} option is enabled, a warning
 is issued.  The compiler may also choose to make optimizations based
-on the knowledge that certain function arguments will not be null.
+on the knowledge that certain function arguments will never be null.
 
 If no argument index list is given to the @code{nonnull} attribute,
 all pointer arguments are marked as non-null.  To illustrate, the
@@ -3192,6 +3447,20 @@ my_memcpy (void *dest, const void *src, size_t len)
         __attribute__((nonnull));
 @end smallexample
 
+@item returns_nonnull
+@cindex @code{returns_nonnull} function attribute
+The @code{returns_nonnull} attribute specifies that the function
+return value should be a non-null pointer.  For instance, the declaration:
+
+@smallexample
+extern void *
+mymalloc (size_t len) __attribute__((returns_nonnull));
+@end smallexample
+
+@noindent
+lets the compiler optimize callers based on the knowledge
+that the return value will never be null.
+
 @item noreturn
 @cindex @code{noreturn} function attribute
 A few standard library functions, such as @code{abort} and @code{exit},
@@ -3239,6 +3508,7 @@ typedef void voidfn ();
 volatile voidfn fatal;
 @end smallexample
 
+@noindent
 This approach does not work in GNU C++.
 
 @item nothrow
@@ -3250,6 +3520,13 @@ 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 nosave_low_regs
+@cindex @code{nosave_low_regs} attribute
+Use this attribute on SH targets to indicate that an @code{interrupt_handler}
+function should not save and restore registers R0..R7.  This can be used on SH3*
+and SH4* targets that have a second R0..R7 register bank for non-reentrant
+interrupt handlers.
+
 @item optimize
 @cindex @code{optimize} function attribute
 The @code{optimize} attribute is used to specify that a function is to
@@ -3263,9 +3540,9 @@ that affect more than one function.
 @xref{Function Specific Option Pragmas}, for details about the
 @samp{#pragma GCC optimize} pragma.
 
-This can be used for instance to have frequently executed functions
+This can be used for instance to have frequently-executed functions
 compiled with more aggressive optimization options that produce faster
-and larger code, while other functions can be called with less
+and larger code, while other functions can be compiled with less
 aggressive options.
 
 @item OS_main/OS_task
@@ -3276,19 +3553,19 @@ do not save/restore any call-saved register in their prologue/epilogue.
 
 The @code{OS_main} attribute can be used when there @emph{is
 guarantee} that interrupts are disabled at the time when the function
-is entered.  This will save resources when the stack pointer has to be
+is entered.  This saves resources when the stack pointer has to be
 changed to set up a frame for local variables.
 
 The @code{OS_task} attribute can be used when there is @emph{no
 guarantee} that interrupts are disabled at that time when the function
 is entered like for, e@.g@. task functions in a multi-threading operating
-system. In that case, changing the stack pointer register will be
+system. In that case, changing the stack pointer register is
 guarded by save/clear/restore of the global interrupt enable flag.
 
 The differences to the @code{naked} function attribute are:
 @itemize @bullet
 @item @code{naked} functions do not have a return instruction whereas 
-@code{OS_main} and @code{OS_task} functions will have a @code{RET} or
+@code{OS_main} and @code{OS_task} functions have a @code{RET} or
 @code{RETI} return instruction.
 @item @code{naked} functions do not set up a frame for local variables
 or a frame pointer whereas @code{OS_main} and @code{OS_task} do this
@@ -3302,7 +3579,7 @@ The @code{pcs} attribute can be used to control the calling convention
 used for a function on ARM.  The attribute takes an argument that specifies
 the calling convention to use.
 
-When compiling using the AAPCS ABI (or a variant of that) then valid
+When compiling using the AAPCS ABI (or a variant of it) then valid
 values for the argument are @code{"aapcs"} and @code{"aapcs-vfp"}.  In
 order to use a variant other than @code{"aapcs"} then the compiler must
 be permitted to use the appropriate co-processor registers (i.e., the
@@ -3315,7 +3592,7 @@ double f2d (float) __attribute__((pcs("aapcs")));
 @end smallexample
 
 Variadic functions always use the @code{"aapcs"} calling convention and
-the compiler will reject attempts to specify an alternative.
+the compiler rejects attempts to specify an alternative.
 
 @item pure
 @cindex @code{pure} function attribute
@@ -3344,33 +3621,69 @@ than 2.96.
 
 @item hot
 @cindex @code{hot} function attribute
-The @code{hot} attribute is used to inform the compiler that a function is a
-hot spot of the compiled program.  The function is optimized more aggressively
-and on many target it is placed into special subsection of the text section so
-all hot functions appears close together improving locality.
+The @code{hot} attribute on a function is used to inform the compiler that
+the function is a hot spot of the compiled program.  The function is
+optimized more aggressively and on many target it is placed into special
+subsection of the text section so all hot functions appears close together
+improving locality.
 
 When profile feedback is available, via @option{-fprofile-use}, hot functions
 are automatically detected and this attribute is ignored.
 
-The @code{hot} attribute is not implemented in GCC versions earlier
-than 4.3.
+The @code{hot} attribute on functions is not implemented in GCC versions
+earlier than 4.3.
+
+@cindex @code{hot} label attribute
+The @code{hot} attribute on a label is used to inform the compiler that
+path following the label are more likely than paths that are not so
+annotated.  This attribute is used in cases where @code{__builtin_expect}
+cannot be used, for instance with computed goto or @code{asm goto}.
+
+The @code{hot} attribute on labels is not implemented in GCC versions
+earlier than 4.8.
 
 @item cold
 @cindex @code{cold} function attribute
-The @code{cold} attribute is used to inform the compiler that a function is
-unlikely executed.  The function is optimized for size rather than speed and on
-many targets it is placed into special subsection of the text section so all
-cold functions appears close together improving code locality of non-cold parts
-of program.  The paths leading to call of cold functions within code are marked
-as unlikely by the branch prediction mechanism. It is thus useful to mark
-functions used to handle unlikely conditions, such as @code{perror}, as cold to
-improve optimization of hot functions that do call marked functions in rare
-occasions.
-
-When profile feedback is available, via @option{-fprofile-use}, hot functions
+The @code{cold} attribute on functions is used to inform the compiler that
+the function is unlikely to be executed.  The function is optimized for
+size rather than speed and on many targets it is placed into special
+subsection of the text section so all cold functions appears close together
+improving code locality of non-cold parts of program.  The paths leading
+to call of cold functions within code are marked as unlikely by the branch
+prediction mechanism.  It is thus useful to mark functions used to handle
+unlikely conditions, such as @code{perror}, as cold to improve optimization
+of hot functions that do call marked functions in rare occasions.
+
+When profile feedback is available, via @option{-fprofile-use}, cold functions
 are automatically detected and this attribute is ignored.
 
-The @code{cold} attribute is not implemented in GCC versions earlier than 4.3.
+The @code{cold} attribute on functions is not implemented in GCC versions
+earlier than 4.3.
+
+@cindex @code{cold} label attribute
+The @code{cold} attribute on labels is used to inform the compiler that
+the path following the label is unlikely to be executed.  This attribute
+is used in cases where @code{__builtin_expect} cannot be used, for instance
+with computed goto or @code{asm goto}.
+
+The @code{cold} attribute on labels is not implemented in GCC versions
+earlier than 4.8.
+
+@item no_sanitize_address
+@itemx no_address_safety_analysis
+@cindex @code{no_sanitize_address} function attribute
+The @code{no_sanitize_address} attribute on functions is used
+to inform the compiler that it should not instrument memory accesses
+in the function when compiling with the @option{-fsanitize=address} option.
+The @code{no_address_safety_analysis} is a deprecated alias of the
+@code{no_sanitize_address} attribute, new code should use
+@code{no_sanitize_address}.
+
+@item no_sanitize_undefined
+@cindex @code{no_sanitize_undefined} function attribute
+The @code{no_sanitize_undefined} attribute on functions is used
+to inform the compiler that it should not check for undefined behavior
+in the function when compiling with the @option{-fsanitize=undefined} option.
 
 @item regparm (@var{number})
 @cindex @code{regparm} attribute
@@ -3378,35 +3691,56 @@ The @code{cold} attribute is not implemented in GCC versions earlier than 4.3.
 On the Intel 386, the @code{regparm} attribute causes the compiler to
 pass arguments number one to @var{number} if they are of integral type
 in registers EAX, EDX, and ECX instead of on the stack.  Functions that
-take a variable number of arguments will continue to be passed all of their
+take a variable number of arguments continue to be passed all of their
 arguments on the stack.
 
 Beware that on some ELF systems this attribute is unsuitable for
 global functions in shared libraries with lazy binding (which is the
-default).  Lazy binding will send the first call via resolving code in
+default).  Lazy binding sends the first call via resolving code in
 the loader, which might assume EAX, EDX and ECX can be clobbered, as
 per the standard calling conventions.  Solaris 8 is affected by this.
-GNU systems with GLIBC 2.1 or higher, and FreeBSD, are believed to be
+Systems with the GNU C Library version 2.1 or higher
+and FreeBSD are believed to be
 safe since the loaders there save EAX, EDX and ECX.  (Lazy binding can be
 disabled with the linker or the loader if desired, to avoid the
 problem.)
 
+@item reset
+@cindex reset handler functions
+Use this attribute on the NDS32 target to indicate that the specified function
+is a reset handler.  The compiler will generate corresponding sections
+for use in a reset handler.  You can use the following attributes
+to provide extra exception handling:
+@table @code
+@item nmi
+@cindex @code{nmi} attribute
+Provide a user-defined function to handle NMI exception.
+@item warm
+@cindex @code{warm} attribute
+Provide a user-defined function to handle warm reset exception.
+@end table
+
 @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
+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.
+variable number of arguments 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 if necessary.
+prologue and epilogue that realigns the run-time stack if necessary.
 This supports mixing legacy codes that run with a 4-byte aligned stack
 with modern codes that keep a 16-byte stack for SSE compatibility.
 
+@item renesas
+@cindex @code{renesas} attribute
+On SH targets this attribute specifies that the function or struct follows the
+Renesas ABI.
+
 @item resbank
 @cindex @code{resbank} attribute
 On the SH2A target, this attribute enables the high-speed register
@@ -3423,8 +3757,8 @@ from the bank is executed by issuing a RESBANK instruction.
 @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
+return more than one time.  The compiler ensures that all registers
+are dead before calling such a function and emits a warning about
 the variables that may be clobbered after the second return from the
 function.  Examples of such functions are @code{setjmp} and @code{vfork}.
 The @code{longjmp}-like counterpart of such function, if any, might need
@@ -3440,7 +3774,7 @@ regardless of whether they are used or not.
 @cindex save volatile registers on the MicroBlaze
 Use this attribute on the MicroBlaze to indicate that the function is
 an interrupt handler.  All volatile registers (in addition to non-volatile
-registers) will be saved in the function prologue.  If the function is a leaf
+registers) are saved in the function prologue.  If the function is a leaf
 function, only volatiles used by the function are saved.  A normal function
 return is generated instead of a return from interrupt.
 
@@ -3492,15 +3826,15 @@ The warnings for missing or incorrect sentinels are enabled with
 @option{-Wformat}.
 
 @item short_call
-See long_call/short_call.
+See @code{long_call/short_call}.
 
 @item shortcall
-See longcall/shortcall.
+See @code{longcall/shortcall}.
 
 @item signal
 @cindex interrupt handler functions on the AVR processors
 Use this attribute on the AVR to indicate that the specified
-function is an interrupt handler.  The compiler will generate function
+function is an interrupt handler.  The compiler generates function
 entry and exit sequences suitable for use in an interrupt handler when this
 attribute is present.
 
@@ -3510,13 +3844,14 @@ The AVR hardware globally disables interrupts when an interrupt is executed.
 Interrupt handler functions defined with the @code{signal} attribute
 do not re-enable interrupts.  It is save to enable interrupts in a
 @code{signal} handler.  This ``save'' only applies to the code
-generated by the compiler and not to the IRQ-layout of the
+generated by the compiler and not to the IRQ layout of the
 application which is responsibility of the application.
 
 If both @code{signal} and @code{interrupt} are specified for the same
-function, @code{signal} will be silently ignored.
+function, @code{signal} is silently ignored.
 
 @item sp_switch
+@cindex @code{sp_switch} attribute
 Use this attribute on the SH to indicate an @code{interrupt_handler}
 function should switch to an alternate stack.  It expects a string
 argument that names a global variable holding the address of the
@@ -3531,12 +3866,12 @@ void f () __attribute__ ((interrupt_handler,
 @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
+assume that the called function pops off the stack space used to
 pass arguments, unless it takes a variable number of arguments.
 
 @item syscall_linkage
 @cindex @code{syscall_linkage} attribute
-This attribute is used to modify the IA64 calling convention by marking
+This attribute is used to modify the IA-64 calling convention by marking
 all input registers as live at all function exits.  This makes it possible
 to restart a system call after an interrupt without having to save/restore
 the input registers.  This also prevents kernel data from leaking into
@@ -3555,12 +3890,12 @@ more than one function to be compiled with specific target options.
 
 For instance on a 386, you could compile one function with
 @code{target("sse4.1,arch=core2")} and another with
-@code{target("sse4a,arch=amdfam10")} that would be equivalent to
+@code{target("sse4a,arch=amdfam10")}.  This is equivalent to
 compiling the first function with @option{-msse4.1} and
 @option{-march=core2} options, and the second function with
 @option{-msse4a} and @option{-march=amdfam10} options.  It is up to the
 user to make sure that a function is only invoked on a machine that
-supports the particular ISA it was compiled for (for example by using
+supports the particular ISA it is compiled for (for example by using
 @code{cpuid} on 386 to determine what feature bits and architecture
 family are used).
 
@@ -3569,6 +3904,14 @@ int core2_func (void) __attribute__ ((__target__ ("arch=core2")));
 int sse3_func (void) __attribute__ ((__target__ ("sse3")));
 @end smallexample
 
+You can either use multiple
+strings to specify multiple options, or separate the options
+with a comma (@samp{,}).
+
+The @code{target} attribute is presently implemented for
+i386/x86_64, PowerPC, and Nios II targets only.
+The options supported are specific to each target.
+
 On the 386, the following options are allowed:
 
 @table @samp
@@ -3582,6 +3925,11 @@ Enable/disable the generation of the advanced bit instructions.
 @cindex @code{target("aes")} attribute
 Enable/disable the generation of the AES instructions.
 
+@item default
+@cindex @code{target("default")} attribute
+@xref{Function Multiversioning}, where it is used to specify the
+default function version.
+
 @item mmx
 @itemx no-mmx
 @cindex @code{target("mmx")} attribute
@@ -3662,7 +4010,7 @@ Enable/disable the generation of the CLD before string moves.
 @itemx no-fancy-math-387
 @cindex @code{target("fancy-math-387")} attribute
 Enable/disable the generation of the @code{sin}, @code{cos}, and
-@code{sqrt} instructions on the 387 floating point unit.
+@code{sqrt} instructions on the 387 floating-point unit.
 
 @item fused-madd
 @itemx no-fused-madd
@@ -3695,7 +4043,7 @@ Do/do not align destination of inlined string operations.
 @cindex @code{target("recip")} attribute
 Enable/disable the generation of RCPSS, RCPPS, RSQRTSS and RSQRTPS
 instructions followed an additional Newton-Raphson step instead of
-doing a floating point division.
+doing a floating-point division.
 
 @item arch=@var{ARCH}
 @cindex @code{target("arch=@var{ARCH}")} attribute
@@ -3707,7 +4055,7 @@ Specify the architecture to tune for in compiling the function.
 
 @item fpmath=@var{FPMATH}
 @cindex @code{target("fpmath=@var{FPMATH}")} attribute
-Specify which floating point unit to use.  The
+Specify which floating-point unit to use.  The
 @code{target("fpmath=sse,387")} option must be specified as
 @code{target("fpmath=sse+387")} because the comma would separate
 different options.
@@ -3720,8 +4068,8 @@ On the PowerPC, the following options are allowed:
 @itemx no-altivec
 @cindex @code{target("altivec")} attribute
 Generate code that uses (does not use) AltiVec instructions.  In
-32-bit code, you cannot enable Altivec instructions unless
-@option{-mabi=altivec} was used on the command line.
+32-bit code, you cannot enable AltiVec instructions unless
+@option{-mabi=altivec} is used on the command line.
 
 @item cmpb
 @itemx no-cmpb
@@ -3735,7 +4083,7 @@ the PowerPC V2.05 architecture.
 @cindex @code{target("dlmzb")} attribute
 Generate code that uses (does not use) the string-search @samp{dlmzb}
 instruction on the IBM 405, 440, 464 and 476 processors.  This instruction is
-generated by default when targetting those processors.
+generated by default when targeting those processors.
 
 @item fprnd
 @itemx no-fprnd
@@ -3747,7 +4095,7 @@ that support the PowerPC V2.03 architecture.
 @item hard-dfp
 @itemx no-hard-dfp
 @cindex @code{target("hard-dfp")} attribute
-Generate code that uses (does not use) the decimal floating point
+Generate code that uses (does not use) the decimal floating-point
 instructions implemented on some POWER processors.
 
 @item isel
@@ -3774,7 +4122,7 @@ other processors that support the extended PowerPC V2.05 architecture.
 @cindex @code{target("mulhw")} attribute
 Generate code that uses (does not use) the half-word multiply and
 multiply-accumulate instructions on the IBM 405, 440, 464 and 476 processors.
-These instructions are generated by default when targetting those
+These instructions are generated by default when targeting those
 processors.
 
 @item multiple
@@ -3793,8 +4141,8 @@ location.
 @item popcntb
 @itemx no-popcntb
 @cindex @code{target("popcntb")} attribute
-Generate code that uses (does not use) the popcount and double
-precision FP reciprocal estimate instruction implemented on the POWER5
+Generate code that uses (does not use) the popcount and double-precision
+FP reciprocal estimate instruction implemented on the POWER5
 processor and other processors that support the PowerPC V2.02
 architecture.
 
@@ -3823,7 +4171,7 @@ floating-point square root.
 @itemx no-recip-precision
 @cindex @code{target("recip-precision")} attribute
 Assume (do not assume) that the reciprocal estimate instructions
-provide higher precision estimates than is mandated by the powerpc
+provide higher-precision estimates than is mandated by the powerpc
 ABI.
 
 @item string
@@ -3839,17 +4187,17 @@ do small block moves.
 Generate code that uses (does not use) vector/scalar (VSX)
 instructions, and also enable the use of built-in functions that allow
 more direct access to the VSX instruction set.  In 32-bit code, you
-cannot enable VSX or Altivec instructions unless
-@option{-mabi=altivec} was used on the command line.
+cannot enable VSX or AltiVec instructions unless
+@option{-mabi=altivec} is used on the command line.
 
 @item friz
 @itemx no-friz
 @cindex @code{target("friz")} attribute
 Generate (do not generate) the @code{friz} instruction when the
 @option{-funsafe-math-optimizations} option is used to optimize
-rounding a floating point value to 64-bit integer and back to floating
+rounding a floating-point value to 64-bit integer and back to floating
 point.  The @code{friz} instruction does not return the same value if
-the floating point number is too large to fit in an integer.
+the floating-point number is too large to fit in an integer.
 
 @item avoid-indexed-addresses
 @itemx no-avoid-indexed-addresses
@@ -3873,7 +4221,7 @@ away so that a longer more expensive calling sequence is required.
 @cindex @code{target("cpu=@var{CPU}")} attribute
 Specify the architecture to generate code for when compiling the
 function.  If you select the @code{target("cpu=power7")} attribute when
-generating 32-bit code, VSX and Altivec instructions are not generated
+generating 32-bit code, VSX and AltiVec instructions are not generated
 unless you use the @option{-mabi=altivec} option on the command line.
 
 @item tune=@var{TUNE}
@@ -3881,41 +4229,63 @@ unless you use the @option{-mabi=altivec} option on the command line.
 Specify the architecture to tune for when compiling the function.  If
 you do not specify the @code{target("tune=@var{TUNE}")} attribute and
 you do specify the @code{target("cpu=@var{CPU}")} attribute,
-compilation will tune for the @var{CPU} architecture, and not the
+compilation tunes for the @var{CPU} architecture, and not the
 default tuning specified on the command line.
 @end table
 
-On the 386/x86_64 and PowerPC backends, you can use either multiple
-strings to specify multiple options, or you can separate the option
-with a comma (@code{,}).
+When compiling for Nios II, the following options are allowed:
 
-On the 386/x86_64 and PowerPC backends, the inliner will not inline a
+@table @samp
+@item custom-@var{insn}=@var{N}
+@itemx no-custom-@var{insn}
+@cindex @code{target("custom-@var{insn}=@var{N}")} attribute
+@cindex @code{target("no-custom-@var{insn}")} attribute
+Each @samp{custom-@var{insn}=@var{N}} attribute locally enables use of a
+custom instruction with encoding @var{N} when generating code that uses 
+@var{insn}.  Similarly, @samp{no-custom-@var{insn}} locally inhibits use of
+the custom instruction @var{insn}.
+These target attributes correspond to the
+@option{-mcustom-@var{insn}=@var{N}} and @option{-mno-custom-@var{insn}}
+command-line options, and support the same set of @var{insn} keywords.
+@xref{Nios II Options}, for more information.
+
+@item custom-fpu-cfg=@var{name}
+@cindex @code{target("custom-fpu-cfg=@var{name}")} attribute
+This attribute corresponds to the @option{-mcustom-fpu-cfg=@var{name}}
+command-line option, to select a predefined set of custom instructions
+named @var{name}.
+@xref{Nios II Options}, for more information.
+@end table
+
+On the 386/x86_64 and PowerPC back ends, the inliner does not inline a
 function that has different target options than the caller, unless the
 callee has a subset of the target options of the caller.  For example
 a function declared with @code{target("sse3")} can inline a function
 with @code{target("sse2")}, since @code{-msse3} implies @code{-msse2}.
 
-The @code{target} attribute is not implemented in GCC versions earlier
-than 4.4 for the i386/x86_64 and 4.6 for the PowerPC backends.  It is
-not currently implemented for other backends.
-
 @item tiny_data
 @cindex tiny data section on the H8/300H and H8S
 Use this attribute on the H8/300H and H8S to indicate that the specified
 variable should be placed into the tiny data section.
-The compiler will generate more efficient code for loads and stores
+The compiler generates more efficient code for loads and stores
 on data in the tiny data section.  Note the tiny data area is limited to
-slightly under 32kbytes of data.
+slightly under 32KB of data.
 
 @item trap_exit
+@cindex @code{trap_exit} attribute
 Use this attribute on the SH for an @code{interrupt_handler} to return using
 @code{trapa} instead of @code{rte}.  This attribute expects an integer
 argument specifying the trap number to be used.
 
+@item trapa_handler
+@cindex @code{trapa_handler} attribute
+On SH targets this function attribute is similar to @code{interrupt_handler}
+but it does not save and restore all registers.
+
 @item unused
 @cindex @code{unused} 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
+to be possibly unused.  GCC does not produce a warning for this
 function.
 
 @item used
@@ -3926,21 +4296,22 @@ This is useful, for example, when the function is referenced only in
 inline assembly.
 
 When applied to a member function of a C++ class template, the
-attribute also means that the function will be instantiated if the
+attribute also means that the function is instantiated if the
 class itself is instantiated.
 
 @item version_id
 @cindex @code{version_id} attribute
-This IA64 HP-UX attribute, attached to a global variable or function, renames a
+This IA-64 HP-UX attribute, attached to a global variable or function, renames a
 symbol to contain a version string, thus allowing for function level
-versioning.  HP-UX system header files may use version level functioning
+versioning.  HP-UX system header files may use function level versioning
 for some system calls.
 
 @smallexample
 extern int foo () __attribute__((version_id ("20040821")));
 @end smallexample
 
-Calls to @var{foo} will be mapped to calls to @var{foo@{20040821@}}.
+@noindent
+Calls to @var{foo} are mapped to calls to @var{foo@{20040821@}}.
 
 @item visibility ("@var{visibility_type}")
 @cindex @code{visibility} attribute
@@ -3975,8 +4346,8 @@ other modules.
 Default visibility corresponds to ``external linkage'' in the language.
 
 @item hidden
-Hidden visibility indicates that the entity declared will have a new
-form of linkage, which we'll call ``hidden linkage''.  Two
+Hidden visibility indicates that the entity declared has a new
+form of linkage, which we call ``hidden linkage''.  Two
 declarations of an object with hidden linkage refer to the same object
 if they are in the same shared object.
 
@@ -3993,7 +4364,7 @@ that the calling function loaded the correct value.
 
 @item protected
 Protected visibility is like default visibility except that it
-indicates that references within the defining module will bind to the
+indicates that references within the defining module bind to the
 definition in that module.  That is, the declared entity cannot be
 overridden by another module.
 
@@ -4004,7 +4375,7 @@ All visibilities are supported on many, but not all, ELF targets
 pseudo-op).  Default visibility is supported everywhere.  Hidden
 visibility is supported on Darwin targets.
 
-The visibility attribute should be applied only to declarations which
+The visibility attribute should be applied only to declarations that
 would otherwise have external linkage.  The attribute should be applied
 consistently, so that the same entity should not be declared with
 different settings of the attribute.
@@ -4025,6 +4396,12 @@ 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.
+
+@smallexample
+namespace nspace1 __attribute__ ((visibility ("protected")))
+@{ /* @r{Do something.} */; @}
+@end smallexample
+
 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
@@ -4043,7 +4420,7 @@ visibility from the template is used.
 On MeP, the @code{vliw} attribute tells the compiler to emit
 instructions in VLIW mode instead of core mode.  Note that this
 attribute is not allowed unless a VLIW coprocessor has been configured
-and enabled through command line options.
+and enabled through command-line options.
 
 @item warn_unused_result
 @cindex @code{warn_unused_result} attribute
@@ -4063,13 +4440,14 @@ int foo ()
 @}
 @end smallexample
 
+@noindent
 results in warning on line 5.
 
 @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
+library functions that can be overridden in user code, though it can
 also be used with non-function declarations.  Weak symbols are supported
 for ELF targets, and also for a.out targets when using the GNU assembler
 and linker.
@@ -4098,7 +4476,7 @@ A weak reference is an alias that does not by itself require a
 definition to be given for the target symbol.  If the target symbol is
 only referenced through weak references, then it becomes a @code{weak}
 undefined symbol.  If it is directly referenced, however, then such
-strong references prevail, and a definition will be required for the
+strong references prevail, and a definition is required for the
 symbol, not necessarily in the same translation unit.
 
 The effect is equivalent to moving all references to the alias to a
@@ -4141,8 +4519,7 @@ namespace is now in use for GCC-specific pragmas.  However, it has been
 found convenient to use @code{__attribute__} to achieve a natural
 attachment of attributes to their corresponding declarations, whereas
 @code{#pragma GCC} is of use for constructs that do not naturally form
-part of the grammar.  @xref{Other Directives,,Miscellaneous
-Preprocessing Directives, cpp, The GNU C Preprocessor}.
+part of the grammar.  @xref{Pragmas,,Pragmas Accepted by GCC}.
 
 @node Attribute Syntax
 @section Attribute Syntax
@@ -4207,9 +4584,9 @@ specifiers, not separated by any other tokens.
 In GNU C, an attribute specifier list may appear after the colon following a
 label, other than a @code{case} or @code{default} label.  The only
 attribute it makes sense to use after a label is @code{unused}.  This
-feature is intended for code generated by programs which contains labels
-that may be unused but which is compiled with @option{-Wall}.  It would
-not normally be appropriate to use in it human-written code, though it
+feature is intended for program-generated code that may contain unused labels,
+but which is compiled with @option{-Wall}.  It is
+not normally appropriate to use in it human-written code, though it
 could be useful in cases where the code that jumps to the label is
 contained within an @code{#ifdef} conditional.  GNU C++ only permits
 attributes on labels if the attribute specifier is immediately
@@ -4261,7 +4638,7 @@ 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
+type specifier that is not an attribute specifier; this resolves an
 ambiguity in the interpretation of @code{void f(int
 (__attribute__((foo)) x))}, but is subject to change.  At present, if
 the parentheses of a function declarator contain only attributes then
@@ -4311,7 +4688,7 @@ attributes correctly apply to the declarator, but for most individual
 attributes the semantics this implies are not implemented.
 When attribute specifiers follow the @code{*} of a pointer
 declarator, they may be mixed with any type qualifiers present.
-The following describes the formal semantics of this syntax.  It will make the
+The following describes the formal semantics of this syntax.  It makes the
 most sense if you are familiar with the formal specification of
 declarators in the ISO C standard.
 
@@ -4359,18 +4736,18 @@ is not yet supported.
 For compatibility with existing code written for compiler versions that
 did not implement attributes on nested declarators, some laxity is
 allowed in the placing of attributes.  If an attribute that only applies
-to types is applied to a declaration, it will be treated as applying to
+to types is applied to a declaration, it is treated as applying to
 the type of that declaration.  If an attribute that only applies to
-declarations is applied to the type of a declaration, it will be treated
+declarations is applied to the type of a declaration, it is treated
 as applying to that declaration; and, for compatibility with code
 placing the attributes immediately before the identifier declared, such
-an attribute applied to a function return type will be treated as
+an attribute applied to a function return type is treated as
 applying to the function type, and such an attribute applied to an array
-element type will be treated as applying to the array type.  If an
+element type is treated as applying to the array type.  If an
 attribute that only applies to function types is applied to a
-pointer-to-function type, it will be treated as applying to the pointer
+pointer-to-function type, it is treated as applying to the pointer
 target type; if such an attribute is applied to a function return type
-that is not a pointer-to-function type, it will be treated as applying
+that is not a pointer-to-function type, it is treated as applying
 to the function type.
 
 @node Function Prototypes
@@ -4509,8 +4886,8 @@ struct foo @{ int x[2] __attribute__ ((aligned (8))); @};
 @end smallexample
 
 @noindent
-This is an alternative to creating a union with a @code{double} member
-that forces the union to be double-word aligned.
+This is an alternative to creating a union with a @code{double} member,
+which forces the union to be double-word aligned.
 
 As in the preceding examples, you can explicitly specify the alignment
 (in bytes) that you wish the compiler to use for a given variable or
@@ -4518,10 +4895,10 @@ structure field.  Alternatively, you can leave out the alignment factor
 and just ask the compiler to align a variable or field to the
 default alignment for the target architecture you are compiling for.
 The default alignment is sufficient for all scalar types, but may not be
-enough for all vector types on a target which supports vector operations.
+enough for all vector types on a target that supports vector operations.
 The default alignment is fixed for a particular target ABI.
 
-Gcc also provides a target specific macro @code{__BIGGEST_ALIGNMENT__},
+GCC also provides a target specific macro @code{__BIGGEST_ALIGNMENT__},
 which is the largest alignment ever used for any data type on the
 target machine you are compiling for.  For example, you could write:
 
@@ -4535,21 +4912,21 @@ often make copy operations more efficient, because the compiler can
 use whatever instructions copy the biggest chunks of memory when
 performing copies to or from the variables or fields that you have
 aligned this way.  Note that the value of @code{__BIGGEST_ALIGNMENT__}
-may change depending on command line options.
+may change depending on command-line options.
 
 When used on a struct, or struct member, the @code{aligned} attribute can
 only increase the alignment; in order to decrease it, the @code{packed}
 attribute must be specified as well.  When used as part of a typedef, the
 @code{aligned} attribute can both increase and decrease alignment, and
-specifying the @code{packed} attribute will generate a warning.
+specifying the @code{packed} attribute generates a warning.
 
 Note that the effectiveness of @code{aligned} attributes may be limited
 by inherent limitations in your linker.  On many systems, the linker is
 only able to arrange for variables to be aligned up to a certain maximum
 alignment.  (For some linkers, the maximum supported alignment may
 be very very small.)  If your linker is only able to align variables
-up to a maximum of 8 byte alignment, then specifying @code{aligned(16)}
-in an @code{__attribute__} will still only provide you with 8 byte
+up to a maximum of 8-byte alignment, then specifying @code{aligned(16)}
+in an @code{__attribute__} still only provides you with 8-byte
 alignment.  See your linker documentation for further information.
 
 The @code{aligned} attribute can also be used for functions
@@ -4565,7 +4942,7 @@ a pointer to a type compatible with the variable.  The return value
 of the function (if any) is ignored.
 
 If @option{-fexceptions} is enabled, then @var{cleanup_function}
-will be run during the stack unwinding that happens during the
+is run during the stack unwinding that happens during the
 processing of the exception.  Note that the @code{cleanup} attribute
 does not allow the exception to be caught, only to perform an action.
 It is undefined what happens if @var{cleanup_function} does not
@@ -4601,8 +4978,9 @@ extern int old_var;
 int new_fn () @{ return old_var; @}
 @end smallexample
 
-results in a warning on line 3 but not line 2.  The optional msg
-argument, which must be a string, will be printed in the warning if
+@noindent
+results in a warning on line 3 but not line 2.  The optional @var{msg}
+argument, which must be a string, is printed in the warning if
 present.
 
 The @code{deprecated} attribute can also be used for functions and
@@ -4612,12 +4990,12 @@ types (@pxref{Function Attributes}, @pxref{Type Attributes}.)
 @cindex @code{mode} attribute
 This attribute specifies the data type for the declaration---whichever
 type corresponds to the mode @var{mode}.  This in effect lets you
-request an integer or floating point type according to its width.
+request an integer or floating-point type according to its width.
 
-You may also specify a mode of @samp{byte} or @samp{__byte__} to
-indicate the mode corresponding to a one-byte integer, @samp{word} or
-@samp{__word__} for the mode of a one-word integer, and @samp{pointer}
-or @samp{__pointer__} for the mode used to represent pointers.
+You may also specify a mode of @code{byte} or @code{__byte__} to
+indicate the mode corresponding to a one-byte integer, @code{word} or
+@code{__word__} for the mode of a one-word integer, and @code{pointer}
+or @code{__pointer__} for the mode used to represent pointers.
 
 @item packed
 @cindex @code{packed} attribute
@@ -4682,7 +5060,7 @@ uninitialized global variables but the linker requires
 each object be defined once, with the exception that uninitialized
 variables tentatively go in the @code{common} (or @code{bss}) section
 and can be multiply ``defined''.  Using the @code{section} attribute
-will change what section the variable goes into and may cause the
+changes what section the variable goes into and may cause the
 linker to issue an error if an uninitialized variable has multiple
 definitions.  You can force a variable to be initialized with the
 @option{-fno-common} flag or the @code{nocommon} attribute.
@@ -4714,7 +5092,7 @@ main()
 
 @noindent
 You may only use the @code{shared} attribute along with @code{section}
-attribute with a fully initialized global definition because of the way
+attribute with a fully-initialized global definition because of the way
 linkers work.  See @code{section} attribute for more information.
 
 The @code{shared} attribute is only available on Microsoft Windows@.
@@ -4732,15 +5110,16 @@ Not all targets support this attribute.
 
 @item unused
 This attribute, attached to a variable, means that the variable is meant
-to be possibly unused.  GCC will not produce a warning for this
+to be possibly unused.  GCC does 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.
+This attribute, attached to a variable with the static storage, means that
+the variable must be emitted even if it appears that the variable is not
+referenced.
 
 When applied to a static data member of a C++ class template, the
-attribute also means that the member will be instantiated if the
+attribute also means that the member is instantiated if the
 class itself is instantiated.
 
 @item vector_size (@var{bytes})
@@ -4754,7 +5133,7 @@ int foo __attribute__ ((vector_size (16)));
 @noindent
 causes the compiler to set the mode for @code{foo}, to be 16 bytes,
 divided into @code{int} sized units.  Assuming a 32-bit int (a vector of
-4 units of 4 bytes), the corresponding mode of @code{foo} will be V4SI@.
+4 units of 4 bytes), the corresponding mode of @code{foo} is V4SI@.
 
 This attribute is only applicable to integral and float scalars,
 although arrays, pointers, and function return values are allowed in
@@ -4821,7 +5200,7 @@ of the data but not how this data is accessed.
 
 In order to read data located with the @code{progmem} attribute
 (inline) assembler must be used.
-@example
+@smallexample
 /* Use custom macros from @w{@uref{http://nongnu.org/avr-libc/user-manual/,AVR-LibC}} */
 #include <avr/pgmspace.h> 
 
@@ -4833,7 +5212,7 @@ int read_var (int i)
     /* Access var[] by accessor macro from avr/pgmspace.h */
     return (int) pgm_read_word (& var[i]);
 @}
-@end example
+@end smallexample
 
 AVR is a Harvard architecture processor and data and read-only data
 normally resides in the data memory (RAM).
@@ -4854,15 +5233,15 @@ Three attributes are currently defined for the Blackfin.
 @cindex @code{l1_data_A} variable attribute
 @cindex @code{l1_data_B} variable attribute
 Use these attributes on the Blackfin to place the variable into L1 Data SRAM.
-Variables with @code{l1_data} attribute will be put into the specific section
-named @code{.l1.data}. Those with @code{l1_data_A} attribute will be put into
+Variables with @code{l1_data} attribute are put into the specific section
+named @code{.l1.data}. Those with @code{l1_data_A} attribute are put into
 the specific section named @code{.l1.data.A}. Those with @code{l1_data_B}
-attribute will be put into the specific section named @code{.l1.data.B}.
+attribute are put into the specific section named @code{.l1.data.B}.
 
 @item l2
 @cindex @code{l2} variable attribute
 Use this attribute on the Blackfin to place the variable into L2 SRAM.
-Variables with @code{l2} attribute will be put into the specific section
+Variables with @code{l2} attribute are put into the specific section
 named @code{.l2.data}.
 @end table
 
@@ -4881,7 +5260,7 @@ Small model objects live in the lower 16MB of memory (so that their
 addresses can be loaded with the @code{ld24} instruction).
 
 Medium and large model objects may live anywhere in the 32-bit address space
-(the compiler will generate @code{seth/add3} instructions to load their
+(the compiler generates @code{seth/add3} instructions to load their
 addresses).
 @end table
 
@@ -4891,17 +5270,17 @@ addresses).
 The MeP target has a number of addressing modes and busses.  The
 @code{near} space spans the standard memory space's first 16 megabytes
 (24 bits).  The @code{far} space spans the entire 32-bit memory space.
-The @code{based} space is a 128 byte region in the memory space which
+The @code{based} space is a 128-byte region in the memory space that
 is addressed relative to the @code{$tp} register.  The @code{tiny}
-space is a 65536 byte region relative to the @code{$gp} register.  In
+space is a 65536-byte region relative to the @code{$gp} register.  In
 addition to these memory regions, the MeP target has a separate 16-bit
 control bus which is specified with @code{cb} attributes.
 
 @table @code
 
 @item based
-Any variable with the @code{based} attribute will be assigned to the
-@code{.based} section, and will be accessed with relative to the
+Any variable with the @code{based} attribute is assigned to the
+@code{.based} section, and is accessed with relative to the
 @code{$tp} register.
 
 @item tiny
@@ -4925,11 +5304,11 @@ stored.
 Variables with the @code{io} attribute are used to address
 memory-mapped peripherals.  If an address is specified, the variable
 is assigned that address, else it is not assigned an address (it is
-assumed some other module will assign an address).  Example:
+assumed some other module assigns an address).  Example:
 
-@example
+@smallexample
 int timer_count __attribute__((io(0x123)));
-@end example
+@end smallexample
 
 @item cb
 @itemx cb (@var{addr})
@@ -4937,9 +5316,9 @@ Variables with the @code{cb} attribute are used to access the control
 bus, using special instructions.  @code{addr} indicates the control bus
 address.  Example:
 
-@example
+@smallexample
 int cpu_clock __attribute__((cb(0x123)));
-@end example
+@end smallexample
 
 @end table
 
@@ -4955,9 +5334,9 @@ Two attributes are currently defined for i386 configurations:
 @cindex @code{ms_struct} attribute
 @cindex @code{gcc_struct} attribute
 
-If @code{packed} is used on a structure, or if bit-fields are used
-it may be that the Microsoft ABI packs them differently
-than GCC would normally pack them.  Particularly when moving packed
+If @code{packed} is used on a structure, or if bit-fields are used,
+it may be that the Microsoft ABI lays out the structure differently
+than the way GCC normally does.  Particularly when moving packed
 data between functions compiled with GCC and the native Microsoft compiler
 (either via function call or as data in a file), it may be necessary to access
 either format.
@@ -4966,38 +5345,38 @@ 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
+of the bit-field packing.  
+The padding and alignment of members of structures and whether a bit-field 
+can straddle a storage-unit boundary are determine by these rules:
 
 @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
+@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.
+object or the current packing size (specified with either the
+@code{aligned} attribute or the @code{pack} pragma),
+whichever is less.  For structures, unions, and arrays,
+the alignment requirement is the largest alignment requirement of its members.
 Every object is allocated an offset so that:
 
-offset %  alignment-requirement == 0
+@smallexample
+offset % alignment_requirement == 0
+@end smallexample
 
-@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
+@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.
+common alignment requirements of the bit-fields.
 @end enumerate
 
-Handling of zero-length bitfields:
-
-MSVC interprets zero-length bitfields in the following ways:
+MSVC interprets zero-length bit-fields 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.
+@item If a zero-length bit-field is inserted between two bit-fields that
+are normally coalesced, the bit-fields are not coalesced.
 
 For example:
 
@@ -5010,12 +5389,13 @@ struct
  @} 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.
+@noindent
+The size of @code{t1} is 8 bytes with the zero-length bit-field.  If the
+zero-length bit-field were removed, @code{t1}'s size would be 4 bytes.
 
-@item If a zero-length 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.
+@item If a zero-length bit-field is inserted after a bit-field, @code{foo}, and the
+alignment of the zero-length bit-field is greater than the member that follows it,
+@code{bar}, @code{bar} is aligned as the type of the zero-length bit-field.
 
 For example:
 
@@ -5035,20 +5415,21 @@ struct
  @} 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
+@noindent
+For @code{t2}, @code{bar} is placed at offset 2, rather than offset 1.
+Accordingly, the size of @code{t2} is 4.  For @code{t3}, the zero-length
+bit-field does not affect the alignment of @code{bar} or, as a result, the size
 of the structure.
 
 Taking this into account, it is important to note the following:
 
 @enumerate
-@item If a zero-length 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 If a zero-length bit-field follows a normal bit-field, the type of the
+zero-length bit-field may affect the alignment of the structure as whole. For
+example, @code{t2} has a size of 4 bytes, since the zero-length bit-field follows a
+normal bit-field, and is of type short.
 
-@item Even if a zero-length bitfield is not followed by a normal bitfield, it may
+@item Even if a zero-length bit-field is not followed by a normal bit-field, it may
 still affect the alignment of the structure:
 
 @smallexample
@@ -5059,10 +5440,11 @@ struct
  @} t4;
 @end smallexample
 
-Here, @code{t4} will take up 4 bytes.
+@noindent
+Here, @code{t4} takes up 4 bytes.
 @end enumerate
 
-@item Zero-length bitfields following non-bitfield members are ignored:
+@item Zero-length bit-fields following non-bit-field members are ignored:
 
 @smallexample
 struct
@@ -5073,7 +5455,8 @@ struct
  @} t5;
 @end smallexample
 
-Here, @code{t5} will take up 2 bytes.
+@noindent
+Here, @code{t5} takes up 2 bytes.
 @end enumerate
 @end table
 
@@ -5104,8 +5487,8 @@ One attribute is currently defined for xstormy16 configurations:
 @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
+allowed also), GCC places the variable in the first 0x100 bytes of
+memory and use special opcodes to access it.  Such variables are
 placed in either the @code{.bss_below100} section or the
 @code{.data_below100} section.
 
@@ -5156,8 +5539,8 @@ typedef int more_aligned_int __attribute__ ((aligned (8)));
 @end smallexample
 
 @noindent
-force the compiler to insure (as far as it can) that each variable whose
-type is @code{struct S} or @code{more_aligned_int} will be allocated and
+force the compiler to ensure (as far as it can) that each variable whose
+type is @code{struct S} or @code{more_aligned_int} is allocated and
 aligned @emph{at least} on a 8-byte boundary.  On a SPARC, having all
 variables of type @code{struct S} aligned to 8-byte boundaries allows
 the compiler to use the @code{ldd} and @code{std} (doubleword load and
@@ -5187,16 +5570,16 @@ struct S @{ short f[3]; @} __attribute__ ((aligned));
 
 Whenever you leave out the alignment factor in an @code{aligned}
 attribute specification, the compiler automatically sets the alignment
-for the type to the largest alignment which is ever used for any data
+for the type to the largest alignment that is ever used for any data
 type on the target machine you are compiling for.  Doing this can often
 make copy operations more efficient, because the compiler can use
 whatever instructions copy the biggest chunks of memory when performing
-copies to or from the variables which have types that you have aligned
+copies to or from the variables that have types that you have aligned
 this way.
 
 In the example above, if the size of each @code{short} is 2 bytes, then
 the size of the entire @code{struct S} type is 6 bytes.  The smallest
-power of two which is greater than or equal to that is 8, so the
+power of two that is greater than or equal to that is 8, so the
 compiler sets the alignment for the entire @code{struct S} type to 8
 bytes.
 
@@ -5206,10 +5589,10 @@ objects of that type, the compiler's ability to select a time-efficient
 alignment is primarily useful only when you plan to create arrays of
 variables having the relevant (efficiently aligned) type.  If you
 declare or use arrays of variables of an efficiently-aligned type, then
-it is likely that your program will also be doing pointer arithmetic (or
+it is likely that your program also does pointer arithmetic (or
 subscripting, which amounts to the same thing) on pointers to the
 relevant type, and the code that the compiler generates for these
-pointer arithmetic operations will often be more efficient for
+pointer arithmetic operations is often more efficient for
 efficiently-aligned types than for other types.
 
 The @code{aligned} attribute can only increase the alignment; but you
@@ -5220,13 +5603,13 @@ by inherent limitations in your linker.  On many systems, the linker is
 only able to arrange for variables to be aligned up to a certain maximum
 alignment.  (For some linkers, the maximum supported alignment may
 be very very small.)  If your linker is only able to align variables
-up to a maximum of 8 byte alignment, then specifying @code{aligned(16)}
-in an @code{__attribute__} will still only provide you with 8 byte
+up to a maximum of 8-byte alignment, then specifying @code{aligned(16)}
+in an @code{__attribute__} still only provides you with 8-byte
 alignment.  See your linker documentation for further information.
 
 @item packed
 This attribute, attached to @code{struct} or @code{union} type
-definition, specifies that each member (other than zero-width bitfields)
+definition, specifies that each member (other than zero-width bit-fields)
 of the structure or union is placed to minimize the memory required.  When
 attached to an @code{enum} definition, it indicates that the smallest
 integral type should be used.
@@ -5240,7 +5623,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} needs to
 be packed too.
 
 @smallexample
@@ -5259,7 +5642,7 @@ struct __attribute__ ((__packed__)) my_packed_struct
 @end smallexample
 
 You may only specify this attribute on the definition of an @code{enum},
-@code{struct} or @code{union}, not on a @code{typedef} which does not
+@code{struct} or @code{union}, not on a @code{typedef} that does not
 also define the enumerated type, structure or union.
 
 @item transparent_union
@@ -5285,7 +5668,7 @@ to work properly.
 Transparent unions are designed for library functions that have multiple
 interfaces for compatibility reasons.  For example, suppose the
 @code{wait} function must accept either a value of type @code{int *} to
-comply with Posix, or a value of type @code{union wait *} to comply with
+comply with POSIX, or a value of type @code{union wait *} to comply with
 the 4.1BSD interface.  If @code{wait}'s parameter were @code{void *},
 @code{wait} would accept both kinds of arguments, but it would also
 accept any other pointer type and this would make argument type checking
@@ -5302,6 +5685,7 @@ typedef union __attribute__ ((__transparent_union__))
 pid_t wait (wait_status_ptr_t);
 @end smallexample
 
+@noindent
 This interface allows either @code{int *} or @code{union wait *}
 arguments to be passed, using the @code{int *} calling convention.
 The program can call @code{wait} with arguments of either type:
@@ -5311,6 +5695,7 @@ int w1 () @{ int w; return wait (&w); @}
 int w2 () @{ union wait w; return wait (&w); @}
 @end smallexample
 
+@noindent
 With this interface, @code{wait}'s implementation might look like this:
 
 @smallexample
@@ -5323,7 +5708,7 @@ pid_t wait (wait_status_ptr_t p)
 @item unused
 When attached to a type (including a @code{union} or a @code{struct}),
 this attribute means that variables of that type are meant to appear
-possibly unused.  GCC will not produce a warning for any variables of
+possibly unused.  GCC does not produce a warning for any variables of
 that type, even if the variable appears to do nothing.  This is often
 the case with lock or thread classes, which are usually defined and then
 not referenced, but contain constructors and destructors that have
@@ -5350,11 +5735,12 @@ typedef T1 T3 __attribute__ ((deprecated));
 T3 z __attribute__ ((deprecated));
 @end smallexample
 
+@noindent
 results in a warning on line 2 and 3 but not lines 4, 5, or 6.  No
 warning is issued for line 4 because T2 is not explicitly
 deprecated.  Line 5 has no warning because T3 is explicitly
-deprecated.  Similarly for line 6.  The optional msg
-argument, which must be a string, will be printed in the warning if
+deprecated.  Similarly for line 6.  The optional @var{msg}
+argument, which must be a string, is printed in the warning if
 present.
 
 The @code{deprecated} attribute can also be used for functions and
@@ -5363,7 +5749,9 @@ variables (@pxref{Function Attributes}, @pxref{Variable Attributes}.)
 @item may_alias
 Accesses through pointers to types with this attribute are not subject
 to type-based alias analysis, but are instead assumed to be able to alias
-any other type of objects.  In the context of 6.5/7 an lvalue expression
+any other type of objects.
+In the context of section 6.5 paragraph 7 of the C99 standard,
+an lvalue expression
 dereferencing such a pointer is treated like having a character type.
 See @option{-fstrict-aliasing} for more information on aliasing issues.
 This extension exists to support some vector APIs, in which pointers to
@@ -5392,6 +5780,7 @@ main (void)
 @}
 @end smallexample
 
+@noindent
 If you replaced @code{short_a} with @code{short} in the variable
 declaration, the above program would abort when compiled with
 @option{-fstrict-aliasing}, which is on by default at @option{-O2} or
@@ -5407,11 +5796,15 @@ 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
+Otherwise the two shared objects are unable to use the same
 typeinfo node and exception handling will break.
 
 @end table
 
+To specify multiple attributes, separate them by commas within the
+double parentheses: for example, @samp{__attribute__ ((aligned (16),
+packed))}.
+
 @subsection ARM Type Attributes
 
 On those ARM targets that support @code{dllimport} (such as Symbian
@@ -5430,6 +5823,7 @@ __declspec(dllexport)
 C::C() @{@}
 @end smallexample
 
+@noindent
 In this code, @code{C::C} is exported from the current DLL, but the
 virtual table for @code{C} is not exported.  (You can use
 @code{__attribute__} instead of @code{__declspec} if you prefer, but
@@ -5458,7 +5852,7 @@ Two attributes are currently defined for i386 configurations:
 
 If @code{packed} is used on a structure, or if bit-fields are used
 it may be that the Microsoft ABI packs them differently
-than GCC would normally pack them.  Particularly when moving packed
+than GCC normally packs them.  Particularly when moving packed
 data between functions compiled with GCC and the native Microsoft compiler
 (either via function call or as data in a file), it may be necessary to access
 either format.
@@ -5467,10 +5861,6 @@ Currently @option{-m[no-]ms-bitfields} is provided for the Microsoft Windows X86
 compilers to match the native Microsoft compiler.
 @end table
 
-To specify multiple attributes, separate them by commas within the
-double parentheses: for example, @samp{__attribute__ ((aligned (16),
-packed))}.
-
 @anchor{PowerPC Type Attributes}
 @subsection PowerPC Type Attributes
 
@@ -5520,7 +5910,7 @@ designs, @code{__alignof__ (double)} is 4 or even 2.
 
 Some machines never actually require alignment; they allow reference to any
 data type even at an odd address.  For these machines, @code{__alignof__}
-reports the smallest alignment that GCC will give the data type, usually as
+reports the smallest alignment that GCC gives the data type, usually as
 mandated by the target ABI.
 
 If the operand of @code{__alignof__} is an lvalue rather than a type,
@@ -5616,12 +6006,12 @@ refers to its address, because that can't be inlined.
 
 @opindex Winline
 Note that certain usages in a function definition can make it unsuitable
-for inline substitution.  Among these usages are: use of varargs, use of
-alloca, use of variable sized data types (@pxref{Variable Length}),
+for inline substitution.  Among these usages are: variadic functions, use of
+@code{alloca}, use of variable-length data types (@pxref{Variable Length}),
 use of computed goto (@pxref{Labels as Values}), use of nonlocal goto,
 and nested functions (@pxref{Nested Functions}).  Using @option{-Winline}
-will warn when a function marked @code{inline} could not be substituted,
-and will give the reason for the failure.
+warns when a function marked @code{inline} could not be substituted,
+and gives the reason for the failure.
 
 @cindex automatic @code{inline} for C++ member fns
 @cindex @code{inline} automatic for C++ member fns
@@ -5662,8 +6052,8 @@ This combination of @code{inline} and @code{extern} has almost the
 effect of a macro.  The way to use it is to put a function definition in
 a header file with these keywords, and put another copy of the
 definition (lacking @code{inline} and @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 definition in the header file causes most calls to the function
+to be inlined.  If any uses of the function remain, they refer to
 the single copy in the library.
 
 @node Volatiles
@@ -5681,7 +6071,7 @@ implementation defined as to what constitutes a volatile access.  The
 minimum requirement is that at a sequence point all previous accesses
 to volatile objects have stabilized and no subsequent accesses have
 occurred.  Thus an implementation is free to reorder and combine
-volatile accesses which occur between sequence points, but cannot do
+volatile accesses that occur between sequence points, but cannot do
 so for accesses across a sequence point.  The use of volatile does
 not allow you to violate the restriction on updating objects multiple
 times between two sequence points.
@@ -5698,9 +6088,10 @@ volatile int vobj;
 vobj = 1;
 @end smallexample
 
+@noindent
 Unless @var{*ptr} and @var{vobj} can be aliased, it is not guaranteed
-that the write to @var{*ptr} will have occurred by the time the update
-of @var{vobj} has happened.  If you need this guarantee, you must use
+that the write to @var{*ptr} occurs by the time the update
+of @var{vobj} happens.  If you need this guarantee, you must use
 a stronger memory barrier such as:
 
 @smallexample
@@ -5741,11 +6132,11 @@ If you need to read the volatile object after an assignment has
 occurred, you must use a separate expression with an intervening
 sequence point.
 
-As bitfields are not individually addressable, volatile bitfields may
-be implicitly read when written to, or when adjacent bitfields are
-accessed.  Bitfield operations may be optimized such that adjacent
-bitfields are only partially accessed, if they straddle a storage unit
-boundary.  For these reasons it is unwise to use volatile bitfields to
+As bit-fields are not individually addressable, volatile bit-fields may
+be implicitly read when written to, or when adjacent bit-fields are
+accessed.  Bit-field operations may be optimized such that adjacent
+bit-fields are only partially accessed, if they straddle a storage unit
+boundary.  For these reasons it is unwise to use volatile bit-fields to
 access hardware.
 
 @node Extended Asm
@@ -5757,7 +6148,7 @@ access hardware.
 
 In an assembler instruction using @code{asm}, you can specify the
 operands of the instruction using C expressions.  This means you need not
-guess which registers or memory locations will contain the data you want
+guess which registers or memory locations contain the data you want
 to use.
 
 You must specify an assembler instruction template much like what
@@ -5773,7 +6164,7 @@ asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
 @noindent
 Here @code{angle} is the C expression for the input operand while
 @code{result} is that of the output operand.  Each has @samp{"f"} as its
-operand constraint, saying that a floating point register is required.
+operand constraint, saying that a floating-point register is required.
 The @samp{=} in @samp{=f} indicates that the operand is an output; all
 output operands' constraints must use @samp{=}.  The constraints use the
 same language used in the machine description (@pxref{Constraints}).
@@ -5819,22 +6210,19 @@ assembler input.  The extended @code{asm} feature is most often used for
 machine instructions the compiler itself does not know exist.  If
 the output expression cannot be directly addressed (for example, it is a
 bit-field), your constraint must allow a register.  In that case, GCC
-will use the register as the output of the @code{asm}, and then store
+uses the register as the output of the @code{asm}, and then stores
 that register into the output.
 
-The ordinary output operands must be write-only; GCC will assume that
+The ordinary output operands must be write-only; GCC assumes that
 the values in these operands before the instruction are dead and need
 not be generated.  Extended asm supports input-output or read-write
 operands.  Use the constraint character @samp{+} to indicate such an
-operand and list it with the output operands.  You should only use
-read-write operands when the constraints for the operand (or the
-operand in which only some of the bits are to be changed) allow a
-register.
+operand and list it with the output operands.
 
 You may, as an alternative, logically split its function into two
 separate operands, one input operand and one write-only output
 operand.  The connection between them is expressed by constraints
-which say they need to be in the same location when the instruction
+that say they need to be in the same location when the instruction
 executes.  You can use the same C expression for both operands, or
 different expressions.  For example, here we write the (fictitious)
 @samp{combine} instruction with @code{bar} as its read-only source
@@ -5849,10 +6237,10 @@ The constraint @samp{"0"} for operand 1 says that it must occupy the
 same location as operand 0.  A number in constraint is allowed only in
 an input operand and it must refer to an output operand.
 
-Only a number in the constraint can guarantee that one operand will be in
+Only a number in the constraint can guarantee that one operand is in
 the same place as another.  The mere fact that @code{foo} is the value
-of both operands is not enough to guarantee that they will be in the
-same place in the generated assembler code.  The following would not
+of both operands is not enough to guarantee that they are in the
+same place in the generated assembler code.  The following does not
 work reliably:
 
 @smallexample
@@ -5930,12 +6318,12 @@ have no part mentioned in the clobber description.
 There is no way for you to specify that an input
 operand is modified without also specifying it as an output
 operand.  Note that if all the output operands you specify are for this
-purpose (and hence unused), you will then also need to specify
+purpose (and hence unused), you then also need to specify
 @code{volatile} for the @code{asm} construct, as described below, to
 prevent GCC from deleting the @code{asm} statement as unused.
 
 If you refer to a particular hardware register from the assembler code,
-you will probably have to list the register after the third colon to
+you probably have to list the register after the third colon to
 tell the compiler the register's value is modified.  In some assemblers,
 the register names begin with @samp{%}; to produce one @samp{%} in the
 assembler code, you must write @samp{%%} in the input.
@@ -5949,9 +6337,9 @@ effect.  But it is valid no matter what the machine.
 
 If your assembler instructions access memory in an unpredictable
 fashion, add @samp{memory} to the list of clobbered registers.  This
-will cause GCC to not keep memory values cached in registers across the
+causes GCC to not keep memory values cached in registers across the
 assembler instruction and not optimize stores or loads to that memory.
-You will also want to add the @code{volatile} keyword if the memory
+You also should add the @code{volatile} keyword if the memory
 affected is not listed in the inputs or outputs of the @code{asm}, as
 the @samp{memory} clobber does not count as a side-effect of the
 @code{asm}.  If you know how large the accessed memory is, you can add
@@ -5972,7 +6360,7 @@ int foo ()
   int *y = &x;
   int result;
   asm ("magic stuff accessing an 'int' pointed to by '%1'"
-        "=&d" (r) : "a" (y), "m" (*y));
+       : "=&d" (result) : "a" (y), "m" (*y));
   return result;
 @}
 @end smallexample
@@ -5985,7 +6373,7 @@ to break the line, plus a tab character to move to the instruction field
 assembler allows semicolons as a line-breaking character.  Note that some
 assembler dialects use semicolons to start a comment.
 The input operands are guaranteed not to use any of the clobbered
-registers, and neither will the output operands' addresses, so you can
+registers, and neither do the output operands' addresses, so you can
 read and write the clobbered registers as many times as you like.  Here
 is an example of multiple instructions in a template; it assumes the
 subroutine @code{_foo} accepts arguments in registers 9 and 10:
@@ -6037,14 +6425,14 @@ encapsulate them in macros that look like functions.  For example,
 @noindent
 Here the variable @code{__arg} is used to make sure that the instruction
 operates on a proper @code{double} value, and to accept only those
-arguments @code{x} which can convert automatically to a @code{double}.
+arguments @code{x} that can convert automatically to a @code{double}.
 
 Another way to make sure the instruction operates on the correct data
 type is to use a cast in the @code{asm}.  This is different from using a
 variable @code{__arg} in that it converts more different types.  For
-example, if the desired type were @code{int}, casting the argument to
-@code{int} would accept a pointer with no complaint, while assigning the
-argument to an @code{int} variable named @code{__arg} would warn about
+example, if the desired type is @code{int}, casting the argument to
+@code{int} accepts a pointer with no complaint, while assigning the
+argument to an @code{int} variable named @code{__arg} warns about
 using a pointer unless the caller explicitly casts it.
 
 If an @code{asm} has output operands, GCC assumes for optimization
@@ -6071,14 +6459,14 @@ the @code{asm}.  For example:
 
 @noindent
 The @code{volatile} keyword indicates that the instruction has
-important side-effects.  GCC will not delete a volatile @code{asm} if
+important side-effects.  GCC does 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
+prove that control flow never reaches the location of the
 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
+register that 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
@@ -6087,7 +6475,7 @@ setting it with a volatile @code{asm}, like this PowerPC example:
 @end smallexample
 
 @noindent
-This will not work reliably, as the compiler may move the addition back
+This does 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:
@@ -6100,19 +6488,19 @@ you don't want moved, for example:
 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}
+Also, GCC performs 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
+An @code{asm} instruction without any output operands is 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
 implement this, we found no way to make it work reliably.  The problem
-is that output operands might need reloading, which would result in
+is that output operands might need reloading, which result in
 additional following ``store'' instructions.  On most machines, these
-instructions would alter the condition code before there was time to
+instructions alter the condition code before there is time to
 test it.  This problem doesn't arise for ordinary ``test'' and
 ``compare'' instructions because they don't have any output operands.
 
@@ -6130,7 +6518,7 @@ to fall through to the next statement.
 This form of @code{asm} is restricted to not have outputs.  This is due
 to a internal restriction in the compiler that control transfer instructions
 cannot have outputs.  This restriction on @code{asm goto} may be lifted
-in some future version of the compiler.  In the mean time, @code{asm goto}
+in some future version of the compiler.  In the meantime, @code{asm goto}
 may include a memory clobber, and so leave outputs in memory.
 
 @smallexample
@@ -6145,6 +6533,7 @@ int frob(int x)
 @}
 @end smallexample
 
+@noindent
 In this (inefficient) example, the @code{frob} instruction sets the
 carry bit to indicate an error.  The @code{jc} instruction detects
 this and branches to the @code{error} label.  Finally, the output
@@ -6175,6 +6564,7 @@ void doit(void)
 @}
 @end smallexample
 
+@noindent
 In this (also inefficient) example, the @code{mfsr} instruction reads
 an address from some out-of-band machine register, and the following
 @code{jmp} instruction branches to that address.  The address read by
@@ -6197,15 +6587,16 @@ does not in fact fall through.
 #define TRACE  TRACE1(__COUNTER__)
 @end smallexample
 
+@noindent
 In this example (which in fact inspired the @code{asm goto} feature)
 we want on rare occasions to call the @code{trace} function; on other
 occasions we'd like to keep the overhead to the absolute minimum.
 The normal code path consists of a single @code{nop} instruction.
 However, we record the address of this @code{nop} together with the
 address of a label that calls the @code{trace} function.  This allows
-the @code{nop} instruction to be patched at runtime to be an
+the @code{nop} instruction to be patched at run time to be an
 unconditional branch to the stored label.  It is assumed that an
-optimizing compiler will move the labeled block out of line, to
+optimizing compiler moves the labeled block out of line, to
 optimize the fall through path from the @code{asm}.
 
 If you are writing a header file that should be includable in ISO C
@@ -6222,60 +6613,62 @@ statements in the pattern of the @code{asm} and multiplying that by the
 length of the longest instruction on that processor.  Statements in the
 @code{asm} are identified by newline characters and whatever statement
 separator characters are supported by the assembler; on most processors
-this is the `@code{;}' character.
+this is the @samp{;} character.
 
 Normally, GCC's estimate is perfectly adequate to ensure that correct
 code is generated, but it is possible to confuse the compiler if you use
 pseudo instructions or assembler macros that expand into multiple real
 instructions or if you use assembler directives that expand to more
-space in the object file than would be needed for a single instruction.
-If this happens then the assembler will produce a diagnostic saying that
+space in the object file than is needed for a single instruction.
+If this happens then the assembler produces a diagnostic saying that
 a label is unreachable.
 
-@subsection i386 floating point asm operands
+@subsection i386 floating-point asm operands
 
-There are several rules on the usage of stack-like regs in
-asm_operands insns.  These rules apply only to the operands that are
-stack-like regs:
+On i386 targets, there are several rules on the usage of stack-like registers
+in the operands of an @code{asm}.  These rules apply only to the operands
+that are stack-like registers:
 
 @enumerate
 @item
-Given a set of input regs that die in an asm_operands, it is
-necessary to know which are implicitly popped by the asm, and
-which must be explicitly popped by gcc.
+Given a set of input registers that die in an @code{asm}, it is
+necessary to know which are implicitly popped by the @code{asm}, and
+which must be explicitly popped by GCC@.
 
-An input reg that is implicitly popped by the asm must be
+An input register that is implicitly popped by the @code{asm} must be
 explicitly clobbered, unless it is constrained to match an
 output operand.
 
 @item
-For any input reg that is implicitly popped by an asm, it is
+For any input register that is implicitly popped by an @code{asm}, it is
 necessary to know how to adjust the stack to compensate for the pop.
 If any non-popped input is closer to the top of the reg-stack than
-the implicitly popped reg, it would not be possible to know what the
+the implicitly popped register, it would not be possible to know what the
 stack looked like---it's not clear how the rest of the stack ``slides
 up''.
 
-All implicitly popped input regs must be closer to the top of
+All implicitly popped input registers must be closer to the top of
 the reg-stack than any input that is not implicitly popped.
 
-It is possible that if an input dies in an insn, reload might
-use the input reg for an output reload.  Consider this example:
+It is possible that if an input dies in an @code{asm}, the compiler might
+use the input register for an output reload.  Consider this example:
 
 @smallexample
 asm ("foo" : "=t" (a) : "f" (b));
 @end smallexample
 
-This asm says that input B is not popped by the asm, and that
-the asm pushes a result onto the reg-stack, i.e., the stack is one
-deeper after the asm than it was before.  But, it is possible that
-reload will think that it can use the same reg for both the input and
-the output, if input B dies in this insn.
+@noindent
+This code says that input @code{b} is not popped by the @code{asm}, and that
+the @code{asm} pushes a result onto the reg-stack, i.e., the stack is one
+deeper after the @code{asm} than it was before.  But, it is possible that
+reload may think that it can use the same register for both the input and
+the output.
 
-If any input operand uses the @code{f} constraint, all output reg
-constraints must use the @code{&} earlyclobber.
+To prevent this from happening,
+if any input operand uses the @code{f} constraint, all output register
+constraints must use the @code{&} early-clobber modifier.
 
-The asm above would be written as
+The example above would be correctly written as:
 
 @smallexample
 asm ("foo" : "=&t" (a) : "f" (b));
@@ -6283,40 +6676,42 @@ asm ("foo" : "=&t" (a) : "f" (b));
 
 @item
 Some operands need to be in particular places on the stack.  All
-output operands fall in this category---there is no other way to
-know which regs the outputs appear in unless the user indicates
+output operands fall in this category---GCC has no other way to
+know which registers the outputs appear in unless you indicate
 this in the constraints.
 
-Output operands must specifically indicate which reg an output
-appears in after an asm.  @code{=f} is not allowed: the operand
-constraints must select a class with a single reg.
+Output operands must specifically indicate which register an output
+appears in after an @code{asm}.  @code{=f} is not allowed: the operand
+constraints must select a class with a single register.
 
 @item
-Output operands may not be ``inserted'' between existing stack regs.
+Output operands may not be ``inserted'' between existing stack registers.
 Since no 387 opcode uses a read/write operand, all output operands
-are dead before the asm_operands, and are pushed by the asm_operands.
+are dead before the @code{asm}, and are pushed by the @code{asm}.
 It makes no sense to push anywhere but the top of the reg-stack.
 
 Output operands must start at the top of the reg-stack: output
-operands may not ``skip'' a reg.
+operands may not ``skip'' a register.
 
 @item
-Some asm statements may need extra stack space for internal
+Some @code{asm} statements may need extra stack space for internal
 calculations.  This can be guaranteed by clobbering stack registers
 unrelated to the inputs and outputs.
 
 @end enumerate
 
-Here are a couple of reasonable asms to want to write.  This asm
+Here are a couple of reasonable @code{asm}s to want to write.  This
+@code{asm}
 takes one input, which is internally popped, and produces two outputs.
 
 @smallexample
 asm ("fsincos" : "=t" (cos), "=u" (sin) : "0" (inp));
 @end smallexample
 
-This asm takes two inputs, which are popped by the @code{fyl2xp1} opcode,
-and replaces them with one output.  The user must code the @code{st(1)}
-clobber for reg-stack.c to know that @code{fyl2xp1} pops both inputs.
+@noindent
+This @code{asm} takes two inputs, which are popped by the @code{fyl2xp1} opcode,
+and replaces them with one output.  The @code{st(1)} clobber is necessary 
+for the compiler to know that @code{fyl2xp1} pops both inputs.
 
 @smallexample
 asm ("fyl2xp1" : "=t" (result) : "0" (x), "u" (y) : "st(1)");
@@ -6387,7 +6782,7 @@ register variable should be allocated.
 @item
 Global register variables reserve registers throughout the program.
 This may be useful in programs such as programming language
-interpreters which have a couple of global variables that are accessed
+interpreters that have a couple of global variables that are accessed
 very often.
 
 @item
@@ -6403,7 +6798,7 @@ to local register variables may be deleted or moved or simplified.
 These local variables are sometimes convenient for use with the extended
 @code{asm} feature (@pxref{Extended Asm}), if you want to write one
 output of the assembler instruction directly into a particular register.
-(This will work provided the register you specify fits the constraints
+(This works provided the register you specify fits the constraints
 specified for that operand in the @code{asm}.)
 @end itemize
 
@@ -6424,18 +6819,18 @@ register int *foo asm ("a5");
 @end smallexample
 
 @noindent
-Here @code{a5} is the name of the register which should be used.  Choose a
-register which is normally saved and restored by function calls on your
+Here @code{a5} is the name of the register that should be used.  Choose a
+register that is normally saved and restored by function calls on your
 machine, so that library routines will not clobber it.
 
-Naturally the register name is cpu-dependent, so you would need to
+Naturally the register name is cpu-dependent, so you need to
 conditionalize your program according to cpu type.  The register
-@code{a5} would be a good choice on a 68000 for a variable of pointer
+@code{a5} is a good choice on a 68000 for a variable of pointer
 type.  On machines with register windows, be sure to choose a ``global''
 register that is not affected magically by the function call mechanism.
 
-In addition, operating systems on one type of cpu may differ in how they
-name the registers; then you would need additional conditionals.  For
+In addition, different operating systems on the same CPU may differ in how they
+name the registers; then you need additional conditionals.  For
 example, some 68000 operating systems call this register @code{%a5}.
 
 Eventually there may be a way of asking the compiler to choose a register
@@ -6444,10 +6839,10 @@ how to enable you to guide the choice.  No solution is evident.
 
 Defining a global register variable in a certain register reserves that
 register entirely for this use, at least within the current compilation.
-The register will not be allocated for any other purpose in the functions
-in the current compilation.  The register will not be saved and restored by
+The register is not allocated for any other purpose in the functions
+in the current compilation, and is not saved and restored by
 these functions.  Stores into this register are never deleted even if they
-would appear to be dead, but references may be deleted or moved or
+appear to be dead, but references may be deleted or moved or
 simplified.
 
 It is not safe to access the global register variables from signal
@@ -6458,8 +6853,8 @@ you recompile them specially for the task at hand).
 @cindex @code{qsort}, and global register variables
 It is not safe for one function that uses a global register variable to
 call another such function @code{foo} by way of a third function
-@code{lose} that was compiled without knowledge of this variable (i.e.@: in a
-different source file in which the variable wasn't declared).  This is
+@code{lose} that is compiled without knowledge of this variable (i.e.@: in a
+different source file in which the variable isn't declared).  This is
 because @code{lose} might save the register and put some other value there.
 For example, you can't expect a global register variable to be available in
 the comparison-function that you pass to @code{qsort}, since @code{qsort}
@@ -6467,31 +6862,31 @@ might have put something else in that register.  (If you are prepared to
 recompile @code{qsort} with the same global register variable, you can
 solve this problem.)
 
-If you want to recompile @code{qsort} or other source files which do not
-actually use your global register variable, so that they will not use that
+If you want to recompile @code{qsort} or other source files that do not
+actually use your global register variable, so that they do not use that
 register for any other purpose, then it suffices to specify the compiler
 option @option{-ffixed-@var{reg}}.  You need not actually add a global
 register declaration to their source code.
 
-A function which can alter the value of a global register variable cannot
+A function that can alter the value of a global register variable cannot
 safely be called from a function compiled without this variable, because it
 could clobber the value the caller expects to find there on return.
-Therefore, the function which is the entry point into the part of the
+Therefore, the function that is the entry point into the part of the
 program that uses the global register variable must explicitly save and
-restore the value which belongs to its caller.
+restore the value that belongs to its caller.
 
 @cindex register variable after @code{longjmp}
 @cindex global register after @code{longjmp}
 @cindex value after @code{longjmp}
 @findex longjmp
 @findex setjmp
-On most machines, @code{longjmp} will restore to each global register
+On most machines, @code{longjmp} restores to each global register
 variable the value it had at the time of the @code{setjmp}.  On some
-machines, however, @code{longjmp} will not change the value of global
+machines, however, @code{longjmp} does not change the value of global
 register variables.  To be portable, the function that called @code{setjmp}
 should make other arrangements to save the values of the global register
 variables, and to restore them in a @code{longjmp}.  This way, the same
-thing will happen regardless of what @code{longjmp} does.
+thing happens regardless of what @code{longjmp} does.
 
 All global register variable declarations must precede all function
 definitions.  If such a declaration could appear after function
@@ -6507,7 +6902,7 @@ as the subroutines for division and remainder, modify g3 and g4.  g1 and
 g2 are local temporaries.
 
 On the 68000, a2 @dots{} a5 should be suitable, as should d2 @dots{} d7.
-Of course, it will not do to use more than a few of those.
+Of course, it does not do to use more than a few of those.
 
 @node Local Reg Vars
 @subsection Specifying Registers for Local Variables
@@ -6523,9 +6918,9 @@ register int *foo asm ("a5");
 @end smallexample
 
 @noindent
-Here @code{a5} is the name of the register which should be used.  Note
+Here @code{a5} is the name of the register that should be used.  Note
 that this is the same syntax used for defining global register
-variables, but for a local variable it would appear within a function.
+variables, but for a local variable it appears within a function.
 
 Naturally the register name is cpu-dependent, but this is not a
 problem, since specific registers are most often useful with explicit
@@ -6534,18 +6929,18 @@ generally require that you conditionalize your program according to
 cpu type.
 
 In addition, operating systems on one type of cpu may differ in how they
-name the registers; then you would need additional conditionals.  For
+name the registers; then you need additional conditionals.  For
 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.
 
-This option does not guarantee that GCC will generate code that has
+This option does not guarantee that GCC generates code that has
 this variable in the register you specify at all times.  You may not
 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
+instruction template} part of an @code{asm} statement and assume it
+always refers to this variable.  However, using the variable as an
 @code{asm} @emph{operand} guarantees that the specified register is used
 for the operand.
 
@@ -6554,16 +6949,18 @@ 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
+register that 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
+arithmetic operator overwrites 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
+
+@noindent
 In those cases, a solution is to use a temporary variable for
 each arbitrary expression.   @xref{Example of asm with clobbered asm reg}.
 
@@ -6613,7 +7010,7 @@ effect aside from this.
 You can define an @code{enum} tag without specifying its possible values.
 This results in an incomplete type, much like what you get if you write
 @code{struct foo} without describing the elements.  A later declaration
-which does specify the possible values completes the type.
+that does specify the possible values completes the type.
 
 You can't allocate variables or storage using the type while it is
 incomplete.  However, you can work with pointers to that type.
@@ -6630,7 +7027,7 @@ This extension is not supported by GNU C++.
 @cindex @code{__FUNCTION__} identifier
 @cindex @code{__PRETTY_FUNCTION__} identifier
 
-GCC provides three magic variables which hold the name of the current
+GCC provides three magic variables that hold the name of the current
 function, as a string.  The first of these is @code{__func__}, which
 is part of the C99 standard:
 
@@ -6718,26 +7115,26 @@ 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
-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 expected behavior is that the function returns the address of
+the function that is returned to.  To work around this behavior use
 the @code{noinline} function attribute.
 
 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
+of the stack has been reached, this function returns @code{0} or a
 random value.  In addition, @code{__builtin_frame_address} may be used
 to determine if the top of the stack has been reached.
 
 Additional post-processing of the returned value may be needed, see
-@code{__builtin_extract_return_address}.
+@code{__builtin_extract_return_addr}.
 
 This function should only be used with a nonzero argument for debugging
 purposes.
 @end deftypefn
 
-@deftypefn {Built-in Function} {void *} __builtin_extract_return_address (void *@var{addr})
+@deftypefn {Built-in Function} {void *} __builtin_extract_return_addr (void *@var{addr})
 The address as returned by @code{__builtin_return_address} may have to be fed
 through this function to get the actual encoded address.  For example, on the
 31-bit S/390 platform the highest bit has to be masked out, or on SPARC
@@ -6748,7 +7145,7 @@ If no fixup is needed, this function simply passes through @var{addr}.
 @end deftypefn
 
 @deftypefn {Built-in Function} {void *} __builtin_frob_return_address (void *@var{addr})
-This function does the reverse of @code{__builtin_extract_return_address}.
+This function does the reverse of @code{__builtin_extract_return_addr}.
 @end deftypefn
 
 @deftypefn {Built-in Function} {void *} __builtin_frame_address (unsigned int @var{level})
@@ -6759,17 +7156,17 @@ of the function.  Calling @code{__builtin_frame_address} with a value of
 @code{1} yields the frame address of the caller of the current function,
 and so forth.
 
-The frame is the area on the stack which holds local variables and saved
+The frame is the area on the stack that holds local variables and saved
 registers.  The frame address is normally the address of the first word
 pushed on to the stack by the function.  However, the exact definition
 depends upon the processor and the calling convention.  If the processor
 has a dedicated frame pointer register, and the function has a frame,
-then @code{__builtin_frame_address} will return the value of the frame
+then @code{__builtin_frame_address} returns the value of the frame
 pointer register.
 
 On some machines it may be impossible to determine the frame 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} if
+of the stack has been reached, this function returns @code{0} if
 the first frame pointer is properly initialized by the startup code.
 
 This function should only be used with a nonzero argument for debugging
@@ -6777,9 +7174,9 @@ purposes.
 @end deftypefn
 
 @node Vector Extensions
-@section Using vector instructions through built-in functions
+@section Using Vector Instructions through Built-in Functions
 
-On some targets, the instruction set contains SIMD vector instructions that
+On some targets, the instruction set contains SIMD vector instructions which
 operate on multiple values contained in one large register at the same time.
 For example, on the i386 the MMX, 3DNow!@: and SSE extensions can be used
 this way.
@@ -6791,16 +7188,18 @@ types.  This should be done using an appropriate @code{typedef}:
 typedef int v4si __attribute__ ((vector_size (16)));
 @end smallexample
 
+@noindent
 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}.
+corresponding mode of @code{foo} is @acronym{V4SI}.
 
 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.
+are allowed in conjunction with this construct. Only sizes that are
+a power of two are currently allowed.
 
 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},
@@ -6808,20 +7207,20 @@ and as unsigned: @code{char}, @code{short}, @code{int}, @code{long},
 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.
+causes GCC to synthesize the instructions using a narrower mode.
 For example, if you specify a variable of type @code{V4SI} and your
-architecture does not allow for this specific SIMD type, GCC will
-produce code that uses 4 @code{SIs}.
+architecture does not allow for this specific SIMD type, GCC
+produces code that uses 4 @code{SIs}.
 
 The types defined in this manner can be used with a subset of normal C
-operations.  Currently, GCC will allow using the following operators
+operations.  Currently, GCC allows using the following operators
 on these types: @code{+, -, *, /, unary minus, ^, |, &, ~, %}@.
 
 The operations behave like C++ @code{valarrays}.  Addition is defined as
 the addition of the corresponding elements of the operands.  For
-example, in the code below, each of the 4 elements in @var{a} will be
+example, in the code below, each of the 4 elements in @var{a} is
 added to the corresponding 4 elements in @var{b} and the resulting
-vector will be stored in @var{c}.
+vector is stored in @var{c}.
 
 @smallexample
 typedef int v4si __attribute__ ((vector_size (16)));
@@ -6837,16 +7236,16 @@ minus or complement operators on a vector type is a vector whose
 elements are the negative or complemented values of the corresponding
 elements in the operand.
 
-In C it is possible to use shifting operators @code{<<}, @code{>>} on
+It is possible to use shifting operators @code{<<}, @code{>>} on
 integer-type vectors. The operation is defined as following: @code{@{a0,
 a1, @dots{}, an@} >> @{b0, b1, @dots{}, bn@} == @{a0 >> b0, a1 >> b1,
 @dots{}, an >> bn@}}@. Vector operands must have the same number of
 elements. 
 
-For the convenience in C it is allowed to use a binary vector operation
-where one operand is a scalar. In that case the compiler will transform
+For convenience, it is allowed to use a binary vector operation
+where one operand is a scalar. In that case the compiler transforms
 the scalar operand into a vector where each element is the scalar from
-the operation. The transformation will happen only if the scalar could be
+the operation. The transformation happens only if the scalar could be
 safely converted to the vector-element type.
 Consider the following code.
 
@@ -6862,13 +7261,13 @@ a = 2 * b;    /* a = @{2,2,2,2@} * b; */
 a = l + a;    /* Error, cannot convert long to int. */
 @end smallexample
 
-In C vectors can be subscripted as if the vector were an array with
+Vectors can be subscripted as if the vector were an array with
 the same number of elements and base type.  Out of bound accesses
-invoke undefined behavior at runtime.  Warnings for out of bound
+invoke undefined behavior at run time.  Warnings for out of bound
 accesses for vector subscription can be enabled with
 @option{-Warray-bounds}.
 
-In GNU C vector comparison is supported within standard comparison
+Vector comparison is supported with standard comparison
 operators: @code{==, !=, <, <=, >, >=}. Comparison operands can be
 vector expressions of integer-type or real-type. Comparison between
 integer-type vectors and real-type vectors are not supported.  The
@@ -6891,6 +7290,19 @@ c = a >  b;     /* The result would be @{0, 0,-1, 0@}  */
 c = a == b;     /* The result would be @{0,-1, 0,-1@}  */
 @end smallexample
 
+In C++, the ternary operator @code{?:} is available. @code{a?b:c}, where
+@code{b} and @code{c} are vectors of the same type and @code{a} is an
+integer vector with the same number of elements of the same size as @code{b}
+and @code{c}, computes all three arguments and creates a vector
+@code{@{a[0]?b[0]:c[0], a[1]?b[1]:c[1], @dots{}@}}.  Note that unlike in
+OpenCL, @code{a} is thus interpreted as @code{a != 0} and not @code{a < 0}.
+As in the case of binary operations, this syntax is also accepted when
+one of @code{b} or @code{c} is a scalar that is then transformed into a
+vector. If both @code{b} and @code{c} are scalars and the type of
+@code{true?b:c} has the same size as the element type of @code{a}, then
+@code{b} and @code{c} are converted to a vector type whose elements have
+this type and with the same number of elements as @code{a}.
+
 Vector shuffling is available using functions
 @code{__builtin_shuffle (vec, mask)} and
 @code{__builtin_shuffle (vec0, vec1, mask)}.
@@ -6955,37 +7367,41 @@ This extension is sufficient such that
 #define offsetof(@var{type}, @var{member})  __builtin_offsetof (@var{type}, @var{member})
 @end smallexample
 
+@noindent
 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 __sync Builtins
-@section Legacy __sync built-in functions for atomic memory access
+@section Legacy __sync Built-in Functions for Atomic Memory Access
 
-The following builtins are intended to be compatible with those described
+The following built-in functions
+are intended to be compatible with those described
 in the @cite{Intel Itanium Processor-specific Application Binary Interface},
 section 7.4.  As such, they depart from the normal GCC practice of using
-the ``__builtin_'' prefix, and further that they are overloaded such that
+the @samp{__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
+counterparts.  GCC allows 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
+operation cannot be implemented on the target processor, a warning is
+generated and a call an external function is generated.  The external
+function carries the same name as the built-in version,
+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
+In most cases, these built-in functions are considered a @dfn{full barrier}.
+That is,
+no memory operand is moved across the operation, either forward or
+backward.  Further, instructions are issued as necessary to prevent the
 processor from speculating loads across the operation and from queuing stores
 after the operation.
 
@@ -6994,7 +7410,7 @@ All of the routines are described in the Intel documentation to take
 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
+protects all variables that are globally accessible.  If in the future
 we make some use of this list, an empty list will continue to mean all
 globally accessible variables.
 
@@ -7011,7 +7427,7 @@ globally accessible variables.
 @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
+These built-in functions perform the operation suggested by the name, and
 returns the value that had previously been in memory.  That is,
 
 @smallexample
@@ -7020,7 +7436,7 @@ returns the value that had previously been in memory.  That is,
 @end smallexample
 
 @emph{Note:} GCC 4.4 and later implement @code{__sync_fetch_and_nand}
-builtin as @code{*ptr = ~(tmp & value)} instead of @code{*ptr = ~tmp & value}.
+as @code{*ptr = ~(tmp & value)} instead of @code{*ptr = ~tmp & value}.
 
 @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, ...)
@@ -7034,7 +7450,7 @@ builtin as @code{*ptr = ~(tmp & value)} instead of @code{*ptr = ~tmp & value}.
 @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
+These built-in functions perform the operation suggested by the name, and
 return the new value.  That is,
 
 @smallexample
@@ -7043,28 +7459,29 @@ return the new value.  That is,
 @end smallexample
 
 @emph{Note:} GCC 4.4 and later implement @code{__sync_nand_and_fetch}
-builtin as @code{*ptr = ~(*ptr & value)} instead of
+as @code{*ptr = ~(*ptr & value)} instead of
 @code{*ptr = ~*ptr & value}.
 
 @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
+These built-in functions 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
+@var{newval} is 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.
+This built-in function 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
+This built-in function, 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}}.
@@ -7075,18 +7492,21 @@ 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
+This built-in function is not a full barrier,
+but rather an @dfn{acquire barrier}.
+This means that references after the operation cannot move to (or be
+speculated to) before the operation, 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}.
+This built-in function 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 built-in function 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.
@@ -7101,38 +7521,39 @@ functions, but all also have a memory model parameter.  These are all
 identified by being prefixed with @samp{__atomic}, and most are overloaded
 such that they work with multiple types.
 
-GCC will allow any integral scalar or pointer type that is 1, 2, 4, or 8
+GCC allows any integral scalar or pointer type that is 1, 2, 4, or 8
 bytes in length. 16-byte integral types are also allowed if
 @samp{__int128} (@pxref{__int128}) is supported by the architecture.
 
 Target architectures are encouraged to provide their own patterns for
 each of these built-in functions.  If no target is provided, the original 
-non-memory model set of @samp{__sync} atomic built-in functions will be
+non-memory model set of @samp{__sync} atomic built-in functions are
 utilized, along with any required synchronization fences surrounding it in
-order to achieve the proper behaviour.  Execution in this case is subject
+order to achieve the proper behavior.  Execution in this case is subject
 to the same restrictions as those built-in functions.
 
 If there is no pattern or mechanism to provide a lock free instruction
 sequence, a call is made to an external routine with the same parameters
-to be resolved at runtime.
+to be resolved at run time.
 
 The four non-arithmetic functions (load, store, exchange, and 
 compare_exchange) all have a generic version as well.  This generic
-version will work on any data type.  If the data type size maps to one
-of the integral sizes which may have lock free support, the generic
-version will utilize the lock free built-in function.  Otherwise an
-external call is left to be resolved at runtime.  This external call will
-be the same format with the addition of a @samp{size_t} parameter inserted
+version works on any data type.  If the data type size maps to one
+of the integral sizes that may have lock free support, the generic
+version utilizes the lock free built-in function.  Otherwise an
+external call is left to be resolved at run time.  This external call is
+the same format with the addition of a @samp{size_t} parameter inserted
 as the first parameter indicating the size of the object being pointed to.
 All objects must be the same size.
 
-There are 6 different memory models which can be specified.  These map
+There are 6 different memory models that can be specified.  These map
 to the same names in the C++11 standard.  Refer there or to the
 @uref{http://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync,GCC wiki on
 atomic synchronization} for more detailed definitions.  These memory
 models integrate both barriers to code motion as well as synchronization
 requirements with other threads. These are listed in approximately
-ascending order of strength.
+ascending order of strength. It is also possible to use target specific
+flags for memory model flags, like Hardware Lock Elision.
 
 @table  @code
 @item __ATOMIC_RELAXED
@@ -7154,23 +7575,23 @@ Full barrier in both directions and synchronizes with acquire loads and
 release stores in all threads.
 @end table
 
-When implementing patterns for these built-in functions , the memory model
+When implementing patterns for these built-in functions, the memory model
 parameter can be ignored as long as the pattern implements the most
 restrictive @code{__ATOMIC_SEQ_CST} model.  Any of the other memory models
-will execute correctly with this memory model but they may not execute as
-efficiently as they could with a more appropriate implemention of the
+execute correctly with this memory model but they may not execute as
+efficiently as they could with a more appropriate implementation of the
 relaxed requirements.
 
 Note that the C++11 standard allows for the memory model parameter to be
-determined at runtime rather than at compile time.  These built-in
-functions will map any runtime value to @code{__ATOMIC_SEQ_CST} rather
+determined at run time rather than at compile time.  These built-in
+functions map any run-time value to @code{__ATOMIC_SEQ_CST} rather
 than invoke a runtime library call or inline a switch statement.  This is
 standard compliant, safe, and the simplest approach for now.
 
 The memory model parameter is a signed int, but only the lower 8 bits are
 reserved for the memory model.  The remainder of the signed int is reserved
-for future use and should be 0.  Use of the predefined atomic values will
-ensure proper usage.
+for future use and should be 0.  Use of the predefined atomic values
+ensures proper usage.
 
 @deftypefn {Built-in Function} @var{type} __atomic_load_n (@var{type} *ptr, int memmodel)
 This built-in function implements an atomic load operation.  It returns the
@@ -7183,7 +7604,7 @@ and @code{__ATOMIC_CONSUME}.
 @end deftypefn
 
 @deftypefn {Built-in Function} void __atomic_load (@var{type} *ptr, @var{type} *ret, int memmodel)
-This is the generic version of an atomic load.  It will return the
+This is the generic version of an atomic load.  It returns the
 contents of @code{*@var{ptr}} in @code{*@var{ret}}.
 
 @end deftypefn
@@ -7198,7 +7619,7 @@ The valid memory model variants are
 @end deftypefn
 
 @deftypefn {Built-in Function} void __atomic_store (@var{type} *ptr, @var{type} *val, int memmodel)
-This is the generic version of an atomic store.  It will store the value
+This is the generic version of an atomic store.  It stores the value
 of @code{*@var{val}} into @code{*@var{ptr}}.
 
 @end deftypefn
@@ -7215,9 +7636,9 @@ The valid memory model variants are
 @end deftypefn
 
 @deftypefn {Built-in Function} void __atomic_exchange (@var{type} *ptr, @var{type} *val, @var{type} *ret, int memmodel)
-This is the generic version of an atomic exchange.  It will store the
+This is the generic version of an atomic exchange.  It stores the
 contents of @code{*@var{val}} into @code{*@var{ptr}}. The original value
-of @code{*@var{ptr}} will be copied into @code{*@var{ret}}.
+of @code{*@var{ptr}} is copied into @code{*@var{ret}}.
 
 @end deftypefn
 
@@ -7289,8 +7710,10 @@ All memory models are valid.
 
 This built-in function performs an atomic test-and-set operation on
 the byte at @code{*@var{ptr}}.  The byte is set to some implementation
-defined non-zero "set" value and the return value is @code{true} if and only
-if the previous contents were "set".
+defined nonzero ``set'' value and the return value is @code{true} if and only
+if the previous contents were ``set''.
+It should be only used for operands of type @code{bool} or @code{char}. For 
+other types only part of the value may be set.
 
 All memory models are valid.
 
@@ -7299,7 +7722,11 @@ All memory models are valid.
 @deftypefn {Built-in Function} void __atomic_clear (bool *ptr, int memmodel)
 
 This built-in function performs an atomic clear operation on
-@code{*@var{ptr}}.  After the operation, @code{*@var{ptr}} will contain 0.
+@code{*@var{ptr}}.  After the operation, @code{*@var{ptr}} contains 0.
+It should be only used for operands of type @code{bool} or @code{char} and 
+in conjunction with @code{__atomic_test_and_set}.
+For other types it may only clear partially. If the type is not @code{bool}
+prefer using @code{__atomic_store}.
 
 The valid memory model variants are
 @code{__ATOMIC_RELAXED}, @code{__ATOMIC_SEQ_CST}, and
@@ -7327,11 +7754,12 @@ All memory orders are valid.
 
 @deftypefn {Built-in Function} bool __atomic_always_lock_free (size_t size,  void *ptr)
 
-This built-in function returns true if objects of @var{size} bytes will always
+This built-in function returns true if objects of @var{size} bytes always
 generate lock free atomic instructions for the target architecture.  
-@var{size} must resolve to a compile time constant and the result also resolves to compile time constant.
+@var{size} must resolve to a compile-time constant and the result also
+resolves to a compile-time constant.
 
-@var{ptr} is an optional pointer to the object which may be used to determine
+@var{ptr} is an optional pointer to the object that may be used to determine
 alignment.  A value of 0 indicates typical alignment should be used.  The 
 compiler may also ignore this parameter.
 
@@ -7343,18 +7771,51 @@ if (_atomic_always_lock_free (sizeof (long long), 0))
 
 @deftypefn {Built-in Function} bool __atomic_is_lock_free (size_t size, void *ptr)
 
-This built-in function returns true if objects of @var{size} bytes will always
+This built-in function returns true if objects of @var{size} bytes always
 generate lock free atomic instructions for the target architecture.  If
 it is not known to be lock free a call is made to a runtime routine named
 @code{__atomic_is_lock_free}.
 
-@var{ptr} is an optional pointer to the object which may be used to determine
+@var{ptr} is an optional pointer to the object that may be used to determine
 alignment.  A value of 0 indicates typical alignment should be used.  The 
 compiler may also ignore this parameter.
 @end deftypefn
 
+@node x86 specific memory model extensions for transactional memory
+@section x86 specific memory model extensions for transactional memory
+
+The i386 architecture supports additional memory ordering flags
+to mark lock critical sections for hardware lock elision. 
+These must be specified in addition to an existing memory model to 
+atomic intrinsics.
+
+@table @code
+@item __ATOMIC_HLE_ACQUIRE
+Start lock elision on a lock variable.
+Memory model must be @code{__ATOMIC_ACQUIRE} or stronger.
+@item __ATOMIC_HLE_RELEASE
+End lock elision on a lock variable.
+Memory model must be @code{__ATOMIC_RELEASE} or stronger.
+@end table
+
+When a lock acquire fails it is required for good performance to abort
+the transaction quickly. This can be done with a @code{_mm_pause}
+
+@smallexample
+#include <immintrin.h> // For _mm_pause
+
+int lockvar;
+
+/* Acquire lock with lock elision */
+while (__atomic_exchange_n(&lockvar, 1, __ATOMIC_ACQUIRE|__ATOMIC_HLE_ACQUIRE))
+    _mm_pause(); /* Abort failed transaction */
+...
+/* Free lock with lock elision */
+__atomic_store_n(&lockvar, 0, __ATOMIC_RELEASE|__ATOMIC_HLE_RELEASE);
+@end smallexample
+
 @node Object Size Checking
-@section Object Size Checking Builtins
+@section Object Size Checking Built-in Functions
 @findex __builtin_object_size
 @findex __builtin___memcpy_chk
 @findex __builtin___mempcpy_chk
@@ -7425,7 +7886,7 @@ 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.
+The intended use can be e.g.@:
 
 @smallexample
 #undef memcpy
@@ -7443,11 +7904,11 @@ memcpy (p, "abcde", n);
 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.  */
+   at run time.  */
 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.  */
+   will abort the program at run time.  */
 memcpy (&buf[6], "abcde", 5);
 @end smallexample
 
@@ -7483,11 +7944,37 @@ In addition to this, there are checking built-in functions
 @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.
+@code{fputc} etc.@: functions, it does, otherwise the checking function
+is called and the @var{flag} argument passed to it.
+
+@node Cilk Plus Builtins
+@section Cilk Plus C/C++ language extension Built-in Functions.
+
+GCC provides support for the following built-in reduction funtions if Cilk Plus
+is enabled. Cilk Plus can be enabled using the @option{-fcilkplus} flag.
+
+@itemize @bullet
+@item __sec_implicit_index
+@item __sec_reduce
+@item __sec_reduce_add
+@item __sec_reduce_all_nonzero
+@item __sec_reduce_all_zero
+@item __sec_reduce_any_nonzero
+@item __sec_reduce_any_zero
+@item __sec_reduce_max
+@item __sec_reduce_min
+@item __sec_reduce_max_ind
+@item __sec_reduce_min_ind
+@item __sec_reduce_mul
+@item __sec_reduce_mutating
+@end itemize
+
+Further details and examples about these built-in functions are described 
+in the Cilk Plus language manual which can be found at 
+@uref{http://www.cilkplus.org}.
 
 @node Other Builtins
-@section Other built-in functions provided by GCC
+@section Other Built-in Functions Provided by GCC
 @cindex built-in functions
 @findex __builtin_fpclassify
 @findex __builtin_isfinite
@@ -7884,7 +8371,7 @@ should be called and the @var{flag} argument passed to it.
 
 GCC provides a large number of built-in functions other than the ones
 mentioned above.  Some of these are for internal use in the processing
-of exceptions or variable-length argument lists and will not be
+of exceptions or variable-length argument lists and are not
 documented here because they may change from time to time; we do not
 recommend general use of these functions.
 
@@ -7892,12 +8379,12 @@ The remaining functions are provided for optimization purposes.
 
 @opindex fno-builtin
 GCC includes built-in versions of many of the functions in the standard
-C library.  The versions prefixed with @code{__builtin_} will always be
+C library.  The versions prefixed with @code{__builtin_} are always
 treated as having the same meaning as the C library function even if you
 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.
+not optimized in a particular case, a call to the library function is
+emitted.
 
 @opindex ansi
 @opindex std
@@ -8014,7 +8501,7 @@ are all recognized as built-in functions unless
 is specified for an individual function).  All of these functions have
 corresponding versions prefixed with @code{__builtin_}.
 
-GCC provides built-in versions of the ISO C99 floating point comparison
+GCC provides built-in versions of the ISO C99 floating-point comparison
 macros that avoid raising exceptions for unordered operands.  They have
 the same names as the standard macros ( @code{isgreater},
 @code{isgreaterequal}, @code{isless}, @code{islessequal},
@@ -8024,7 +8511,7 @@ prefixed.  We intend for a library implementor to be able to simply
 In the same fashion, GCC provides @code{fpclassify}, @code{isfinite},
 @code{isinf_sign} and @code{isnormal} built-ins used with
 @code{__builtin_} prefixed.  The @code{isinf} and @code{isnan}
-builtins appear both with and without the @code{__builtin_} prefix.
+built-in functions appear both with and without the @code{__builtin_} prefix.
 
 @deftypefn {Built-in Function} int __builtin_types_compatible_p (@var{type1}, @var{type2})
 
@@ -8054,7 +8541,7 @@ type; this is what the C standard specifies.
 For example, @code{enum @{foo, bar@}} is not similar to
 @code{enum @{hot, dog@}}.
 
-You would typically use this function in code whose execution varies
+You typically use this function in code whose execution varies
 depending on the arguments' types.  For example:
 
 @smallexample
@@ -8087,7 +8574,7 @@ integer constant expression, is nonzero.  Otherwise it returns @var{exp2}.
 This built-in function is analogous to the @samp{? :} operator in C,
 except that the expression returned has its type unaltered by promotion
 rules.  Also, the built-in function does not evaluate the expression
-that was not chosen.  For example, if @var{const_exp} evaluates to true,
+that is not chosen.  For example, if @var{const_exp} evaluates to true,
 @var{exp2} is not evaluated even if it has side-effects.
 
 This built-in function can return an lvalue if the chosen argument is an
@@ -8133,7 +8620,7 @@ infinities, NaNs and negative zeros are involved.
 
 @deftypefn {Built-in Function} int __builtin_constant_p (@var{exp})
 You can use the built-in function @code{__builtin_constant_p} to
-determine if a value is known to be constant at compile-time and hence
+determine if a value is known to be constant at compile time and hence
 that GCC can perform constant-folding on expressions involving that
 value.  The argument of the function is the value to test.  The function
 returns the integer 1 if the argument is known to be a compile-time
@@ -8142,8 +8629,8 @@ return of 0 does not indicate that the value is @emph{not} a constant,
 but merely that GCC cannot prove it is a constant with the specified
 value of the @option{-O} option.
 
-You would typically use this function in an embedded application where
-memory was a critical resource.  If you have some complex calculation,
+You typically use this function in an embedded application where
+memory is a critical resource.  If you have some complex calculation,
 you may want it to be folded if it involves constants, but need to call
 a function if it does not.  For example:
 
@@ -8155,9 +8642,9 @@ a function if it does not.  For example:
 
 You may use this built-in function in either a macro or an inline
 function.  However, if you use it in an inlined function and pass an
-argument of the function as the argument to the built-in, GCC will
-never return 1 when you call the inline function with a string constant
-or compound literal (@pxref{Compound Literals}) and will not return 1
+argument of the function as the argument to the built-in, GCC 
+never returns 1 when you call the inline function with a string constant
+or compound literal (@pxref{Compound Literals}) and does not return 1
 when you pass a constant numeric value to the inline function unless you
 specify the @option{-O} option.
 
@@ -8175,8 +8662,8 @@ static const int table[] = @{
 This is an acceptable initializer even if @var{EXPRESSION} is not a
 constant expression, including the case where
 @code{__builtin_constant_p} returns 1 because @var{EXPRESSION} can be
-folded to a constant but @var{EXPRESSION} contains operands that would
-not otherwise be permitted in a static initializer (for example,
+folded to a constant but @var{EXPRESSION} contains operands that are
+not otherwise permitted in a static initializer (for example,
 @code{0 && foo ()}).  GCC must be more conservative about evaluating the
 built-in in this case, because it has no opportunity to perform
 optimization.
@@ -8205,7 +8692,7 @@ if (__builtin_expect (x, 0))
 @end smallexample
 
 @noindent
-would indicate that we do not expect to call @code{foo}, since
+indicates that we do not expect to call @code{foo}, since
 we expect @code{x} to be zero.  Since you are limited to integral
 expressions for @var{exp}, you should use constructions such as
 
@@ -8232,10 +8719,10 @@ the program is undefined.  It is useful in situations where the
 compiler cannot deduce the unreachability of the code.
 
 One such case is immediately following an @code{asm} statement that
-will either never terminate, or one that transfers control elsewhere
+either never terminates, or one that transfers control elsewhere
 and never returns.  In this example, without the
-@code{__builtin_unreachable}, GCC would issue a warning that control
-reaches the end of a non-void function.  It would also generate code
+@code{__builtin_unreachable}, GCC issues a warning that control
+reaches the end of a non-void function.  It also generates code
 to return after the @code{asm}.
 
 @smallexample
@@ -8253,8 +8740,9 @@ int f (int c, int v)
 @}
 @end smallexample
 
+@noindent
 Because the @code{asm} statement unconditionally transfers control out
-of the function, control will never reach the end of the function
+of the function, control never reaches the end of the function
 body.  The @code{__builtin_unreachable} is in fact unreachable and
 communicates this fact to the compiler.
 
@@ -8286,21 +8774,42 @@ This function returns its first argument, and allows the compiler
 to assume that the returned pointer is at least @var{align} bytes
 aligned.  This built-in can have either two or three arguments,
 if it has three, the third argument should have integer type, and
-if it is non-zero means misalignment offset.  For example:
+if it is nonzero means misalignment offset.  For example:
 
 @smallexample
 void *x = __builtin_assume_aligned (arg, 16);
 @end smallexample
 
-means that the compiler can assume x, set to arg, is at least
-16 byte aligned, while:
+@noindent
+means that the compiler can assume @code{x}, set to @code{arg}, is at least
+16-byte aligned, while:
 
 @smallexample
 void *x = __builtin_assume_aligned (arg, 32, 8);
 @end smallexample
 
-means that the compiler can assume for x, set to arg, that
-(char *) x - 8 is 32 byte aligned.
+@noindent
+means that the compiler can assume for @code{x}, set to @code{arg}, that
+@code{(char *) x - 8} is 32-byte aligned.
+@end deftypefn
+
+@deftypefn {Built-in Function} int __builtin_LINE ()
+This function is the equivalent to the preprocessor @code{__LINE__}
+macro and returns the line number of the invocation of the built-in.
+In a C++ default argument for a function @var{F}, it gets the line number of
+the call to @var{F}.
+@end deftypefn
+
+@deftypefn {Built-in Function} {const char *} __builtin_FUNCTION ()
+This function is the equivalent to the preprocessor @code{__FUNCTION__}
+macro and returns the function name the invocation of the built-in is in.
+@end deftypefn
+
+@deftypefn {Built-in Function} {const char *} __builtin_FILE ()
+This function is the equivalent to the preprocessor @code{__FILE__}
+macro and returns the file name the invocation of the built-in is in.
+In a C++ default argument for a function @var{F}, it gets the file name of
+the call to @var{F}.
 @end deftypefn
 
 @deftypefn {Built-in Function} void __builtin___clear_cache (char *@var{begin}, char *@var{end})
@@ -8321,7 +8830,7 @@ This function is used to minimize cache-miss latency by moving data into
 a cache before it is accessed.
 You can insert calls to @code{__builtin_prefetch} into code for which
 you know addresses of data in memory that is likely to be accessed soon.
-If the target supports them, data prefetch instructions will be generated.
+If the target supports them, data prefetch instructions are generated.
 If the prefetch is done early enough before the access then the data will
 be in the cache by the time it is accessed.
 
@@ -8350,8 +8859,8 @@ for (i = 0; i < n; i++)
 
 Data prefetch does not generate faults if @var{addr} is invalid, but
 the address expression itself must be valid.  For example, a prefetch
-of @code{p->next} will not fault if @code{p->next} is not a valid
-address, but evaluation will fault if @code{p} is not a valid address.
+of @code{p->next} does not fault if @code{p->next} is not a valid
+address, but evaluation faults if @code{p} is not a valid address.
 
 If the target does not support data prefetch, the address expression
 is evaluated if it includes side effects but no other code is generated
@@ -8379,7 +8888,7 @@ five int arguments should be the target library's notion of the
 possible FP classes and are used for return values.  They must be
 constant values and they must appear in this order: @code{FP_NAN},
 @code{FP_INFINITE}, @code{FP_NORMAL}, @code{FP_SUBNORMAL} and
-@code{FP_ZERO}.  The ellipsis is for exactly one floating point value
+@code{FP_ZERO}.  The ellipsis is for exactly one floating-point value
 to classify.  GCC treats the last argument as type-generic, which
 means it does not do default promotion from float to double.
 @end deftypefn
@@ -8412,9 +8921,10 @@ type is @code{long double}.
 @end deftypefn
 
 @deftypefn {Built-in Function} int __builtin_isinf_sign (...)
-Similar to @code{isinf}, except the return value will be negative for
-an argument of @code{-Inf}.  Note while the parameter list is an
-ellipsis, this function only accepts exactly one floating point
+Similar to @code{isinf}, except the return value is -1 for
+an argument of @code{-Inf} and 1 for an argument of @code{+Inf}.
+Note while the parameter list is an
+ellipsis, this function only accepts exactly one floating-point
 argument.  GCC treats this parameter as type-generic, which means it
 does not do default promotion from float to double.
 @end deftypefn
@@ -8432,7 +8942,7 @@ truncated to fit the significand field provided.  The significand is
 forced to be a quiet NaN@.
 
 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
+consumed by @code{strtol}, is evaluated early enough that it is considered a
 compile-time constant.
 @end deftypefn
 
@@ -8470,7 +8980,7 @@ Similar to @code{__builtin_nans}, except the return type is @code{float}.
 Similar to @code{__builtin_nans}, except the return type is @code{long double}.
 @end deftypefn
 
-@deftypefn {Built-in Function} int __builtin_ffs (unsigned int x)
+@deftypefn {Built-in Function} int __builtin_ffs (int x)
 Returns one plus the index of the least significant 1-bit of @var{x}, or
 if @var{x} is zero, returns zero.
 @end deftypefn
@@ -8486,8 +8996,8 @@ significant bit position.  If @var{x} is 0, the result is undefined.
 @end deftypefn
 
 @deftypefn {Built-in Function} int __builtin_clrsb (int x)
-Returns the number of leading redundant sign bits in @var{x}, i.e. the
-number of bits following the most significant bit which are identical
+Returns the number of leading redundant sign bits in @var{x}, i.e.@: the
+number of bits following the most significant bit that are identical
 to it.  There are no special cases for 0 or other values. 
 @end deftypefn
 
@@ -8500,9 +9010,9 @@ Returns the parity of @var{x}, i.e.@: the number of 1-bits in @var{x}
 modulo 2.
 @end deftypefn
 
-@deftypefn {Built-in Function} int __builtin_ffsl (unsigned long)
+@deftypefn {Built-in Function} int __builtin_ffsl (long)
 Similar to @code{__builtin_ffs}, except the argument type is
-@code{unsigned long}.
+@code{long}.
 @end deftypefn
 
 @deftypefn {Built-in Function} int __builtin_clzl (unsigned long)
@@ -8530,9 +9040,9 @@ Similar to @code{__builtin_parity}, except the argument type is
 @code{unsigned long}.
 @end deftypefn
 
-@deftypefn {Built-in Function} int __builtin_ffsll (unsigned long long)
+@deftypefn {Built-in Function} int __builtin_ffsll (long long)
 Similar to @code{__builtin_ffs}, except the argument type is
-@code{unsigned long long}.
+@code{long long}.
 @end deftypefn
 
 @deftypefn {Built-in Function} int __builtin_clzll (unsigned long long)
@@ -8575,15 +9085,20 @@ Similar to @code{__builtin_powi}, except the argument and return types
 are @code{long double}.
 @end deftypefn
 
-@deftypefn {Built-in Function} int32_t __builtin_bswap32 (int32_t x)
+@deftypefn {Built-in Function} uint16_t __builtin_bswap16 (uint16_t x)
 Returns @var{x} with the order of the bytes reversed; for example,
-@code{0xaabbccdd} becomes @code{0xddccbbaa}.  Byte here always means
+@code{0xaabb} becomes @code{0xbbaa}.  Byte here always means
 exactly 8 bits.
 @end deftypefn
 
-@deftypefn {Built-in Function} int64_t __builtin_bswap64 (int64_t x)
+@deftypefn {Built-in Function} uint32_t __builtin_bswap32 (uint32_t x)
+Similar to @code{__builtin_bswap16}, except the argument and return types
+are 32 bit.
+@end deftypefn
+
+@deftypefn {Built-in Function} uint64_t __builtin_bswap64 (uint64_t x)
 Similar to @code{__builtin_bswap32}, except the argument and return types
-are 64-bit.
+are 64 bit.
 @end deftypefn
 
 @node Target Builtins
@@ -8595,19 +9110,30 @@ instructions, but allow the compiler to schedule those calls.
 
 @menu
 * Alpha Built-in Functions::
+* Altera Nios II Built-in Functions::
+* ARC Built-in Functions::
+* ARC SIMD Built-in Functions::
 * ARM iWMMXt Built-in Functions::
 * ARM NEON Intrinsics::
+* ARM ACLE Intrinsics::
 * AVR Built-in Functions::
 * Blackfin Built-in Functions::
 * FR-V Built-in Functions::
 * X86 Built-in Functions::
+* X86 transactional memory intrinsics::
 * MIPS DSP Built-in Functions::
 * MIPS Paired-Single Support::
 * MIPS Loongson Built-in Functions::
 * Other MIPS Built-in Functions::
+* MSP430 Built-in Functions::
+* NDS32 Built-in Functions::
 * picoChip Built-in Functions::
+* PowerPC Built-in Functions::
 * PowerPC AltiVec/VSX Built-in Functions::
+* PowerPC Hardware Transactional Memory Built-in Functions::
 * RX Built-in Functions::
+* S/390 System z Built-in Functions::
+* SH Built-in Functions::
 * SPARC VIS Built-in Functions::
 * SPU Built-in Functions::
 * TI C6X Built-in Functions::
@@ -8687,7 +9213,7 @@ long __builtin_alpha_ctlz (long)
 long __builtin_alpha_ctpop (long)
 @end smallexample
 
-The following builtins are available on systems that use the OSF/1
+The following built-in functions are available on systems that use the OSF/1
 PALcode.  Normally they invoke the @code{rduniq} and @code{wruniq}
 PAL calls, but when invoked with @option{-mtls-kernel}, they invoke
 @code{rdval} and @code{wrval}.
@@ -8697,6 +9223,534 @@ void *__builtin_thread_pointer (void)
 void __builtin_set_thread_pointer (void *)
 @end smallexample
 
+@node Altera Nios II Built-in Functions
+@subsection Altera Nios II Built-in Functions
+
+These built-in functions are available for the Altera Nios II
+family of processors.
+
+The following built-in functions are always available.  They
+all generate the machine instruction that is part of the name.
+
+@example
+int __builtin_ldbio (volatile const void *)
+int __builtin_ldbuio (volatile const void *)
+int __builtin_ldhio (volatile const void *)
+int __builtin_ldhuio (volatile const void *)
+int __builtin_ldwio (volatile const void *)
+void __builtin_stbio (volatile void *, int)
+void __builtin_sthio (volatile void *, int)
+void __builtin_stwio (volatile void *, int)
+void __builtin_sync (void)
+int __builtin_rdctl (int) 
+void __builtin_wrctl (int, int)
+@end example
+
+The following built-in functions are always available.  They
+all generate a Nios II Custom Instruction. The name of the
+function represents the types that the function takes and
+returns. The letter before the @code{n} is the return type
+or void if absent. The @code{n} represents the first parameter
+to all the custom instructions, the custom instruction number.
+The two letters after the @code{n} represent the up to two
+parameters to the function.
+
+The letters represent the following data types:
+@table @code
+@item <no letter>
+@code{void} for return type and no parameter for parameter types.
+
+@item i
+@code{int} for return type and parameter type
+
+@item f
+@code{float} for return type and parameter type
+
+@item p
+@code{void *} for return type and parameter type
+
+@end table
+
+And the function names are:
+@example
+void __builtin_custom_n (void)
+void __builtin_custom_ni (int)
+void __builtin_custom_nf (float)
+void __builtin_custom_np (void *)
+void __builtin_custom_nii (int, int)
+void __builtin_custom_nif (int, float)
+void __builtin_custom_nip (int, void *)
+void __builtin_custom_nfi (float, int)
+void __builtin_custom_nff (float, float)
+void __builtin_custom_nfp (float, void *)
+void __builtin_custom_npi (void *, int)
+void __builtin_custom_npf (void *, float)
+void __builtin_custom_npp (void *, void *)
+int __builtin_custom_in (void)
+int __builtin_custom_ini (int)
+int __builtin_custom_inf (float)
+int __builtin_custom_inp (void *)
+int __builtin_custom_inii (int, int)
+int __builtin_custom_inif (int, float)
+int __builtin_custom_inip (int, void *)
+int __builtin_custom_infi (float, int)
+int __builtin_custom_inff (float, float)
+int __builtin_custom_infp (float, void *)
+int __builtin_custom_inpi (void *, int)
+int __builtin_custom_inpf (void *, float)
+int __builtin_custom_inpp (void *, void *)
+float __builtin_custom_fn (void)
+float __builtin_custom_fni (int)
+float __builtin_custom_fnf (float)
+float __builtin_custom_fnp (void *)
+float __builtin_custom_fnii (int, int)
+float __builtin_custom_fnif (int, float)
+float __builtin_custom_fnip (int, void *)
+float __builtin_custom_fnfi (float, int)
+float __builtin_custom_fnff (float, float)
+float __builtin_custom_fnfp (float, void *)
+float __builtin_custom_fnpi (void *, int)
+float __builtin_custom_fnpf (void *, float)
+float __builtin_custom_fnpp (void *, void *)
+void * __builtin_custom_pn (void)
+void * __builtin_custom_pni (int)
+void * __builtin_custom_pnf (float)
+void * __builtin_custom_pnp (void *)
+void * __builtin_custom_pnii (int, int)
+void * __builtin_custom_pnif (int, float)
+void * __builtin_custom_pnip (int, void *)
+void * __builtin_custom_pnfi (float, int)
+void * __builtin_custom_pnff (float, float)
+void * __builtin_custom_pnfp (float, void *)
+void * __builtin_custom_pnpi (void *, int)
+void * __builtin_custom_pnpf (void *, float)
+void * __builtin_custom_pnpp (void *, void *)
+@end example
+
+@node ARC Built-in Functions
+@subsection ARC Built-in Functions
+
+The following built-in functions are provided for ARC targets.  The
+built-ins generate the corresponding assembly instructions.  In the
+examples given below, the generated code often requires an operand or
+result to be in a register.  Where necessary further code will be
+generated to ensure this is true, but for brevity this is not
+described in each case.
+
+@emph{Note:} Using a built-in to generate an instruction not supported
+by a target may cause problems. At present the compiler is not
+guaranteed to detect such misuse, and as a result an internal compiler
+error may be generated.
+
+@deftypefn {Built-in Function} int __builtin_arc_aligned (void *@var{val}, int @var{alignval})
+Return 1 if @var{val} is known to have the byte alignment given
+by @var{alignval}, otherwise return 0.
+Note that this is different from
+@smallexample
+__alignof__(*(char *)@var{val}) >= alignval
+@end smallexample
+because __alignof__ sees only the type of the dereference, whereas
+__builtin_arc_align uses alignment information from the pointer
+as well as from the pointed-to type.
+The information available will depend on optimization level.
+@end deftypefn
+
+@deftypefn {Built-in Function} void __builtin_arc_brk (void)
+Generates
+@example
+brk
+@end example
+@end deftypefn
+
+@deftypefn {Built-in Function} {unsigned int} __builtin_arc_core_read (unsigned int @var{regno})
+The operand is the number of a register to be read.  Generates:
+@example
+mov  @var{dest}, r@var{regno}
+@end example
+where the value in @var{dest} will be the result returned from the
+built-in.
+@end deftypefn
+
+@deftypefn {Built-in Function} void __builtin_arc_core_write (unsigned int @var{regno}, unsigned int @var{val})
+The first operand is the number of a register to be written, the
+second operand is a compile time constant to write into that
+register.  Generates:
+@example
+mov  r@var{regno}, @var{val}
+@end example
+@end deftypefn
+
+@deftypefn {Built-in Function} int __builtin_arc_divaw (int @var{a}, int @var{b})
+Only available if either @option{-mcpu=ARC700} or @option{-meA} is set.
+Generates:
+@example
+divaw  @var{dest}, @var{a}, @var{b}
+@end example
+where the value in @var{dest} will be the result returned from the
+built-in.
+@end deftypefn
+
+@deftypefn {Built-in Function} void __builtin_arc_flag (unsigned int @var{a})
+Generates
+@example
+flag  @var{a}
+@end example
+@end deftypefn
+
+@deftypefn {Built-in Function} {unsigned int} __builtin_arc_lr (unsigned int @var{auxr})
+The operand, @var{auxv}, is the address of an auxiliary register and
+must be a compile time constant.  Generates:
+@example
+lr  @var{dest}, [@var{auxr}]
+@end example
+Where the value in @var{dest} will be the result returned from the
+built-in.
+@end deftypefn
+
+@deftypefn {Built-in Function} void __builtin_arc_mul64 (int @var{a}, int @var{b})
+Only available with @option{-mmul64}.  Generates:
+@example
+mul64  @var{a}, @var{b}
+@end example
+@end deftypefn
+
+@deftypefn {Built-in Function} void __builtin_arc_mulu64 (unsigned int @var{a}, unsigned int @var{b})
+Only available with @option{-mmul64}.  Generates:
+@example
+mulu64  @var{a}, @var{b}
+@end example
+@end deftypefn
+
+@deftypefn {Built-in Function} void __builtin_arc_nop (void)
+Generates:
+@example
+nop
+@end example
+@end deftypefn
+
+@deftypefn {Built-in Function} int __builtin_arc_norm (int @var{src})
+Only valid if the @samp{norm} instruction is available through the
+@option{-mnorm} option or by default with @option{-mcpu=ARC700}.
+Generates:
+@example
+norm  @var{dest}, @var{src}
+@end example
+Where the value in @var{dest} will be the result returned from the
+built-in.
+@end deftypefn
+
+@deftypefn {Built-in Function}  {short int} __builtin_arc_normw (short int @var{src})
+Only valid if the @samp{normw} instruction is available through the
+@option{-mnorm} option or by default with @option{-mcpu=ARC700}.
+Generates:
+@example
+normw  @var{dest}, @var{src}
+@end example
+Where the value in @var{dest} will be the result returned from the
+built-in.
+@end deftypefn
+
+@deftypefn {Built-in Function}  void __builtin_arc_rtie (void)
+Generates:
+@example
+rtie
+@end example
+@end deftypefn
+
+@deftypefn {Built-in Function}  void __builtin_arc_sleep (int @var{a}
+Generates:
+@example
+sleep  @var{a}
+@end example
+@end deftypefn
+
+@deftypefn {Built-in Function}  void __builtin_arc_sr (unsigned int @var{auxr}, unsigned int @var{val})
+The first argument, @var{auxv}, is the address of an auxiliary
+register, the second argument, @var{val}, is a compile time constant
+to be written to the register.  Generates:
+@example
+sr  @var{auxr}, [@var{val}]
+@end example
+@end deftypefn
+
+@deftypefn {Built-in Function}  int __builtin_arc_swap (int @var{src})
+Only valid with @option{-mswap}.  Generates:
+@example
+swap  @var{dest}, @var{src}
+@end example
+Where the value in @var{dest} will be the result returned from the
+built-in.
+@end deftypefn
+
+@deftypefn {Built-in Function}  void __builtin_arc_swi (void)
+Generates:
+@example
+swi
+@end example
+@end deftypefn
+
+@deftypefn {Built-in Function}  void __builtin_arc_sync (void)
+Only available with @option{-mcpu=ARC700}.  Generates:
+@example
+sync
+@end example
+@end deftypefn
+
+@deftypefn {Built-in Function}  void __builtin_arc_trap_s (unsigned int @var{c})
+Only available with @option{-mcpu=ARC700}.  Generates:
+@example
+trap_s  @var{c}
+@end example
+@end deftypefn
+
+@deftypefn {Built-in Function}  void __builtin_arc_unimp_s (void)
+Only available with @option{-mcpu=ARC700}.  Generates:
+@example
+unimp_s
+@end example
+@end deftypefn
+
+The instructions generated by the following builtins are not
+considered as candidates for scheduling.  They are not moved around by
+the compiler during scheduling, and thus can be expected to appear
+where they are put in the C code:
+@example
+__builtin_arc_brk()
+__builtin_arc_core_read()
+__builtin_arc_core_write()
+__builtin_arc_flag()
+__builtin_arc_lr()
+__builtin_arc_sleep()
+__builtin_arc_sr()
+__builtin_arc_swi()
+@end example
+
+@node ARC SIMD Built-in Functions
+@subsection ARC SIMD Built-in Functions
+
+SIMD builtins provided by the compiler can be used to generate the
+vector instructions.  This section describes the available builtins
+and their usage in programs.  With the @option{-msimd} option, the
+compiler provides 128-bit vector types, which can be specified using
+the @code{vector_size} attribute.  The header file @file{arc-simd.h}
+can be included to use the following predefined types:
+@example
+typedef int __v4si   __attribute__((vector_size(16)));
+typedef short __v8hi __attribute__((vector_size(16)));
+@end example
+
+These types can be used to define 128-bit variables.  The built-in
+functions listed in the following section can be used on these
+variables to generate the vector operations.
+
+For all builtins, @code{__builtin_arc_@var{someinsn}}, the header file
+@file{arc-simd.h} also provides equivalent macros called
+@code{_@var{someinsn}} that can be used for programming ease and
+improved readability.  The following macros for DMA control are also
+provided:
+@example
+#define _setup_dma_in_channel_reg _vdiwr
+#define _setup_dma_out_channel_reg _vdowr
+@end example
+
+The following is a complete list of all the SIMD built-ins provided
+for ARC, grouped by calling signature.
+
+The following take two @code{__v8hi} arguments and return a
+@code{__v8hi} result:
+@example
+__v8hi __builtin_arc_vaddaw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vaddw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vand (__v8hi, __v8hi)
+__v8hi __builtin_arc_vandaw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vavb (__v8hi, __v8hi)
+__v8hi __builtin_arc_vavrb (__v8hi, __v8hi)
+__v8hi __builtin_arc_vbic (__v8hi, __v8hi)
+__v8hi __builtin_arc_vbicaw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vdifaw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vdifw (__v8hi, __v8hi)
+__v8hi __builtin_arc_veqw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vh264f (__v8hi, __v8hi)
+__v8hi __builtin_arc_vh264ft (__v8hi, __v8hi)
+__v8hi __builtin_arc_vh264fw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vlew (__v8hi, __v8hi)
+__v8hi __builtin_arc_vltw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmaxaw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmaxw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vminaw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vminw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmr1aw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmr1w (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmr2aw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmr2w (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmr3aw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmr3w (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmr4aw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmr4w (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmr5aw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmr5w (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmr6aw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmr6w (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmr7aw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmr7w (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmrb (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmulaw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmulfaw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmulfw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vmulw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vnew (__v8hi, __v8hi)
+__v8hi __builtin_arc_vor (__v8hi, __v8hi)
+__v8hi __builtin_arc_vsubaw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vsubw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vsummw (__v8hi, __v8hi)
+__v8hi __builtin_arc_vvc1f (__v8hi, __v8hi)
+__v8hi __builtin_arc_vvc1ft (__v8hi, __v8hi)
+__v8hi __builtin_arc_vxor (__v8hi, __v8hi)
+__v8hi __builtin_arc_vxoraw (__v8hi, __v8hi)
+@end example
+
+The following take one @code{__v8hi} and one @code{int} argument and return a
+@code{__v8hi} result:
+
+@example
+__v8hi __builtin_arc_vbaddw (__v8hi, int)
+__v8hi __builtin_arc_vbmaxw (__v8hi, int)
+__v8hi __builtin_arc_vbminw (__v8hi, int)
+__v8hi __builtin_arc_vbmulaw (__v8hi, int)
+__v8hi __builtin_arc_vbmulfw (__v8hi, int)
+__v8hi __builtin_arc_vbmulw (__v8hi, int)
+__v8hi __builtin_arc_vbrsubw (__v8hi, int)
+__v8hi __builtin_arc_vbsubw (__v8hi, int)
+@end example
+
+The following take one @code{__v8hi} argument and one @code{int} argument which
+must be a 3-bit compile time constant indicating a register number
+I0-I7.  They return a @code{__v8hi} result.
+@example
+__v8hi __builtin_arc_vasrw (__v8hi, const int)
+__v8hi __builtin_arc_vsr8 (__v8hi, const int)
+__v8hi __builtin_arc_vsr8aw (__v8hi, const int)
+@end example
+
+The following take one @code{__v8hi} argument and one @code{int}
+argument which must be a 6-bit compile time constant.  They return a
+@code{__v8hi} result.
+@example
+__v8hi __builtin_arc_vasrpwbi (__v8hi, const int)
+__v8hi __builtin_arc_vasrrpwbi (__v8hi, const int)
+__v8hi __builtin_arc_vasrrwi (__v8hi, const int)
+__v8hi __builtin_arc_vasrsrwi (__v8hi, const int)
+__v8hi __builtin_arc_vasrwi (__v8hi, const int)
+__v8hi __builtin_arc_vsr8awi (__v8hi, const int)
+__v8hi __builtin_arc_vsr8i (__v8hi, const int)
+@end example
+
+The following take one @code{__v8hi} argument and one @code{int} argument which
+must be a 8-bit compile time constant.  They return a @code{__v8hi}
+result.
+@example
+__v8hi __builtin_arc_vd6tapf (__v8hi, const int)
+__v8hi __builtin_arc_vmvaw (__v8hi, const int)
+__v8hi __builtin_arc_vmvw (__v8hi, const int)
+__v8hi __builtin_arc_vmvzw (__v8hi, const int)
+@end example
+
+The following take two @code{int} arguments, the second of which which
+must be a 8-bit compile time constant.  They return a @code{__v8hi}
+result:
+@example
+__v8hi __builtin_arc_vmovaw (int, const int)
+__v8hi __builtin_arc_vmovw (int, const int)
+__v8hi __builtin_arc_vmovzw (int, const int)
+@end example
+
+The following take a single @code{__v8hi} argument and return a
+@code{__v8hi} result:
+@example
+__v8hi __builtin_arc_vabsaw (__v8hi)
+__v8hi __builtin_arc_vabsw (__v8hi)
+__v8hi __builtin_arc_vaddsuw (__v8hi)
+__v8hi __builtin_arc_vexch1 (__v8hi)
+__v8hi __builtin_arc_vexch2 (__v8hi)
+__v8hi __builtin_arc_vexch4 (__v8hi)
+__v8hi __builtin_arc_vsignw (__v8hi)
+__v8hi __builtin_arc_vupbaw (__v8hi)
+__v8hi __builtin_arc_vupbw (__v8hi)
+__v8hi __builtin_arc_vupsbaw (__v8hi)
+__v8hi __builtin_arc_vupsbw (__v8hi)
+@end example
+
+The followign take two @code{int} arguments and return no result:
+@example
+void __builtin_arc_vdirun (int, int)
+void __builtin_arc_vdorun (int, int)
+@end example
+
+The following take two @code{int} arguments and return no result.  The
+first argument must a 3-bit compile time constant indicating one of
+the DR0-DR7 DMA setup channels:
+@example
+void __builtin_arc_vdiwr (const int, int)
+void __builtin_arc_vdowr (const int, int)
+@end example
+
+The following take an @code{int} argument and return no result:
+@example
+void __builtin_arc_vendrec (int)
+void __builtin_arc_vrec (int)
+void __builtin_arc_vrecrun (int)
+void __builtin_arc_vrun (int)
+@end example
+
+The following take a @code{__v8hi} argument and two @code{int}
+arguments and return a @code{__v8hi} result.  The second argument must
+be a 3-bit compile time constants, indicating one the registers I0-I7,
+and the third argument must be an 8-bit compile time constant.
+
+@emph{Note:} Although the equivalent hardware instructions do not take
+an SIMD register as an operand, these builtins overwrite the relevant
+bits of the @code{__v8hi} register provided as the first argument with
+the value loaded from the @code{[Ib, u8]} location in the SDM.
+
+@example
+__v8hi __builtin_arc_vld32 (__v8hi, const int, const int)
+__v8hi __builtin_arc_vld32wh (__v8hi, const int, const int)
+__v8hi __builtin_arc_vld32wl (__v8hi, const int, const int)
+__v8hi __builtin_arc_vld64 (__v8hi, const int, const int)
+@end example
+
+The following take two @code{int} arguments and return a @code{__v8hi}
+result.  The first argument must be a 3-bit compile time constants,
+indicating one the registers I0-I7, and the second argument must be an
+8-bit compile time constant.
+
+@example
+__v8hi __builtin_arc_vld128 (const int, const int)
+__v8hi __builtin_arc_vld64w (const int, const int)
+@end example
+
+The following take a @code{__v8hi} argument and two @code{int}
+arguments and return no result.  The second argument must be a 3-bit
+compile time constants, indicating one the registers I0-I7, and the
+third argument must be an 8-bit compile time constant.
+
+@example
+void __builtin_arc_vst128 (__v8hi, const int, const int)
+void __builtin_arc_vst64 (__v8hi, const int, const int)
+@end example
+
+The following take a @code{__v8hi} argument and three @code{int}
+arguments and return no result.  The second argument must be a 3-bit
+compile-time constant, identifying the 16-bit sub-register to be
+stored, the third argument must be a 3-bit compile time constants,
+indicating one the registers I0-I7, and the fourth argument must be an
+8-bit compile time constant.
+
+@example
+void __builtin_arc_vst16_n (__v8hi, const int, const int, const int)
+void __builtin_arc_vst32_n (__v8hi, const int, const int, const int)
+@end example
+
 @node ARM iWMMXt Built-in Functions
 @subsection ARM iWMMXt Built-in Functions
 
@@ -8708,17 +9762,23 @@ typedef int v2si __attribute__ ((vector_size (8)));
 typedef short v4hi __attribute__ ((vector_size (8)));
 typedef char v8qi __attribute__ ((vector_size (8)));
 
-int __builtin_arm_getwcx (int)
-void __builtin_arm_setwcx (int, int)
+int __builtin_arm_getwcgr0 (void)
+void __builtin_arm_setwcgr0 (int)
+int __builtin_arm_getwcgr1 (void)
+void __builtin_arm_setwcgr1 (int)
+int __builtin_arm_getwcgr2 (void)
+void __builtin_arm_setwcgr2 (int)
+int __builtin_arm_getwcgr3 (void)
+void __builtin_arm_setwcgr3 (int)
 int __builtin_arm_textrmsb (v8qi, int)
 int __builtin_arm_textrmsh (v4hi, int)
 int __builtin_arm_textrmsw (v2si, int)
 int __builtin_arm_textrmub (v8qi, int)
 int __builtin_arm_textrmuh (v4hi, int)
 int __builtin_arm_textrmuw (v2si, int)
-v8qi __builtin_arm_tinsrb (v8qi, int)
-v4hi __builtin_arm_tinsrh (v4hi, int)
-v2si __builtin_arm_tinsrw (v2si, int)
+v8qi __builtin_arm_tinsrb (v8qi, int, int)
+v4hi __builtin_arm_tinsrh (v4hi, int, int)
+v2si __builtin_arm_tinsrw (v2si, int, int)
 long long __builtin_arm_tmia (long long, int, int)
 long long __builtin_arm_tmiabb (long long, int, int)
 long long __builtin_arm_tmiabt (long long, int, int)
@@ -8790,9 +9850,9 @@ v4hi __builtin_arm_wrorh (v4hi, long long)
 v4hi __builtin_arm_wrorhi (v4hi, int)
 v2si __builtin_arm_wrorw (v2si, long long)
 v2si __builtin_arm_wrorwi (v2si, int)
-v2si __builtin_arm_wsadb (v8qi, v8qi)
+v2si __builtin_arm_wsadb (v2si, v8qi, v8qi)
 v2si __builtin_arm_wsadbz (v8qi, v8qi)
-v2si __builtin_arm_wsadh (v4hi, v4hi)
+v2si __builtin_arm_wsadh (v2si, v4hi, v4hi)
 v2si __builtin_arm_wsadhz (v4hi, v4hi)
 v4hi __builtin_arm_wshufh (v4hi, int)
 long long __builtin_arm_wslld (long long, long long)
@@ -8852,6 +9912,11 @@ when the @option{-mfpu=neon} switch is used:
 
 @include arm-neon-intrinsics.texi
 
+@node ARM ACLE Intrinsics
+@subsection ARM ACLE Intrinsics
+
+@include arm-acle-intrinsics.texi
+
 @node AVR Built-in Functions
 @subsection AVR Built-in Functions
 
@@ -8862,7 +9927,7 @@ or if not a specific built-in is implemented or not. For example, if
 @code{__BUILTIN_AVR_NOP} is defined to @code{1} and undefined otherwise.
 
 The following built-in functions map to the respective machine
-instruction, i.e. @code{nop}, @code{sei}, @code{cli}, @code{sleep},
+instruction, i.e.@: @code{nop}, @code{sei}, @code{cli}, @code{sleep},
 @code{wdr}, @code{swap}, @code{fmul}, @code{fmuls}
 resp. @code{fmulsu}. The three @code{fmul*} built-ins are implemented
 as library call if no hardware multiplier is available.
@@ -8887,8 +9952,8 @@ void __builtin_avr_delay_cycles (unsigned long ticks)
 
 @noindent
 @code{ticks} is the number of ticks to delay execution. Note that this
-built-in does not take into account the effect of interrupts which
-might increase delay time. @code{ticks} must be a compile time
+built-in does not take into account the effect of interrupts that
+might increase delay time. @code{ticks} must be a compile-time
 integer constant; delays with a variable number of cycles are not supported.
 
 @smallexample
@@ -8941,8 +10006,8 @@ __builtin_avr_insert_bits (0x32107654, bits, 0)
 @end smallexample
 
 @smallexample
-// high-nibble of result is the high-nibble of val
-// low-nibble of result is the low-nibble of bits
+// high nibble of result is the high nibble of val
+// low nibble of result is the low nibble of bits
 __builtin_avr_insert_bits (0xffff3210, bits, val)
 @end smallexample
 
@@ -8972,7 +10037,7 @@ 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
+@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.
@@ -9020,7 +10085,7 @@ 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.
+selects 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}
@@ -9388,7 +10453,7 @@ 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@.
+into the data cache.  The instruction is issued in slot I1@.
 @end table
 
 @node X86 Built-in Functions
@@ -9397,10 +10462,10 @@ into the data cache.  The instruction will be issued in slot I1@.
 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},
+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
+that perform run-time 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.
@@ -9412,19 +10477,19 @@ vector of eight 8-bit integers.  Some of the built-in functions operate on
 MMX registers as a whole 64-bit entity, these use @code{V1DI} as their mode.
 
 If 3DNow!@: extensions are enabled, @code{V2SF} is used as a mode for a vector
-of two 32-bit floating point values.
+of two 32-bit floating-point values.
 
 If SSE extensions are enabled, @code{V4SF} is used for a vector of four 32-bit
-floating point values.  Some instructions use a vector of four 32-bit
+floating-point values.  Some instructions use a vector of four 32-bit
 integers, these use @code{V4SI}.  Finally, some instructions operate on an
 entire vector register, interpreting it as a 128-bit integer, these use mode
 @code{TI}.
 
 In 64-bit mode, the x86-64 family of processors uses additional built-in
 functions for efficient use of @code{TF} (@code{__float128}) 128-bit
-floating point and @code{TC} 128-bit complex floating point values.
+floating point and @code{TC} 128-bit complex floating-point values.
 
-The following floating point built-in functions are available in 64-bit
+The following floating-point built-in functions are available in 64-bit
 mode.  All of them implement the function that is part of the name.
 
 @smallexample
@@ -9440,7 +10505,7 @@ Generates the @code{pause} machine instruction with a compiler memory
 barrier.
 @end table
 
-The following floating point built-in functions are made available in the
+The following floating-point built-in functions are made available in the
 64-bit mode.
 
 @table @code
@@ -9453,6 +10518,161 @@ Similar to @code{__builtin_huge_val}, except the return type is @code{__float128
 @findex __builtin_huge_valq
 @end table
 
+The following built-in functions are always available and can be used to
+check the target platform type.
+
+@deftypefn {Built-in Function} void __builtin_cpu_init (void)
+This function runs the CPU detection code to check the type of CPU and the
+features supported.  This built-in function needs to be invoked along with the built-in functions
+to check CPU type and features, @code{__builtin_cpu_is} and
+@code{__builtin_cpu_supports}, only when used in a function that is
+executed before any constructors are called.  The CPU detection code is
+automatically executed in a very high priority constructor.
+
+For example, this function has to be used in @code{ifunc} resolvers that
+check for CPU type using the built-in functions @code{__builtin_cpu_is}
+and @code{__builtin_cpu_supports}, or in constructors on targets that
+don't support constructor priority.
+@smallexample
+
+static void (*resolve_memcpy (void)) (void)
+@{
+  // ifunc resolvers fire before constructors, explicitly call the init
+  // function.
+  __builtin_cpu_init ();
+  if (__builtin_cpu_supports ("ssse3"))
+    return ssse3_memcpy; // super fast memcpy with ssse3 instructions.
+  else
+    return default_memcpy;
+@}
+
+void *memcpy (void *, const void *, size_t)
+     __attribute__ ((ifunc ("resolve_memcpy")));
+@end smallexample
+
+@end deftypefn
+
+@deftypefn {Built-in Function} int __builtin_cpu_is (const char *@var{cpuname})
+This function returns a positive integer if the run-time CPU
+is of type @var{cpuname}
+and returns @code{0} otherwise. The following CPU names can be detected:
+
+@table @samp
+@item intel
+Intel CPU.
+
+@item atom
+Intel Atom CPU.
+
+@item core2
+Intel Core 2 CPU.
+
+@item corei7
+Intel Core i7 CPU.
+
+@item nehalem
+Intel Core i7 Nehalem CPU.
+
+@item westmere
+Intel Core i7 Westmere CPU.
+
+@item sandybridge
+Intel Core i7 Sandy Bridge CPU.
+
+@item amd
+AMD CPU.
+
+@item amdfam10h
+AMD Family 10h CPU.
+
+@item barcelona
+AMD Family 10h Barcelona CPU.
+
+@item shanghai
+AMD Family 10h Shanghai CPU.
+
+@item istanbul
+AMD Family 10h Istanbul CPU.
+
+@item btver1
+AMD Family 14h CPU.
+
+@item amdfam15h
+AMD Family 15h CPU.
+
+@item bdver1
+AMD Family 15h Bulldozer version 1.
+
+@item bdver2
+AMD Family 15h Bulldozer version 2.
+
+@item bdver3
+AMD Family 15h Bulldozer version 3.
+
+@item bdver4
+AMD Family 15h Bulldozer version 4.
+
+@item btver2
+AMD Family 16h CPU.
+@end table
+
+Here is an example:
+@smallexample
+if (__builtin_cpu_is ("corei7"))
+  @{
+     do_corei7 (); // Core i7 specific implementation.
+  @}
+else
+  @{
+     do_generic (); // Generic implementation.
+  @}
+@end smallexample
+@end deftypefn
+
+@deftypefn {Built-in Function} int __builtin_cpu_supports (const char *@var{feature})
+This function returns a positive integer if the run-time CPU
+supports @var{feature}
+and returns @code{0} otherwise. The following features can be detected:
+
+@table @samp
+@item cmov
+CMOV instruction.
+@item mmx
+MMX instructions.
+@item popcnt
+POPCNT instruction.
+@item sse
+SSE instructions.
+@item sse2
+SSE2 instructions.
+@item sse3
+SSE3 instructions.
+@item ssse3
+SSSE3 instructions.
+@item sse4.1
+SSE4.1 instructions.
+@item sse4.2
+SSE4.2 instructions.
+@item avx
+AVX instructions.
+@item avx2
+AVX2 instructions.
+@end table
+
+Here is an example:
+@smallexample
+if (__builtin_cpu_supports ("popcnt"))
+  @{
+     asm("popcnt %1,%0" : "=r"(count) : "rm"(n) : "cc");
+  @}
+else
+  @{
+     count = generic_countbits (n); //generic implementation.
+  @}
+@end smallexample
+@end deftypefn
+
+
 The following built-in functions are made available by @option{-mmmx}.
 All of them generate the machine instruction that is part of the name.
 
@@ -9526,8 +10746,6 @@ v8qi __builtin_ia32_pmaxub (v8qi, v8qi)
 v4hi __builtin_ia32_pmaxsw (v4hi, v4hi)
 v8qi __builtin_ia32_pminub (v8qi, v8qi)
 v4hi __builtin_ia32_pminsw (v4hi, v4hi)
-int __builtin_ia32_pextrw (v4hi, int)
-v4hi __builtin_ia32_pinsrw (v4hi, int, int)
 int __builtin_ia32_pmovmskb (v8qi)
 void __builtin_ia32_maskmovq (v8qi, v8qi, char *)
 void __builtin_ia32_movntq (di *, di)
@@ -9558,26 +10776,26 @@ v4sf __builtin_ia32_addss (v4sf, v4sf)
 v4sf __builtin_ia32_subss (v4sf, v4sf)
 v4sf __builtin_ia32_mulss (v4sf, v4sf)
 v4sf __builtin_ia32_divss (v4sf, v4sf)
-v4si __builtin_ia32_cmpeqps (v4sf, v4sf)
-v4si __builtin_ia32_cmpltps (v4sf, v4sf)
-v4si __builtin_ia32_cmpleps (v4sf, v4sf)
-v4si __builtin_ia32_cmpgtps (v4sf, v4sf)
-v4si __builtin_ia32_cmpgeps (v4sf, v4sf)
-v4si __builtin_ia32_cmpunordps (v4sf, v4sf)
-v4si __builtin_ia32_cmpneqps (v4sf, v4sf)
-v4si __builtin_ia32_cmpnltps (v4sf, v4sf)
-v4si __builtin_ia32_cmpnleps (v4sf, v4sf)
-v4si __builtin_ia32_cmpngtps (v4sf, v4sf)
-v4si __builtin_ia32_cmpngeps (v4sf, v4sf)
-v4si __builtin_ia32_cmpordps (v4sf, v4sf)
-v4si __builtin_ia32_cmpeqss (v4sf, v4sf)
-v4si __builtin_ia32_cmpltss (v4sf, v4sf)
-v4si __builtin_ia32_cmpless (v4sf, v4sf)
-v4si __builtin_ia32_cmpunordss (v4sf, v4sf)
-v4si __builtin_ia32_cmpneqss (v4sf, v4sf)
-v4si __builtin_ia32_cmpnlts (v4sf, v4sf)
-v4si __builtin_ia32_cmpnless (v4sf, v4sf)
-v4si __builtin_ia32_cmpordss (v4sf, v4sf)
+v4sf __builtin_ia32_cmpeqps (v4sf, v4sf)
+v4sf __builtin_ia32_cmpltps (v4sf, v4sf)
+v4sf __builtin_ia32_cmpleps (v4sf, v4sf)
+v4sf __builtin_ia32_cmpgtps (v4sf, v4sf)
+v4sf __builtin_ia32_cmpgeps (v4sf, v4sf)
+v4sf __builtin_ia32_cmpunordps (v4sf, v4sf)
+v4sf __builtin_ia32_cmpneqps (v4sf, v4sf)
+v4sf __builtin_ia32_cmpnltps (v4sf, v4sf)
+v4sf __builtin_ia32_cmpnleps (v4sf, v4sf)
+v4sf __builtin_ia32_cmpngtps (v4sf, v4sf)
+v4sf __builtin_ia32_cmpngeps (v4sf, v4sf)
+v4sf __builtin_ia32_cmpordps (v4sf, v4sf)
+v4sf __builtin_ia32_cmpeqss (v4sf, v4sf)
+v4sf __builtin_ia32_cmpltss (v4sf, v4sf)
+v4sf __builtin_ia32_cmpless (v4sf, v4sf)
+v4sf __builtin_ia32_cmpunordss (v4sf, v4sf)
+v4sf __builtin_ia32_cmpneqss (v4sf, v4sf)
+v4sf __builtin_ia32_cmpnltss (v4sf, v4sf)
+v4sf __builtin_ia32_cmpnless (v4sf, v4sf)
+v4sf __builtin_ia32_cmpordss (v4sf, v4sf)
 v4sf __builtin_ia32_maxps (v4sf, v4sf)
 v4sf __builtin_ia32_maxss (v4sf, v4sf)
 v4sf __builtin_ia32_minps (v4sf, v4sf)
@@ -9611,18 +10829,12 @@ int __builtin_ia32_movmskps (v4sf)
 The following built-in functions are available when @option{-msse} is used.
 
 @table @code
-@item v4sf __builtin_ia32_loadaps (float *)
-Generates the @code{movaps} machine instruction as a load from memory.
-@item void __builtin_ia32_storeaps (float *, v4sf)
-Generates the @code{movaps} machine instruction as a store to memory.
 @item v4sf __builtin_ia32_loadups (float *)
 Generates the @code{movups} machine instruction as a load from memory.
 @item void __builtin_ia32_storeups (float *, v4sf)
 Generates the @code{movups} machine instruction as a store to memory.
-@item v4sf __builtin_ia32_loadsss (float *)
+@item v4sf __builtin_ia32_loadss (float *)
 Generates the @code{movss} machine instruction as a load from memory.
-@item void __builtin_ia32_storess (float *, v4sf)
-Generates the @code{movss} machine instruction as a store to memory.
 @item v4sf __builtin_ia32_loadhps (v4sf, const v2sf *)
 Generates the @code{movhps} machine instruction as a load from memory.
 @item v4sf __builtin_ia32_loadlps (v4sf, const v2sf *)
@@ -9806,22 +11018,13 @@ v2df __builtin_ia32_hsubpd (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)
 v4sf __builtin_ia32_movshdup (v4sf)
 v4sf __builtin_ia32_movsldup (v4sf)
 void __builtin_ia32_mwait (unsigned int, unsigned int)
 @end smallexample
 
-The following built-in functions are available when @option{-msse3} is used.
-
-@table @code
-@item v2df __builtin_ia32_loadddup (double const *)
-Generates the @code{movddup} machine instruction as a load from memory.
-@end table
-
 The following built-in functions are available when @option{-mssse3} is used.
-All of them generate the machine instruction that is part of the name
-with MMX registers.
+All of them generate the machine instruction that is part of the name.
 
 @smallexample
 v2si __builtin_ia32_phaddd (v2si, v2si)
@@ -9843,8 +11046,7 @@ v4hi __builtin_ia32_pabsw (v4hi)
 @end smallexample
 
 The following built-in functions are available when @option{-mssse3} is used.
-All of them generate the machine instruction that is part of the name
-with SSE registers.
+All of them generate the machine instruction that is part of the name.
 
 @smallexample
 v4si __builtin_ia32_phaddd128 (v4si, v4si)
@@ -10132,7 +11334,7 @@ used. All of them generate the machine instruction that is part of the
 name.
 
 @smallexample
-v32qi __builtin_ia32_mpsadbw256 (v32qi,v32qi,v32qi,int)
+v32qi __builtin_ia32_mpsadbw256 (v32qi,v32qi,int)
 v32qi __builtin_ia32_pabsb256 (v32qi)
 v16hi __builtin_ia32_pabsw256 (v16hi)
 v8si __builtin_ia32_pabsd256 (v8si)
@@ -10367,8 +11569,8 @@ The following built-in functions are available when @option{-mxop} is used.
 @smallexample
 v2df __builtin_ia32_vfrczpd (v2df)
 v4sf __builtin_ia32_vfrczps (v4sf)
-v2df __builtin_ia32_vfrczsd (v2df, v2df)
-v4sf __builtin_ia32_vfrczss (v4sf, v4sf)
+v2df __builtin_ia32_vfrczsd (v2df)
+v4sf __builtin_ia32_vfrczss (v4sf)
 v4df __builtin_ia32_vfrczpd256 (v4df)
 v8sf __builtin_ia32_vfrczps256 (v8sf)
 v2di __builtin_ia32_vpcmov (v2di, v2di, v2di)
@@ -10492,42 +11694,41 @@ v8hi __builtin_ia32_vpshlw (v8hi, v8hi)
 @end smallexample
 
 The following built-in functions are available when @option{-mfma4} is used.
-All of them generate the machine instruction that is part of the name
-with MMX registers.
-
-@smallexample
-v2df __builtin_ia32_fmaddpd (v2df, v2df, v2df)
-v4sf __builtin_ia32_fmaddps (v4sf, v4sf, v4sf)
-v2df __builtin_ia32_fmaddsd (v2df, v2df, v2df)
-v4sf __builtin_ia32_fmaddss (v4sf, v4sf, v4sf)
-v2df __builtin_ia32_fmsubpd (v2df, v2df, v2df)
-v4sf __builtin_ia32_fmsubps (v4sf, v4sf, v4sf)
-v2df __builtin_ia32_fmsubsd (v2df, v2df, v2df)
-v4sf __builtin_ia32_fmsubss (v4sf, v4sf, v4sf)
-v2df __builtin_ia32_fnmaddpd (v2df, v2df, v2df)
-v4sf __builtin_ia32_fnmaddps (v4sf, v4sf, v4sf)
-v2df __builtin_ia32_fnmaddsd (v2df, v2df, v2df)
-v4sf __builtin_ia32_fnmaddss (v4sf, v4sf, v4sf)
-v2df __builtin_ia32_fnmsubpd (v2df, v2df, v2df)
-v4sf __builtin_ia32_fnmsubps (v4sf, v4sf, v4sf)
-v2df __builtin_ia32_fnmsubsd (v2df, v2df, v2df)
-v4sf __builtin_ia32_fnmsubss (v4sf, v4sf, v4sf)
-v2df __builtin_ia32_fmaddsubpd  (v2df, v2df, v2df)
-v4sf __builtin_ia32_fmaddsubps  (v4sf, v4sf, v4sf)
-v2df __builtin_ia32_fmsubaddpd  (v2df, v2df, v2df)
-v4sf __builtin_ia32_fmsubaddps  (v4sf, v4sf, v4sf)
-v4df __builtin_ia32_fmaddpd256 (v4df, v4df, v4df)
-v8sf __builtin_ia32_fmaddps256 (v8sf, v8sf, v8sf)
-v4df __builtin_ia32_fmsubpd256 (v4df, v4df, v4df)
-v8sf __builtin_ia32_fmsubps256 (v8sf, v8sf, v8sf)
-v4df __builtin_ia32_fnmaddpd256 (v4df, v4df, v4df)
-v8sf __builtin_ia32_fnmaddps256 (v8sf, v8sf, v8sf)
-v4df __builtin_ia32_fnmsubpd256 (v4df, v4df, v4df)
-v8sf __builtin_ia32_fnmsubps256 (v8sf, v8sf, v8sf)
-v4df __builtin_ia32_fmaddsubpd256 (v4df, v4df, v4df)
-v8sf __builtin_ia32_fmaddsubps256 (v8sf, v8sf, v8sf)
-v4df __builtin_ia32_fmsubaddpd256 (v4df, v4df, v4df)
-v8sf __builtin_ia32_fmsubaddps256 (v8sf, v8sf, v8sf)
+All of them generate the machine instruction that is part of the name.
+
+@smallexample
+v2df __builtin_ia32_vfmaddpd (v2df, v2df, v2df)
+v4sf __builtin_ia32_vfmaddps (v4sf, v4sf, v4sf)
+v2df __builtin_ia32_vfmaddsd (v2df, v2df, v2df)
+v4sf __builtin_ia32_vfmaddss (v4sf, v4sf, v4sf)
+v2df __builtin_ia32_vfmsubpd (v2df, v2df, v2df)
+v4sf __builtin_ia32_vfmsubps (v4sf, v4sf, v4sf)
+v2df __builtin_ia32_vfmsubsd (v2df, v2df, v2df)
+v4sf __builtin_ia32_vfmsubss (v4sf, v4sf, v4sf)
+v2df __builtin_ia32_vfnmaddpd (v2df, v2df, v2df)
+v4sf __builtin_ia32_vfnmaddps (v4sf, v4sf, v4sf)
+v2df __builtin_ia32_vfnmaddsd (v2df, v2df, v2df)
+v4sf __builtin_ia32_vfnmaddss (v4sf, v4sf, v4sf)
+v2df __builtin_ia32_vfnmsubpd (v2df, v2df, v2df)
+v4sf __builtin_ia32_vfnmsubps (v4sf, v4sf, v4sf)
+v2df __builtin_ia32_vfnmsubsd (v2df, v2df, v2df)
+v4sf __builtin_ia32_vfnmsubss (v4sf, v4sf, v4sf)
+v2df __builtin_ia32_vfmaddsubpd  (v2df, v2df, v2df)
+v4sf __builtin_ia32_vfmaddsubps  (v4sf, v4sf, v4sf)
+v2df __builtin_ia32_vfmsubaddpd  (v2df, v2df, v2df)
+v4sf __builtin_ia32_vfmsubaddps  (v4sf, v4sf, v4sf)
+v4df __builtin_ia32_vfmaddpd256 (v4df, v4df, v4df)
+v8sf __builtin_ia32_vfmaddps256 (v8sf, v8sf, v8sf)
+v4df __builtin_ia32_vfmsubpd256 (v4df, v4df, v4df)
+v8sf __builtin_ia32_vfmsubps256 (v8sf, v8sf, v8sf)
+v4df __builtin_ia32_vfnmaddpd256 (v4df, v4df, v4df)
+v8sf __builtin_ia32_vfnmaddps256 (v8sf, v8sf, v8sf)
+v4df __builtin_ia32_vfnmsubpd256 (v4df, v4df, v4df)
+v8sf __builtin_ia32_vfnmsubps256 (v8sf, v8sf, v8sf)
+v4df __builtin_ia32_vfmaddsubpd256 (v4df, v4df, v4df)
+v8sf __builtin_ia32_vfmaddsubps256 (v8sf, v8sf, v8sf)
+v4df __builtin_ia32_vfmsubaddpd256 (v4df, v4df, v4df)
+v8sf __builtin_ia32_vfmsubaddps256 (v8sf, v8sf, v8sf)
 
 @end smallexample
 
@@ -10574,6 +11775,31 @@ unsigned int __builtin_ia32_lzcnt_u32(unsigned int);
 unsigned long long __builtin_ia32_lzcnt_u64 (unsigned long long);
 @end smallexample
 
+The following built-in functions are available when @option{-mfxsr} is used.
+All of them generate the machine instruction that is part of the name.
+@smallexample
+void __builtin_ia32_fxsave (void *)
+void __builtin_ia32_fxrstor (void *)
+void __builtin_ia32_fxsave64 (void *)
+void __builtin_ia32_fxrstor64 (void *)
+@end smallexample
+
+The following built-in functions are available when @option{-mxsave} is used.
+All of them generate the machine instruction that is part of the name.
+@smallexample
+void __builtin_ia32_xsave (void *, long long)
+void __builtin_ia32_xrstor (void *, long long)
+void __builtin_ia32_xsave64 (void *, long long)
+void __builtin_ia32_xrstor64 (void *, long long)
+@end smallexample
+
+The following built-in functions are available when @option{-mxsaveopt} is used.
+All of them generate the machine instruction that is part of the name.
+@smallexample
+void __builtin_ia32_xsaveopt (void *, long long)
+void __builtin_ia32_xsaveopt64 (void *, long long)
+@end smallexample
+
 The following built-in functions are available when @option{-mtbm} is used.
 Both of them generate the immediate form of the bextr machine instruction.
 @smallexample
@@ -10601,7 +11827,6 @@ v2sf __builtin_ia32_pfrcp (v2sf)
 v2sf __builtin_ia32_pfrcpit1 (v2sf, v2sf)
 v2sf __builtin_ia32_pfrcpit2 (v2sf, v2sf)
 v2sf __builtin_ia32_pfrsqrt (v2sf)
-v2sf __builtin_ia32_pfrsqrtit1 (v2sf, v2sf)
 v2sf __builtin_ia32_pfsub (v2sf, v2sf)
 v2sf __builtin_ia32_pfsubr (v2sf, v2sf)
 v2sf __builtin_ia32_pi2fd (v2si)
@@ -10621,6 +11846,88 @@ v2sf __builtin_ia32_pswapdsf (v2sf)
 v2si __builtin_ia32_pswapdsi (v2si)
 @end smallexample
 
+The following built-in functions are available when @option{-mrtm} is used
+They are used for restricted transactional memory. These are the internal
+low level functions. Normally the functions in 
+@ref{X86 transactional memory intrinsics} should be used instead.
+
+@smallexample
+int __builtin_ia32_xbegin ()
+void __builtin_ia32_xend ()
+void __builtin_ia32_xabort (status)
+int __builtin_ia32_xtest ()
+@end smallexample
+
+@node X86 transactional memory intrinsics
+@subsection X86 transaction memory intrinsics
+
+Hardware transactional memory intrinsics for i386. These allow to use
+memory transactions with RTM (Restricted Transactional Memory).
+For using HLE (Hardware Lock Elision) see @ref{x86 specific memory model extensions for transactional memory} instead.
+This support is enabled with the @option{-mrtm} option.
+
+A memory transaction commits all changes to memory in an atomic way,
+as visible to other threads. If the transaction fails it is rolled back
+and all side effects discarded.
+
+Generally there is no guarantee that a memory transaction ever succeeds
+and suitable fallback code always needs to be supplied.
+
+@deftypefn {RTM Function} {unsigned} _xbegin ()
+Start a RTM (Restricted Transactional Memory) transaction. 
+Returns _XBEGIN_STARTED when the transaction
+started successfully (note this is not 0, so the constant has to be 
+explicitely tested). When the transaction aborts all side effects
+are undone and an abort code is returned. There is no guarantee
+any transaction ever succeeds, so there always needs to be a valid
+tested fallback path.
+@end deftypefn
+
+@smallexample
+#include <immintrin.h>
+
+if ((status = _xbegin ()) == _XBEGIN_STARTED) @{
+    ... transaction code...
+    _xend ();
+@} else @{
+    ... non transactional fallback path...
+@}
+@end smallexample
+
+Valid abort status bits (when the value is not @code{_XBEGIN_STARTED}) are:
+
+@table @code
+@item _XABORT_EXPLICIT
+Transaction explicitely aborted with @code{_xabort}. The parameter passed
+to @code{_xabort} is available with @code{_XABORT_CODE(status)}
+@item _XABORT_RETRY
+Transaction retry is possible.
+@item _XABORT_CONFLICT
+Transaction abort due to a memory conflict with another thread
+@item _XABORT_CAPACITY
+Transaction abort due to the transaction using too much memory
+@item _XABORT_DEBUG
+Transaction abort due to a debug trap
+@item _XABORT_NESTED
+Transaction abort in a inner nested transaction
+@end table
+
+@deftypefn {RTM Function} {void} _xend ()
+Commit the current transaction. When no transaction is active this will
+fault. All memory side effects of the transactions will become visible
+to other threads in an atomic matter.
+@end deftypefn
+
+@deftypefn {RTM Function} {int} _xtest ()
+Return a value not zero when a transaction is currently active, otherwise 0.
+@end deftypefn
+
+@deftypefn {RTM Function} {void} _xabort (status)
+Abort the current transaction. When no transaction is active this is a no-op.
+status must be a 8bit constant, that is included in the status code returned
+by @code{_xbegin}
+@end deftypefn
+
 @node MIPS DSP Built-in Functions
 @subsection MIPS DSP Built-in Functions
 
@@ -10642,8 +11949,8 @@ using the command-line option @option{-mdspr2}; this option implies
 
 The SCOUNT and POS bits of the DSP control register are global.  The
 WRDSP, EXTPDP, EXTPDPV and MTHLIP instructions modify the SCOUNT and
-POS bits.  During optimization, the compiler will not delete these
-instructions and it will not delete calls to functions containing
+POS bits.  During optimization, the compiler does not delete these
+instructions and it does not delete calls to functions containing
 these instructions.
 
 At present, GCC only provides support for operations on 32-bit
@@ -10677,8 +11984,8 @@ d = (v2q15) @{0.1234 * 0x1.0p15, 0.4567 * 0x1.0p15@};
 @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
+order applies to big-endian targets.  For example, the code above
+sets the lowest byte of @code{a} to @code{1} on little-endian targets
 and @code{4} on big-endian targets.
 
 @emph{Note:} Q7, Q15 and Q31 values must be initialized with their integer
@@ -10722,8 +12029,8 @@ typedef long long a64;
 @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{long long}, but we use @code{a64} to indicate values that are
+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
@@ -10948,7 +12255,7 @@ b = (v2sf) @{e, f@};
 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
+For example, the code above sets the lower half of @code{a} to
 @code{1.5} on little-endian targets and @code{9.1} on big-endian targets.
 
 @node MIPS Loongson Built-in Functions
@@ -11142,7 +12449,7 @@ Absolute value (@code{abs.ps}).
 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
+modulo 8, otherwise the result is unpredictable.  Please read the
 instruction description for details.
 @end table
 
@@ -11155,7 +12462,7 @@ In each case, @var{cond} can be any of the 16 floating-point conditions:
 @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},
+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:
@@ -11219,23 +12526,23 @@ 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}}).
+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}}).
+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)
+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)
+Reduced-precision reciprocal square root (sequence step 2)
 (@code{rsqrt2.@var{fmt}}).
 @end table
 
@@ -11354,6 +12661,85 @@ else
 @end smallexample
 @end table
 
+@node Other MIPS Built-in Functions
+@subsection Other MIPS Built-in Functions
+
+GCC provides other MIPS-specific built-in functions:
+
+@table @code
+@item void __builtin_mips_cache (int @var{op}, const volatile void *@var{addr})
+Insert a @samp{cache} instruction with operands @var{op} and @var{addr}.
+GCC defines the preprocessor macro @code{___GCC_HAVE_BUILTIN_MIPS_CACHE}
+when this function is available.
+
+@item unsigned int __builtin_mips_get_fcsr (void)
+@itemx void __builtin_mips_set_fcsr (unsigned int @var{value})
+Get and set the contents of the floating-point control and status register
+(FPU control register 31).  These functions are only available in hard-float
+code but can be called in both MIPS16 and non-MIPS16 contexts.
+
+@code{__builtin_mips_set_fcsr} can be used to change any bit of the
+register except the condition codes, which GCC assumes are preserved.
+@end table
+
+@node MSP430 Built-in Functions
+@subsection MSP430 Built-in Functions
+
+GCC provides a couple of special builtin functions to aid in the
+writing of interrupt handlers in C.
+
+@table @code
+@item __bic_SR_register_on_exit (int @var{mask})
+This clears the indicated bits in the saved copy of the status register
+currently residing on the stack.  This only works inside interrupt
+handlers and the changes to the status register will only take affect
+once the handler returns.
+
+@item __bis_SR_register_on_exit (int @var{mask})
+This sets the indicated bits in the saved copy of the status register
+currently residing on the stack.  This only works inside interrupt
+handlers and the changes to the status register will only take affect
+once the handler returns.
+@end table
+
+@node NDS32 Built-in Functions
+@subsection NDS32 Built-in Functions
+
+These built-in functions are available for the NDS32 target:
+
+@deftypefn {Built-in Function} void __builtin_nds32_isync (int *@var{addr})
+Insert an ISYNC instruction into the instruction stream where
+@var{addr} is an instruction address for serialization.
+@end deftypefn
+
+@deftypefn {Built-in Function} void __builtin_nds32_isb (void)
+Insert an ISB instruction into the instruction stream.
+@end deftypefn
+
+@deftypefn {Built-in Function} int __builtin_nds32_mfsr (int @var{sr})
+Return the content of a system register which is mapped by @var{sr}.
+@end deftypefn
+
+@deftypefn {Built-in Function} int __builtin_nds32_mfusr (int @var{usr})
+Return the content of a user space register which is mapped by @var{usr}.
+@end deftypefn
+
+@deftypefn {Built-in Function} void __builtin_nds32_mtsr (int @var{value}, int @var{sr})
+Move the @var{value} to a system register which is mapped by @var{sr}.
+@end deftypefn
+
+@deftypefn {Built-in Function} void __builtin_nds32_mtusr (int @var{value}, int @var{usr})
+Move the @var{value} to a user space register which is mapped by @var{usr}.
+@end deftypefn
+
+@deftypefn {Built-in Function} void __builtin_nds32_setgie_en (void)
+Enable global interrupt.
+@end deftypefn
+
+@deftypefn {Built-in Function} void __builtin_nds32_setgie_dis (void)
+Disable global interrupt.
+@end deftypefn
+
 @node picoChip Built-in Functions
 @subsection picoChip Built-in Functions
 
@@ -11363,7 +12749,7 @@ picoChip instruction set.
 @table @code
 @item int __builtin_sbc (int @var{value})
 Sign bit count.  Return the number of consecutive bits in @var{value}
-which have the same value as the sign-bit.  The result is the number of
+that have the same value as the sign bit.  The result is the number of
 leading sign bits minus one, giving the number of redundant sign bits in
 @var{value}.
 
@@ -11385,22 +12771,94 @@ Saturating subtraction.  Return the result of subtracting @var{y} from
 @var{x}, storing the value @minus{}32768 if the result overflows.
 
 @item void __builtin_halt (void)
-Halt.  The processor will stop execution.  This built-in is useful for
+Halt.  The processor stops execution.  This built-in is useful for
 implementing assertions.
 
 @end table
 
-@node Other MIPS Built-in Functions
-@subsection Other MIPS Built-in Functions
+@node PowerPC Built-in Functions
+@subsection PowerPC Built-in Functions
 
-GCC provides other MIPS-specific built-in functions:
+These built-in functions are available for the PowerPC family of
+processors:
+@smallexample
+float __builtin_recipdivf (float, float);
+float __builtin_rsqrtf (float);
+double __builtin_recipdiv (double, double);
+double __builtin_rsqrt (double);
+uint64_t __builtin_ppc_get_timebase ();
+unsigned long __builtin_ppc_mftb ();
+double __builtin_unpack_longdouble (long double, int);
+long double __builtin_pack_longdouble (double, double);
+@end smallexample
 
-@table @code
-@item void __builtin_mips_cache (int @var{op}, const volatile void *@var{addr})
-Insert a @samp{cache} instruction with operands @var{op} and @var{addr}.
-GCC defines the preprocessor macro @code{___GCC_HAVE_BUILTIN_MIPS_CACHE}
-when this function is available.
-@end table
+The @code{vec_rsqrt}, @code{__builtin_rsqrt}, and
+@code{__builtin_rsqrtf} functions generate multiple instructions to
+implement the reciprocal sqrt functionality using reciprocal sqrt
+estimate instructions.
+
+The @code{__builtin_recipdiv}, and @code{__builtin_recipdivf}
+functions generate multiple instructions to implement division using
+the reciprocal estimate instructions.
+
+The @code{__builtin_ppc_get_timebase} and @code{__builtin_ppc_mftb}
+functions generate instructions to read the Time Base Register.  The
+@code{__builtin_ppc_get_timebase} function may generate multiple
+instructions and always returns the 64 bits of the Time Base Register.
+The @code{__builtin_ppc_mftb} function always generates one instruction and
+returns the Time Base Register value as an unsigned long, throwing away
+the most significant word on 32-bit environments.
+
+The following built-in functions are available for the PowerPC family
+of processors, starting with ISA 2.06 or later (@option{-mcpu=power7}
+or @option{-mpopcntd}):
+@smallexample
+long __builtin_bpermd (long, long);
+int __builtin_divwe (int, int);
+int __builtin_divweo (int, int);
+unsigned int __builtin_divweu (unsigned int, unsigned int);
+unsigned int __builtin_divweuo (unsigned int, unsigned int);
+long __builtin_divde (long, long);
+long __builtin_divdeo (long, long);
+unsigned long __builtin_divdeu (unsigned long, unsigned long);
+unsigned long __builtin_divdeuo (unsigned long, unsigned long);
+unsigned int cdtbcd (unsigned int);
+unsigned int cbcdtd (unsigned int);
+unsigned int addg6s (unsigned int, unsigned int);
+@end smallexample
+
+The @code{__builtin_divde}, @code{__builtin_divdeo},
+@code{__builitin_divdeu}, @code{__builtin_divdeou} functions require a
+64-bit environment support ISA 2.06 or later.
+
+The following built-in functions are available for the PowerPC family
+of processors when hardware decimal floating point
+(@option{-mhard-dfp}) is available:
+@smallexample
+_Decimal64 __builtin_dxex (_Decimal64);
+_Decimal128 __builtin_dxexq (_Decimal128);
+_Decimal64 __builtin_ddedpd (int, _Decimal64);
+_Decimal128 __builtin_ddedpdq (int, _Decimal128);
+_Decimal64 __builtin_denbcd (int, _Decimal64);
+_Decimal128 __builtin_denbcdq (int, _Decimal128);
+_Decimal64 __builtin_diex (_Decimal64, _Decimal64);
+_Decimal128 _builtin_diexq (_Decimal128, _Decimal128);
+_Decimal64 __builtin_dscli (_Decimal64, int);
+_Decimal128 __builitn_dscliq (_Decimal128, int);
+_Decimal64 __builtin_dscri (_Decimal64, int);
+_Decimal128 __builitn_dscriq (_Decimal128, int);
+unsigned long long __builtin_unpack_dec128 (_Decimal128, int);
+_Decimal128 __builtin_pack_dec128 (unsigned long long, unsigned long long);
+@end smallexample
+
+The following built-in functions are available for the PowerPC family
+of processors when the Vector Scalar (vsx) instruction set is
+available:
+@smallexample
+unsigned long long __builtin_unpack_vector_int128 (vector __int128_t, int);
+vector __int128_t __builtin_pack_vector_int128 (unsigned long long,
+                                                unsigned long long);
+@end smallexample
 
 @node PowerPC AltiVec/VSX Built-in Functions
 @subsection PowerPC AltiVec Built-in Functions
@@ -11478,6 +12936,7 @@ does not work:
   vec_add ((vector signed int)@{1, 2, 3, 4@}, foo);
 @end smallexample
 
+@noindent
 Since @code{vec_add} is a macro, the vector constant in the example
 is treated as four separate arguments.  Wrap the entire argument in
 parentheses for this to work.
@@ -13451,32 +14910,629 @@ void vec_vsx_st (vector unsigned char, int, unsigned char *);
 void vec_vsx_st (vector bool char, int, vector bool char *);
 void vec_vsx_st (vector bool char, int, unsigned char *);
 void vec_vsx_st (vector bool char, int, signed char *);
-@end smallexample
 
-Note that the @samp{vec_ld} and @samp{vec_st} builtins will always
-generate the Altivec @samp{LVX} and @samp{STVX} instructions even
+vector double vec_xxpermdi (vector double, vector double, int);
+vector float vec_xxpermdi (vector float, vector float, int);
+vector long long vec_xxpermdi (vector long long, vector long long, int);
+vector unsigned long long vec_xxpermdi (vector unsigned long long,
+                                        vector unsigned long long, int);
+vector int vec_xxpermdi (vector int, vector int, int);
+vector unsigned int vec_xxpermdi (vector unsigned int,
+                                  vector unsigned int, int);
+vector short vec_xxpermdi (vector short, vector short, int);
+vector unsigned short vec_xxpermdi (vector unsigned short,
+                                    vector unsigned short, int);
+vector signed char vec_xxpermdi (vector signed char, vector signed char, int);
+vector unsigned char vec_xxpermdi (vector unsigned char,
+                                   vector unsigned char, int);
+
+vector double vec_xxsldi (vector double, vector double, int);
+vector float vec_xxsldi (vector float, vector float, int);
+vector long long vec_xxsldi (vector long long, vector long long, int);
+vector unsigned long long vec_xxsldi (vector unsigned long long,
+                                      vector unsigned long long, int);
+vector int vec_xxsldi (vector int, vector int, int);
+vector unsigned int vec_xxsldi (vector unsigned int, vector unsigned int, int);
+vector short vec_xxsldi (vector short, vector short, int);
+vector unsigned short vec_xxsldi (vector unsigned short,
+                                  vector unsigned short, int);
+vector signed char vec_xxsldi (vector signed char, vector signed char, int);
+vector unsigned char vec_xxsldi (vector unsigned char,
+                                 vector unsigned char, int);
+@end smallexample
+
+Note that the @samp{vec_ld} and @samp{vec_st} built-in functions always
+generate the AltiVec @samp{LVX} and @samp{STVX} instructions even
 if the VSX instruction set is available.  The @samp{vec_vsx_ld} and
-@samp{vec_vsx_st} builtins will always generate the VSX @samp{LXVD2X},
+@samp{vec_vsx_st} built-in functions always generate the VSX @samp{LXVD2X},
 @samp{LXVW4X}, @samp{STXVD2X}, and @samp{STXVW4X} instructions.
 
-GCC provides a few other builtins on Powerpc to access certain instructions:
+If the ISA 2.07 additions to the vector/scalar (power8-vector)
+instruction set is available, the following additional functions are
+available for both 32-bit and 64-bit targets.  For 64-bit targets, you
+can use @var{vector long} instead of @var{vector long long},
+@var{vector bool long} instead of @var{vector bool long long}, and
+@var{vector unsigned long} instead of @var{vector unsigned long long}.
+
+@smallexample
+vector long long vec_abs (vector long long);
+
+vector long long vec_add (vector long long, vector long long);
+vector unsigned long long vec_add (vector unsigned long long,
+                                   vector unsigned long long);
+
+int vec_all_eq (vector long long, vector long long);
+int vec_all_ge (vector long long, vector long long);
+int vec_all_gt (vector long long, vector long long);
+int vec_all_le (vector long long, vector long long);
+int vec_all_lt (vector long long, vector long long);
+int vec_all_ne (vector long long, vector long long);
+int vec_any_eq (vector long long, vector long long);
+int vec_any_ge (vector long long, vector long long);
+int vec_any_gt (vector long long, vector long long);
+int vec_any_le (vector long long, vector long long);
+int vec_any_lt (vector long long, vector long long);
+int vec_any_ne (vector long long, vector long long);
+
+vector long long vec_eqv (vector long long, vector long long);
+vector long long vec_eqv (vector bool long long, vector long long);
+vector long long vec_eqv (vector long long, vector bool long long);
+vector unsigned long long vec_eqv (vector unsigned long long,
+                                   vector unsigned long long);
+vector unsigned long long vec_eqv (vector bool long long,
+                                   vector unsigned long long);
+vector unsigned long long vec_eqv (vector unsigned long long,
+                                   vector bool long long);
+vector int vec_eqv (vector int, vector int);
+vector int vec_eqv (vector bool int, vector int);
+vector int vec_eqv (vector int, vector bool int);
+vector unsigned int vec_eqv (vector unsigned int, vector unsigned int);
+vector unsigned int vec_eqv (vector bool unsigned int,
+                             vector unsigned int);
+vector unsigned int vec_eqv (vector unsigned int,
+                             vector bool unsigned int);
+vector short vec_eqv (vector short, vector short);
+vector short vec_eqv (vector bool short, vector short);
+vector short vec_eqv (vector short, vector bool short);
+vector unsigned short vec_eqv (vector unsigned short, vector unsigned short);
+vector unsigned short vec_eqv (vector bool unsigned short,
+                               vector unsigned short);
+vector unsigned short vec_eqv (vector unsigned short,
+                               vector bool unsigned short);
+vector signed char vec_eqv (vector signed char, vector signed char);
+vector signed char vec_eqv (vector bool signed char, vector signed char);
+vector signed char vec_eqv (vector signed char, vector bool signed char);
+vector unsigned char vec_eqv (vector unsigned char, vector unsigned char);
+vector unsigned char vec_eqv (vector bool unsigned char, vector unsigned char);
+vector unsigned char vec_eqv (vector unsigned char, vector bool unsigned char);
+
+vector long long vec_max (vector long long, vector long long);
+vector unsigned long long vec_max (vector unsigned long long,
+                                   vector unsigned long long);
+
+vector long long vec_min (vector long long, vector long long);
+vector unsigned long long vec_min (vector unsigned long long,
+                                   vector unsigned long long);
+
+vector long long vec_nand (vector long long, vector long long);
+vector long long vec_nand (vector bool long long, vector long long);
+vector long long vec_nand (vector long long, vector bool long long);
+vector unsigned long long vec_nand (vector unsigned long long,
+                                    vector unsigned long long);
+vector unsigned long long vec_nand (vector bool long long,
+                                   vector unsigned long long);
+vector unsigned long long vec_nand (vector unsigned long long,
+                                    vector bool long long);
+vector int vec_nand (vector int, vector int);
+vector int vec_nand (vector bool int, vector int);
+vector int vec_nand (vector int, vector bool int);
+vector unsigned int vec_nand (vector unsigned int, vector unsigned int);
+vector unsigned int vec_nand (vector bool unsigned int,
+                              vector unsigned int);
+vector unsigned int vec_nand (vector unsigned int,
+                              vector bool unsigned int);
+vector short vec_nand (vector short, vector short);
+vector short vec_nand (vector bool short, vector short);
+vector short vec_nand (vector short, vector bool short);
+vector unsigned short vec_nand (vector unsigned short, vector unsigned short);
+vector unsigned short vec_nand (vector bool unsigned short,
+                                vector unsigned short);
+vector unsigned short vec_nand (vector unsigned short,
+                                vector bool unsigned short);
+vector signed char vec_nand (vector signed char, vector signed char);
+vector signed char vec_nand (vector bool signed char, vector signed char);
+vector signed char vec_nand (vector signed char, vector bool signed char);
+vector unsigned char vec_nand (vector unsigned char, vector unsigned char);
+vector unsigned char vec_nand (vector bool unsigned char, vector unsigned char);
+vector unsigned char vec_nand (vector unsigned char, vector bool unsigned char);
+
+vector long long vec_orc (vector long long, vector long long);
+vector long long vec_orc (vector bool long long, vector long long);
+vector long long vec_orc (vector long long, vector bool long long);
+vector unsigned long long vec_orc (vector unsigned long long,
+                                   vector unsigned long long);
+vector unsigned long long vec_orc (vector bool long long,
+                                   vector unsigned long long);
+vector unsigned long long vec_orc (vector unsigned long long,
+                                   vector bool long long);
+vector int vec_orc (vector int, vector int);
+vector int vec_orc (vector bool int, vector int);
+vector int vec_orc (vector int, vector bool int);
+vector unsigned int vec_orc (vector unsigned int, vector unsigned int);
+vector unsigned int vec_orc (vector bool unsigned int,
+                             vector unsigned int);
+vector unsigned int vec_orc (vector unsigned int,
+                             vector bool unsigned int);
+vector short vec_orc (vector short, vector short);
+vector short vec_orc (vector bool short, vector short);
+vector short vec_orc (vector short, vector bool short);
+vector unsigned short vec_orc (vector unsigned short, vector unsigned short);
+vector unsigned short vec_orc (vector bool unsigned short,
+                               vector unsigned short);
+vector unsigned short vec_orc (vector unsigned short,
+                               vector bool unsigned short);
+vector signed char vec_orc (vector signed char, vector signed char);
+vector signed char vec_orc (vector bool signed char, vector signed char);
+vector signed char vec_orc (vector signed char, vector bool signed char);
+vector unsigned char vec_orc (vector unsigned char, vector unsigned char);
+vector unsigned char vec_orc (vector bool unsigned char, vector unsigned char);
+vector unsigned char vec_orc (vector unsigned char, vector bool unsigned char);
+
+vector int vec_pack (vector long long, vector long long);
+vector unsigned int vec_pack (vector unsigned long long,
+                              vector unsigned long long);
+vector bool int vec_pack (vector bool long long, vector bool long long);
+
+vector int vec_packs (vector long long, vector long long);
+vector unsigned int vec_packs (vector unsigned long long,
+                               vector unsigned long long);
+
+vector unsigned int vec_packsu (vector long long, vector long long);
+
+vector long long vec_rl (vector long long,
+                         vector unsigned long long);
+vector long long vec_rl (vector unsigned long long,
+                         vector unsigned long long);
+
+vector long long vec_sl (vector long long, vector unsigned long long);
+vector long long vec_sl (vector unsigned long long,
+                         vector unsigned long long);
+
+vector long long vec_sr (vector long long, vector unsigned long long);
+vector unsigned long long char vec_sr (vector unsigned long long,
+                                       vector unsigned long long);
+
+vector long long vec_sra (vector long long, vector unsigned long long);
+vector unsigned long long vec_sra (vector unsigned long long,
+                                   vector unsigned long long);
+
+vector long long vec_sub (vector long long, vector long long);
+vector unsigned long long vec_sub (vector unsigned long long,
+                                   vector unsigned long long);
+
+vector long long vec_unpackh (vector int);
+vector unsigned long long vec_unpackh (vector unsigned int);
+
+vector long long vec_unpackl (vector int);
+vector unsigned long long vec_unpackl (vector unsigned int);
+
+vector long long vec_vaddudm (vector long long, vector long long);
+vector long long vec_vaddudm (vector bool long long, vector long long);
+vector long long vec_vaddudm (vector long long, vector bool long long);
+vector unsigned long long vec_vaddudm (vector unsigned long long,
+                                       vector unsigned long long);
+vector unsigned long long vec_vaddudm (vector bool unsigned long long,
+                                       vector unsigned long long);
+vector unsigned long long vec_vaddudm (vector unsigned long long,
+                                       vector bool unsigned long long);
+
+vector long long vec_vbpermq (vector signed char, vector signed char);
+vector long long vec_vbpermq (vector unsigned char, vector unsigned char);
+
+vector long long vec_vclz (vector long long);
+vector unsigned long long vec_vclz (vector unsigned long long);
+vector int vec_vclz (vector int);
+vector unsigned int vec_vclz (vector int);
+vector short vec_vclz (vector short);
+vector unsigned short vec_vclz (vector unsigned short);
+vector signed char vec_vclz (vector signed char);
+vector unsigned char vec_vclz (vector unsigned char);
+
+vector signed char vec_vclzb (vector signed char);
+vector unsigned char vec_vclzb (vector unsigned char);
+
+vector long long vec_vclzd (vector long long);
+vector unsigned long long vec_vclzd (vector unsigned long long);
+
+vector short vec_vclzh (vector short);
+vector unsigned short vec_vclzh (vector unsigned short);
+
+vector int vec_vclzw (vector int);
+vector unsigned int vec_vclzw (vector int);
+
+vector signed char vec_vgbbd (vector signed char);
+vector unsigned char vec_vgbbd (vector unsigned char);
+
+vector long long vec_vmaxsd (vector long long, vector long long);
+
+vector unsigned long long vec_vmaxud (vector unsigned long long,
+                                      unsigned vector long long);
+
+vector long long vec_vminsd (vector long long, vector long long);
+
+vector unsigned long long vec_vminud (vector long long,
+                                      vector long long);
+
+vector int vec_vpksdss (vector long long, vector long long);
+vector unsigned int vec_vpksdss (vector long long, vector long long);
+
+vector unsigned int vec_vpkudus (vector unsigned long long,
+                                 vector unsigned long long);
+
+vector int vec_vpkudum (vector long long, vector long long);
+vector unsigned int vec_vpkudum (vector unsigned long long,
+                                 vector unsigned long long);
+vector bool int vec_vpkudum (vector bool long long, vector bool long long);
+
+vector long long vec_vpopcnt (vector long long);
+vector unsigned long long vec_vpopcnt (vector unsigned long long);
+vector int vec_vpopcnt (vector int);
+vector unsigned int vec_vpopcnt (vector int);
+vector short vec_vpopcnt (vector short);
+vector unsigned short vec_vpopcnt (vector unsigned short);
+vector signed char vec_vpopcnt (vector signed char);
+vector unsigned char vec_vpopcnt (vector unsigned char);
+
+vector signed char vec_vpopcntb (vector signed char);
+vector unsigned char vec_vpopcntb (vector unsigned char);
+
+vector long long vec_vpopcntd (vector long long);
+vector unsigned long long vec_vpopcntd (vector unsigned long long);
+
+vector short vec_vpopcnth (vector short);
+vector unsigned short vec_vpopcnth (vector unsigned short);
+
+vector int vec_vpopcntw (vector int);
+vector unsigned int vec_vpopcntw (vector int);
+
+vector long long vec_vrld (vector long long, vector unsigned long long);
+vector unsigned long long vec_vrld (vector unsigned long long,
+                                    vector unsigned long long);
+
+vector long long vec_vsld (vector long long, vector unsigned long long);
+vector long long vec_vsld (vector unsigned long long,
+                           vector unsigned long long);
+
+vector long long vec_vsrad (vector long long, vector unsigned long long);
+vector unsigned long long vec_vsrad (vector unsigned long long,
+                                     vector unsigned long long);
+
+vector long long vec_vsrd (vector long long, vector unsigned long long);
+vector unsigned long long char vec_vsrd (vector unsigned long long,
+                                         vector unsigned long long);
+
+vector long long vec_vsubudm (vector long long, vector long long);
+vector long long vec_vsubudm (vector bool long long, vector long long);
+vector long long vec_vsubudm (vector long long, vector bool long long);
+vector unsigned long long vec_vsubudm (vector unsigned long long,
+                                       vector unsigned long long);
+vector unsigned long long vec_vsubudm (vector bool long long,
+                                       vector unsigned long long);
+vector unsigned long long vec_vsubudm (vector unsigned long long,
+                                       vector bool long long);
+
+vector long long vec_vupkhsw (vector int);
+vector unsigned long long vec_vupkhsw (vector unsigned int);
+
+vector long long vec_vupklsw (vector int);
+vector unsigned long long vec_vupklsw (vector int);
+@end smallexample
+
+If the ISA 2.07 additions to the vector/scalar (power8-vector)
+instruction set is available, the following additional functions are
+available for 64-bit targets.  New vector types
+(@var{vector __int128_t} and @var{vector __uint128_t}) are available
+to hold the @var{__int128_t} and @var{__uint128_t} types to use these
+builtins.
+
+The normal vector extract, and set operations work on
+@var{vector __int128_t} and @var{vector __uint128_t} types,
+but the index value must be 0.
+
 @smallexample
-float __builtin_recipdivf (float, float);
-float __builtin_rsqrtf (float);
-double __builtin_recipdiv (double, double);
-double __builtin_rsqrt (double);
-long __builtin_bpermd (long, long);
-int __builtin_bswap16 (int);
+vector __int128_t vec_vaddcuq (vector __int128_t, vector __int128_t);
+vector __uint128_t vec_vaddcuq (vector __uint128_t, vector __uint128_t);
+
+vector __int128_t vec_vadduqm (vector __int128_t, vector __int128_t);
+vector __uint128_t vec_vadduqm (vector __uint128_t, vector __uint128_t);
+
+vector __int128_t vec_vaddecuq (vector __int128_t, vector __int128_t,
+                                vector __int128_t);
+vector __uint128_t vec_vaddecuq (vector __uint128_t, vector __uint128_t, 
+                                 vector __uint128_t);
+
+vector __int128_t vec_vaddeuqm (vector __int128_t, vector __int128_t,
+                                vector __int128_t);
+vector __uint128_t vec_vaddeuqm (vector __uint128_t, vector __uint128_t, 
+                                 vector __uint128_t);
+
+vector __int128_t vec_vsubecuq (vector __int128_t, vector __int128_t,
+                                vector __int128_t);
+vector __uint128_t vec_vsubecuq (vector __uint128_t, vector __uint128_t, 
+                                 vector __uint128_t);
+
+vector __int128_t vec_vsubeuqm (vector __int128_t, vector __int128_t,
+                                vector __int128_t);
+vector __uint128_t vec_vsubeuqm (vector __uint128_t, vector __uint128_t,
+                                 vector __uint128_t);
+
+vector __int128_t vec_vsubcuq (vector __int128_t, vector __int128_t);
+vector __uint128_t vec_vsubcuq (vector __uint128_t, vector __uint128_t);
+
+__int128_t vec_vsubuqm (__int128_t, __int128_t);
+__uint128_t vec_vsubuqm (__uint128_t, __uint128_t);
+
+vector __int128_t __builtin_bcdadd (vector __int128_t, vector__int128_t);
+int __builtin_bcdadd_lt (vector __int128_t, vector__int128_t);
+int __builtin_bcdadd_eq (vector __int128_t, vector__int128_t);
+int __builtin_bcdadd_gt (vector __int128_t, vector__int128_t);
+int __builtin_bcdadd_ov (vector __int128_t, vector__int128_t);
+vector __int128_t bcdsub (vector __int128_t, vector__int128_t);
+int __builtin_bcdsub_lt (vector __int128_t, vector__int128_t);
+int __builtin_bcdsub_eq (vector __int128_t, vector__int128_t);
+int __builtin_bcdsub_gt (vector __int128_t, vector__int128_t);
+int __builtin_bcdsub_ov (vector __int128_t, vector__int128_t);
 @end smallexample
 
-The @code{vec_rsqrt}, @code{__builtin_rsqrt}, and
-@code{__builtin_rsqrtf} functions generate multiple instructions to
-implement the reciprocal sqrt functionality using reciprocal sqrt
-estimate instructions.
+If the cryptographic instructions are enabled (@option{-mcrypto} or
+@option{-mcpu=power8}), the following builtins are enabled.
 
-The @code{__builtin_recipdiv}, and @code{__builtin_recipdivf}
-functions generate multiple instructions to implement division using
-the reciprocal estimate instructions.
+@smallexample
+vector unsigned long long __builtin_crypto_vsbox (vector unsigned long long);
+
+vector unsigned long long __builtin_crypto_vcipher (vector unsigned long long,
+                                                    vector unsigned long long);
+
+vector unsigned long long __builtin_crypto_vcipherlast
+                                     (vector unsigned long long,
+                                      vector unsigned long long);
+
+vector unsigned long long __builtin_crypto_vncipher (vector unsigned long long,
+                                                     vector unsigned long long);
+
+vector unsigned long long __builtin_crypto_vncipherlast
+                                     (vector unsigned long long,
+                                      vector unsigned long long);
+
+vector unsigned char __builtin_crypto_vpermxor (vector unsigned char,
+                                                vector unsigned char,
+                                                vector unsigned char);
+
+vector unsigned short __builtin_crypto_vpermxor (vector unsigned short,
+                                                 vector unsigned short,
+                                                 vector unsigned short);
+
+vector unsigned int __builtin_crypto_vpermxor (vector unsigned int,
+                                               vector unsigned int,
+                                               vector unsigned int);
+
+vector unsigned long long __builtin_crypto_vpermxor (vector unsigned long long,
+                                                     vector unsigned long long,
+                                                     vector unsigned long long);
+
+vector unsigned char __builtin_crypto_vpmsumb (vector unsigned char,
+                                               vector unsigned char);
+
+vector unsigned short __builtin_crypto_vpmsumb (vector unsigned short,
+                                                vector unsigned short);
+
+vector unsigned int __builtin_crypto_vpmsumb (vector unsigned int,
+                                              vector unsigned int);
+
+vector unsigned long long __builtin_crypto_vpmsumb (vector unsigned long long,
+                                                    vector unsigned long long);
+
+vector unsigned long long __builtin_crypto_vshasigmad
+                               (vector unsigned long long, int, int);
+
+vector unsigned int __builtin_crypto_vshasigmaw (vector unsigned int,
+                                                 int, int);
+@end smallexample
+
+The second argument to the @var{__builtin_crypto_vshasigmad} and
+@var{__builtin_crypto_vshasigmaw} builtin functions must be a constant
+integer that is 0 or 1.  The third argument to these builtin functions
+must be a constant integer in the range of 0 to 15.
+
+@node PowerPC Hardware Transactional Memory Built-in Functions
+@subsection PowerPC Hardware Transactional Memory Built-in Functions
+GCC provides two interfaces for accessing the Hardware Transactional
+Memory (HTM) instructions available on some of the PowerPC family
+of prcoessors (eg, POWER8).  The two interfaces come in a low level
+interface, consisting of built-in functions specific to PowerPC and a
+higher level interface consisting of inline functions that are common
+between PowerPC and S/390.
+
+@subsubsection PowerPC HTM Low Level Built-in Functions
+
+The following low level built-in functions are available with
+@option{-mhtm} or @option{-mcpu=CPU} where CPU is `power8' or later.
+They all generate the machine instruction that is part of the name.
+
+The HTM built-ins return true or false depending on their success and
+their arguments match exactly the type and order of the associated
+hardware instruction's operands.  Refer to the ISA manual for a
+description of each instruction's operands.
+
+@smallexample
+unsigned int __builtin_tbegin (unsigned int)
+unsigned int __builtin_tend (unsigned int)
+
+unsigned int __builtin_tabort (unsigned int)
+unsigned int __builtin_tabortdc (unsigned int, unsigned int, unsigned int)
+unsigned int __builtin_tabortdci (unsigned int, unsigned int, int)
+unsigned int __builtin_tabortwc (unsigned int, unsigned int, unsigned int)
+unsigned int __builtin_tabortwci (unsigned int, unsigned int, int)
+
+unsigned int __builtin_tcheck (unsigned int)
+unsigned int __builtin_treclaim (unsigned int)
+unsigned int __builtin_trechkpt (void)
+unsigned int __builtin_tsr (unsigned int)
+@end smallexample
+
+In addition to the above HTM built-ins, we have added built-ins for
+some common extended mnemonics of the HTM instructions:
+
+@smallexample
+unsigned int __builtin_tendall (void)
+unsigned int __builtin_tresume (void)
+unsigned int __builtin_tsuspend (void)
+@end smallexample
+
+The following set of built-in functions are available to gain access
+to the HTM specific special purpose registers.
+
+@smallexample
+unsigned long __builtin_get_texasr (void)
+unsigned long __builtin_get_texasru (void)
+unsigned long __builtin_get_tfhar (void)
+unsigned long __builtin_get_tfiar (void)
+
+void __builtin_set_texasr (unsigned long);
+void __builtin_set_texasru (unsigned long);
+void __builtin_set_tfhar (unsigned long);
+void __builtin_set_tfiar (unsigned long);
+@end smallexample
+
+Example usage of these low level built-in functions may look like:
+
+@smallexample
+#include <htmintrin.h>
+
+int num_retries = 10;
+
+while (1)
+  @{
+    if (__builtin_tbegin (0))
+      @{
+        /* Transaction State Initiated.  */
+        if (is_locked (lock))
+          __builtin_tabort (0);
+        ... transaction code...
+        __builtin_tend (0);
+        break;
+      @}
+    else
+      @{
+        /* Transaction State Failed.  Use locks if the transaction
+           failure is "persistent" or we've tried too many times.  */
+        if (num_retries-- <= 0
+            || _TEXASRU_FAILURE_PERSISTENT (__builtin_get_texasru ()))
+          @{
+            acquire_lock (lock);
+            ... non transactional fallback path...
+            release_lock (lock);
+            break;
+          @}
+      @}
+  @}
+@end smallexample
+
+One final built-in function has been added that returns the value of
+the 2-bit Transaction State field of the Machine Status Register (MSR)
+as stored in @code{CR0}.
+
+@smallexample
+unsigned long __builtin_ttest (void)
+@end smallexample
+
+This built-in can be used to determine the current transaction state
+using the following code example:
+
+@smallexample
+#include <htmintrin.h>
+
+unsigned char tx_state = _HTM_STATE (__builtin_ttest ());
+
+if (tx_state == _HTM_TRANSACTIONAL)
+  @{
+    /* Code to use in transactional state.  */
+  @}
+else if (tx_state == _HTM_NONTRANSACTIONAL)
+  @{
+    /* Code to use in non-transactional state.  */
+  @}
+else if (tx_state == _HTM_SUSPENDED)
+  @{
+    /* Code to use in transaction suspended state.  */
+  @}
+@end smallexample
+
+@subsubsection PowerPC HTM High Level Inline Functions
+
+The following high level HTM interface is made available by including
+@code{<htmxlintrin.h>} and using @option{-mhtm} or @option{-mcpu=CPU}
+where CPU is `power8' or later.  This interface is common between PowerPC
+and S/390, allowing users to write one HTM source implementation that
+can be compiled and executed on either system.
+
+@smallexample
+long __TM_simple_begin (void)
+long __TM_begin (void* const TM_buff)
+long __TM_end (void)
+void __TM_abort (void)
+void __TM_named_abort (unsigned char const code)
+void __TM_resume (void)
+void __TM_suspend (void)
+
+long __TM_is_user_abort (void* const TM_buff)
+long __TM_is_named_user_abort (void* const TM_buff, unsigned char *code)
+long __TM_is_illegal (void* const TM_buff)
+long __TM_is_footprint_exceeded (void* const TM_buff)
+long __TM_nesting_depth (void* const TM_buff)
+long __TM_is_nested_too_deep(void* const TM_buff)
+long __TM_is_conflict(void* const TM_buff)
+long __TM_is_failure_persistent(void* const TM_buff)
+long __TM_failure_address(void* const TM_buff)
+long long __TM_failure_code(void* const TM_buff)
+@end smallexample
+
+Using these common set of HTM inline functions, we can create
+a more portable version of the HTM example in the previous
+section that will work on either PowerPC or S/390:
+
+@smallexample
+#include <htmxlintrin.h>
+
+int num_retries = 10;
+TM_buff_type TM_buff;
+
+while (1)
+  @{
+    if (__TM_begin (TM_buff))
+      @{
+        /* Transaction State Initiated.  */
+        if (is_locked (lock))
+          __TM_abort ();
+        ... transaction code...
+        __TM_end ();
+        break;
+      @}
+    else
+      @{
+        /* Transaction State Failed.  Use locks if the transaction
+           failure is "persistent" or we've tried too many times.  */
+        if (num_retries-- <= 0
+            || __TM_is_failure_persistent (TM_buff))
+          @{
+            acquire_lock (lock);
+            ... non transactional fallback path...
+            release_lock (lock);
+            break;
+          @}
+      @}
+  @}
+@end smallexample
 
 @node RX Built-in Functions
 @subsection RX Built-in Functions
@@ -13500,36 +15556,36 @@ with the specified value.
 
 @deftypefn {Built-in Function}  void __builtin_rx_machi (int, int)
 Generates the @code{machi} machine instruction to add the result of
-multiplying the top 16-bits of the two arguments into the
+multiplying the top 16 bits of the two arguments into the
 accumulator.
 @end deftypefn
 
 @deftypefn {Built-in Function}  void __builtin_rx_maclo (int, int)
 Generates the @code{maclo} machine instruction to add the result of
-multiplying the bottom 16-bits of the two arguments into the
+multiplying the bottom 16 bits of the two arguments into the
 accumulator.
 @end deftypefn
 
 @deftypefn {Built-in Function}  void __builtin_rx_mulhi (int, int)
 Generates the @code{mulhi} machine instruction to place the result of
-multiplying the top 16-bits of the two arguments into the
+multiplying the top 16 bits of the two arguments into the
 accumulator.
 @end deftypefn
 
 @deftypefn {Built-in Function}  void __builtin_rx_mullo (int, int)
 Generates the @code{mullo} machine instruction to place the result of
-multiplying the bottom 16-bits of the two arguments into the
+multiplying the bottom 16 bits of the two arguments into the
 accumulator.
 @end deftypefn
 
 @deftypefn {Built-in Function}  int  __builtin_rx_mvfachi (void)
 Generates the @code{mvfachi} machine instruction to read the top
-32-bits of the accumulator.
+32 bits of the accumulator.
 @end deftypefn
 
 @deftypefn {Built-in Function}  int  __builtin_rx_mvfacmi (void)
 Generates the @code{mvfacmi} machine instruction to read the middle
-32-bits of the accumulator.
+32 bits of the accumulator.
 @end deftypefn
 
 @deftypefn {Built-in Function}  int __builtin_rx_mvfc (int)
@@ -13539,12 +15595,12 @@ register specified in its argument and returns its value.
 
 @deftypefn {Built-in Function}  void __builtin_rx_mvtachi (int)
 Generates the @code{mvtachi} machine instruction to set the top
-32-bits of the accumulator.
+32 bits of the accumulator.
 @end deftypefn
 
 @deftypefn {Built-in Function}  void __builtin_rx_mvtaclo (int)
 Generates the @code{mvtaclo} machine instruction to set the bottom
-32-bits of the accumulator.
+32 bits of the accumulator.
 @end deftypefn
 
 @deftypefn {Built-in Function}  void __builtin_rx_mvtc (int reg, int val)
@@ -13575,8 +15631,8 @@ repeated multiply and accumulate sequence.
 
 @deftypefn {Built-in Function}  void __builtin_rx_round (float)
 Generates the @code{round} machine instruction which returns the
-floating point argument rounded according to the current rounding mode
-set in the floating point status word register.
+floating-point argument rounded according to the current rounding mode
+set in the floating-point status word register.
 @end deftypefn
 
 @deftypefn {Built-in Function}  int __builtin_rx_sat (int)
@@ -13593,6 +15649,155 @@ bit in the processor status word.
 Generates the @code{wait} machine instruction.
 @end deftypefn
 
+@node S/390 System z Built-in Functions
+@subsection S/390 System z Built-in Functions
+@deftypefn {Built-in Function} int __builtin_tbegin (void*)
+Generates the @code{tbegin} machine instruction starting a
+non-constraint hardware transaction.  If the parameter is non-NULL the
+memory area is used to store the transaction diagnostic buffer and
+will be passed as first operand to @code{tbegin}.  This buffer can be
+defined using the @code{struct __htm_tdb} C struct defined in
+@code{htmintrin.h} and must reside on a double-word boundary.  The
+second tbegin operand is set to @code{0xff0c}. This enables
+save/restore of all GPRs and disables aborts for FPR and AR
+manipulations inside the transaction body.  The condition code set by
+the tbegin instruction is returned as integer value.  The tbegin
+instruction by definition overwrites the content of all FPRs.  The
+compiler will generate code which saves and restores the FPRs.  For
+soft-float code it is recommended to used the @code{*_nofloat}
+variant.  In order to prevent a TDB from being written it is required
+to pass an constant zero value as parameter.  Passing the zero value
+through a variable is not sufficient.  Although modifications of
+access registers inside the transaction will not trigger an
+transaction abort it is not supported to actually modify them.  Access
+registers do not get saved when entering a transaction. They will have
+undefined state when reaching the abort code.
+@end deftypefn
+
+Macros for the possible return codes of tbegin are defined in the
+@code{htmintrin.h} header file:
+
+@table @code
+@item _HTM_TBEGIN_STARTED
+@code{tbegin} has been executed as part of normal processing.  The
+transaction body is supposed to be executed.
+@item _HTM_TBEGIN_INDETERMINATE
+The transaction was aborted due to an indeterminate condition which
+might be persistent.
+@item _HTM_TBEGIN_TRANSIENT
+The transaction aborted due to a transient failure.  The transaction
+should be re-executed in that case.
+@item _HTM_TBEGIN_PERSISTENT
+The transaction aborted due to a persistent failure.  Re-execution
+under same circumstances will not be productive.
+@end table
+
+@defmac _HTM_FIRST_USER_ABORT_CODE
+The @code{_HTM_FIRST_USER_ABORT_CODE} defined in @code{htmintrin.h}
+specifies the first abort code which can be used for
+@code{__builtin_tabort}.  Values below this threshold are reserved for
+machine use.
+@end defmac
+
+@deftp {Data type} {struct __htm_tdb}
+The @code{struct __htm_tdb} defined in @code{htmintrin.h} describes
+the structure of the transaction diagnostic block as specified in the
+Principles of Operation manual chapter 5-91.
+@end deftp
+
+@deftypefn {Built-in Function} int __builtin_tbegin_nofloat (void*)
+Same as @code{__builtin_tbegin} but without FPR saves and restores.
+Using this variant in code making use of FPRs will leave the FPRs in
+undefined state when entering the transaction abort handler code.
+@end deftypefn
+
+@deftypefn {Built-in Function} int __builtin_tbegin_retry (void*, int)
+In addition to @code{__builtin_tbegin} a loop for transient failures
+is generated.  If tbegin returns a condition code of 2 the transaction
+will be retried as often as specified in the second argument.  The
+perform processor assist instruction is used to tell the CPU about the
+number of fails so far.
+@end deftypefn
+
+@deftypefn {Built-in Function} int __builtin_tbegin_retry_nofloat (void*, int)
+Same as @code{__builtin_tbegin_retry} but without FPR saves and
+restores.  Using this variant in code making use of FPRs will leave
+the FPRs in undefined state when entering the transaction abort
+handler code.
+@end deftypefn
+
+@deftypefn {Built-in Function} void __builtin_tbeginc (void)
+Generates the @code{tbeginc} machine instruction starting a constraint
+hardware transaction.  The second operand is set to @code{0xff08}.
+@end deftypefn
+
+@deftypefn {Built-in Function} int __builtin_tend (void)
+Generates the @code{tend} machine instruction finishing a transaction
+and making the changes visible to other threads.  The condition code
+generated by tend is returned as integer value.
+@end deftypefn
+
+@deftypefn {Built-in Function} void __builtin_tabort (int)
+Generates the @code{tabort} machine instruction with the specified
+abort code.  Abort codes from 0 through 255 are reserved and will
+result in an error message.
+@end deftypefn
+
+@deftypefn {Built-in Function} void __builtin_tx_assist (int)
+Generates the @code{ppa rX,rY,1} machine instruction.  Where the
+integer parameter is loaded into rX and a value of zero is loaded into
+rY.  The integer parameter specifies the number of times the
+transaction repeatedly aborted.
+@end deftypefn
+
+@deftypefn {Built-in Function} int __builtin_tx_nesting_depth (void)
+Generates the @code{etnd} machine instruction.  The current nesting
+depth is returned as integer value.  For a nesting depth of 0 the code
+is not executed as part of an transaction.
+@end deftypefn
+
+@deftypefn {Built-in Function} void __builtin_non_tx_store (uint64_t *, uint64_t)
+
+Generates the @code{ntstg} machine instruction.  The second argument
+is written to the first arguments location.  The store operation will
+not be rolled-back in case of an transaction abort.
+@end deftypefn
+
+@node SH Built-in Functions
+@subsection SH Built-in Functions
+The following built-in functions are supported on the SH1, SH2, SH3 and SH4
+families of processors:
+
+@deftypefn {Built-in Function} {void} __builtin_set_thread_pointer (void *@var{ptr})
+Sets the @samp{GBR} register to the specified value @var{ptr}.  This is usually
+used by system code that manages threads and execution contexts.  The compiler
+normally does not generate code that modifies the contents of @samp{GBR} and
+thus the value is preserved across function calls.  Changing the @samp{GBR}
+value in user code must be done with caution, since the compiler might use
+@samp{GBR} in order to access thread local variables.
+
+@end deftypefn
+
+@deftypefn {Built-in Function} {void *} __builtin_thread_pointer (void)
+Returns the value that is currently set in the @samp{GBR} register.
+Memory loads and stores that use the thread pointer as a base address are
+turned into @samp{GBR} based displacement loads and stores, if possible.
+For example:
+@smallexample
+struct my_tcb
+@{
+   int a, b, c, d, e;
+@};
+
+int get_tcb_value (void)
+@{
+  // Generate @samp{mov.l @@(8,gbr),r0} instruction
+  return ((my_tcb*)__builtin_thread_pointer ())->c;
+@}
+
+@end smallexample
+@end deftypefn
+
 @node SPARC VIS Built-in Functions
 @subsection SPARC VIS Built-in Functions
 
@@ -13778,6 +15983,7 @@ does not work:
   spu_add ((vector signed int)@{1, 2, 3, 4@}, foo);
 @end smallexample
 
+@noindent
 Since @code{spu_add} is a macro, the vector constant in the example
 is treated as four separate arguments.  Wrap the entire argument in
 parentheses for this to work.
@@ -13863,7 +16069,7 @@ void __tile_udn_send (unsigned long long)
 @end smallexample
 
 The intrinsic @code{void __tile_network_barrier (void)} is used to
-guarantee that no network operatons before it will be reordered with
+guarantee that no network operations before it are reordered with
 those after it.
 
 @node TILEPro Built-in Functions
@@ -13878,7 +16084,8 @@ unsigned __insn_@var{op} (...)
 
 @end smallexample
 
-Where @var{op} is the name of the instruction.  Refer to the ISA manual
+@noindent
+where @var{op} is the name of the instruction.  Refer to the ISA manual
 for the complete list of instructions.
 
 GCC also provides intrinsics to directly access the network registers.
@@ -13900,7 +16107,7 @@ void __tile_udn_send (unsigned)
 @end smallexample
 
 The intrinsic @code{void __tile_network_barrier (void)} is used to
-guarantee that no network operatons before it will be reordered with
+guarantee that no network operations before it are reordered with
 those after it.
 
 @node Target Format Checks
@@ -13927,9 +16134,9 @@ bit-fields.  See the Solaris man page for @code{cmn_err} for more information.
 @subsection Darwin Format Checks
 
 Darwin targets support the @code{CFString} (or @code{__CFString__}) in the format
-attribute context.  Declarations made with such attribution will be parsed for correct syntax
+attribute context.  Declarations made with such attribution are parsed for correct syntax
 and format argument types.  However, parsing of the format string itself is currently undefined
-and will not be carried out by this version of the compiler.
+and is not carried out by this version of the compiler.
 
 Additionally, @code{CFStringRefs} (defined by the @code{CoreFoundation} headers) may
 also be used as format arguments.  Note that the relevant headers are only likely to be
@@ -13961,6 +16168,7 @@ for further explanation.
 * Visibility Pragmas::
 * Push/Pop Macro Pragmas::
 * Function Specific Option Pragmas::
+* Loop-Specific Pragmas::
 @end menu
 
 @node ARM Pragmas
@@ -14009,10 +16217,10 @@ compatibility with other compilers, but note that the common
 @code{1234H} numeric syntax is not supported (use @code{0x1234}
 instead).  Example:
 
-@example
+@smallexample
 #pragma ADDRESS port3 0x103
 char port3;
-@end example
+@end smallexample
 
 @end table
 
@@ -14023,7 +16231,7 @@ char port3;
 
 @item custom io_volatile (on|off)
 @cindex pragma, custom io_volatile
-Overrides the command line option @code{-mio-volatile} for the current
+Overrides the command-line option @code{-mio-volatile} for the current
 file.  Note that for compatibility with future GCC releases, this
 option should only be used once before any @code{io} variables in each
 file.
@@ -14034,9 +16242,9 @@ Specifies which coprocessor registers are available to the register
 allocator.  @var{registers} may be a single register, register range
 separated by ellipses, or comma-separated list of those.  Example:
 
-@example
+@smallexample
 #pragma GCC coprocessor available $c0...$c10, $c28
-@end example
+@end smallexample
 
 @item GCC coprocessor call_saved @var{registers}
 @cindex pragma, coprocessor call_saved
@@ -14045,9 +16253,9 @@ any function using them.  @var{registers} may be a single register,
 register range separated by ellipses, or comma-separated list of
 those.  Example:
 
-@example
+@smallexample
 #pragma GCC coprocessor call_saved $c4...$c6, $c31
-@end example
+@end smallexample
 
 @item GCC coprocessor subclass '(A|B|C|D)' = @var{registers}
 @cindex pragma, coprocessor subclass
@@ -14056,34 +16264,34 @@ used by inline @code{asm} constructs.  @var{registers} may be a single
 register, register range separated by ellipses, or comma-separated
 list of those.  Example:
 
-@example
+@smallexample
 #pragma GCC coprocessor subclass 'B' = $c2, $c4, $c6
 
 asm ("cpfoo %0" : "=B" (x));
-@end example
+@end smallexample
 
 @item GCC disinterrupt @var{name} , @var{name} @dots{}
 @cindex pragma, disinterrupt
 For the named functions, the compiler adds code to disable interrupts
-for the duration of those functions.  Any functions so named, which
-are not encountered in the source, cause a warning that the pragma was
+for the duration of those functions.  If any functions so named 
+are not encountered in the source, a warning is emitted that the pragma is
 not used.  Examples:
 
-@example
+@smallexample
 #pragma disinterrupt foo
 #pragma disinterrupt bar, grill
 int foo () @{ @dots{} @}
-@end example
+@end smallexample
 
 @item GCC call @var{name} , @var{name} @dots{}
 @cindex pragma, call
 For the named functions, the compiler always uses a register-indirect
 call model when calling the named functions.  Examples:
 
-@example
+@smallexample
 extern int foo ();
 #pragma call foo
-@end example
+@end smallexample
 
 @end table
 
@@ -14138,7 +16346,7 @@ This pragma is accepted, but has no effect.
 
 @item unused (@var{var} [, @var{var}]@dots{})
 @cindex pragma, unused
-This pragma declares variables to be possibly unused.  GCC will not
+This pragma declares variables to be possibly unused.  GCC does not
 produce warnings for the listed variables.  The effect is similar to
 that of the @code{unused} attribute, except that this pragma may appear
 anywhere within the variables' scopes.
@@ -14181,10 +16389,9 @@ adding a call to the @code{.init} section.
 @node Symbol-Renaming Pragmas
 @subsection Symbol-Renaming Pragmas
 
-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.  @code{#pragma extern_prefix} is only
-available on platforms whose system headers need it. To get this effect
+For compatibility with the Solaris system headers, GCC
+supports two @code{#pragma} directives that change the name used in
+assembly for a given declaration. To get this effect
 on all platforms supported by GCC, use the asm labels extension (@pxref{Asm
 Labels}).
 
@@ -14194,20 +16401,10 @@ Labels}).
 
 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 on all platforms).
-
-@item extern_prefix @var{string}
-@cindex pragma, extern_prefix
-
-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)@.
+is defined if this pragma is available (currently on all platforms).
 @end table
 
-These pragmas and the asm labels extension interact in a complicated
+This pragma and the asm labels extension interact in a complicated
 manner.  Here are some corner cases you may want to be aware of.
 
 @enumerate
@@ -14226,25 +16423,14 @@ 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 Microsoft Windows compilers, GCC supports a
-set of @code{#pragma} directives which change the maximum alignment of
-members of structures (other than zero-width bitfields), unions, and
+set of @code{#pragma} directives that change the maximum alignment of
+members of structures (other than zero-width bit-fields), 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.
 
@@ -14263,7 +16449,7 @@ 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}
+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
@@ -14319,14 +16505,14 @@ 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
+@var{option} is a double quoted string that matches the command-line
 option.
 
-@example
+@smallexample
 #pragma GCC diagnostic warning "-Wformat"
 #pragma GCC diagnostic error "-Wformat"
 #pragma GCC diagnostic ignored "-Wformat"
-@end example
+@end smallexample
 
 Note that these pragmas override any command-line options.  GCC keeps
 track of the location of each pragma, and issues diagnostics according
@@ -14338,20 +16524,20 @@ after a line do not affect diagnostics caused by that line.
 
 Causes GCC to remember the state of the diagnostics as of each
 @code{push}, and restore to that point at each @code{pop}.  If a
-@code{pop} has no matching @code{push}, the command line options are
+@code{pop} has no matching @code{push}, the command-line options are
 restored.
 
-@example
+@smallexample
 #pragma GCC diagnostic error "-Wuninitialized"
-  foo(a);			/* error is given for this one */
+  foo(a);                       /* error is given for this one */
 #pragma GCC diagnostic push
 #pragma GCC diagnostic ignored "-Wuninitialized"
-  foo(b);			/* no diagnostic for this one */
+  foo(b);                       /* no diagnostic for this one */
 #pragma GCC diagnostic pop
-  foo(c);			/* error is given for this one */
+  foo(c);                       /* error is given for this one */
 #pragma GCC diagnostic pop
-  foo(d);			/* depends on command line options */
-@end example
+  foo(d);                       /* depends on command-line options */
+@end smallexample
 
 @end table
 
@@ -14379,6 +16565,7 @@ information.  For example,
 TODO(Remember to fix this)
 @end smallexample
 
+@noindent
 prints @samp{/tmp/file.c:4: note: #pragma message:
 TODO - Remember to fix this}.
 
@@ -14436,6 +16623,7 @@ For example:
 int x [X];
 @end smallexample
 
+@noindent
 In this example, the definition of X as 1 is saved by @code{#pragma
 push_macro} and restored by @code{#pragma pop_macro}.
 
@@ -14448,15 +16636,14 @@ push_macro} and restored by @code{#pragma pop_macro}.
 
 This pragma allows you to set target specific options for functions
 defined later in the source file.  One or more strings can be
-specified.  Each function that is defined after this point will be as
+specified.  Each function that is defined after this point is as
 if @code{attribute((target("STRING")))} was specified for that
 function.  The parenthesis around the options is optional.
 @xref{Function Attributes}, for more information about the
 @code{target} attribute and the attribute syntax.
 
-The @code{#pragma GCC target} attribute is not implemented in GCC versions earlier
-than 4.4 for the i386/x86_64 and 4.6 for the PowerPC backends.  At
-present, it is not implemented for other backends.
+The @code{#pragma GCC target} pragma is presently implemented for
+i386/x86_64, PowerPC, and Nios II targets only.
 @end table
 
 @table @code
@@ -14465,7 +16652,7 @@ present, it is not implemented for other backends.
 
 This pragma allows you to set global optimization options for functions
 defined later in the source file.  One or more strings can be
-specified.  Each function that is defined after this point will be as
+specified.  Each function that is defined after this point is as
 if @code{attribute((optimize("STRING")))} was specified for that
 function.  The parenthesis around the options is optional.
 @xref{Function Attributes}, for more information about the
@@ -14503,6 +16690,48 @@ The @samp{#pragma GCC reset_options} pragma is not implemented in GCC
 versions earlier than 4.4.
 @end table
 
+@node Loop-Specific Pragmas
+@subsection Loop-Specific Pragmas
+
+@table @code
+@item #pragma GCC ivdep
+@cindex pragma GCC ivdep
+@end table
+
+With this pragma, the programmer asserts that there are no loop-carried
+dependencies which would prevent that consecutive iterations of
+the following loop can be executed concurrently with SIMD
+(single instruction multiple data) instructions.
+
+For example, the compiler can only unconditionally vectorize the following
+loop with the pragma:
+
+@smallexample
+void foo (int n, int *a, int *b, int *c)
+@{
+  int i, j;
+#pragma GCC ivdep
+  for (i = 0; i < n; ++i)
+    a[i] = b[i] + c[i];
+@}
+@end smallexample
+
+@noindent
+In this example, using the @code{restrict} qualifier had the same
+effect. In the following example, that would not be possible. Assume
+@math{k < -m} or @math{k >= m}. Only with the pragma, the compiler knows
+that it can unconditionally vectorize the following loop:
+
+@smallexample
+void ignore_vec_dep (int *a, int k, int c, int m)
+@{
+#pragma GCC ivdep
+  for (int i = 0; i < m; i++)
+    a[i] = a[i + k] * c;
+@}
+@end smallexample
+
+
 @node Unnamed Fields
 @section Unnamed struct/union fields within structs/unions
 @cindex @code{struct}
@@ -14524,13 +16753,14 @@ struct @{
 @} foo;
 @end smallexample
 
-In this example, the user would be able to access members of the unnamed
+@noindent
+In this example, you are able to access members of the unnamed
 union with code like @samp{foo.b}.  Note that only unnamed structs and
 unions are allowed, you may not have, for example, an unnamed
 @code{int}.
 
 You must never create such structures that cause ambiguous field definitions.
-For example, this structure:
+For example, in this structure:
 
 @smallexample
 struct @{
@@ -14541,7 +16771,8 @@ struct @{
 @} foo;
 @end smallexample
 
-It is ambiguous which @code{a} is being referred to with @samp{foo.a}.
+@noindent
+it is ambiguous which @code{a} is being referred to with @samp{foo.a}.
 The compiler gives errors for such constructs.
 
 @opindex fms-extensions
@@ -14566,6 +16797,7 @@ extern void f1 (struct s1 *);
 void f2 (struct s2 *p) @{ f1 (p); @}
 @end smallexample
 
+@noindent
 In the call to @code{f1} inside @code{f2}, the pointer @code{p} is
 converted into a pointer to the anonymous field.
 
@@ -14589,7 +16821,7 @@ These usages are only permitted when they are not ambiguous.
 
 Thread-local storage (@acronym{TLS}) is a mechanism by which variables
 are allocated such that there is one instance of the variable per extant
-thread.  The run-time model GCC uses to implement this originates
+thread.  The runtime model GCC uses to implement this originates
 in the IA-64 processor-specific ABI, but has since been migrated
 to other processors as well.  It requires significant support from
 the linker (@command{ld}), dynamic linker (@command{ld.so}), and
@@ -14615,7 +16847,7 @@ static, function-scoped static, or static data member of a class.  It may
 not be applied to block-scoped automatic or non-static data member.
 
 When the address-of operator is applied to a thread-local variable, it is
-evaluated at run-time and returns the address of the current thread's
+evaluated at run time and returns the address of the current thread's
 instance of that variable.  An address so obtained may be used by any
 thread.  When a thread terminates, any pointers to thread-local variables
 in that thread become invalid.
@@ -14628,7 +16860,7 @@ standard.
 
 See @uref{http://www.akkadia.org/drepper/tls.pdf,
 ELF Handling For Thread-Local Storage} for a detailed explanation of
-the four thread-local storage addressing models, and how the run-time
+the four thread-local storage addressing models, and how the runtime
 is expected to function.
 
 @menu
@@ -14805,7 +17037,7 @@ duration.
 Change paragraph 1
 
 @quotation
-All objects which have neither thread storage duration, dynamic
+All objects that have neither thread storage duration, dynamic
 storage duration nor are local [@dots{}].
 @end quotation
 
@@ -14848,7 +17080,7 @@ Non-@code{static} members shall not be @code{__thread}.
 Integer constants can be written as binary constants, consisting of a
 sequence of @samp{0} and @samp{1} digits, prefixed by @samp{0b} or
 @samp{0B}.  This is particularly useful in environments that operate a
-lot on the bit-level (like microcontrollers).
+lot on the bit level (like microcontrollers).
 
 The following statements are identical:
 
@@ -14887,10 +17119,11 @@ 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.
+* Function Multiversioning::   Declaring multiple function versions.
 * Namespace Association:: Strong using-directives for namespace association.
 * Type Traits::         Compiler support for type traits
 * Java Exceptions::     Tweaking exception handling to work with Java.
-* Deprecated Features:: Things will disappear from g++.
+* Deprecated Features:: Things will disappear from G++.
 * Backwards Compatibility:: Compatibilities with earlier definitions of C++.
 @end menu
 
@@ -14920,7 +17153,7 @@ volatile int *src = @var{somevalue};
 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 lvalue to rvalue conversion which is responsible for causing an
+is lvalue to rvalue conversion that is responsible for causing an
 access.  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
@@ -14938,10 +17171,10 @@ references.  Again, if you wish to force a read, cast the reference to
 an rvalue.
 
 G++ implements the same behavior as GCC does when assigning to a
-volatile object -- there is no reread of the assigned-to object, the
+volatile object---there is no reread of the assigned-to object, the
 assigned rvalue is reused.  Note that in C++ assignment expressions
-are lvalues, and if used as an lvalue, the volatile object will be
-referred to.  For instance, @var{vref} will refer to @var{vobj}, as
+are lvalues, and if used as an lvalue, the volatile object is
+referred to.  For instance, @var{vref} refers to @var{vobj}, as
 expected, in the following example:
 
 @smallexample
@@ -14986,12 +17219,12 @@ void T::fn () __restrict__
 @end smallexample
 
 @noindent
-Within the body of @code{T::fn}, @var{this} will have the effective
+Within the body of @code{T::fn}, @var{this} has the effective
 definition @code{T *__restrict__ const this}.  Notice that the
 interpretation of a @code{__restrict__} member function qualifier is
 different to that of @code{const} or @code{volatile} qualifier, in that it
 is applied to the pointer rather than the object.  This is consistent with
-other compilers which implement restricted pointers.
+other compilers that implement restricted pointers.
 
 As with all outermost parameter qualifiers, @code{__restrict__} is
 ignored in function definition matching.  This means you only need to
@@ -15002,7 +17235,7 @@ in a function prototype as well.
 @section Vague Linkage
 @cindex vague linkage
 
-There are several constructs in C++ which require space in the object
+There are several constructs in C++ that require space in the object
 file but are not clearly tied to a single translation unit.  We say that
 these constructs have ``vague linkage''.  Typically such constructs are
 emitted wherever they are needed, though sometimes we can be more
@@ -15016,7 +17249,7 @@ inlined, but sometimes an out-of-line copy is necessary, if the address
 of the function is taken or if inlining fails.  In general, we emit an
 out-of-line copy in all translation units where one is needed.  As an
 exception, we only emit inline virtual functions with the vtable, since
-it will always require a copy.
+it always requires a copy.
 
 Local static variables and string constants used in an inline function
 are also considered to have vague linkage, since they must be shared
@@ -15034,7 +17267,7 @@ and the vtable is only emitted in the translation unit where the key
 method is defined.
 
 @emph{Note:} If the chosen key method is later defined as inline, the
-vtable will still be emitted in every translation unit which defines it.
+vtable is still emitted in every translation unit that defines it.
 Make sure that any inline virtuals are declared inline in the class
 body, even if they are not defined there.
 
@@ -15045,7 +17278,7 @@ C++ requires information about types to be written out in order to
 implement @samp{dynamic_cast}, @samp{typeid} and exception handling.
 For polymorphic classes (classes with virtual functions), the @samp{type_info}
 object is written out along with the vtable so that @samp{dynamic_cast}
-can determine the dynamic type of a class object at runtime.  For all
+can determine the dynamic type of a class object at run time.  For all
 other types, we write out the @samp{type_info} object when it is used: when
 applying @samp{typeid} to an expression, throwing an object, or
 referring to a type in a catch clause or exception specification.
@@ -15063,14 +17296,14 @@ these constructs will be discarded at link time.  This is known as
 COMDAT support.
 
 On targets that don't support COMDAT, but do support weak symbols, GCC
-will use them.  This way one copy will override all the others, but
-the unused copies will still take up space in the executable.
+uses them.  This way one copy overrides all the others, but
+the unused copies still take up space in the executable.
 
-For targets which do not support either COMDAT or weak symbols,
-most entities with vague linkage will be emitted as local symbols to
-avoid duplicate definition errors from the linker.  This will not happen
-for local statics in inlines, however, as having multiple copies will
-almost certainly break things.
+For targets that do not support either COMDAT or weak symbols,
+most entities with vague linkage are emitted as local symbols to
+avoid duplicate definition errors from the linker.  This does not happen
+for local statics in inlines, however, as having multiple copies
+almost certainly breaks things.
 
 @xref{C++ Interface,,Declarations and Definitions in One Header}, for
 another way to control placement of these constructs.
@@ -15107,9 +17340,9 @@ functions, debugging information, and the internal tables that implement
 virtual functions) must be kept in each object file that includes class
 definitions.  You can use this pragma to avoid such duplication.  When a
 header file containing @samp{#pragma interface} is included in a
-compilation, this auxiliary information will not be generated (unless
+compilation, this auxiliary information is not generated (unless
 the main input source file itself uses @samp{#pragma implementation}).
-Instead, the object files will contain references to be resolved at link
+Instead, the object files contain references to be resolved at link
 time.
 
 The second form of this directive is useful for the case where you have
@@ -15132,7 +17365,7 @@ implementation files.
 @cindex naming convention, implementation headers
 If you use @samp{#pragma implementation} with no argument, it applies to
 an include file with the same basename@footnote{A file's @dfn{basename}
-was the name stripped of all leading path information and of trailing
+is the name stripped of all leading path information and of trailing
 suffixes, such as @samp{.h} or @samp{.C} or @samp{.cc}.} as your source
 file.  For example, in @file{allclass.cc}, giving just
 @samp{#pragma implementation}
@@ -15173,7 +17406,7 @@ code for the function itself; this defines a version of the function
 that can be found via pointers (or by callers compiled without
 inlining).  If all calls to the function can be inlined, you can avoid
 emitting the function by compiling with @option{-fno-implement-inlines}.
-If any calls were not inlined, you will get linker errors.
+If any calls are not inlined, you will get linker errors.
 
 @node Template Instantiation
 @section Where's the Template?
@@ -15224,32 +17457,23 @@ GNU/Linux or Solaris 2, or on Microsoft Windows, G++ supports the
 Borland model.  On other systems, G++ implements neither automatic
 model.
 
-A future version of G++ will support a hybrid model whereby the compiler
-will emit any instantiations for which the template definition is
-included in the compile, and store template definitions and
-instantiation context information into the object file for the rest.
-The link wrapper will extract that information as necessary and invoke
-the compiler to produce the remaining instantiations.  The linker will
-then combine duplicate instantiations.
-
-In the mean time, you have the following options for dealing with
-template instantiations:
+You have the following options for dealing with template instantiations:
 
 @enumerate
 @item
 @opindex frepo
-Compile your template-using code with @option{-frepo}.  The compiler will
-generate files with the extension @samp{.rpo} listing all of the
-template instantiations used in the corresponding object files which
-could be instantiated there; the link wrapper, @samp{collect2}, will
-then update the @samp{.rpo} files to tell the compiler where to place
+Compile your template-using code with @option{-frepo}.  The compiler
+generates files with the extension @samp{.rpo} listing all of the
+template instantiations used in the corresponding object files that
+could be instantiated there; the link wrapper, @samp{collect2},
+then updates the @samp{.rpo} files to tell the compiler where to place
 those instantiations and rebuild any affected object files.  The
 link-time overhead is negligible after the first pass, as the compiler
-will continue to place the instantiations in the same files.
+continues to place the instantiations in the same files.
 
 This is your best option for application code written for the Borland
-model, as it will just work.  Code written for the Cfront model will
-need to be modified so that the template definitions are available at
+model, as it just works.  Code written for the Cfront model 
+needs to be modified so that the template definitions are available at
 one or more points of instantiation; usually this is as simple as adding
 @code{#include <tmethods.cc>} to the end of each template header.
 
@@ -15283,6 +17507,7 @@ template ostream& operator <<
                 (ostream&, const Foo<int>&);
 @end smallexample
 
+@noindent
 for each of the instances you need, and create a template instantiation
 library from those.
 
@@ -15295,9 +17520,10 @@ compile it without @option{-fno-implicit-templates} so you get all of the
 instances required by your explicit instantiations (but not by any
 other files) without having to specify them as well.
 
-G++ has extended the template instantiation syntax given in the ISO
-standard to allow forward declaration of explicit instantiations
-(with @code{extern}), instantiation of the compiler support data for a
+The ISO C++ 2011 standard allows forward declaration of explicit
+instantiations (with @code{extern}). G++ supports explicit instantiation
+declarations in C++98 mode and has extended the template instantiation
+syntax to support instantiation of the compiler support data for a
 template class (i.e.@: the vtable) without instantiating any of its
 members (with @code{inline}), and instantiation of only the static data
 members of a template class, without the support data or member
@@ -15311,8 +17537,8 @@ static template class Foo<int>;
 
 @item
 Do nothing.  Pretend G++ does implement automatic instantiation
-management.  Code written for the Borland model will work fine, but
-each translation unit will contain instances of each of the templates it
+management.  Code written for the Borland model works fine, but
+each translation unit contains instances of each of the templates it
 uses.  In a large program, this can lead to an unacceptable amount of code
 duplication.
 @end enumerate
@@ -15333,7 +17559,7 @@ that is not an option, you can extract the pointer to the function that
 would be called for a given object/PMF pair and call it directly inside
 the inner loop, to save a bit of time.
 
-Note that you will still be paying the penalty for the call through a
+Note that you still pay the penalty for the call through a
 function pointer; on most modern architectures, such a call defeats the
 branch prediction features of the CPU@.  This is also true of normal
 virtual function calls.
@@ -15365,6 +17591,31 @@ You must specify @option{-Wno-pmf-conversions} to use this extension.
 Some attributes only make sense for C++ programs.
 
 @table @code
+@item abi_tag ("@var{tag}", ...)
+@cindex @code{abi_tag} attribute
+The @code{abi_tag} attribute can be applied to a function or class
+declaration.  It modifies the mangled name of the function or class to
+incorporate the tag name, in order to distinguish the function or
+class from an earlier version with a different ABI; perhaps the class
+has changed size, or the function has a different return type that is
+not encoded in the mangled name.
+
+The argument can be a list of strings of arbitrary length.  The
+strings are sorted on output, so the order of the list is
+unimportant.
+
+A redeclaration of a function or class must not add new ABI tags,
+since doing so would change the mangled name.
+
+The ABI tags apply to a name, so all instantiations and
+specializations of a template have the same tags.  The attribute will
+be ignored if applied to an explicit specialization or instantiation.
+
+The @option{-Wabi-tag} flag enables a warning about a class which does
+not have all the ABI tags used by its subobjects and virtual functions; for users with code
+that needs to coexist with an earlier ABI, using this option can help
+to find all affected types that need to be tagged.
+
 @item init_priority (@var{priority})
 @cindex @code{init_priority} attribute
 
@@ -15379,7 +17630,7 @@ a constant integral expression currently bounded between 101 and 65535
 inclusive.  Lower numbers indicate a higher priority.
 
 In the following example, @code{A} would normally be created before
-@code{B}, but the @code{init_priority} attribute has reversed that order:
+@code{B}, but the @code{init_priority} attribute reverses that order:
 
 @smallexample
 Some_Class  A  __attribute__ ((init_priority (2000)));
@@ -15395,20 +17646,94 @@ relative ordering.
 
 This type attribute informs C++ that the class is a Java interface.  It may
 only be applied to classes declared within an @code{extern "Java"} block.
-Calls to methods declared in this interface will be dispatched using GCJ's
+Calls to methods declared in this interface are dispatched using GCJ's
 interface table mechanism, instead of regular virtual table dispatch.
 
+@item warn_unused
+@cindex @code{warn_unused} attribute
+
+For C++ types with non-trivial constructors and/or destructors it is
+impossible for the compiler to determine whether a variable of this
+type is truly unused if it is not referenced. This type attribute
+informs the compiler that variables of this type should be warned
+about if they appear to be unused, just like variables of fundamental
+types.
+
+This attribute is appropriate for types which just represent a value,
+such as @code{std::string}; it is not appropriate for types which
+control a resource, such as @code{std::mutex}.
+
+This attribute is also accepted in C, but it is unnecessary because C
+does not have constructors or destructors.
+
 @end table
 
 See also @ref{Namespace Association}.
 
+@node Function Multiversioning
+@section Function Multiversioning
+@cindex function versions
+
+With the GNU C++ front end, for target i386, you may specify multiple
+versions of a function, where each function is specialized for a
+specific target feature.  At runtime, the appropriate version of the
+function is automatically executed depending on the characteristics of
+the execution platform.  Here is an example.
+
+@smallexample
+__attribute__ ((target ("default")))
+int foo ()
+@{
+  // The default version of foo.
+  return 0;
+@}
+
+__attribute__ ((target ("sse4.2")))
+int foo ()
+@{
+  // foo version for SSE4.2
+  return 1;
+@}
+
+__attribute__ ((target ("arch=atom")))
+int foo ()
+@{
+  // foo version for the Intel ATOM processor
+  return 2;
+@}
+
+__attribute__ ((target ("arch=amdfam10")))
+int foo ()
+@{
+  // foo version for the AMD Family 0x10 processors.
+  return 3;
+@}
+
+int main ()
+@{
+  int (*p)() = &foo;
+  assert ((*p) () == foo ());
+  return 0;
+@}
+@end smallexample
+
+In the above example, four versions of function foo are created. The
+first version of foo with the target attribute "default" is the default
+version.  This version gets executed when no other target specific
+version qualifies for execution on a particular platform. A new version
+of foo is created by using the same function signature but with a
+different target string.  Function foo is called or a pointer to it is
+taken just like a regular function.  GCC takes care of doing the
+dispatching to call the right version at runtime.  Refer to the
+@uref{http://gcc.gnu.org/wiki/FunctionMultiVersioning, GCC wiki on
+Function Multiversioning} for more details.
+
 @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 will be removed in future versions of G++.
+@strong{Caution:} The semantics of this extension are equivalent
+to C++ 2011 inline namespaces.  Users should use inline namespaces
+instead as this 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:
@@ -15436,7 +17761,7 @@ namespace std @{
     template <class T> struct A @{ @};
   @}
   using namespace debug __attribute ((__strong__));
-  template <> struct A<int> @{ @};   // @r{ok to specialize}
+  template <> struct A<int> @{ @};   // @r{OK to specialize}
 
   template <class T> void f (A<T>);
 @}
@@ -15451,8 +17776,9 @@ int main()
 @node Type Traits
 @section Type Traits
 
-The C++ front-end implements syntactic extensions that allow to
-determine at compile time various characteristics of a type (or of a
+The C++ front end implements syntactic extensions that allow
+compile-time determination of 
+various characteristics of a type (or of a
 pair of types).
 
 @table @code
@@ -15588,10 +17914,10 @@ an enumeration type ([dcl.enum]).
 @section Java Exceptions
 
 The Java language uses a slightly different exception handling model
-from C++.  Normally, GNU C++ will automatically detect when you are
+from C++.  Normally, GNU C++ automatically detects when you are
 writing C++ code that uses Java exceptions, and handle them
 appropriately.  However, if C++ code only needs to execute destructors
-when Java exceptions are thrown through it, GCC will guess incorrectly.
+when Java exceptions are thrown through it, GCC guesses incorrectly.
 Sample problematic code is:
 
 @smallexample
@@ -15676,7 +18002,7 @@ 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) @} }
+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
@@ -15702,7 +18028,7 @@ deprecated.   @xref{Deprecated Features}.
 @table @code
 @item For scope
 If a variable is declared at for scope, it used to remain in scope until
-the end of the scope which contained the for statement (rather than just
+the end of the scope that contained the for statement (rather than just
 within the for scope).  G++ retains this, but issues a warning, if such a
 variable is accessed outside the for scope.
 
@@ -15710,6 +18036,9 @@ variable is accessed outside the for scope.
 Old C system header files did not contain an @code{extern "C" @{@dots{}@}}
 scope to set the language.  On such systems, all header files are
 implicitly scoped inside a C language scope.  Also, an empty prototype
-@code{()} will be treated as an unspecified number of arguments, rather
+@code{()} is treated as an unspecified number of arguments, rather
 than no arguments, as C++ demands.
 @end table
+
+@c  LocalWords:  emph deftypefn builtin ARCv2EM SIMD builtins msimd
+@c  LocalWords:  typedef v4si v8hi DMA dma vdiwr vdowr followign