This brings rev 1.2 (document printf0()) into EGCS 1.1.2.

1 files changed, 571 insertions, 258 deletions

diff --git a/contrib/gcc/extend.texi b/contrib/gcc/extend.texi
index 8eee030..7fafbe3 100644
--- a/contrib/gcc/extend.texi
+++ b/contrib/gcc/extend.texi
@@ -1,4 +1,4 @@
-@c Copyright (C) 1988, 1989, 1992, 1993, 1994 Free Software Foundation, Inc.
+@c Copyright (C) 1988,89,92,93,94,96 Free Software Foundation, Inc.
 @c This is part of the GCC manual.
 @c For copying conditions, see the file gcc.texi.
 
@@ -62,6 +62,7 @@ C++ Language}, for extensions that apply @emph{only} to C++.
 * Incomplete Enums::    @code{enum foo;}, with details to follow.
 * Function Names::	Printable strings which are the name of the current
 			 function.
+* Return Address::      Getting the return or frame address of a function.
 @end menu
 @end ifset
 @ifclear INTERNALS
@@ -107,6 +108,7 @@ C++ Language}, for extensions that apply @emph{only} to C++.
 * Incomplete Enums::    @code{enum foo;}, with details to follow.
 * Function Names::	Printable strings which are the name of the current
 			 function.
+* Return Address::      Getting the return or frame address of a function.
 @end menu
 @end ifclear
 
@@ -235,12 +237,12 @@ example:
 @section Labels as Values
 @cindex labels as values
 @cindex computed gotos
-@cindex goto with computed label 
+@cindex goto with computed label
 @cindex address of a label
 
 You can get the address of a label defined in the current function
 (or a containing function) with the unary operator @samp{&&}.  The
-value has type @code{void *}.  This value is a constant and can be used 
+value has type @code{void *}.  This value is a constant and can be used
 wherever a constant of that type is valid.  For example:
 
 @example
@@ -286,7 +288,7 @@ use that rather than an array unless the problem does not fit a
 
 Another use of label values is in an interpreter for threaded code.
 The labels within the interpreter function can be stored in the
-threaded code for super-fast dispatching.  
+threaded code for super-fast dispatching.
 
 You can use this mechanism to jump to code in a different function.  If
 you do that, totally unpredictable things will happen.  The best way to
@@ -364,9 +366,8 @@ does not refer to anything that has gone out of scope, you should be
 safe.
 
 GNU CC implements taking the address of a nested function using a
