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
@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
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. Eight attributes,
-@code{noreturn}, @code{const}, @code{format}, @code{section},
+attribute specification inside double parentheses. Nine attributes,
+@code{noreturn}, @code{const}, @code{format},
+@code{no_instrument_function}, @code{section},
@code{constructor}, @code{destructor}, @code{unused} and @code{weak} are
currently defined for functions. Other attributes, including
@code{section} are supported for variables declarations (@pxref{Variable
@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
@code{my_format}.
The parameter @var{archetype} determines how the format string is
-interpreted, and should be either @code{printf} or @code{scanf}. The
+interpreted, and should be either @code{printf}, @code{scanf}, or
+@code{strftime}. 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
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}.
@noindent
causes the compiler to check the arguments in calls to
-@code{my_dgettext} whose result is passed to a @code{printf} or
-@code{scanf} type function for consistency with the @code{printf} style
-format string argument @code{my_format}.
+@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} and @code{scanf} 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.
+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 no_instrument_function
+@cindex @code{no_instrument_function} function attribute
+If @samp{-finstrument-functions} is given, profiling function calls will
+be generated at entry and exit of most user-compiled functions.
+Functions with this attribute will not be so instrumented.
@item section ("section-name")
@cindex @code{section} function attribute
Not all target machines support this attribute.
+@item no_check_memory_usage
+@cindex @code{no_check_memory_usage} function attribute
+If @samp{-fcheck-memory-usage} is given, calls to support routines will
+be generated before most memory accesses, to permit support code to
+record usage and detect uses of uninitialized or unallocated storage.
+Since the compiler cannot handle them properly, @code{asm} statements
+are not allowed. Declaring a function with this attribute disables the
+memory checking code for that function, permitting the use of @code{asm}
+statements without requiring separate compilation with different
+options, and allowing you to write support routines of your own if you
+wish, without getting infinite recursion if they get compiled with this
+option.
+
@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
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
@example
/* @r{Use prototypes unless the compiler is old-fashioned.} */
-#if __STDC__
+#ifdef __STDC__
#define P(x) x
#else
#define P(x) ()
@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
@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})
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
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
@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:
@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 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:
+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));
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"
: "r0", "r1", "r2", "r3", "r4", "r5");
@end example
+It is an error for a clobber description to overlap an input or output
+operand (for example, an operand describing a register class with one
+member, mentioned in the clobber list). Most notably, it is invalid to
+describe that an input operand is modified, but unused as output. It has
+to be specified as an input and output operand anyway. Note that if there
+are only unused output operands, you will then also need to specify
+@code{volatile} for the @code{asm} construct, as described below.
+
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"
: "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:"
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}
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
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
Local register variables in specific registers do not reserve the
registers. The compiler's data flow analysis is capable of determining
where the specified registers contain live values, and where they are
-available for other uses.
+available for other uses. Stores into local register variables may be deleted
+when they appear to be dead according to dataflow analysis. References
+to local register variables may be deleted or moved or simplified.
These local variables are sometimes convenient for use with the extended
@code{asm} feature (@pxref{Extended Asm}), if you want to write one
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.
+
+Stores into local register variables may be deleted when they appear to be dead
+according to dataflow analysis. References to local register variables may
+be deleted or moved or simplified.
@node Alternate Keywords
@section Alternate Keywords
@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
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:
+Working Paper to allow forward declaration of explicit instantiations
+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
OSDN Git Service
