@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1996, 1998, 1999, 2000,
-@c 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
+@c 2001, 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
@code{format}, @code{format_arg}, @code{no_instrument_function},
@code{section}, @code{constructor}, @code{destructor}, @code{used},
@code{unused}, @code{deprecated}, @code{weak}, @code{malloc},
-@code{alias}, @code{warn_unused_result}, @code{nonnull}
-and @code{externally_visible}. Several other
+@code{alias}, @code{warn_unused_result}, @code{nonnull},
+@code{gnu_inline} and @code{externally_visible}. Several other
attributes are defined for functions on particular target systems. Other
attributes, including @code{section} are supported for variables declarations
(@pxref{Variable Attributes}) and for types (@pxref{Type Attributes}).
For functions declared inline, this attribute inlines the function even
if no optimization level was specified.
+@item gnu_inline
+@cindex @code{gnu_inline} function attribute
+This attribute on an inline declaration results in the old GNU C89
+inline behavior even in the ISO C99 mode.
+
@cindex @code{flatten} function attribute
@item flatten
Generally, inlining into a function is limited. For a function marked with
Permissible values for this parameter are: IRQ, FIQ, SWI, ABORT and UNDEF@.
+On ARMv7-M the interrupt type is ignored, and the attibute means the function
+may be called with a word aligned stack pointer.
+
@item interrupt_handler
@cindex interrupt handler functions on the Blackfin, m68k, H8/300 and SH processors
Use this attribute on the Blackfin, m68k, H8/300, H8/300H, H8S, and SH to
@item naked
@cindex function without a prologue/epilogue code
-Use this attribute on the ARM, AVR, C4x and IP2K ports to indicate that the
-specified function does not need prologue/epilogue sequences generated by
+Use this attribute on the ARM, AVR, C4x, IP2K and SPU ports to indicate that
+the specified function does not need prologue/epilogue sequences generated by
the compiler. It is up to the programmer to provide these sequences.
@item near
@item sseregparm
@cindex @code{sseregparm} attribute
On the Intel 386 with SSE support, the @code{sseregparm} attribute
-causes the compiler to pass up to 8 floating point arguments in
+causes the compiler to pass up to 3 floating point arguments in
SSE registers instead of on the stack. Functions that take a
variable number of arguments will continue to pass all of their
floating point arguments on the stack.
For documentation of @code{altivec} attribute please see the
documentation in the @xref{PowerPC Type Attributes}, section.
+@subsection SPU Variable Attributes
+
+The SPU supports the @code{spu_vector} attribute for variables. For
+documentation of this attribute please see the documentation in the
+@xref{SPU Type Attributes}, section.
+
@subsection Xstormy16 Variable Attributes
One attribute is currently defined for xstormy16 configurations:
These attributes mainly are intended to support the @code{__vector},
@code{__pixel}, and @code{__bool} AltiVec keywords.
+@anchor{SPU Type Attributes}
+@subsection SPU Type Attributes
+
+The SPU supports the @code{spu_vector} attribute for types. This attribute
+allows one to declare vector data types supported by the Sony/Toshiba/IBM SPU
+Language Extensions Specification. It is intended to support the
+@code{__vector} keyword.
+
+
@node Inline
@section An Inline Function is As Fast As a Macro
@cindex inline functions
into their callers with the option @option{-finline-functions}.
GCC implements three different semantics of declaring a function
-inline. One is available with @option{-std=gnu89}, another when
+inline. One is available with @option{-std=gnu89} or when @code{gnu_inline}
+attribute is present on all inline declarations, another when
@option{-std=c99} or @option{-std=gnu99}, and the third is used when
compiling C++.
actually perform. However, there are applications in which this
data is hard to collect.
-The return value is the value of @var{exp}, which should be an
-integral expression. The value of @var{c} must be a compile-time
-constant. The semantics of the built-in are that it is expected
-that @var{exp} == @var{c}. For example:
+The return value is the value of @var{exp}, which should be an integral
+expression. The semantics of the built-in are that it is expected that
+@var{exp} == @var{c}. For example:
@smallexample
if (__builtin_expect (x, 0))
are @code{long double}.
@end deftypefn
+@deftypefn {Built-in Function} int32_t __builtin_bswap32 (int32_t x)
+Returns @var{x} with the order of the bytes reversed; for example,
+@code{0xaabbccdd} becomes @code{0xddccbbaa}. Byte here always means
+exactly 8 bits.
+@end deftypefn
+
+@deftypefn {Built-in Function} int64_t __builtin_bswap64 (int64_t x)
+Similar to @code{__builtin_bswap32}, except the argument and return types
+are 64-bit.
+@end deftypefn
@node Target Builtins
@section Built-in Functions Specific to Particular Target Machines
* MIPS Paired-Single Support::
* PowerPC AltiVec Built-in Functions::
* SPARC VIS Built-in Functions::
+* SPU Built-in Functions::
@end menu
@node Alpha Built-in Functions
int64_t __builtin_vis_pdist (v8qi, v8qi, int64_t);
@end smallexample
+@node SPU Built-in Functions
+@subsection SPU Built-in Functions
+
+GCC provides extensions for the SPU processor as described in the
+Sony/Toshiba/IBM SPU Language Extensions Specification, which can be
+found at @uref{http://cell.scei.co.jp/} or
+@uref{http://www.ibm.com/developerworks/power/cell/}. GCC's
+implementation differs in several ways.
+
+@itemize @bullet
+
+@item
+The optional extension of specifying vector constants in parentheses is
+not supported.
+
+@item
+A vector initializer requires no cast if the vector constant is of the
+same type as the variable it is initializing.
+
+@item
+If @code{signed} or @code{unsigned} is omitted, the signedness of the
+vector type is the default signedness of the base type. The default
+varies depending on the operating system, so a portable program should
+always specify the signedness.
+
+@item
+By default, the keyword @code{__vector} is added. The macro
+@code{vector} is defined in @code{<spu_intrinsics.h>} and can be
+undefined.
+
+@item
+GCC allows using a @code{typedef} name as the type specifier for a
+vector type.
+
+@item
+For C, overloaded functions are implemented with macros so the following
+does not work:
+
+@smallexample
+ spu_add ((vector signed int)@{1, 2, 3, 4@}, foo);
+@end smallexample
+
+Since @code{spu_add} is a macro, the vector constant in the example
+is treated as four separate arguments. Wrap the entire argument in
+parentheses for this to work.
+
+@item
+The extended version of @code{__builtin_expect} is not supported.
+
+@end itemize
+
+@emph{Note:} Only the interface described in the aforementioned
+specification is supported. Internally, GCC uses built-in functions to
+implement the required functionality, but these are not supported and
+are subject to change without notice.
+
@node Target Format Checks
@section Format Checks Specific to Particular Target Machines
Both the C and C++ standard have the concept of volatile objects. These
are normally accessed by pointers and used for accessing hardware. The
-standards encourage compilers to refrain from optimizations
-concerning accesses to volatile objects that it might perform on
-non-volatile objects. The C standard leaves it implementation defined
-as to what constitutes a volatile access. The C++ standard omits to
-specify this, except to say that C++ should behave in a similar manner
+standards encourage compilers to refrain from optimizations concerning
+accesses to volatile objects. The C standard leaves it implementation
+defined as to what constitutes a volatile access. The C++ standard omits
+to specify this, except to say that C++ should behave in a similar manner
to C with respect to volatiles, where possible. The minimum either
standard specifies is that at a sequence point all previous accesses to
volatile objects have stabilized and no subsequent accesses have
allow you to violate the restriction on updating objects multiple times
within a sequence point.
-In most expressions, it is intuitively obvious what is a read and what is
-a write. For instance
-
-@smallexample
-volatile int *dst = @var{somevalue};
-volatile int *src = @var{someothervalue};
-*dst = *src;
-@end smallexample
-
-@noindent
-will cause a read of the volatile object pointed to by @var{src} and stores the
-value into the volatile object pointed to by @var{dst}. There is no
-guarantee that these reads and writes are atomic, especially for objects
-larger than @code{int}.
+@xref{Qualifiers implementation, , Volatile qualifier and the C compiler}.
-Less obvious expressions are where something which looks like an access
-is used in a void context. An example would be,
+The behavior differs slightly between C and C++ in the non-obvious cases:
@smallexample
volatile int *src = @var{somevalue};
*src;
@end smallexample
-With C, such expressions are rvalues, and as rvalues cause a read of
-the object, GCC interprets this as a read of the volatile being pointed
-to. The C++ standard specifies that such expressions do not undergo
-lvalue to rvalue conversion, and that the type of the dereferenced
+With C, such expressions are rvalues, and GCC interprets this either as a
+read of the volatile object being pointed to or only as request to evaluate
+the side-effects. The C++ standard specifies that such expressions do not
+undergo lvalue to rvalue conversion, and that the type of the dereferenced
object may be incomplete. The C++ standard does not specify explicitly
-that it is this lvalue to rvalue conversion which is responsible for
+that it is this lvalue to rvalue conversion which may be responsible for
causing an access. However, there is reason to believe that it is,
because otherwise certain simple expressions become undefined. However,
because it would surprise most programmers, G++ treats dereferencing a
-pointer to volatile object of complete type in a void context as a read
-of the object. When the object has incomplete type, G++ issues a
-warning.
-
-@smallexample
-struct S;
-struct T @{int m;@};
-volatile S *ptr1 = @var{somevalue};
-volatile T *ptr2 = @var{somevalue};
-*ptr1;
-*ptr2;
-@end smallexample
-
-In this example, a warning is issued for @code{*ptr1}, and @code{*ptr2}
-causes a read of the object pointed to. If you wish to force an error on
-the first case, you must force a conversion to rvalue with, for instance
-a static cast, @code{static_cast<S>(*ptr1)}.
+pointer to volatile object of complete type when the value is unused as
+GCC would do for an equivalent type in C. When the object has incomplete
+type, G++ issues a warning; if you wish to force an error, you must
+force a conversion to rvalue with, for instance, a static cast.
When using a reference to volatile, G++ does not treat equivalent
expressions as accesses to volatiles, but instead issues a warning that
OSDN Git Service
