-@c Copyright (C) 1988,1989,1992,1993,1994,1996,1998,1999,2000,2001,2002,
-@c 2003 Free Software Foundation, Inc.
+@c Copyright (C) 1988,1989,1992,1993,1994,1996,1998,1999,2000,2001,2002, 2003
+@c Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
@menu
* Statement Exprs:: Putting statements and declarations inside expressions.
-* Local Labels:: Labels local to a statement-expression.
+* Local Labels:: Labels local to a block.
* Labels as Values:: Getting pointers to labels, and computed gotos.
* Nested Functions:: As in Algol and Pascal, lexical scoping of functions.
* Constructing Calls:: Dispatching a call to another function.
* Hex Floats:: Hexadecimal floating-point constants.
* Zero Length:: Zero-length arrays.
* Variable Length:: Arrays whose length is computed at run time.
+* Empty Structures:: Structures with no members.
* Variadic Macros:: Macros with a variable number of arguments.
* Escaped Newlines:: Slightly looser rules for escaped newlines.
-* Multi-line Strings:: String literals with embedded newlines.
* Subscripting:: Any array can be subscripted, even if not an lvalue.
* Pointer Arith:: Arithmetic on @code{void}-pointers and function pointers.
* Initializers:: Non-constant initializers.
@c the above section title wrapped and causes an underfull hbox.. i
@c changed it from "within" to "in". --mew 4feb93
-
A compound statement enclosed in parentheses may appear as an expression
in GNU C@. This allows you to use loops, switches, and local variables
within an expression.
If you don't know the type of the operand, you can still do this, but you
must use @code{typeof} (@pxref{Typeof}).
-Statement expressions are not supported fully in G++, and their fate
-there is unclear. (It is possible that they will become fully supported
-at some point, or that they will be deprecated, or that the bugs that
-are present will continue to exist indefinitely.) Presently, statement
-expressions do not work well as default arguments.
+In G++, the result value of a statement expression undergoes array and
+function pointer decay, and is returned by value to the enclosing
+expression. For instance, if @code{A} is a class, then
-In addition, there are semantic issues with statement-expressions in
-C++. If you try to use statement-expressions instead of inline
-functions in C++, you may be surprised at the way object destruction is
-handled. For example:
+@smallexample
+ A a;
-@example
-#define foo(a) (@{int b = (a); b + 3; @})
-@end example
+ (@{a;@}).Foo ()
+@end smallexample
@noindent
-does not work the same way as:
+will construct a temporary @code{A} object to hold the result of the
+statement expression, and that will be used to invoke @code{Foo}.
+Therefore the @code{this} pointer observed by @code{Foo} will not be the
+address of @code{a}.
+
+Any temporaries created within a statement within a statement expression
+will be destroyed at the statement's end. This makes statement
+expressions inside macros slightly different from function calls. In
+the latter case temporaries introduced during argument evaluation will
+be destroyed at the end of the statement that includes the function
+call. In the statement expression case they will be destroyed during
+the statement expression. For instance,
-@example
-inline int foo(int a) @{ int b = a; return b + 3; @}
-@end example
+@smallexample
+#define macro(a) (@{__typeof__(a) b = (a); b + 3; @})
+template<typename T> T function(T a) @{ T b = a; return b + 3; @}
+
+void foo ()
+@{
+ macro (X ());
+ function (X ());
+@}
+@end smallexample
@noindent
-In particular, if the expression passed into @code{foo} involves the
-creation of temporaries, the destructors for those temporaries will be
-run earlier in the case of the macro than in the case of the function.
+will have different places where temporaries are destroyed. For the
+@code{macro} case, the temporary @code{X} will be destroyed just after
+the initialization of @code{b}. In the @code{function} case that
+temporary will be destroyed when the function returns.
These considerations mean that it is probably a bad idea to use
statement-expressions of this form in header files that are designed to
@cindex local labels
@cindex macros, local labels
-Each statement expression is a scope in which @dfn{local labels} can be
-declared. A local label is simply an identifier; you can jump to it
-with an ordinary @code{goto} statement, but only from within the
-statement expression it belongs to.
+GCC allows you to declare @dfn{local labels} in any nested block
+scope. A local label is just like an ordinary label, but you can
+only reference it (with a @code{goto} statement, or by taking its
+address) within the block in which it was declared.
A local label declaration looks like this:
__label__ @var{label1}, @var{label2}, /* @r{@dots{}} */;
@end example
-Local label declarations must come at the beginning of the statement
-expression, right after the @samp{(@{}, before any ordinary
-declarations.
+Local label declarations must come at the beginning of the block,
+before any ordinary declarations or statements.
The label declaration defines the label @emph{name}, but does not define
the label itself. You must do this in the usual way, with
@code{@var{label}:}, within the statements of the statement expression.
-The local label feature is useful because statement expressions are
-often used in macros. If the macro contains nested loops, a @code{goto}
-can be useful for breaking out of them. However, an ordinary label
-whose scope is the whole function cannot be used: if the macro can be
-expanded several times in one function, the label will be multiply
-defined in that function. A local label avoids this problem. For
-example:
+The local label feature is useful for complex macros. If a macro
+contains nested loops, a @code{goto} can be useful for breaking out of
+them. However, an ordinary label whose scope is the whole function
+cannot be used: if the macro can be expanded several times in one
+function, the label will be multiply defined in that function. A
+local label avoids this problem. For example:
+
+@example
+#define SEARCH(value, array, target) \
+do @{ \
+ __label__ found; \
+ typeof (target) _SEARCH_target = (target); \
+ typeof (*(array)) *_SEARCH_array = (array); \
+ int i, j; \
+ int value; \
+ for (i = 0; i < max; i++) \
+ for (j = 0; j < max; j++) \
+ if (_SEARCH_array[i][j] == _SEARCH_target) \
+ @{ (value) = i; goto found; @} \
+ (value) = -1; \
+ found:; \
+@} while (0)
+@end example
+
+This could also be written using a statement-expression:
@example
#define SEARCH(array, target) \
@})
@end example
+Local label declarations also make the labels they declare visible to
+nested functions, if there are any. @xref{Nested Functions}, for details.
+
@node Labels as Values
@section Labels as Values
@cindex labels as values
@cindex lvalues, generalized
@cindex extensions, @code{?:}
@cindex @code{?:} extensions
+
Compound expressions, conditional expressions and casts are allowed as
lvalues provided their operands are lvalues. This means that you can take
-their addresses or store values into them.
+their addresses or store values into them. All these extensions are
+deprecated.
-Standard C++ allows compound expressions and conditional expressions as
-lvalues, and permits casts to reference type, so use of this extension
-is deprecated for C++ code.
+Standard C++ allows compound expressions and conditional expressions
+as lvalues, and permits casts to reference type, so use of this
+extension is not supported for C++ code.
For example, a compound expression can be assigned, provided the last
expression in the sequence is an lvalue. These two expressions are
(a ? b = 5 : (c = 5))
@end example
-A cast is a valid lvalue if its operand is an lvalue. A simple
+A cast is a valid lvalue if its operand is an lvalue. This extension
+is deprecated. A simple
assignment whose left-hand side is a cast works by converting the
right-hand side first to the specified type, then to the type of the
inner left-hand side expression. After this is stored, the value is
struct foo d[1] = @{ @{ 1 @{ 2, 3, 4 @} @} @}; // @r{Invalid.}
@end example
+@node Empty Structures
+@section Structures With No Members
+@cindex empty structures
+@cindex zero-size structures
+
+GCC permits a C structure to have no members:
+
+@example
+struct empty @{
+@};
+@end example
+
+The structure will have size zero. In C++, empty structures are part
+of the language. G++ treats empty structures as if they had a single
+member of type @code{char}.
+
@node Variable Length
@section Arrays of Variable Length
@cindex variable-length arrays
Recently, the preprocessor has relaxed its treatment of escaped
newlines. Previously, the newline had to immediately follow a
-backslash. The current implementation allows whitespace in the form of
-spaces, horizontal and vertical tabs, and form feeds between the
+backslash. The current implementation allows whitespace in the form
+of spaces, horizontal and vertical tabs, and form feeds between the
backslash and the subsequent newline. The preprocessor issues a
warning, but treats it as a valid escaped newline and combines the two
lines to form a single logical line. This works within comments and
-tokens, including multi-line strings, as well as between tokens.
-Comments are @emph{not} treated as whitespace for the purposes of this
-relaxation, since they have not yet been replaced with spaces.
-
-@node Multi-line Strings
-@section String Literals with Embedded Newlines
-@cindex multi-line string literals
-
-As an extension, GNU CPP permits string literals to cross multiple lines
-without escaping the embedded newlines. Each embedded newline is
-replaced with a single @samp{\n} character in the resulting string
-literal, regardless of what form the newline took originally.
-
-CPP currently allows such strings in directives as well (other than the
-@samp{#include} family). This is deprecated and will eventually be
-removed.
+tokens, as well as between tokens. Comments are @emph{not} treated as
+whitespace for the purposes of this relaxation, since they have not
+yet been replaced with spaces.
@node Subscripting
@section Non-Lvalue Arrays May Have Subscripts
@code{format}, @code{format_arg}, @code{no_instrument_function},
@code{section}, @code{constructor}, @code{destructor}, @code{used},
@code{unused}, @code{deprecated}, @code{weak}, @code{malloc},
-@code{alias}, and @code{nonnull}. Several other attributes are defined
-for functions on particular target systems. Other attributes, including
-@code{section} are supported for variables declarations
+@code{alias}, @code{warn_unused_result} and @code{nonnull}. Several other
+attributes are defined for functions on particular target systems. Other
+attributes, including @code{section} are supported for variables declarations
(@pxref{Variable Attributes}) and for types (@pxref{Type Attributes}).
You may also specify attributes with @samp{__} preceding and following
better code. More importantly, it helps avoid spurious warnings of
uninitialized variables.
+The @code{noreturn} keyword does not affect the exceptional path when that
+applies: a @code{noreturn}-marked function may still return to the caller
+by throwing an exception.
+
Do not assume that registers saved by the calling function are
restored before calling the @code{noreturn} function.
@item unused
This attribute, attached to a function, means that the function is meant
to be possibly unused. GCC will not produce a warning for this
-function. GNU C++ does not currently support this attribute as
-definitions without parameters are valid in C++.
+function.
@cindex @code{used} attribute.
@item used
The @code{deprecated} attribute can also be used for variables and
types (@pxref{Variable Attributes}, @pxref{Type Attributes}.)
+@item warn_unused_result
+@cindex @code{warn_unused_result} attribute
+The @code{warn_unused_result} attribute causes a warning to be emitted
+if a caller of the function with this attribute does not use its
+return value. This is useful for functions where not checking
+the result is either a security problem or always a bug, such as
+@code{realloc}.
+
+@smallexample
+int fn () __attribute__ ((warn_unused_result));
+int foo ()
+@{
+ if (fn () < 0) return -1;
+ fn ();
+ return 0;
+@}
+@end smallexample
+
+results in warning on line 5.
+
@item weak
@cindex @code{weak} attribute
The @code{weak} attribute causes the declaration to be emitted as a weak
@cindex @code{malloc} attribute
The @code{malloc} attribute is used to tell the compiler that a function
may be treated as if it were the malloc function. The compiler assumes
-that calls to malloc result in a pointers that cannot alias anything.
+that calls to malloc result in pointers that cannot alias anything.
This will often improve optimization.
@item alias ("@var{target}")
int i __attribute__ ((visibility ("hidden")));
@end smallexample
-See the ELF gABI for complete details, but the short story is
+See the ELF gABI for complete details, but the short story is:
@table @dfn
@item default
Internal visibility is like hidden visibility, but with additional
processor specific semantics. Unless otherwise specified by the psABI,
gcc defines internal visibility to mean that the function is @emph{never}
-called from another module. Note that hidden symbols, while then cannot
+called from another module. Note that hidden symbols, while they cannot
be referenced directly by other modules, can be referenced indirectly via
function pointers. By indicating that a symbol cannot be called from
outside the module, gcc may for instance omit the load of a PIC register
Not all ELF targets support this attribute.
-@item tls_model ("@var{tls_model}")
-@cindex @code{tls_model} attribute
-The @code{tls_model} attribute sets thread-local storage model
-(@pxref{Thread-Local}) of a particular @code{__thread} variable,
-overriding @code{-ftls-model=} command line switch on a per-variable
-basis.
-The @var{tls_model} argument should be one of @code{global-dynamic},
-@code{local-dynamic}, @code{initial-exec} or @code{local-exec}.
-
@item regparm (@var{number})
+@cindex @code{regparm} attribute
@cindex functions that are passed arguments in registers on the 386
On the Intel 386, the @code{regparm} attribute causes the compiler to
pass up to @var{number} integer arguments in registers EAX,
variable number of arguments will continue to be passed all of their
arguments on the stack.
+Beware that on some ELF systems this attribute is unsuitable for
+global functions in shared libraries with lazy binding (which is the
+default). Lazy binding will send the first call via resolving code in
+the loader, which might assume EAX, EDX and ECX can be clobbered, as
+per the standard calling conventions. Solaris 8 is affected by this.
+GNU systems with GLIBC 2.1 or higher, and FreeBSD, are believed to be
+safe since the loaders there save all registers. (Lazy binding can be
+disabled with the linker or the loader if desired, to avoid the
+problem.)
+
@item stdcall
@cindex functions that pop the argument stack on the 386
On the Intel 386, the @code{stdcall} attribute causes the compiler to
both the @option{-mlongcall} switch and the @code{#pragma longcall}
setting.
-@xref{RS/6000 and PowerPC Options}, for more information on when long
-calls are and are not necessary.
+@xref{RS/6000 and PowerPC Options}, for more information on whether long
+calls are necessary.
@item long_call/short_call
@cindex indirect calls on ARM
-This attribute allows to specify how to call a particular function on
+This attribute specifies how a particular function is called on
ARM@. Both attributes override the @option{-mlong-calls} (@pxref{ARM Options})
command line switch and @code{#pragma long_calls} settings. The
@code{long_call} attribute causes the compiler to always call the
@item function_vector
@cindex calling functions through the function vector on the H8/300 processors
-Use this attribute on the H8/300 and H8/300H to indicate that the specified
+Use this attribute on the H8/300, H8/300H, and H8S to indicate that the specified
function should be called through the function vector. Calling a
function through the function vector will reduce code size, however;
the function vector has a limited size (maximum 128 entries on the H8/300
-and 64 entries on the H8/300H) and shares space with the interrupt vector.
+and 64 entries on the H8/300H and H8S) and shares space with the interrupt vector.
You must use GAS and GLD from GNU binutils version 2.7 or later for
this attribute to work correctly.
generate function entry and exit sequences suitable for use in an
interrupt handler when this attribute is present.
-Note, interrupt handlers for the H8/300, H8/300H and SH processors can
-be specified via the @code{interrupt_handler} attribute.
+Note, interrupt handlers for the m68k, H8/300, H8/300H, H8S, and SH processors
+can be specified via the @code{interrupt_handler} attribute.
-Note, on the AVR interrupts will be enabled inside the function.
+Note, on the AVR, interrupts will be enabled inside the function.
-Note, for the ARM you can specify the kind of interrupt to be handled by
+Note, for the ARM, you can specify the kind of interrupt to be handled by
adding an optional parameter to the interrupt attribute like this:
@smallexample
Permissible values for this parameter are: IRQ, FIQ, SWI, ABORT and UNDEF@.
@item interrupt_handler
-@cindex interrupt handler functions on the H8/300 and SH processors
-Use this attribute on the H8/300, H8/300H and SH to indicate that the
-specified function is an interrupt handler. The compiler will generate
+@cindex interrupt handler functions on the m68k, H8/300 and SH processors
+Use this attribute on the m68k, H8/300, H8/300H, H8S, and SH to indicate that
+the specified function is an interrupt handler. The compiler will generate
function entry and exit sequences suitable for use in an interrupt
handler when this attribute is present.
@end smallexample
@item trap_exit
-Use this attribute on the SH for an @code{interrupt_handle} to return using
+Use this attribute on the SH for an @code{interrupt_handler} to return using
@code{trapa} instead of @code{rte}. This attribute expects an integer
argument specifying the trap number to be used.
@item eightbit_data
-@cindex eight bit data on the H8/300 and H8/300H
-Use this attribute on the H8/300 and H8/300H to indicate that the specified
+@cindex eight bit data on the H8/300, H8/300H, and H8S
+Use this attribute on the H8/300, H8/300H, and H8S to indicate that the specified
variable should be placed into the eight bit data section.
The compiler will generate more efficient code for certain operations
on data in the eight bit data area. Note the eight bit data area is limited to
this attribute to work correctly.
@item tiny_data
-@cindex tiny data section on the H8/300H
-Use this attribute on the H8/300H to indicate that the specified
+@cindex tiny data section on the H8/300H and H8S
+Use this attribute on the H8/300H and H8S to indicate that the specified
variable should be placed into the tiny data section.
The compiler will generate more efficient code for loads and stores
on data in the tiny data section. Note the tiny data area is limited to
slightly under 32kbytes of data.
+@item saveall
+@cindex save all registers on the H8/300, H8/300H, and H8S
+Use this attribute on the H8/300, H8/300H, and H8S to indicate that
+all registers except the stack pointer should be saved in the prologue
+regardless of whether they are used or not.
+
@item signal
@cindex signal handler functions on the AVR processors
Use this attribute on the AVR to indicate that the specified
-function is an signal handler. The compiler will generate function
-entry and exit sequences suitable for use in an signal handler when this
-attribute is present. Interrupts will be disabled inside function.
+function is a signal handler. The compiler will generate function
+entry and exit sequences suitable for use in a signal handler when this
+attribute is present. Interrupts will be disabled inside the function.
@item naked
@cindex function without a prologue/epilogue code
Use this attribute on the ARM, AVR, C4x and IP2K ports to indicate that the
-specified function do not need prologue/epilogue sequences generated by
+specified function does not need prologue/epilogue sequences generated by
the compiler. It is up to the programmer to provide these sequences.
@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.
+@cindex variable addressability on the IA-64
+
+On the M32R/D, use this attribute to set the addressability of an
+object, and of the code generated for a function. The identifier
+@var{model-name} is one of @code{small}, @code{medium}, or
+@code{large}, representing each of the code models.
Small model objects live in the lower 16MB of memory (so that their
addresses can be loaded with the @code{ld24} instruction), and are
and may not be reachable with the @code{bl} instruction (the compiler will
generate the much slower @code{seth/add3/jl} instruction sequence).
+On IA-64, use this attribute to set the addressability of an object.
+At present, the only supported identifier for @var{model-name} is
+@code{small}, indicating addressability via ``small'' (22-bit)
+addresses (so that their addresses can be loaded with the @code{addl}
+instruction). Caveat: such addressing is by definition not position
+independent and hence this attribute must not be used for objects
+defined by shared libraries.
+
+@item far
+@cindex functions which handle memory bank switching
+On 68HC11 and 68HC12 the @code{far} attribute causes the compiler to
+use a calling convention that takes care of switching memory banks when
+entering and leaving a function. This calling convention is also the
+default when using the @option{-mlong-calls} option.
+
+On 68HC12 the compiler will use the @code{call} and @code{rtc} instructions
+to call and return from a function.
+
+On 68HC11 the compiler will generate a sequence of instructions
+to invoke a board-specific routine to switch the memory bank and call the
+real function. The board-specific routine simulates a @code{call}.
+At the end of a function, it will jump to a board-specific routine
+instead of using @code{rts}. The board-specific return routine simulates
+the @code{rtc}.
+
+@item near
+@cindex functions which do not handle memory bank switching on 68HC11/68HC12
+On 68HC11 and 68HC12 the @code{near} attribute causes the compiler to
+use the normal calling convention based on @code{jsr} and @code{rts}.
+This attribute can be used to cancel the effect of the @option{-mlong-calls}
+option.
+
+@item dllimport
+@cindex @code{__declspec(dllimport)}
+On Windows targets, the @code{dllimport} attribute causes the compiler
+to reference a function or variable via a global pointer to a pointer
+that is set up by the Windows dll library. The pointer name is formed by
+combining @code{_imp__} and the function or variable name. The attribute
+implies @code{extern} storage.
+
+Currently, the attribute is ignored for inlined functions. If the
+attribute is applied to a symbol @emph{definition}, an error is reported.
+If a symbol previously declared @code{dllimport} is later defined, the
+attribute is ignored in subsequent references, and a warning is emitted.
+The attribute is also overridden by a subsequent declaration as
+@code{dllexport}.
+
+When applied to C++ classes, the attribute marks non-inlined
+member functions and static data members as imports. However, the
+attribute is ignored for virtual methods to allow creation of vtables
+using thunks.
+
+On cygwin, mingw and arm-pe targets, @code{__declspec(dllimport)} is
+recognized as a synonym for @code{__attribute__ ((dllimport))} for
+compatibility with other Windows compilers.
+
+The use of the @code{dllimport} attribute on functions is not necessary,
+but provides a small performance benefit by eliminating a thunk in the
+dll. The use of the @code{dllimport} attribute on imported variables was
+required on older versions of GNU ld, but can now be avoided by passing
+the @option{--enable-auto-import} switch to ld. As with functions, using
+the attribute for a variable eliminates a thunk in the dll.
+
+One drawback to using this attribute is that a pointer to a function or
+variable marked as dllimport cannot be used as a constant address. The
+attribute can be disabled for functions by setting the
+@option{-mnop-fun-dllimport} flag.
+
+@item dllexport
+@cindex @code{__declspec(dllexport)}
+On Windows targets the @code{dllexport} attribute causes the compiler to
+provide a global pointer to a pointer in a dll, so that it can be
+referenced with the @code{dllimport} attribute. The pointer name is
+formed by combining @code{_imp__} and the function or variable name.
+
+Currently, the @code{dllexport}attribute is ignored for inlined
+functions, but export can be forced by using the
+@option{-fkeep-inline-functions} flag. The attribute is also ignored for
+undefined symbols.
+
+When applied to C++ classes. the attribute marks defined non-inlined
+member functions and static data members as exports. Static consts
+initialized in-class are not marked unless they are also defined
+out-of-class.
+
+On cygwin, mingw and arm-pe targets, @code{__declspec(dllexport)} is
+recognized as a synonym for @code{__attribute__ ((dllexport))} for
+compatibility with other Windows compilers.
+
+Alternative methods for including the symbol in the dll's export table
+are to use a .def file with an @code{EXPORTS} section or, with GNU ld,
+using the @option{--export-all} linker flag.
+
@end table
You can specify multiple attributes in a declaration by separating them
attachment of attributes to their corresponding declarations, whereas
@code{#pragma GCC} is of use for constructs that do not naturally form
part of the grammar. @xref{Other Directives,,Miscellaneous
-Preprocessing Directives, cpp, The C Preprocessor}.
+Preprocessing Directives, cpp, The GNU C Preprocessor}.
@node Attribute Syntax
@section Attribute Syntax
An @dfn{attribute specifier list} is a sequence of one or more attribute
specifiers, not separated by any other tokens.
-An attribute specifier list may appear after the colon following a
+In GNU C, an attribute specifier list may appear after the colon following a
label, other than a @code{case} or @code{default} label. The only
attribute it makes sense to use after a label is @code{unused}. This
feature is intended for code generated by programs which contains labels
that may be unused but which is compiled with @option{-Wall}. It would
not normally be appropriate to use in it human-written code, though it
could be useful in cases where the code that jumps to the label is
-contained within an @code{#ifdef} conditional.
+contained within an @code{#ifdef} conditional. GNU C++ does not permit
+such placement of attribute lists, as it is permissible for a
+declaration, which could begin with an attribute list, to be labelled in
+C++. Declarations cannot be labelled in C90 or C99, so the ambiguity
+does not arise there.
An attribute specifier list may appear as part of a @code{struct},
@code{union} or @code{enum} specifier. It may go either immediately
designs, @code{__alignof__ (double)} is 4 or even 2.
Some machines never actually require alignment; they allow reference to any
-data type even at an odd addresses. For these machines, @code{__alignof__}
+data type even at an odd address. For these machines, @code{__alignof__}
reports the @emph{recommended} alignment of a type.
If the operand of @code{__alignof__} is an lvalue rather than a type,
The keyword @code{__attribute__} allows you to specify special
attributes of variables or structure fields. This keyword is followed
-by an attribute specification inside double parentheses. Ten
-attributes are currently defined for variables: @code{aligned},
-@code{mode}, @code{nocommon}, @code{packed}, @code{section},
-@code{transparent_union}, @code{unused}, @code{deprecated},
-@code{vector_size}, and @code{weak}. Some other attributes are defined
-for variables on particular target systems. Other attributes are
-available for functions (@pxref{Function Attributes}) and for types
-(@pxref{Type Attributes}). Other front ends might define more
-attributes (@pxref{C++ Extensions,,Extensions to the C++ Language}).
+by an attribute specification inside double parentheses. Some
+attributes are currently defined generically for variables.
+Other attributes are defined for variables on particular target
+systems. Other attributes are available for functions
+(@pxref{Function Attributes}) and for types (@pxref{Type Attributes}).
+Other front ends might define more attributes
+(@pxref{C++ Extensions,,Extensions to the C++ Language}).
You may also specify attributes with @samp{__} preceding and following
each keyword. This allows you to use them in header files without
in an @code{__attribute__} will still only provide you with 8 byte
alignment. See your linker documentation for further information.
+@item cleanup (@var{cleanup_function})
+@cindex @code{cleanup} attribute
+The @code{cleanup} attribute runs a function when the variable goes
+out of scope. This attribute can only be applied to auto function
+scope variables; it may not be applied to parameters or variables
+with static storage duration. The function must take one parameter,
+a pointer to a type compatible with the variable. The return value
+of the function (if any) is ignored.
+
+If @option{-fexceptions} is enabled, then @var{cleanup_function}
+will be run during the stack unwinding that happens during the
+processing of the exception. Note that the @code{cleanup} attribute
+does not allow the exception to be caught, only to perform an action.
+It is undefined what happens if @var{cleanup_function} does not
+return normally.
+
+@item common
+@itemx nocommon
+@cindex @code{common} attribute
+@cindex @code{nocommon} attribute
+@opindex fcommon
+@opindex fno-common
+The @code{common} attribute requests GCC to place a variable in
+``common'' storage. The @code{nocommon} attribute requests the
+opposite -- to allocate space for it directly.
+
+These attributes override the default chosen by the
+@option{-fno-common} and @option{-fcommon} flags respectively.
+
+@item deprecated
+@cindex @code{deprecated} attribute
+The @code{deprecated} attribute results in a warning if the variable
+is used anywhere in the source file. This is useful when identifying
+variables that are expected to be removed in a future version of a
+program. The warning also includes the location of the declaration
+of the deprecated variable, to enable users to easily find further
+information about why the variable is deprecated, or what they should
+do instead. Note that the warning only occurs for uses:
+
+@smallexample
+extern int old_var __attribute__ ((deprecated));
+extern int old_var;
+int new_fn () @{ return old_var; @}
+@end smallexample
+
+results in a warning on line 3 but not line 2.
+
+The @code{deprecated} attribute can also be used for functions and
+types (@pxref{Function Attributes}, @pxref{Type Attributes}.)
+
@item mode (@var{mode})
@cindex @code{mode} attribute
This attribute specifies the data type for the declaration---whichever
@samp{__word__} for the mode of a one-word integer, and @samp{pointer}
or @samp{__pointer__} for the mode used to represent pointers.
-@item nocommon
-@cindex @code{nocommon} attribute
-@opindex fno-common
-This attribute specifies requests GCC not to place a variable
-``common'' but instead to allocate space for it directly. If you
-specify the @option{-fno-common} flag, GCC will do this for all
-variables.
-
-Specifying the @code{nocommon} attribute for a variable provides an
-initialization of zeros. A variable may only be initialized in one
-source file.
-
@item packed
@cindex @code{packed} attribute
The @code{packed} attribute specifies that a variable or structure field
@item shared
@cindex @code{shared} variable attribute
-On Windows NT, in addition to putting variable definitions in a named
+On Windows, in addition to putting variable definitions in a named
section, the section can also be shared among all running copies of an
executable or DLL@. For example, this small program defines shared data
by putting it in a named section @code{shared} and marking the section
attribute with a fully initialized global definition because of the way
linkers work. See @code{section} attribute for more information.
-The @code{shared} attribute is only available on Windows NT@.
+The @code{shared} attribute is only available on Windows@.
+
+@item tls_model ("@var{tls_model}")
+@cindex @code{tls_model} attribute
+The @code{tls_model} attribute sets thread-local storage model
+(@pxref{Thread-Local}) of a particular @code{__thread} variable,
+overriding @code{-ftls-model=} command line switch on a per-variable
+basis.
+The @var{tls_model} argument should be one of @code{global-dynamic},
+@code{local-dynamic}, @code{initial-exec} or @code{local-exec}.
+
+Not all targets support this attribute.
@item transparent_union
This attribute, attached to a function parameter which is a union, means
to be possibly unused. GCC will not produce a warning for this
variable.
-@item deprecated
-The @code{deprecated} attribute results in a warning if the variable
-is used anywhere in the source file. This is useful when identifying
-variables that are expected to be removed in a future version of a
-program. The warning also includes the location of the declaration
-of the deprecated variable, to enable users to easily find further
-information about why the variable is deprecated, or what they should
-do instead. Note that the warnings only occurs for uses:
-
-@smallexample
-extern int old_var __attribute__ ((deprecated));
-extern int old_var;
-int new_fn () @{ return old_var; @}
-@end smallexample
-
-results in a warning on line 3 but not line 2.
-
-The @code{deprecated} attribute can also be used for functions and
-types (@pxref{Function Attributes}, @pxref{Type Attributes}.)
-
@item vector_size (@var{bytes})
This attribute specifies the vector size for the variable, measured in
bytes. For example, the declaration:
@item weak
The @code{weak} attribute is described in @xref{Function Attributes}.
+@item dllimport
+The @code{dllimport} attribute is described in @xref{Function Attributes}.
+
+@item dlexport
+The @code{dllexport} attribute is described in @xref{Function Attributes}.
+
+@end table
+
+@subsection M32R/D Variable Attributes
+
+One attribute is currently defined for the M32R/D.
+
+@table @code
@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.
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
@subsection i386 Variable Attributes
Two attributes are currently defined for i386 configurations:
@code{ms_struct} and @code{gcc_struct}
+@table @code
@item ms_struct
@itemx gcc_struct
-@cindex @code{ms_struct}
-@cindex @code{gcc_struct}
+@cindex @code{ms_struct} attribute
+@cindex @code{gcc_struct} attribute
If @code{packed} is used on a structure, or if bit-fields are used
it may be that the Microsoft ABI packs them differently
Currently @option{-m[no-]ms-bitfields} is provided for the Windows X86
compilers to match the native Microsoft compiler.
-
@end table
-To specify multiple attributes, separate them by commas within the
-double parentheses: for example, @samp{__attribute__ ((aligned (16),
-packed))}.
-
@node Type Attributes
@section Specifying Attributes of Types
@cindex attribute of types
alignment. See your linker documentation for further information.
@item packed
-This attribute, attached to an @code{enum}, @code{struct}, or
-@code{union} type definition, specified that the minimum required memory
-be used to represent the type.
+This attribute, attached to @code{struct} or @code{union} type
+definition, specifies that each member of the structure or union is
+placed to minimize the memory required. When attached to an @code{enum}
+definition, it indicates that the smallest integral type should be used.
@opindex fshort-enums
Specifying this attribute for @code{struct} and @code{union} types is
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, unless that
-declaration also contains the definition of the @code{enum}.
+In the following example @code{struct my_packed_struct}'s members are
+packed closely together, but the internal layout of its @code{s} member
+is not packed -- to do that, @code{struct my_unpacked_struct} would need to
+be packed too.
+
+@smallexample
+struct my_unpacked_struct
+ @{
+ char c;
+ int i;
+ @};
+
+struct my_packed_struct __attribute__ ((__packed__))
+ @{
+ char c;
+ int i;
+ struct my_unpacked_struct s;
+ @};
+@end smallexample
+
+You may only specify this attribute on the definition of a @code{enum},
+@code{struct} or @code{union}, not on a @code{typedef} which does not
+also define the enumerated type, structure or union.
@item transparent_union
This attribute, attached to a @code{union} type definition, indicates
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 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.
to be inlined. If any uses of the function remain, they will refer to
the single copy in the library.
-For future compatibility with when GCC implements ISO C99 semantics for
-inline functions, it is best to use @code{static inline} only. (The
+Since GCC eventually will implement ISO C99 semantics for
+inline functions, it is best to use @code{static inline} only
+to guarantee compatibility. (The
existing semantics will remain available when @option{-std=gnu89} is
specified, but eventually the default will be @option{-std=gnu99} and
that will implement the C99 semantics, though it does not do so yet.)
@noindent
Note that the symbolic operand names have no relation whatsoever to
other C identifiers. You may use any name you like, even those of
-existing C symbols, but must ensure that no two operands within the same
+existing C symbols, but you must ensure that no two operands within the same
assembler construct use the same symbolic name.
Output operand expressions must be lvalues; the compiler can check this.
programs, write @code{__asm__} instead of @code{asm}. @xref{Alternate
Keywords}.
+@subsection Size of an @code{asm}
+
+Some targets require that GCC track the size of each instruction used in
+order to generate correct code. Because the final length of an
+@code{asm} is only known by the assembler, GCC must make an estimate as
+to how big it will be. The estimate is formed by counting the number of
+statements in the pattern of the @code{asm} and multiplying that by the
+length of the longest instruction on that processor. Statements in the
+@code{asm} are identified by newline characters and whatever statement
+separator characters are supported by the assembler; on most processors
+this is the `@code{;}' character.
+
+Normally, GCC's estimate is perfectly adequate to ensure that correct
+code is generated, but it is possible to confuse the compiler if you use
+pseudo instructions or assembler macros that expand into multiple real
+instructions or if you use assembler directives that expand to more
+space in the object file than would be needed for a single instruction.
+If this happens then the assembler will produce a diagnostic saying that
+a label is unreachable.
+
@subsection i386 floating point asm operands
There are several rules on the usage of stack-like regs in
@node Function Names
@section Function Names as Strings
+@cindex @code{__func__} identifier
@cindex @code{__FUNCTION__} identifier
@cindex @code{__PRETTY_FUNCTION__} identifier
-@cindex @code{__func__} identifier
-GCC predefines two magic identifiers to hold the name of the current
-function. The identifier @code{__FUNCTION__} holds the name of the function
-as it appears in the source. The identifier @code{__PRETTY_FUNCTION__}
-holds the name of the function pretty printed in a language specific
-fashion.
+GCC provides three magic variables which hold the name of the current
+function, as a string. The first of these is @code{__func__}, which
+is part of the C99 standard:
+
+@display
+The identifier @code{__func__} is implicitly declared by the translator
+as if, immediately following the opening brace of each function
+definition, the declaration
+
+@smallexample
+static const char __func__[] = "function-name";
+@end smallexample
+
+appeared, where function-name is the name of the lexically-enclosing
+function. This name is the unadorned name of the function.
+@end display
+
+@code{__FUNCTION__} is another name for @code{__func__}. Older
+versions of GCC recognize only this name. However, it is not
+standardized. For maximum portability, we recommend you use
+@code{__func__}, but provide a fallback definition with the
+preprocessor:
+
+@smallexample
+#if __STDC_VERSION__ < 199901L
+# if __GNUC__ >= 2
+# define __func__ __FUNCTION__
+# else
+# define __func__ "<unknown>"
+# endif
+#endif
+@end smallexample
-These names are always the same in a C function, but in a C++ function
-they may be different. For example, this program:
+In C, @code{__PRETTY_FUNCTION__} is yet another name for
+@code{__func__}. However, in C++, @code{__PRETTY_FUNCTION__} contains
+the type signature of the function as well as its bare name. For
+example, this program:
@smallexample
extern "C" @{
@smallexample
__FUNCTION__ = sub
-__PRETTY_FUNCTION__ = int a::sub (int)
-@end smallexample
-
-The compiler automagically replaces the identifiers with a string
-literal containing the appropriate name. Thus, they are neither
-preprocessor macros, like @code{__FILE__} and @code{__LINE__}, nor
-variables. This means that they catenate with other string literals, and
-that they can be used to initialize char arrays. For example
-
-@smallexample
-char here[] = "Function " __FUNCTION__ " in " __FILE__;
+__PRETTY_FUNCTION__ = void a::sub(int)
@end smallexample
-On the other hand, @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__}.
-
-Note that these semantics are deprecated, and that GCC 3.2 will handle
-@code{__FUNCTION__} and @code{__PRETTY_FUNCTION__} the same way as
-@code{__func__}. @code{__func__} is defined by the ISO standard C99:
-
-@display
-The identifier @code{__func__} is implicitly declared by the translator
-as if, immediately following the opening brace of each function
-definition, the declaration
-
-@smallexample
-static const char __func__[] = "function-name";
-@end smallexample
-
-appeared, where function-name is the name of the lexically-enclosing
-function. This name is the unadorned name of the function.
-@end display
-
-By this definition, @code{__func__} is a variable, not a string literal.
-In particular, @code{__func__} does not catenate with other string
-literals.
-
-In @code{C++}, @code{__FUNCTION__} and @code{__PRETTY_FUNCTION__} are
-variables, declared in the same way as @code{__func__}.
+These identifiers are not preprocessor macros. In GCC 3.3 and
+earlier, in C only, @code{__FUNCTION__} and @code{__PRETTY_FUNCTION__}
+were treated as string literals; they could be used to initialize
+@code{char} arrays, and they could be concatenated with other string
+literals. GCC 3.4 and later treat them as variables, like
+@code{__func__}. In C++, @code{__FUNCTION__} and
+@code{__PRETTY_FUNCTION__} have always been variables.
@node Return Address
@section Getting the Return or Frame Address of a Function
@findex __builtin_islessequal
@findex __builtin_islessgreater
@findex __builtin_isunordered
+@findex _Exit
+@findex _exit
@findex abort
@findex abs
+@findex acos
+@findex acosf
+@findex acosh
+@findex acoshf
+@findex acoshl
+@findex acosl
@findex alloca
+@findex asin
+@findex asinf
+@findex asinh
+@findex asinhf
+@findex asinhl
+@findex asinl
+@findex atan
@findex atan2
@findex atan2f
@findex atan2l
+@findex atanf
+@findex atanh
+@findex atanhf
+@findex atanhl
+@findex atanl
@findex bcmp
@findex bzero
+@findex cabs
+@findex cabsf
+@findex cabsl
+@findex cacos
+@findex cacosf
+@findex cacosh
+@findex cacoshf
+@findex cacoshl
+@findex cacosl
+@findex calloc
+@findex carg
+@findex cargf
+@findex cargl
+@findex casin
+@findex casinf
+@findex casinh
+@findex casinhf
+@findex casinhl
+@findex casinl
+@findex catan
+@findex catanf
+@findex catanh
+@findex catanhf
+@findex catanhl
+@findex catanl
+@findex cbrt
+@findex cbrtf
+@findex cbrtl
+@findex ccos
+@findex ccosf
+@findex ccosh
+@findex ccoshf
+@findex ccoshl
+@findex ccosl
@findex ceil
@findex ceilf
@findex ceill
+@findex cexp
+@findex cexpf
+@findex cexpl
@findex cimag
@findex cimagf
@findex cimagl
@findex conj
@findex conjf
@findex conjl
+@findex copysign
+@findex copysignf
+@findex copysignl
@findex cos
@findex cosf
+@findex cosh
+@findex coshf
+@findex coshl
@findex cosl
+@findex cpow
+@findex cpowf
+@findex cpowl
+@findex cproj
+@findex cprojf
+@findex cprojl
@findex creal
@findex crealf
@findex creall
+@findex csin
+@findex csinf
+@findex csinh
+@findex csinhf
+@findex csinhl
+@findex csinl
+@findex csqrt
+@findex csqrtf
+@findex csqrtl
+@findex ctan
+@findex ctanf
+@findex ctanh
+@findex ctanhf
+@findex ctanhl
+@findex ctanl
+@findex dcgettext
+@findex dgettext
+@findex drem
+@findex dremf
+@findex dreml
+@findex erf
+@findex erfc
+@findex erfcf
+@findex erfcl
+@findex erff
+@findex erfl
@findex exit
-@findex _exit
-@findex _Exit
@findex exp
+@findex exp10
+@findex exp10f
+@findex exp10l
+@findex exp2
+@findex exp2f
+@findex exp2l
@findex expf
@findex expl
+@findex expm1
+@findex expm1f
+@findex expm1l
@findex fabs
@findex fabsf
@findex fabsl
+@findex fdim
+@findex fdimf
+@findex fdiml
@findex ffs
@findex floor
@findex floorf
@findex floorl
+@findex fma
+@findex fmaf
+@findex fmal
+@findex fmax
+@findex fmaxf
+@findex fmaxl
+@findex fmin
+@findex fminf
+@findex fminl
@findex fmod
@findex fmodf
@findex fmodl
@findex fprintf_unlocked
@findex fputs
@findex fputs_unlocked
+@findex frexp
+@findex frexpf
+@findex frexpl
+@findex fscanf
+@findex gamma
+@findex gammaf
+@findex gammal
+@findex gettext
+@findex hypot
+@findex hypotf
+@findex hypotl
+@findex ilogb
+@findex ilogbf
+@findex ilogbl
@findex imaxabs
@findex index
+@findex j0
+@findex j0f
+@findex j0l
+@findex j1
+@findex j1f
+@findex j1l
+@findex jn
+@findex jnf
+@findex jnl
@findex labs
+@findex ldexp
+@findex ldexpf
+@findex ldexpl
+@findex lgamma
+@findex lgammaf
+@findex lgammal
@findex llabs
+@findex llrint
+@findex llrintf
+@findex llrintl
+@findex llround
+@findex llroundf
+@findex llroundl
@findex log
+@findex log10
+@findex log10f
+@findex log10l
+@findex log1p
+@findex log1pf
+@findex log1pl
+@findex log2
+@findex log2f
+@findex log2l
+@findex logb
+@findex logbf
+@findex logbl
@findex logf
@findex logl
+@findex lrint
+@findex lrintf
+@findex lrintl
+@findex lround
+@findex lroundf
+@findex lroundl
+@findex malloc
@findex memcmp
@findex memcpy
+@findex mempcpy
@findex memset
+@findex modf
+@findex modff
+@findex modfl
@findex nearbyint
@findex nearbyintf
@findex nearbyintl
+@findex nextafter
+@findex nextafterf
+@findex nextafterl
+@findex nexttoward
+@findex nexttowardf
+@findex nexttowardl
@findex pow
+@findex pow10
+@findex pow10f
+@findex pow10l
@findex powf
@findex powl
@findex printf
@findex printf_unlocked
@findex putchar
@findex puts
+@findex remainder
+@findex remainderf
+@findex remainderl
+@findex remquo
+@findex remquof
+@findex remquol
@findex rindex
+@findex rint
+@findex rintf
+@findex rintl
@findex round
@findex roundf
@findex roundl
-@findex scanf
+@findex scalb
+@findex scalbf
+@findex scalbl
+@findex scalbln
+@findex scalblnf
+@findex scalblnf
+@findex scalbn
+@findex scalbnf
+@findex scanfnl
+@findex significand
+@findex significandf
+@findex significandl
@findex sin
+@findex sincos
+@findex sincosf
+@findex sincosl
@findex sinf
+@findex sinh
+@findex sinhf
+@findex sinhl
@findex sinl
@findex snprintf
@findex sprintf
@findex sqrtf
@findex sqrtl
@findex sscanf
+@findex stpcpy
@findex strcat
@findex strchr
@findex strcmp
@findex strcpy
@findex strcspn
+@findex strdup
+@findex strfmon
+@findex strftime
@findex strlen
@findex strncat
@findex strncmp
@findex strrchr
@findex strspn
@findex strstr
+@findex tan
+@findex tanf
+@findex tanh
+@findex tanhf
+@findex tanhl
+@findex tanl
+@findex tgamma
+@findex tgammaf
+@findex tgammal
@findex trunc
@findex truncf
@findex truncl
+@findex vfprintf
+@findex vfscanf
@findex vprintf
@findex vscanf
@findex vsnprintf
@findex vsprintf
@findex vsscanf
+@findex y0
+@findex y0f
+@findex y0l
+@findex y1
+@findex y1f
+@findex y1l
+@findex yn
+@findex ynf
+@findex ynl
GCC provides a large number of built-in functions other than the ones
mentioned above. Some of these are for internal use in the processing
@opindex ansi
@opindex std
Outside strict ISO C mode (@option{-ansi}, @option{-std=c89} or
-@option{-std=c99}), the functions @code{alloca}, @code{bcmp},
-@code{bzero}, @code{_exit}, @code{ffs}, @code{fprintf_unlocked},
-@code{fputs_unlocked}, @code{index}, @code{printf_unlocked},
-and @code{rindex} may be handled as built-in functions.
+@option{-std=c99}), the functions
+@code{_exit}, @code{alloca}, @code{bcmp}, @code{bzero},
+@code{dcgettext}, @code{dgettext}, @code{dremf}, @code{dreml},
+@code{drem}, @code{exp10f}, @code{exp10l}, @code{exp10}, @code{ffsll},
+@code{ffsl}, @code{ffs}, @code{fprintf_unlocked}, @code{fputs_unlocked},
+@code{gammaf}, @code{gammal}, @code{gamma}, @code{gettext},
+@code{index}, @code{j0f}, @code{j0l}, @code{j0}, @code{j1f}, @code{j1l},
+@code{j1}, @code{jnf}, @code{jnl}, @code{jn}, @code{mempcpy},
+@code{pow10f}, @code{pow10l}, @code{pow10}, @code{printf_unlocked},
+@code{rindex}, @code{scalbf}, @code{scalbl}, @code{scalb},
+@code{significandf}, @code{significandl}, @code{significand},
+@code{sincosf}, @code{sincosl}, @code{sincos}, @code{stpcpy},
+@code{strdup}, @code{strfmon}, @code{y0f}, @code{y0l}, @code{y0},
+@code{y1f}, @code{y1l}, @code{y1}, @code{ynf}, @code{ynl} and @code{yn}
+may be handled as built-in functions.
All these functions have corresponding versions
prefixed with @code{__builtin_}, which may be used even in strict C89
mode.
-The ISO C99 functions @code{conj}, @code{conjf}, @code{conjl}, @code{creal},
-@code{crealf}, @code{creall}, @code{cimag}, @code{cimagf}, @code{cimagl},
-@code{_Exit}, @code{imaxabs}, @code{llabs},
-@code{nearbyint}, @code{nearbyintf}, @code{nearbyintl},
-@code{round}, @code{roundf}, @code{roundl}, @code{snprintf},
-@code{trunc}, @code{truncf}, @code{truncl},
-@code{vscanf}, @code{vsnprintf} and @code{vsscanf}
+The ISO C99 functions
+@code{_Exit}, @code{acoshf}, @code{acoshl}, @code{acosh}, @code{asinhf},
+@code{asinhl}, @code{asinh}, @code{atanhf}, @code{atanhl}, @code{atanh},
+@code{cabsf}, @code{cabsl}, @code{cabs}, @code{cacosf}, @code{cacoshf},
+@code{cacoshl}, @code{cacosh}, @code{cacosl}, @code{cacos},
+@code{cargf}, @code{cargl}, @code{carg}, @code{casinf}, @code{casinhf},
+@code{casinhl}, @code{casinh}, @code{casinl}, @code{casin},
+@code{catanf}, @code{catanhf}, @code{catanhl}, @code{catanh},
+@code{catanl}, @code{catan}, @code{cbrtf}, @code{cbrtl}, @code{cbrt},
+@code{ccosf}, @code{ccoshf}, @code{ccoshl}, @code{ccosh}, @code{ccosl},
+@code{ccos}, @code{cexpf}, @code{cexpl}, @code{cexp}, @code{cimagf},
+@code{cimagl}, @code{cimag},
+@code{conjf}, @code{conjl}, @code{conj}, @code{copysignf},
+@code{copysignl}, @code{copysign}, @code{cpowf}, @code{cpowl},
+@code{cpow}, @code{cprojf}, @code{cprojl}, @code{cproj}, @code{crealf},
+@code{creall}, @code{creal}, @code{csinf}, @code{csinhf}, @code{csinhl},
+@code{csinh}, @code{csinl}, @code{csin}, @code{csqrtf}, @code{csqrtl},
+@code{csqrt}, @code{ctanf}, @code{ctanhf}, @code{ctanhl}, @code{ctanh},
+@code{ctanl}, @code{ctan}, @code{erfcf}, @code{erfcl}, @code{erfc},
+@code{erff}, @code{erfl}, @code{erf}, @code{exp2f}, @code{exp2l},
+@code{exp2}, @code{expm1f}, @code{expm1l}, @code{expm1}, @code{fdimf},
+@code{fdiml}, @code{fdim}, @code{fmaf}, @code{fmal}, @code{fmaxf},
+@code{fmaxl}, @code{fmax}, @code{fma}, @code{fminf}, @code{fminl},
+@code{fmin}, @code{hypotf}, @code{hypotl}, @code{hypot}, @code{ilogbf},
+@code{ilogbl}, @code{ilogb}, @code{imaxabs}, @code{lgammaf},
+@code{lgammal}, @code{lgamma}, @code{llabs}, @code{llrintf},
+@code{llrintl}, @code{llrint}, @code{llroundf}, @code{llroundl},
+@code{llround}, @code{log1pf}, @code{log1pl}, @code{log1p},
+@code{log2f}, @code{log2l}, @code{log2}, @code{logbf}, @code{logbl},
+@code{logb}, @code{lrintf}, @code{lrintl}, @code{lrint}, @code{lroundf},
+@code{lroundl}, @code{lround}, @code{nearbyintf}, @code{nearbyintl},
+@code{nearbyint}, @code{nextafterf}, @code{nextafterl},
+@code{nextafter}, @code{nexttowardf}, @code{nexttowardl},
+@code{nexttoward}, @code{remainderf}, @code{remainderl},
+@code{remainder}, @code{remquof}, @code{remquol}, @code{remquo},
+@code{rintf}, @code{rintl}, @code{rint}, @code{roundf}, @code{roundl},
+@code{round}, @code{scalblnf}, @code{scalblnl}, @code{scalbln},
+@code{scalbnf}, @code{scalbnl}, @code{scalbn}, @code{snprintf},
+@code{tgammaf}, @code{tgammal}, @code{tgamma}, @code{truncf},
+@code{truncl}, @code{trunc}, @code{vfscanf}, @code{vscanf},
+@code{vsnprintf} and @code{vsscanf}
are handled as built-in functions
except in strict ISO C90 mode (@option{-ansi} or @option{-std=c89}).
-There are also built-in versions of the ISO C99 functions @code{atan2f},
-@code{atan2l}, @code{ceilf}, @code{ceill}, @code{cosf}, @code{cosl},
-@code{expf}, @code{expl}, @code{fabsf}, @code{fabsl}, @code{floorf},
-@code{floorl}, @code{fmodf}, @code{fmodl},
-@code{logf}, @code{logl}, @code{powf}, @code{powl},
-@code{sinf}, @code{sinl}, @code{sqrtf} and @code{sqrtl}
+There are also built-in versions of the ISO C99 functions
+@code{acosf}, @code{acosl}, @code{asinf}, @code{asinl}, @code{atan2f},
+@code{atan2l}, @code{atanf}, @code{atanl}, @code{ceilf}, @code{ceill},
+@code{cosf}, @code{coshf}, @code{coshl}, @code{cosl}, @code{expf},
+@code{expl}, @code{fabsf}, @code{fabsl}, @code{floorf}, @code{floorl},
+@code{fmodf}, @code{fmodl}, @code{frexpf}, @code{frexpl}, @code{ldexpf},
+@code{ldexpl}, @code{log10f}, @code{log10l}, @code{logf}, @code{logl},
+@code{modfl}, @code{modf}, @code{powf}, @code{powl}, @code{sinf},
+@code{sinhf}, @code{sinhl}, @code{sinl}, @code{sqrtf}, @code{sqrtl},
+@code{tanf}, @code{tanhf}, @code{tanhl} and @code{tanl}
that are recognized in any mode since ISO C90 reserves these names for
the purpose to which ISO C99 puts them. All these functions have
corresponding versions prefixed with @code{__builtin_}.
-The ISO C90 functions @code{abort}, @code{abs}, @code{atan2}, @code{ceil},
-@code{cos}, @code{exit},
-@code{exp}, @code{fabs}, @code{floor}, @code{fmod},
-@code{fprintf}, @code{fputs}, @code{labs}, @code{log},
-@code{memcmp}, @code{memcpy}, @code{memset}, @code{pow}, @code{printf},
-@code{putchar}, @code{puts}, @code{scanf}, @code{sin}, @code{snprintf},
-@code{sprintf}, @code{sqrt}, @code{sscanf},
-@code{strcat}, @code{strchr}, @code{strcmp},
-@code{strcpy}, @code{strcspn}, @code{strlen}, @code{strncat}, @code{strncmp},
-@code{strncpy}, @code{strpbrk}, @code{strrchr}, @code{strspn}, @code{strstr},
-@code{vprintf} and @code{vsprintf}
+The ISO C90 functions
+@code{abort}, @code{abs}, @code{acos}, @code{asin}, @code{atan2},
+@code{atan}, @code{calloc}, @code{ceil}, @code{cosh}, @code{cos},
+@code{exit}, @code{exp}, @code{fabs}, @code{floor}, @code{fmod},
+@code{fprintf}, @code{fputs}, @code{frexp}, @code{fscanf}, @code{labs},
+@code{ldexp}, @code{log10}, @code{log}, @code{malloc}, @code{memcmp},
+@code{memcpy}, @code{memset}, @code{modf}, @code{pow}, @code{printf},
+@code{putchar}, @code{puts}, @code{scanf}, @code{sinh}, @code{sin},
+@code{snprintf}, @code{sprintf}, @code{sqrt}, @code{sscanf},
+@code{strcat}, @code{strchr}, @code{strcmp}, @code{strcpy},
+@code{strcspn}, @code{strlen}, @code{strncat}, @code{strncmp},
+@code{strncpy}, @code{strpbrk}, @code{strrchr}, @code{strspn},
+@code{strstr}, @code{tanh}, @code{tan}, @code{vfprintf}, @code{vprintf}
+and @code{vsprintf}
are all recognized as built-in functions unless
@option{-fno-builtin} is specified (or @option{-fno-builtin-@var{function}}
is specified for an individual function). All of these functions have
Similar to @code{__builtin_huge_val}, except the return type is @code{float}.
@end deftypefn
-@deftypefn {Built-in Function} long double __builtin_huge_vall (void)
+@deftypefn {Built-in Function} {long double} __builtin_huge_vall (void)
Similar to @code{__builtin_huge_val}, except the return
type is @code{long double}.
@end deftypefn
Similar to @code{__builtin_inf}, except the return type is @code{float}.
@end deftypefn
-@deftypefn {Built-in Function} long double __builtin_infl (void)
+@deftypefn {Built-in Function} {long double} __builtin_infl (void)
Similar to @code{__builtin_inf}, except the return
type is @code{long double}.
@end deftypefn
Similar to @code{__builtin_nan}, except the return type is @code{float}.
@end deftypefn
-@deftypefn {Built-in Function} long double __builtin_nanl (const char *str)
+@deftypefn {Built-in Function} {long double} __builtin_nanl (const char *str)
Similar to @code{__builtin_nan}, except the return type is @code{long double}.
@end deftypefn
Similar to @code{__builtin_nans}, except the return type is @code{float}.
@end deftypefn
-@deftypefn {Built-in Function} long double __builtin_nansl (const char *str)
+@deftypefn {Built-in Function} {long double} __builtin_nansl (const char *str)
Similar to @code{__builtin_nans}, except the return type is @code{long double}.
@end deftypefn
@menu
* Alpha Built-in Functions::
+* ARM Built-in Functions::
* X86 Built-in Functions::
* PowerPC AltiVec Built-in Functions::
@end menu
void __builtin_set_thread_pointer (void *)
@end example
+@node ARM Built-in Functions
+@subsection ARM Built-in Functions
+
+These built-in functions are available for the ARM family of
+processors, when the @option{-mcpu=iwmmxt} switch is used:
+
+@example
+typedef int __v2si __attribute__ ((__mode__ (__V2SI__)))
+
+v2si __builtin_arm_waddw (v2si, v2si)
+v2si __builtin_arm_waddw (v2si, v2si)
+v2si __builtin_arm_wsubw (v2si, v2si)
+v2si __builtin_arm_wsubw (v2si, v2si)
+v2si __builtin_arm_waddwss (v2si, v2si)
+v2si __builtin_arm_wsubwss (v2si, v2si)
+v2si __builtin_arm_wsubwss (v2si, v2si)
+v2si __builtin_arm_wsubwss (v2si, v2si)
+v2si __builtin_arm_wsubwss (v2si, v2si)
+v2si __builtin_arm_waddwus (v2si, v2si)
+v2si __builtin_arm_wsubwus (v2si, v2si)
+v2si __builtin_arm_wsubwus (v2si, v2si)
+v2si __builtin_arm_wmaxuw (v2si, v2si)
+v2si __builtin_arm_wmaxsw (v2si, v2si)
+v2si __builtin_arm_wavg2br (v2si, v2si)
+v2si __builtin_arm_wavg2hr (v2si, v2si)
+v2si __builtin_arm_wavg2b (v2si, v2si)
+v2si __builtin_arm_wavg2h (v2si, v2si)
+v2si __builtin_arm_waccb (v2si)
+v2si __builtin_arm_wacch (v2si)
+v2si __builtin_arm_waccw (v2si)
+v2si __builtin_arm_wmacs (v2si, v2si, v2si)
+v2si __builtin_arm_wmacsz (v2si, v2si, v2si)
+v2si __builtin_arm_wmacu (v2si, v2si, v2si)
+v2si __builtin_arm_wmacuz (v2si, v2si)
+v2si __builtin_arm_wsadb (v2si, v2si)
+v2si __builtin_arm_wsadbz (v2si, v2si)
+v2si __builtin_arm_wsadh (v2si, v2si)
+v2si __builtin_arm_wsadhz (v2si, v2si)
+v2si __builtin_arm_walign (v2si, v2si)
+v2si __builtin_arm_tmia (v2si, int, int)
+v2si __builtin_arm_tmiaph (v2si, int, int)
+v2si __builtin_arm_tmiabb (v2si, int, int)
+v2si __builtin_arm_tmiabt (v2si, int, int)
+v2si __builtin_arm_tmiatb (v2si, int, int)
+v2si __builtin_arm_tmiatt (v2si, int, int)
+int __builtin_arm_tmovmskb (v2si)
+int __builtin_arm_tmovmskh (v2si)
+int __builtin_arm_tmovmskw (v2si)
+v2si __builtin_arm_wmadds (v2si, v2si)
+v2si __builtin_arm_wmaddu (v2si, v2si)
+v2si __builtin_arm_wpackhss (v2si, v2si)
+v2si __builtin_arm_wpackwss (v2si, v2si)
+v2si __builtin_arm_wpackdss (v2si, v2si)
+v2si __builtin_arm_wpackhus (v2si, v2si)
+v2si __builtin_arm_wpackwus (v2si, v2si)
+v2si __builtin_arm_wpackdus (v2si, v2si)
+v2si __builtin_arm_waddb (v2si, v2si)
+v2si __builtin_arm_waddh (v2si, v2si)
+v2si __builtin_arm_waddw (v2si, v2si)
+v2si __builtin_arm_waddbss (v2si, v2si)
+v2si __builtin_arm_waddhss (v2si, v2si)
+v2si __builtin_arm_waddwss (v2si, v2si)
+v2si __builtin_arm_waddbus (v2si, v2si)
+v2si __builtin_arm_waddhus (v2si, v2si)
+v2si __builtin_arm_waddwus (v2si, v2si)
+v2si __builtin_arm_wsubb (v2si, v2si)
+v2si __builtin_arm_wsubh (v2si, v2si)
+v2si __builtin_arm_wsubw (v2si, v2si)
+v2si __builtin_arm_wsubbss (v2si, v2si)
+v2si __builtin_arm_wsubhss (v2si, v2si)
+v2si __builtin_arm_wsubwss (v2si, v2si)
+v2si __builtin_arm_wsubbus (v2si, v2si)
+v2si __builtin_arm_wsubhus (v2si, v2si)
+v2si __builtin_arm_wsubwus (v2si, v2si)
+v2si __builtin_arm_wand (v2si, v2si)
+v2si __builtin_arm_wandn (v2si, v2si)
+v2si __builtin_arm_wor (v2si, v2si)
+v2si __builtin_arm_wxor (v2si, v2si)
+v2si __builtin_arm_wcmpeqb (v2si, v2si)
+v2si __builtin_arm_wcmpeqh (v2si, v2si)
+v2si __builtin_arm_wcmpeqw (v2si, v2si)
+v2si __builtin_arm_wcmpgtub (v2si, v2si)
+v2si __builtin_arm_wcmpgtuh (v2si, v2si)
+v2si __builtin_arm_wcmpgtuw (v2si, v2si)
+v2si __builtin_arm_wcmpgtsb (v2si, v2si)
+v2si __builtin_arm_wcmpgtsh (v2si, v2si)
+v2si __builtin_arm_wcmpgtsw (v2si, v2si)
+int __builtin_arm_textrmsb (v2si, int)
+int __builtin_arm_textrmsh (v2si, int)
+int __builtin_arm_textrmsw (v2si, int)
+int __builtin_arm_textrmub (v2si, int)
+int __builtin_arm_textrmuh (v2si, int)
+int __builtin_arm_textrmuw (v2si, int)
+v2si __builtin_arm_tinsrb (v2si, int, int)
+v2si __builtin_arm_tinsrh (v2si, int, int)
+v2si __builtin_arm_tinsrw (v2si, int, int)
+v2si __builtin_arm_wmaxsw (v2si, v2si)
+v2si __builtin_arm_wmaxsh (v2si, v2si)
+v2si __builtin_arm_wmaxsb (v2si, v2si)
+v2si __builtin_arm_wmaxuw (v2si, v2si)
+v2si __builtin_arm_wmaxuh (v2si, v2si)
+v2si __builtin_arm_wmaxub (v2si, v2si)
+v2si __builtin_arm_wminsw (v2si, v2si)
+v2si __builtin_arm_wminsh (v2si, v2si)
+v2si __builtin_arm_wminsb (v2si, v2si)
+v2si __builtin_arm_wminuw (v2si, v2si)
+v2si __builtin_arm_wminuh (v2si, v2si)
+v2si __builtin_arm_wminub (v2si, v2si)
+v2si __builtin_arm_wmuluh (v2si, v2si)
+v2si __builtin_arm_wmulsh (v2si, v2si)
+v2si __builtin_arm_wmulul (v2si, v2si)
+v2si __builtin_arm_wshufh (v2si, int)
+v2si __builtin_arm_wsllh (v2si, v2si)
+v2si __builtin_arm_wsllw (v2si, v2si)
+v2si __builtin_arm_wslld (v2si, v2si)
+v2si __builtin_arm_wsrah (v2si, v2si)
+v2si __builtin_arm_wsraw (v2si, v2si)
+v2si __builtin_arm_wsrad (v2si, v2si)
+v2si __builtin_arm_wsrlh (v2si, v2si)
+v2si __builtin_arm_wsrlw (v2si, v2si)
+v2si __builtin_arm_wsrld (v2si, v2si)
+v2si __builtin_arm_wrorh (v2si, v2si)
+v2si __builtin_arm_wrorw (v2si, v2si)
+v2si __builtin_arm_wrord (v2si, v2si)
+v2si __builtin_arm_wsllhi (v2si, int)
+v2si __builtin_arm_wsllwi (v2si, int)
+v2si __builtin_arm_wslldi (v2si, v2si)
+v2si __builtin_arm_wsrahi (v2si, int)
+v2si __builtin_arm_wsrawi (v2si, int)
+v2si __builtin_arm_wsradi (v2si, v2si)
+v2si __builtin_arm_wsrlwi (v2si, int)
+v2si __builtin_arm_wsrldi (v2si, int)
+v2si __builtin_arm_wrorhi (v2si, int)
+v2si __builtin_arm_wrorwi (v2si, int)
+v2si __builtin_arm_wrordi (v2si, int)
+v2si __builtin_arm_wunpckihb (v2si, v2si)
+v2si __builtin_arm_wunpckihh (v2si, v2si)
+v2si __builtin_arm_wunpckihw (v2si, v2si)
+v2si __builtin_arm_wunpckilb (v2si, v2si)
+v2si __builtin_arm_wunpckilh (v2si, v2si)
+v2si __builtin_arm_wunpckilw (v2si, v2si)
+v2si __builtin_arm_wunpckehsb (v2si)
+v2si __builtin_arm_wunpckehsh (v2si)
+v2si __builtin_arm_wunpckehsw (v2si)
+v2si __builtin_arm_wunpckehub (v2si)
+v2si __builtin_arm_wunpckehuh (v2si)
+v2si __builtin_arm_wunpckehuw (v2si)
+v2si __builtin_arm_wunpckelsb (v2si)
+v2si __builtin_arm_wunpckelsh (v2si)
+v2si __builtin_arm_wunpckelsw (v2si)
+v2si __builtin_arm_wunpckelub (v2si)
+v2si __builtin_arm_wunpckeluh (v2si)
+v2si __builtin_arm_wunpckeluw (v2si)
+v2si __builtin_arm_wsubwss (v2si, v2si)
+v2si __builtin_arm_wsraw (v2si, v2si)
+v2si __builtin_arm_wsrad (v2si, v2si)
+@end example
+
@node X86 Built-in Functions
@subsection X86 Built-in Functions
Generates the @code{movlps} machine instruction as a store to memory.
@end table
+The following built-in functions are available when @option{-mpni} is used.
+All of them generate the machine instruction that is part of the name.
+
+@example
+v2df __builtin_ia32_addsubpd (v2df, v2df)
+v2df __builtin_ia32_addsubps (v2df, v2df)
+v2df __builtin_ia32_haddpd (v2df, v2df)
+v2df __builtin_ia32_haddps (v2df, v2df)
+v2df __builtin_ia32_hsubpd (v2df, v2df)
+v2df __builtin_ia32_hsubps (v2df, v2df)
+v16qi __builtin_ia32_lddqu (char const *)
+void __builtin_ia32_monitor (void *, unsigned int, unsigned int)
+v2df __builtin_ia32_movddup (v2df)
+v4sf __builtin_ia32_movshdup (v4sf)
+v4sf __builtin_ia32_movsldup (v4sf)
+void __builtin_ia32_mwait (unsigned int, unsigned int)
+@end example
+
+The following built-in functions are available when @option{-mpni} is used.
+
+@table @code
+@item v2df __builtin_ia32_loadddup (double const *)
+Generates the @code{movddup} machine instruction as a load from memory.
+@end table
+
The following built-in functions are available when @option{-m3dnow} is used.
All of them generate the machine instruction that is part of the name.
The following pragmas are available for all architectures running the
Darwin operating system. These are useful for compatibility with other
-MacOS compilers.
+Mac OS compilers.
@table @code
@item mark @var{tokens}@dots{}
New section before @b{[basic.stc.static]}
@quotation
-The keyword @code{__thread} applied to an non-local object gives the
+The keyword @code{__thread} applied to a non-local object gives the
object thread storage duration.
A local variable or class data member declared both @code{static}
want to write code that checks whether these features are available, you can
test for the GNU compiler the same way as for C programs: check for a
predefined macro @code{__GNUC__}. You can also use @code{__GNUG__} to
-test specifically for GNU C++ (@pxref{Standard Predefined,,Standard
-Predefined Macros,cpp.info,The C Preprocessor}).
+test specifically for GNU C++ (@pxref{Common Predefined Macros,,
+Predefined Macros,cpp,The GNU C Preprocessor}).
@menu
* Min and Max:: C++ Minimum and maximum operators.
* Bound member functions:: You can extract a function pointer to the
method denoted by a @samp{->*} or @samp{.*} expression.
* C++ Attributes:: Variable, function, and type attributes for C++ only.
+* Strong Using:: Strong using-directives for namespace composition.
* Java Exceptions:: Tweaking exception handling to work with Java.
-* Deprecated Features:: Things might disappear from g++.
+* Deprecated Features:: Things will disappear from g++.
* Backwards Compatibility:: Compatibilities with earlier definitions of C++.
@end menu
@node Template Instantiation
@section Where's the Template?
-
@cindex template instantiation
C++ templates are the first language feature to require more
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
+g++ has extended the template instantiation syntax given in the ISO
+standard to allow forward declaration of explicit instantiations
(with @code{extern}), instantiation of the compiler support data for a
template class (i.e.@: the vtable) without instantiating any of its
members (with @code{inline}), and instantiation of only the static data
@node Bound member functions
@section Extracting the function pointer from a bound pointer to member function
-
@cindex pmf
@cindex pointer to member function
@cindex bound pointer to member function
@end table
+See also @xref{Strong Using}.
+
+@node Strong Using
+@section Strong Using
+
+A using-directive with @code{__attribute ((strong))} is stronger
+than a normal using-directive in two ways:
+
+@itemize @bullet
+@item
+Templates from the used namespace can be specialized as though they were members of the using namespace.
+
+@item
+The using namespace is considered an associated namespace of all
+templates in the used namespace for purposes of argument-dependent
+name lookup.
+@end itemize
+
+This is useful for composing a namespace transparently from
+implementation namespaces. For example:
+
+@smallexample
+namespace std @{
+ namespace debug @{
+ template <class T> struct A @{ @};
+ @}
+ using namespace debug __attribute ((__strong__));
+ template <> struct A<int> @{ @}; // ok to specialize
+
+ template <class T> void f (A<T>);
+@}
+
+int main()
+@{
+ f (std::A<float>()); // lookup finds std::f
+ f (std::A<int>());
+@}
+@end smallexample
+
@node Java Exceptions
@section Java Exceptions
Floating and complex non-type template parameters have been deprecated,
and are now removed from g++.
-The implicit typename extension has been deprecated and will be removed
-from g++ at some point. In some cases g++ determines that a dependent
-type such as @code{TPL<T>::X} is a type without needing a
-@code{typename} keyword, contrary to the standard.
+The implicit typename extension has been deprecated and is now
+removed from g++.
+
+The use of default arguments in function pointers, function typedefs and
+and other places where they are not permitted by the standard is
+deprecated and will be removed from a future version of g++.
@node Backwards Compatibility
@section Backwards Compatibility
OSDN Git Service