-technique called @dfn{trampolines}.  A paper describing them is
-available from @samp{maya.idiap.ch} in directory @file{pub/tmb},
-file @file{usenix88-lexic.ps.Z}.
+technique called @dfn{trampolines}.   A paper describing them is
+available as @samp{http://master.debian.org/~karlheg/Usenix88-lexic.pdf}.
 
 A nested function can jump to a label inherited from a containing
 function, provided the label was explicitly declared in the containing
@@ -727,11 +728,11 @@ effects of recomputing it.
 @cindex multiprecision arithmetic
 
 GNU C supports data types for integers that are twice as long as
-@code{long int}.  Simply write @code{long long int} for a signed
-integer, or @code{unsigned long long int} for an unsigned integer.
-To make an integer constant of type @code{long long int}, add the suffix
-@code{LL} to the integer.  To make an integer constant of type
-@code{unsigned long long int}, add the suffix @code{ULL} to the integer.
+@code{int}.  Simply write @code{long long int} for a signed integer, or
+@code{unsigned long long int} for an unsigned integer.  To make an
+integer constant of type @code{long long int}, add the suffix @code{LL}
+to the integer.  To make an integer constant of type @code{unsigned long
+long int}, add the suffix @code{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
@@ -783,7 +784,7 @@ the imaginary part is on the stack (or vice-versa).  None of the
 supported debugging info formats has a way to represent noncontiguous
 allocation like this, so GNU CC 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 
+If the variable's actual name is @code{foo}, the two fictitious
 variables are named @code{foo$real} and @code{foo$imag}.  You can
 examine and set these two fictitious variables with your debugger.
 
@@ -1017,7 +1018,7 @@ foo (float f, float g)
 @cindex constructor expressions
 @cindex initializations in expressions
 @cindex structures, constructor expression
-@cindex expressions, constructor 
+@cindex expressions, constructor
 
 GNU C supports constructor expressions.  A constructor looks like
 a cast containing an initializer.  Its value is an object of the
@@ -1118,7 +1119,7 @@ plus one.
 
 In a structure initializer, specify the name of a field to initialize
 with @samp{@var{fieldname}:} before the element value.  For example,
-given the following structure, 
+given the following structure,
 
 @example
 struct point @{ int x, y; @};
@@ -1217,7 +1218,7 @@ write this:
 case 1 ... 5:
 @end example
 
-@noindent 
+@noindent
 rather than this:
 
 @example
@@ -1227,7 +1228,7 @@ case 1...5:
 @node Cast to Union
 @section Cast to a Union Type
 @cindex cast to a union
-@cindex union, casting to a 
+@cindex union, casting to a
 
 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
@@ -1274,7 +1275,7 @@ hack ((union foo) x);
 @cindex functions in arbitrary sections
 @cindex @code{volatile} applied to function
 @cindex @code{const} applied to function
-@cindex functions with @code{printf} or @code{scanf} style arguments
+@cindex functions with @code{printf}, @code{scanf} or @code{strftime} style arguments
 @cindex functions that are passed arguments in registers on the 386
 @cindex functions that pop the argument stack on the 386
 @cindex functions that do not pop the argument stack on the 386
@@ -1333,7 +1334,7 @@ earlier than 2.5.  An alternative way to declare that a function does
 not return, which works in the current version and in some older
 versions, is as follows:
 
-@smallexample  
+@smallexample
 typedef void voidfn ();
 
 volatile voidfn fatal;
@@ -1378,9 +1379,9 @@ return @code{void}.
 
 @item format (@var{archetype}, @var{string-index}, @var{first-to-check})
 @cindex @code{format} function attribute
-The @code{format} attribute specifies that a function takes @code{printf}
-or @code{scanf} style arguments which should be type-checked against a
-format string.  For example, the declaration:
+The @code{format} attribute specifies that a function takes @code{printf},
+@code{scanf}, or @code{strftime} style arguments which should be type-checked
+against a format string.  For example, the declaration:
 
 @smallexample
 extern int
@@ -1394,15 +1395,15 @@ for consistency with the @code{printf} style format string argument
 @code{my_format}.
 
 The parameter @var{archetype} determines how the format string is
-interpreted, and should be @code{printf}, @code{printf0}, or
-@code{scanf}.  @code{printf0} allows the format string to be a null
-pointer, while @code{printf} does not.  The parameter @var{string-index}
-specifies which argument is the format string argument (starting
-from 1), while @var{first-to-check} is the number of the first
-argument to check against the format string.  For functions where
-the arguments are not available to be checked (such as @code{vprintf}),
-specify the third parameter as zero.  In this case the compiler
-only checks the format string for consistency.
+interpreted, and should be either @code{printf}, @code{printf0}, @code{scanf},
+or @code{strftime}.  @code{printf0} allows the format string to be a null
+pointer, while @code{printf} does not.  The
+parameter @var{string-index} specifies which argument is the format
+string argument (starting from 1), while @var{first-to-check} is the
+number of the first argument to check against the format string.  For
+functions where the arguments are not available to be checked (such as
+@code{vprintf}), specify the third parameter as zero.  In this case the
+compiler only checks the format string for consistency.
 
 In the example above, the format string (@code{my_format}) is the second
 argument of the function @code{my_print}, and the arguments to check
@@ -1413,11 +1414,40 @@ The @code{format} attribute allows you to identify your own functions
 which take format strings as arguments, so that GNU CC can check the
 calls to these functions for errors.  The compiler always checks formats
 for the ANSI library functions @code{printf}, @code{fprintf},
-@code{sprintf}, @code{scanf}, @code{fscanf}, @code{sscanf},
+@code{sprintf}, @code{scanf}, @code{fscanf}, @code{sscanf}, @code{strftime},
 @code{vprintf}, @code{vfprintf} and @code{vsprintf} whenever such
 warnings are requested (using @samp{-Wformat}), so there is no need to
 modify the header file @file{stdio.h}.
 
+@item format_arg (@var{string-index})
+@cindex @code{format_arg} function attribute
+The @code{format_arg} attribute specifies that a function takes
+@code{printf} or @code{scanf} style arguments, modifies it (for example,
+to translate it into another language), and passes it to a @code{printf}
+or @code{scanf} style function.  For example, the declaration:
+
+@smallexample
+extern char *
+my_dgettext (char *my_domain, const char *my_format)
+      __attribute__ ((format_arg (2)));
+@end smallexample
+
+@noindent
+causes the compiler to check the arguments in calls to
+@code{my_dgettext} whose result is passed to a @code{printf},
+@code{scanf}, or @code{strftime} type function for consistency with the
+@code{printf} style format string argument @code{my_format}.
+
+The parameter @var{string-index} specifies which argument is the format
+string argument (starting from 1).
+
+The @code{format-arg} attribute allows you to identify your own
+functions which modify format strings, so that GNU CC can check the
+calls to @code{printf}, @code{scanf}, or @code{strftime} function whose
+operands are a call to one of your own function.  The compiler always
+treats @code{gettext}, @code{dgettext}, and @code{dcgettext} in this
+manner.
+
 @item section ("section-name")
 @cindex @code{section} function attribute
 Normally, the compiler places the code it generates in the @code{text} section.
@@ -1455,7 +1485,8 @@ These attributes are not currently implemented for Objective C.
 @item unused
 This attribute, attached to a function, means that the function is meant
 to be possibly unused.  GNU CC will not produce a warning for this
-function.
+function.  GNU C++ does not currently support this attribute as
+definitions without parameters are valid in C++.
 
 @item weak
 @cindex @code{weak} attribute
@@ -1479,6 +1510,8 @@ void f () __attribute__ ((weak, alias ("__f")));
 declares @samp{f} to be a weak alias for @samp{__f}.  In C++, the
 mangled name for the target must be used.
 
+Not all target machines support this attribute.
+
 @item regparm (@var{number})
 @cindex functions that are passed arguments in registers on the 386
 On the Intel 386, the @code{regparm} attribute causes the compiler to
@@ -1493,12 +1526,115 @@ On the Intel 386, the @code{stdcall} attribute causes the compiler to
 assume that the called function will pop off the stack space used to
 pass arguments, unless it takes a variable number of arguments.
 
+The PowerPC compiler for Windows NT currently ignores the @code{stdcall}
+attribute.
+
 @item cdecl
 @cindex functions that do pop the argument stack on the 386
 On the Intel 386, the @code{cdecl} attribute causes the compiler to
-assume that the called function will pop off the stack space used to
-pass arguments, unless it takes a variable number of arguments.  This is
+assume that the calling function will pop off the stack space used to
+pass arguments.  This is
 useful to override the effects of the @samp{-mrtd} switch.
+
+The PowerPC compiler for Windows NT currently ignores the @code{cdecl}
+attribute.
+
+@item longcall
+@cindex functions called via pointer on the RS/6000 and PowerPC
+On the RS/6000 and PowerPC, the @code{longcall} attribute causes the
+compiler to always call the function via a pointer, so that functions
+which reside further than 64 megabytes (67,108,864 bytes) from the
+current location can be called.
+
+@item dllimport
+@cindex functions which are imported from a dll on PowerPC Windows NT
+On the PowerPC running Windows NT, the @code{dllimport} attribute causes
+the compiler to call the function via a global pointer to the function
+pointer that is set up by the Windows NT dll library.  The pointer name
+is formed by combining @code{__imp_} and the function name.
+
+@item dllexport
+@cindex functions which are exported from a dll on PowerPC Windows NT
+On the PowerPC running Windows NT, the @code{dllexport} attribute causes
+the compiler to provide a global pointer to the function pointer, so
+that it can be called with the @code{dllimport} attribute.  The pointer
+name is formed by combining @code{__imp_} and the function name.
+
+@item exception (@var{except-func} [, @var{except-arg}])
+@cindex functions which specify exception handling on PowerPC Windows NT
+On the PowerPC running Windows NT, the @code{exception} attribute causes
+the compiler to modify the structured exception table entry it emits for
+the declared function.  The string or identifier @var{except-func} is
+placed in the third entry of the structured exception table.  It
+represents a function, which is called by the exception handling
+mechanism if an exception occurs.  If it was specified, the string or
+identifier @var{except-arg} is placed in the fourth entry of the
+structured exception table.
+
+@item function_vector
+@cindex calling functions through the function vector on the H8/300 processors
+Use this option on the H8/300 and H8/300H to indicate that the specified
+function should be called through the function vector.  Calling a
+function through the function vector will reduce code size, however;
+the function vector has a limited size (maximum 128 entries on the H8/300
+and 64 entries on the H8/300H) and shares space with the interrupt vector.
+
+You must use GAS and GLD from GNU binutils version 2.7 or later for
+this option to work correctly.
+
+@item interrupt_handler
+@cindex interrupt handler functions on the H8/300 processors
+Use this option on the H8/300 and H8/300H to indicate that the specified
+function is an interrupt handler.  The compiler will generate function
+entry and exit sequences suitable for use in an interrupt handler when this
+attribute is present.
+
+@item eightbit_data
+@cindex eight bit data on the H8/300 and H8/300H
+Use this option on the H8/300 and H8/300H to indicate that the specified
+variable should be placed into the eight bit data section.
+The compiler will generate more efficient code for certain operations
+on data in the eight bit data area.  Note the eight bit data area is limited to
+256 bytes of data.
+
+You must use GAS and GLD from GNU binutils version 2.7 or later for
+this option to work correctly.
+
+@item tiny_data
+@cindex tiny data section on the H8/300H
+Use this option on the H8/300H 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
+on data in the tiny data section.  Note the tiny data area is limited to
+slightly under 32kbytes of data.
+
+@item interrupt
+@cindex interrupt handlers on the M32R/D
+Use this option on the M32R/D to indicate that the specified
+function is an interrupt handler.  The compiler will generate function
+entry and exit sequences suitable for use in an interrupt handler when this
+attribute is present.
+
+@item model (@var{model-name})
+@cindex function addressability on the M32R/D
+Use this attribute on the M32R/D to set the addressability of an object,
+and the code generated for a function.
+The identifier @var{model-name} is one of @code{small}, @code{medium},
+or @code{large}, representing each of the code models.
+
+Small model objects live in the lower 16MB of memory (so that their
+addresses can be loaded with the @code{ld24} instruction), and are
+callable with the @code{bl} instruction.
+
+Medium model objects may live anywhere in the 32 bit address space (the
+compiler will generate @code{seth/add3} instructions to load their addresses),
+and are callable with the @code{bl} instruction.
+
+Large model objects may live anywhere in the 32 bit address space (the
+compiler will generate @code{seth/add3} instructions to load their addresses),
+and may not be reachable with the @code{bl} instruction (the compiler will
+generate the much slower @code{seth/add3/jl} instruction sequence).
+
 @end table
 
 You can specify multiple attributes in a declaration by separating them
@@ -1535,7 +1671,7 @@ old-style non-prototype definition.  Consider the following example:
 
 @example
 /* @r{Use prototypes unless the compiler is old-fashioned.}  */
-#if __STDC__
+#ifdef __STDC__
 #define P(x) x
 #else
 #define P(x) ()
@@ -1601,24 +1737,10 @@ with traditional constructs like @code{dividend//*comment*/divisor}.
 @cindex dollar signs in identifier names
 @cindex identifier names, dollar signs in
 
-In GNU C, you may use dollar signs in identifier names.  This is because
-many traditional C implementations allow such identifiers.
-
-On some machines, dollar signs are allowed in identifiers if you specify
-@w{@samp{-traditional}}.  On a few systems they are allowed by default,
-even if you do not use @w{@samp{-traditional}}.  But they are never
-allowed if you specify @w{@samp{-ansi}}.
-
-There are certain ANSI C programs (obscure, to be sure) that would
-compile incorrectly if dollar signs were permitted in identifiers.  For
-example:
-
-@example
-#define foo(a) #a
-#define lose(b) foo (b)
-#define test$
-lose (test)
-@end example
+In GNU C, you may normally use dollar signs in identifier names.
+This is because many traditional C implementations allow such identifiers.
+However, dollar signs in identifiers are not supported on a few target
+machines, typically because the target assembler does not allow them.
 
 @node Character Escapes
 @section The Character @key{ESC} in Constants
@@ -1799,7 +1921,7 @@ section.  For example, this small program uses several specific section names:
 struct duart a __attribute__ ((section ("DUART_A"))) = @{ 0 @};
 struct duart b __attribute__ ((section ("DUART_B"))) = @{ 0 @};
 char stack[10000] __attribute__ ((section ("STACK"))) = @{ 0 @};
-int init_data_copy __attribute__ ((section ("INITDATACOPY"))) = 0;
+int init_data __attribute__ ((section ("INITDATA"))) = 0;
 
 main()
 @{
@@ -1807,7 +1929,7 @@ main()
   init_sp (stack + sizeof (stack));
 
   /* Initialize initialized data */
-  memcpy (&init_data_copy, &data, &edata - &data);
+  memcpy (&init_data, &data, &edata - &data);
 
   /* Turn on the serial ports */
   init_duart (&a);
@@ -1835,11 +1957,12 @@ If you need to map the entire contents of a module to a particular
 section, consider using the facilities of the linker instead.
 
 @item transparent_union
-This attribute, attached to a function argument variable which is a
-union, means to pass the argument in the same way that the first union
-member would be passed.  You can also use this attribute on a
-@code{typedef} for a union data type; then it applies to all function
-arguments with that type.
+This attribute, attached to a function parameter which is a union, means
+that the corresponding argument may have the type of any union member,
+but the argument is passed as if its type were that of the first union
+member.  For more details see @xref{Type Attributes}.  You can also use
+this attribute on a @code{typedef} for a union data type; then it
+applies to all function parameters with that type.
 
 @item unused
 This attribute, attached to a variable, means that the variable is meant
@@ -1848,6 +1971,20 @@ variable.
 
 @item weak
 The @code{weak} attribute is described in @xref{Function Attributes}.
+
+@item model (@var{model-name})
+@cindex variable addressability on the M32R/D
+Use this attribute on the M32R/D to set the addressability of an object.
+The identifier @var{model-name} is one of @code{small}, @code{medium},
+or @code{large}, representing each of the code models.
+
+Small model objects live in the lower 16MB of memory (so that their
+addresses can be loaded with the @code{ld24} instruction).
+
+Medium and large model objects may live anywhere in the 32 bit address space
+(the compiler will generate @code{seth/add3} instructions to load their
+addresses).
+
 @end table
 
 To specify multiple attributes, separate them by commas within the
@@ -1879,6 +2016,9 @@ closing curly brace of a complete enum, struct or union type
 @emph{definition} and the @code{packed} attribute only past the closing
 brace of a definition.
 
+You may also specify attributes between the enum, struct or union
+tag and the name of the type rather than after the closing brace.
+
 @table @code
 @cindex @code{aligned} attribute
 @item aligned (@var{alignment})
@@ -1886,12 +2026,12 @@ This attribute specifies a minimum alignment (in bytes) for variables
 of the specified type.  For example, the declarations:
 
 @smallexample
-struct S @{ short f[3]; @} __attribute__ ((aligned (8));
-typedef int more_aligned_int __attribute__ ((aligned (8));
+struct S @{ short f[3]; @} __attribute__ ((aligned (8)));
+typedef int more_aligned_int __attribute__ ((aligned (8)));
 @end smallexample
 
 @noindent
-force the compiler to insure (as fas as it can) that each variable whose
+force the compiler to insure (as far as it can) that each variable whose
 type is @code{struct S} or @code{more_aligned_int} will be allocated and
 aligned @emph{at least} on a 8-byte boundary.  On a Sparc, having all
 variables of type @code{struct S} aligned to 8-byte boundaries allows
@@ -1971,21 +2111,76 @@ flag on the line is equivalent to specifying the @code{packed}
 attribute on all @code{enum} definitions.
 
 You may only specify this attribute after a closing curly brace on an
-@code{enum} definition, not in a @code{typedef} declaration.
+@code{enum} definition, not in a @code{typedef} declaration, unless that
+declaration also contains the definition of the @code{enum}.
 
 @item transparent_union
 This attribute, attached to a @code{union} type definition, indicates
-that any variable having that union type should, if passed to a
-function, be passed in the same way that the first union member would be
-passed.  For example:
+that any function parameter having that union type causes calls to that
+function to be treated in a special way.
+
+First, the argument corresponding to a transparent union type can be of
+any type in the union; no cast is required.  Also, if the union contains
+a pointer type, the corresponding argument can be a null pointer
+constant or a void pointer expression; and if the union contains a void
+pointer type, the corresponding argument can be any pointer expression.
+If the union member type is a pointer, qualifiers like @code{const} on
+the referenced type must be respected, just as with normal pointer
+conversions.
+
+Second, the argument is passed to the function using the calling
+conventions of first member of the transparent union, not the calling
+conventions of the union itself.  All members of the union must have the
+same machine representation; this is necessary for this argument passing
+to work properly.
+
+Transparent unions are designed for library functions that have multiple
+interfaces for compatibility reasons.  For example, suppose the
+@code{wait} function must accept either a value of type @code{int *} to
+comply with Posix, or a value of type @code{union wait *} to comply with
+the 4.1BSD interface.  If @code{wait}'s parameter were @code{void *},
+@code{wait} would accept both kinds of arguments, but it would also
+accept any other pointer type and this would make argument type checking
+less useful.  Instead, @code{<sys/wait.h>} might define the interface
+as follows:
+
+@smallexample
+typedef union
+  @{
+    int *__ip;
+    union wait *__up;
+  @} wait_status_ptr_t __attribute__ ((__transparent_union__));
+
+pid_t wait (wait_status_ptr_t);
+@end smallexample
+
+This interface allows either @code{int *} or @code{union wait *}
+arguments to be passed, using the @code{int *} calling convention.
+The program can call @code{wait} with arguments of either type:
+
+@example
+int w1 () @{ int w; return wait (&w); @}
+int w2 () @{ union wait w; return wait (&w); @}
+@end example
+
+With this interface, @code{wait}'s implementation might look like this:
 
 @example
-union foo
+pid_t wait (wait_status_ptr_t p)
 @{
-  char a;
-  int x[2];
-@} __attribute__ ((transparent_union));
+  return waitpid (-1, p.__ip, 0);
+@}
 @end example
+
+@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.  GNU CC will not produce a warning for any variables of
+that type, even if the variable appears to do nothing.  This is often
+the case with lock or thread classes, which are usually defined and then
+not referenced, but contain constructors and destructors that have
+nontrivial bookkeeping functions.
+
 @end table
 
 To specify multiple attributes, separate them by commas within the
@@ -2087,14 +2282,14 @@ did the easy thing, and turned it off.
 @cindex assembler instructions
 @cindex registers
 
-In an assembler instruction using @code{asm}, you can now specify the
-operands of the instruction using C expressions.  This means no more
-guessing which registers or memory locations will contain the data you want
+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
 to use.
 
-You must specify an assembler instruction template much like what appears
-in a machine description, plus an operand constraint string for each
-operand.
+You must specify an assembler instruction template much like what
+appears in a machine description, plus an operand constraint string for
+each operand.
 
 For example, here is how to use the 68881's @code{fsinx} instruction:
 
@@ -2105,64 +2300,66 @@ 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.  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}).
-
-Each operand is described by an operand-constraint string followed by the C
-expression in parentheses.  A colon separates the assembler template from
-the first output operand, and another separates the last output operand
-from the first input, if any.  Commas separate output operands and separate
-inputs.  The total number of operands is limited to ten or to the maximum
-number of operands in any instruction pattern in the machine description,
-whichever is greater.
-
-If there are no output operands, and there are input operands, then there
-must be two consecutive colons surrounding the place where the output
+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}).
+
+Each operand is described by an operand-constraint string followed by
+the C expression in parentheses.  A colon separates the assembler
+template from the first output operand and another separates the last
+output operand from the first input, if any.  Commas separate the
+operands within each group.  The total number of operands is limited to
+ten or to the maximum number of operands in any instruction pattern in
+the machine description, whichever is greater.
+
+If there are no output operands but there are input operands, you must
+place two consecutive colons surrounding the place where the output
 operands would go.
 
 Output operand expressions must be lvalues; the compiler can check this.
-The input operands need not be lvalues.  The compiler cannot check whether
-the operands have data types that are reasonable for the instruction being
-executed.  It does not parse the assembler instruction template and does
-not know what it means, or whether it is valid assembler input.  The
-extended @code{asm} feature is most often used for machine instructions
-that 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, GNU CC will use
-the register as the output of the @code{asm}, and then store that
-register into the output.
-
-The output operands must be write-only; GNU CC will assume that the values
-in these operands before the instruction are dead and need not be
-generated.  Extended asm does not support input-output or read-write
-operands.  For this reason, the constraint character @samp{+}, which
-indicates such an operand, may not be used.
-
-When the assembler instruction has a read-write operand, or an operand
-in which only some of the bits are to be changed, you must 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 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 operand and @code{foo} as its read-write destination:
+The input operands need not be lvalues.  The compiler cannot check
+whether the operands have data types that are reasonable for the
+instruction being executed.  It does not parse the assembler instruction
+template and does not know what it means or even whether it is valid
+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, GNU CC
+will use the register as the output of the @code{asm}, and then store
+that register into the output.
+
+The ordinary output operands must be write-only; GNU CC will assume 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.
+
+When the constraints for the read-write operand (or the operand in which
+only some of the bits are to be changed) allows a register, 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 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 operand and @code{foo} as its
+read-write destination:
 
 @example
 asm ("combine %2,%0" : "=r" (foo) : "0" (foo), "g" (bar));
 @end example
 
 @noindent
-The constraint @samp{"0"} for operand 1 says that it must occupy the same
-location as operand 0.  A digit in constraint is allowed only in an input
-operand, and it must refer to an output operand.
+The constraint @samp{"0"} for operand 1 says that it must occupy the
+same location as operand 0.  A digit in constraint is allowed only in an
+input operand and it must refer to an output operand.
 
 Only a digit in the constraint can guarantee that one operand will be 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 work:
+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
+work reliably:
 
 @example
 asm ("combine %2,%0" : "=r" (foo) : "r" (foo), "g" (bar));
@@ -2176,10 +2373,10 @@ register (copying it afterward to @code{foo}'s own address).  Of course,
 since the register for operand 1 is not even mentioned in the assembler
 code, the result will not work, but GNU CC can't tell that.
 
-Some instructions clobber specific hard registers.  To describe this, write
-a third colon after the input operands, followed by the names of the
-clobbered hard registers (given as strings).  Here is a realistic example
-for the Vax:
+Some instructions clobber specific hard registers.  To describe this,
+write a third colon after the input operands, followed by the names of
+the clobbered hard registers (given as strings).  Here is a realistic
+example for the VAX:
 
 @example
 asm volatile ("movc3 %0,%1,%2"
@@ -2189,32 +2386,32 @@ asm volatile ("movc3 %0,%1,%2"
 @end example
 
 If you refer to a particular hardware register from the assembler code,
-then you will probably have to list the register after the third colon
-to tell the compiler that the register's value is modified.  In many
-assemblers, the register names begin with @samp{%}; to produce one
-@samp{%} in the assembler code, you must write @samp{%%} in the input.
-
-If your assembler instruction can alter the condition code register,
-add @samp{cc} to the list of clobbered registers.  GNU CC on some
-machines represents the condition codes as a specific hardware
-register; @samp{cc} serves to name this register.  On other machines,
-the condition code is handled differently, and specifying @samp{cc}
-has no effect.  But it is valid no matter what the machine.
+you will 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.
+
+If your assembler instruction can alter the condition code register, add
+@samp{cc} to the list of clobbered registers.  GNU CC on some machines
+represents the condition codes as a specific hardware register;
+@samp{cc} serves to name this register.  On other machines, the
+condition code is handled differently, and specifying @samp{cc} has no
+effect.  But it is valid no matter what the machine.
 
 If your assembler instruction modifies memory in an unpredictable
-fashion, add @samp{memory} to the list of clobbered registers.
-This will cause GNU CC to not keep memory values cached in
-registers across the assembler instruction.
+fashion, add @samp{memory} to the list of clobbered registers.  This
+will cause GNU CC to not keep memory values cached in registers across
+the assembler instruction.
 
-You can put multiple assembler instructions together in a single @code{asm}
-template, separated either with newlines (written as @samp{\n}) or with
-semicolons if the assembler allows such semicolons.  The GNU assembler
-allows semicolons and all Unix assemblers seem to do so.  The input
-operands are guaranteed not to use any of the clobbered registers, and
-neither will 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 that the subroutine
-@code{_foo} accepts arguments in registers 9 and 10:
+You can put multiple assembler instructions together in a single
+@code{asm} template, separated either with newlines (written as
+@samp{\n}) or with semicolons if the assembler allows such semicolons.
+The GNU assembler allows semicolons and most Unix assemblers seem to do
+so.  The input operands are guaranteed not to use any of the clobbered
+registers, and neither will 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:
 
 @example
 asm ("movl %0,r9;movl %1,r10;call _foo"
@@ -2223,16 +2420,16 @@ asm ("movl %0,r9;movl %1,r10;call _foo"
      : "r9", "r10");
 @end example
 
-Unless an output operand has the @samp{&} constraint modifier, GNU CC may
-allocate it in the same register as an unrelated input operand, on the
-assumption that the inputs are consumed before the outputs are produced.
+Unless an output operand has the @samp{&} constraint modifier, GNU CC
+may allocate it in the same register as an unrelated input operand, on
+the assumption the inputs are consumed before the outputs are produced.
 This assumption may be false if the assembler code actually consists of
 more than one instruction.  In such a case, use @samp{&} for each output
-operand that may not overlap an input.
-@xref{Modifiers}.
+operand that may not overlap an input.  @xref{Modifiers}.
 
-If you want to test the condition code produced by an assembler instruction,
-you must include a branch and a label in the @code{asm} construct, as follows:
+If you want to test the condition code produced by an assembler
+instruction, you must include a branch and a label in the @code{asm}
+construct, as follows:
 
 @example
 asm ("clr %0;frob %1;beq 0f;mov #1,%0;0:"
@@ -2245,8 +2442,8 @@ This assumes your assembler supports local labels, as the GNU assembler
 and most Unix assemblers do.
 
 Speaking of labels, jumps from one @code{asm} to another are not
-supported.  The compiler's optimizers do not know about these jumps,
-and therefore they cannot take account of them when deciding how to
+supported.  The compiler's optimizers do not know about these jumps, and
+therefore they cannot take account of them when deciding how to
 optimize.
 
 @cindex macros containing @code{asm}
@@ -2265,8 +2462,8 @@ 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}.
 
-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
+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
@@ -2274,27 +2471,40 @@ argument to an @code{int} variable named @code{__arg} would warn about
 using a pointer unless the caller explicitly casts it.
 
 If an @code{asm} has output operands, GNU CC assumes for optimization
-purposes that the instruction has no side effects except to change the
-output operands.  This does not mean that instructions with a side effect
-cannot be used, but you must be careful, because the compiler may eliminate
-them if the output operands aren't used, or move them out of loops, or
-replace two with one if they constitute a common subexpression.  Also, if
-your instruction does have a side effect on a variable that otherwise
-appears not to change, the old value of the variable may be reused later if
-it happens to be found in a register.
+purposes the instruction has no side effects except to change the output
+operands.  This does not mean instructions with a side effect cannot be
+used, but you must be careful, because the compiler may eliminate them
+if the output operands aren't used, or move them out of loops, or
+replace two with one if they constitute a common subexpression.  Also,
+if your instruction does have a side effect on a variable that otherwise
+appears not to change, the old value of the variable may be reused later
+if it happens to be found in a register.
 
 You can prevent an @code{asm} instruction from being deleted, moved
 significantly, or combined, by writing the keyword @code{volatile} after
 the @code{asm}.  For example:
 
 @example
-#define set_priority(x)  \
-asm volatile ("set_priority %0": /* no outputs */ : "g" (x))
-@end example
+#define get_and_set_priority(new)  \
+(@{ int __old; \
+   asm volatile ("get_and_set_priority %0, %1": "=g" (__old) : "g" (new)); \
+   __old; @})
+b@end example
 
 @noindent
-An instruction without output operands will not be deleted or moved
-significantly, regardless, unless it is unreachable.
+If you write an @code{asm} instruction with no outputs, GNU CC will know
+the instruction has side-effects and will not delete the instruction or
+move it outside of loops.  If the side-effects of your instruction are
+not purely external, but will affect variables in your program in ways
+other than reading the inputs and clobbering the specified registers or
+memory, you should write the @code{volatile} keyword to prevent future
+versions of GNU CC from moving the instruction around within a core
+region.
+
+An @code{asm} instruction without any operands or clobbers (and ``old
+style'' @code{asm}) will not be deleted or moved significantly,
+regardless, unless it is unreachable, the same wasy as if you had
+written a @code{volatile} keyword.
 
 Note that even a volatile @code{asm} instruction can be moved in ways
 that appear insignificant to the compiler, such as across jump
@@ -2497,7 +2707,7 @@ Of course, it will not do to use more than a few of those.
 
 @node Local Reg Vars
 @subsection Specifying Registers for Local Variables
-@cindex local variables, specifying registers 
+@cindex local variables, specifying registers
 @cindex specifying registers for local variables
 @cindex registers for local variables
 
@@ -2523,16 +2733,17 @@ In addition, operating systems on one type of cpu may differ in how they
 name the registers; then you would 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
-automatically, but first we need to figure out how it should choose and
-how to enable you to guide the choice.  No solution is evident.
-
 Defining such a register variable does not reserve the register; it
 remains available for other uses in places where flow control determines
 the variable's value is not live.  However, these registers are made
-unavailable for use in the reload pass.  I would not be surprised if
-excessive use of this feature leaves the compiler too few available
-registers to compile certain functions.
+unavailable for use in the reload pass; excessive use of this feature
+leaves the compiler too few available registers to compile certain
+functions.
+
+This option does not guarantee that GNU CC will generate code that has
+this variable in the register you specify at all times.  You may not
+code an explicit reference to this register in an @code{asm} statement
+and assume it will always refer to this variable.
 
 @node Alternate Keywords
 @section Alternate Keywords
@@ -2633,6 +2844,49 @@ For example, @samp{#ifdef __FUNCTION__} does not have any special
 meaning inside a function, since the preprocessor does not do anything
 special with the identifier @code{__FUNCTION__}.
 
+@node Return Address
+@section Getting the Return or Frame Address of a Function
+
+These functions may be used to get information about the callers of a
+function.
+
+@table @code
+@item __builtin_return_address (@var{level})
+This function returns the return address of the current function, or of
+one of its callers.  The @var{level} argument is number of frames to
+scan up the call stack.  A value of @code{0} yields the return address
+of the current function, a value of @code{1} yields the return address
+of the caller of the current function, and so forth.
+
+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}.
+
+This function should only be used with a non-zero argument for debugging
+purposes.
+
+@item __builtin_frame_address (@var{level})
+This function is similar to @code{__builtin_return_address}, but it
+returns the address of the function frame rather than the return address
+of the function.  Calling @code{__builtin_frame_address} with a value of
+@code{0} yields the frame address of the current function, 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
+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
+pointer register.
+
+The caveats that apply to @code{__builtin_return_address} apply to this
+function as well.
+@end table
+
 @node C++ Extensions
 @chapter Extensions to the C++ Language
 @cindex extensions, C++ language
@@ -2674,7 +2928,7 @@ C++ programs:
 @group
 @var{type}
 @var{functionname} (@var{args}) return @var{resultname};
-@{ 
+@{
   @dots{}
   @var{body}
   @dots{}
@@ -2693,7 +2947,7 @@ m ()
 @{
   X b;
   b.a = 23;
-  return b; 
+  return b;
 @}
 @end example
 
@@ -2722,7 +2976,7 @@ at the outset, and assigning to its @code{a} field directly:
 X
 m () return r;
 @{
-  r.a = 23; 
+  r.a = 23;
 @}
 @end example
 
@@ -2733,13 +2987,13 @@ are executed @strong{before} any of the body of @code{m}.
 Functions of this type impose no additional restrictions; in particular,
 you can execute @code{return} statements, or return implicitly by
 reaching the end of the function body (``falling off the edge'').
-Cases like 
+Cases like
 
 @example
 X
 m () return r (23);
 @{
-  return; 
+  return;
 @}
 @end example
 
@@ -2753,7 +3007,7 @@ X
 m () return r;
 @{
   X b;
-  return b; 
+  return b;
 @}
 @end example
 
@@ -2809,7 +3063,7 @@ behavior.  For example, @code{MIN (i++, j++)} will fail, incrementing
 the smaller counter twice.  A GNU C extension allows you to write safe
 macros that avoid this kind of problem (@pxref{Naming Types,,Naming an
 Expression's Type}).  However, writing @code{MIN} and @code{MAX} as
-macros also forces you to use function-call notation notation for a
+macros also forces you to use function-call notation for a
 fundamental arithmetic operation.  Using GNU C++ extensions, you can
 write @w{@samp{int min = i <? j;}} instead.
 
@@ -2824,9 +3078,7 @@ works correctly.
 @cindex destructors vs @code{goto}
 In C++ programs, you can safely use the @code{goto} statement.  When you
 use it to exit a block which contains aggregates requiring destructors,
-the destructors will run before the @code{goto} transfers control.  (In
-ANSI C++, @code{goto} is restricted to targets within the current
-block.)
+the destructors will run before the @code{goto} transfers control.
 
 @cindex constructors vs @code{goto}
 The compiler still forbids using @code{goto} to @emph{enter} a scope
@@ -2903,7 +3155,8 @@ 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
 suffixes, such as @samp{.h} or @samp{.C} or @samp{.cc}.} as your source
-file.  For example, in @file{allclass.cc}, @samp{#pragma implementation}
+file.  For example, in @file{allclass.cc}, giving just
+@samp{#pragma implementation}
 by itself is equivalent to @samp{#pragma implementation "allclass.h"}.
 
 In versions of GNU C++ prior to 2.6.0 @file{allclass.h} was treated as
@@ -2960,41 +3213,123 @@ problem, which I will refer to as the Borland model and the Cfront model.
 @table @asis
 @item Borland model
 Borland C++ solved the template instantiation problem by adding the code
-equivalent of common blocks to their linker; template instances
-are emitted in each translation unit that uses them, and they are
-collapsed together at run time.  The advantage of this model is that the
-linker only has to consider the object files themselves; there is no
-external complexity to worry about.  This disadvantage is that
-compilation time is increased because the template code is being
-compiled repeatedly.  Code written for this model tends to include
-definitions of all member templates in the header file, since they must
-be seen to be compiled.
+equivalent of common blocks to their linker; the compiler emits template
+instances in each translation unit that uses them, and the linker
+collapses them together.  The advantage of this model is that the linker
+only has to consider the object files themselves; there is no external
+complexity to worry about.  This disadvantage is that compilation time
+is increased because the template code is being compiled repeatedly.
+Code written for this model tends to include definitions of all
+templates in the header file, since they must be seen to be
+instantiated.
 
 @item Cfront model
 The AT&T C++ translator, Cfront, solved the template instantiation
 problem by creating the notion of a template repository, an
-automatically maintained place where template instances are stored.  As
-individual object files are built, notes are placed in the repository to
-record where templates and potential type arguments were seen so that
-the subsequent instantiation step knows where to find them.  At link
-time, any needed instances are generated and linked in.  The advantages
-of this model are more optimal compilation speed and the ability to use
-the system linker; to implement the Borland model a compiler vendor also
+automatically maintained place where template instances are stored.  A
+more modern version of the repository works as follows: As individual
+object files are built, the compiler places any template definitions and
+instantiations encountered in the repository.  At link time, the link
+wrapper adds in the objects in the repository and compiles any needed
+instances that were not previously emitted.  The advantages of this
+model are more optimal compilation speed and the ability to use the
+system linker; to implement the Borland model a compiler vendor also
 needs to replace the linker.  The disadvantages are vastly increased
-complexity, and thus potential for error; theoretically, this should be
-just as transparent, but in practice it has been very difficult to build
+complexity, and thus potential for error; for some code this can be
+just as transparent, but in practice it can been very difficult to build
 multiple programs in one directory and one program in multiple
-directories using Cfront.  Code written for this model tends to separate
-definitions of non-inline member templates into a separate file, which
-is magically found by the link preprocessor when a template needs to be
-instantiated.
+directories.  Code written for this model tends to separate definitions
+of non-inline member templates into a separate file, which should be
+compiled separately.
 @end table
 
-Currently, g++ implements neither automatic model.  In the mean time,
-you have three options for dealing with template instantiations:
+When used with GNU ld version 2.8 or later on an ELF system such as
+Linux/GNU 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:
 
 @enumerate
 @item
+Compile your template-using code with @samp{-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
+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.
+
+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
+one or more points of instantiation; usually this is as simple as adding
+@code{#include <tmethods.cc>} to the end of each template header.
+
+For library code, if you want the library to provide all of the template
+instantiations it needs, just try to link all of its object files
+together; the link will fail, but cause the instantiations to be
+generated as a side effect.  Be warned, however, that this may cause
+conflicts if multiple libraries try to provide the same instantiations.
+For greater control, use explicit instantiation as described in the next
+option.
+
+@item
+Compile your code with @samp{-fno-implicit-templates} to disable the
+implicit generation of template instances, and explicitly instantiate
+all the ones you use.  This approach requires more knowledge of exactly
+which instances you need than do the others, but it's less
+mysterious and allows greater control.  You can scatter the explicit
+instantiations throughout your program, perhaps putting them in the
+translation units where the instances are used or the translation units
+that define the templates themselves; you can put all of the explicit
+instantiations you need into one big file; or you can create small files
+like
+
+@example
+#include "Foo.h"
+#include "Foo.cc"
+
+template class Foo<int>;
+template ostream& operator <<
+                (ostream&, const Foo<int>&);
+@end example
+
+for each of the instances you need, and create a template instantiation
+library from those.
+
+If you are using Cfront-model code, you can probably get away with not
+using @samp{-fno-implicit-templates} when compiling files that don't
+@samp{#include} the member template definitions.
+
+If you use one big file to do the instantiations, you may want to
+compile it without @samp{-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 outlined in the
+Working Paper to allow forward declaration of explicit instantiations,
+explicit instantiation of members of template classes and instantiation
+of the compiler support data for a template class (i.e. the vtable)
+without instantiating any of its members:
+
+@example
+extern template int max (int, int);
+template void Foo<int>::f ();
+inline template class Foo<int>;
+@end example
+
+@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
@@ -3005,16 +3340,16 @@ duplication.
 Add @samp{#pragma interface} to all files containing template
 definitions.  For each of these files, add @samp{#pragma implementation
 "@var{filename}"} to the top of some @samp{.C} file which
-@samp{#include}s it.  Then compile everything with -fexternal-templates.
-The templates will then only be expanded in the translation unit which
-implements them (i.e. has a @samp{#pragma implementation} line for the
-file where they live); all other files will use external references.  If
-you're lucky, everything should work properly.  If you get undefined
-symbol errors, you need to make sure that each template instance which
-is used in the program is used in the file which implements that
-template.  If you don't have any use for a particular instance in that
-file, you can just instantiate it explicitly, using the syntax from the
-latest C++ working paper:
+@samp{#include}s it.  Then compile everything with
+@samp{-fexternal-templates}.  The templates will then only be expanded
+in the translation unit which implements them (i.e. has a @samp{#pragma
+implementation} line for the file where they live); all other files will
+use external references.  If you're lucky, everything should work
+properly.  If you get undefined symbol errors, you need to make sure
+that each template instance which is used in the program is used in the
+file which implements that template.  If you don't have any use for a
+particular instance in that file, you can just instantiate it
+explicitly, using the syntax from the latest C++ working paper:
 
 @example
 template class A<int>;
@@ -3026,37 +3361,15 @@ using code written for the Cfront model, the file containing a class
 template and the file containing its member templates should be
 implemented in the same translation unit.
 
-A slight variation on this approach is to use the flag
--falt-external-templates instead; this flag causes template instances to
-be emitted in the translation unit that implements the header where they
-are first instantiated, rather than the one which implements the file
-where the templates are defined.  This header must be the same in all
-translation units, or things are likely to break.
+A slight variation on this approach is to instead use the flag
+@samp{-falt-external-templates}; this flag causes template
+instances to be emitted in the translation unit that implements the
+header where they are first instantiated, rather than the one which
+implements the file where the templates are defined.  This header must
+be the same in all translation units, or things are likely to break.
 
 @xref{C++ Interface,,Declarations and Definitions in One Header}, for
 more discussion of these pragmas.
-
-@item
-Explicitly instantiate all the template instances you use, and compile
-with -fno-implicit-templates.  This is probably your best bet; it may
-require more knowledge of exactly which templates you are using, but
-it's less mysterious than the previous approach, and it doesn't require
-any @samp{#pragma}s or other g++-specific code.  You can scatter the
-instantiations throughout your program, you can create one big file to
-do all the instantiations, or you can create tiny files like
-
-@example
-#include "Foo.h"
-#include "Foo.cc"
-
-template class Foo<int>;
-@end example
-
-for each instance you need, and create a template instantiation library
-from those.  I'm partial to the last, but your mileage may vary.  If you
-are using Cfront-model code, you can probably get away with not using
--fno-implicit-templates when compiling files that don't @samp{#include}
-the member template definitions.
 @end enumerate
 
 @node C++ Signatures
@@ -3130,7 +3443,7 @@ S * p = &obj;
 
 @noindent
 defines a signature pointer @code{p} and initializes it to point to an
-object of type @code{C}.  
+object of type @code{C}.
 The member function call @w{@samp{int i = p->foo ();}}
 executes @samp{obj.foo ()}.