c-tree.texi, [...]: Fix spelling and typos.
* doc/c-tree.texi, doc/contrib.texi, doc/extend.texi, doc/gcc.texi, doc/install.texi, doc/invoke.texi, doc/md.texi, doc/objc.texi, doc/rtl.texi, doc/tm.texi: Fix spelling and typos. Consistently use "built-in" and "bit-field". Minor logical markup improvements. * doc/gcc.1: Regenerate. From-SVN: r43383
This commit is contained in:
Joseph Myers
Joseph Myers
parent
68f4edf079
commit
c771326b4f
|
|
@ -1,3 +1,12 @@
|
|||
2001-06-14 Joseph S. Myers <jsm28@cam.ac.uk>
|
||||
|
||||
* doc/c-tree.texi, doc/contrib.texi, doc/extend.texi,
|
||||
doc/gcc.texi, doc/install.texi, doc/invoke.texi, doc/md.texi,
|
||||
doc/objc.texi, doc/rtl.texi, doc/tm.texi: Fix spelling and typos.
|
||||
Consistently use "built-in" and "bit-field". Minor logical markup
|
||||
improvements.
|
||||
* doc/gcc.1: Regenerate.
|
||||
|
||||
2001-06-14 Richard Henderson <rth@redhat.com>
|
||||
|
||||
* config/mips/mips.md (exception_receiver): New.
|
||||
|
|
|
|||
|
|
@ -372,7 +372,7 @@ the type. (Note this macro does @emph{not} return a
|
|||
@code{IDENTIFIER_NODE}, as you might expect, given its name!) You can
|
||||
look at the @code{DECL_NAME} of the @code{TYPE_DECL} to obtain the
|
||||
actual name of the type. The @code{TYPE_NAME} will be @code{NULL_TREE}
|
||||
for a type that is not a builtin type, the result of a typedef, or a
|
||||
for a type that is not a built-in type, the result of a typedef, or a
|
||||
named class type.
|
||||
|
||||
@item CP_INTEGRAL_TYPE
|
||||
|
|
@ -387,7 +387,7 @@ or a floating point type.
|
|||
This predicate holds for a class-type.
|
||||
|
||||
@item TYPE_BUILT_IN
|
||||
This predicate holds for a builtin type.
|
||||
This predicate holds for a built-in type.
|
||||
|
||||
@item TYPE_PTRMEM_P
|
||||
This predicate holds if the type is a pointer to data member.
|
||||
|
|
@ -450,7 +450,7 @@ double} types. The number of bits in the floating-point representation
|
|||
is given by @code{TYPE_PRECISION}, as in the @code{INTEGER_TYPE} case.
|
||||
|
||||
@item COMPLEX_TYPE
|
||||
Used to represent GCC builtin @code{__complex__} data types. The
|
||||
Used to represent GCC built-in @code{__complex__} data types. The
|
||||
@code{TREE_TYPE} is the type of the real and imaginary parts.
|
||||
|
||||
@item ENUMERAL_TYPE
|
||||
|
|
@ -967,7 +967,7 @@ These nodes represent non-static data members. The @code{DECL_SIZE} and
|
|||
@code{INTEGER_CST}. These values are indexed from zero, where zero
|
||||
indicates the first bit in the object.
|
||||
|
||||
If @code{DECL_C_BIT_FIELD} holds, this field is a bitfield.
|
||||
If @code{DECL_C_BIT_FIELD} holds, this field is a bit-field.
|
||||
|
||||
@item NAMESPACE_DECL
|
||||
@xref{Namespaces}.
|
||||
|
|
@ -976,7 +976,7 @@ If @code{DECL_C_BIT_FIELD} holds, this field is a bitfield.
|
|||
|
||||
These nodes are used to represent class, function, and variable (static
|
||||
data member) templates. The @code{DECL_TEMPLATE_SPECIALIZATIONS} are a
|
||||
@code{TREE_LIST}. The @code{TREE_VALUE} of each node in the lst is a
|
||||
@code{TREE_LIST}. The @code{TREE_VALUE} of each node in the list is a
|
||||
@code{TEMPLATE_DECL}s or @code{FUNCTION_DECL}s representing
|
||||
specializations (including instantiations) of this template. Back-ends
|
||||
can safely ignore @code{TEMPLATE_DECL}s, but should examine
|
||||
|
|
@ -1547,7 +1547,7 @@ Used to represent an @code{if} statement. The @code{IF_COND} is the
|
|||
expression.
|
||||
|
||||
If the condition is a @code{TREE_LIST}, then the @code{TREE_PURPOSE} is
|
||||
a statement (usually a @code{DECL_STMT}). Each time the coondition is
|
||||
a statement (usually a @code{DECL_STMT}). Each time the condition is
|
||||
evaluated, the statement should be executed. Then, the
|
||||
@code{TREE_VALUE} should be used as the conditional expression itself.
|
||||
This representation is used to handle C++ code like this:
|
||||
|
|
@ -2047,7 +2047,7 @@ will be a @code{VAR_DECL}, @code{INDIRECT_REF}, @code{COMPONENT_REF}, or
|
|||
other lvalue.
|
||||
|
||||
These nodes are used to represent not only assignment with @samp{=} but
|
||||
also compount assignments (like @samp{+=}), by reduction to @samp{=}
|
||||
also compound assignments (like @samp{+=}), by reduction to @samp{=}
|
||||
assignment. In other words, the representation for @samp{i += 3} looks
|
||||
just like that for @samp{i = i + 3}.
|
||||
|
||||
|
|
|
|||
|
|
@ -346,7 +346,7 @@ Alan Modra for various Linux bits and testing.
|
|||
|
||||
@item
|
||||
Toon Moene for his direction via the steering committee, Fortran
|
||||
maintainance, and his ongoing work to make us make Fortran run fast.
|
||||
maintenance, and his ongoing work to make us make Fortran run fast.
|
||||
|
||||
@item
|
||||
Jason Molenda for major help in the care and feeding of all the services
|
||||
|
|
@ -374,7 +374,7 @@ Philippe De Muyter for his work on the m68k port.
|
|||
|
||||
@item
|
||||
Joseph S. Myers for his work on the PDP-11 port, format checking and ISO
|
||||
C99 support, and continous emphasis on (and contributions to) documentation.
|
||||
C99 support, and continuous emphasis on (and contributions to) documentation.
|
||||
|
||||
@item
|
||||
Nathan Myers for his work on libstdc++-v3.
|
||||
|
|
@ -413,7 +413,7 @@ Matthias Pfaller for major improvements to the NS32k port.
|
|||
@item
|
||||
Gerald Pfeifer for his direction via the steering committee, pointing
|
||||
out lots of problems we need to solve, maintenance of the web pages, and
|
||||
taking care of documentation maintainance in general.
|
||||
taking care of documentation maintenance in general.
|
||||
|
||||
@item
|
||||
Ovidiu Predescu for his work on the ObjC front end and runtime libraries.
|
||||
|
|
|
|||
|
|
@ -185,7 +185,7 @@ the macro safely as follows:
|
|||
@end example
|
||||
|
||||
Embedded statements are not allowed in constant expressions, such as
|
||||
the value of an enumeration constant, the width of a bit field, or
|
||||
the value of an enumeration constant, the width of a bit-field, or
|
||||
the initial value of a static variable.
|
||||
|
||||
If you don't know the type of the operand, you can still do this, but you
|
||||
|
|
@ -2167,7 +2167,7 @@ the function instead by syntax described below (which, however, is not
|
|||
yet implemented in this case). In some other cases, attribute
|
||||
specifiers are permitted by this grammar but not yet supported by the
|
||||
compiler. All attribute specifiers in this place relate to the
|
||||
declaration as a whole. In the obsolencent usage where a type of
|
||||
declaration as a whole. In the obsolescent usage where a type of
|
||||
@code{int} is implied by the absence of type specifiers, such a list of
|
||||
specifiers and qualifiers may be an attribute specifier list with no
|
||||
other specifiers or qualifiers.
|
||||
|
|
@ -2214,7 +2214,7 @@ ignored.
|
|||
|
||||
An attribute specifier list may appear at the start of a nested
|
||||
declarator. At present, there are some limitations in this usage: the
|
||||
attributes apply to the identifer declared, and to all subsequent
|
||||
attributes apply to the identifier declared, and to all subsequent
|
||||
identifiers declared in that declaration (if it includes a
|
||||
comma-separated list of declarators), rather than to a specific
|
||||
declarator. When attribute specifiers follow the @code{*} of a pointer
|
||||
|
|
@ -2976,7 +2976,7 @@ 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
|
||||
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.
|
||||
|
||||
|
|
@ -3247,7 +3247,7 @@ asm ("foo" : "=t" (a) : "f" (b));
|
|||
@end example
|
||||
|
||||
This asm says that input B is not popped by the asm, and that
|
||||
the asm pushes a result onto the reg-stack, ie, the stack is one
|
||||
the asm pushes a result onto the reg-stack, i.e., the stack is one
|
||||
deeper after the asm than it was before. But, it is possible that
|
||||
reload will think that it can use the same reg for both the input and
|
||||
the output, if input B dies in this insn.
|
||||
|
|
@ -3723,7 +3723,7 @@ function as well.
|
|||
|
||||
@node Other Builtins
|
||||
@section Other built-in functions provided by GNU CC
|
||||
@cindex builtin functions
|
||||
@cindex built-in functions
|
||||
@findex __builtin_isgreater
|
||||
@findex __builtin_isgreaterequal
|
||||
@findex __builtin_isless
|
||||
|
|
@ -4011,8 +4011,8 @@ In most expressions, it is intuitively obvious what is a read and what is
|
|||
a write. For instance
|
||||
|
||||
@example
|
||||
volatile int *dst = <somevalue>;
|
||||
volatile int *src = <someothervalue>;
|
||||
volatile int *dst = @var{somevalue};
|
||||
volatile int *src = @var{someothervalue};
|
||||
*dst = *src;
|
||||
@end example
|
||||
|
||||
|
|
@ -4026,7 +4026,7 @@ Less obvious expressions are where something which looks like an access
|
|||
is used in a void context. An example would be,
|
||||
|
||||
@example
|
||||
volatile int *src = <somevalue>;
|
||||
volatile int *src = @var{somevalue};
|
||||
*src;
|
||||
@end example
|
||||
|
||||
|
|
@ -4046,8 +4046,8 @@ warning.
|
|||
@example
|
||||
struct S;
|
||||
struct T @{int m;@};
|
||||
volatile S *ptr1 = <somevalue>;
|
||||
volatile T *ptr2 = <somevalue>;
|
||||
volatile S *ptr1 = @var{somevalue};
|
||||
volatile T *ptr2 = @var{somevalue};
|
||||
*ptr1;
|
||||
*ptr2;
|
||||
@end example
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
.\" Automatically generated by Pod::Man version 1.16
|
||||
.\" Thu Jun 14 10:58:24 2001
|
||||
.\" Thu Jun 14 22:41:32 2001
|
||||
.\"
|
||||
.\" Standard preamble:
|
||||
.\" ======================================================================
|
||||
|
|
@ -854,8 +854,8 @@ from declaring certain functions or defining certain macros that the
|
|||
\&\s-1ISO\s0 standard doesn't call for; this is to avoid interfering with any
|
||||
programs that might use these names for other things.
|
||||
.Sp
|
||||
Functions which would normally be builtin but do not have semantics
|
||||
defined by \s-1ISO\s0 C (such as \f(CW\*(C`alloca\*(C'\fR and \f(CW\*(C`ffs\*(C'\fR) are not builtin
|
||||
Functions which would normally be built in but do not have semantics
|
||||
defined by \s-1ISO\s0 C (such as \f(CW\*(C`alloca\*(C'\fR and \f(CW\*(C`ffs\*(C'\fR) are not built-in
|
||||
functions with \fB\-ansi\fR is used.
|
||||
.Ip "\fB\-std=\fR" 4
|
||||
.IX Item "-std="
|
||||
|
|
@ -936,10 +936,10 @@ switch only affects the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywo
|
|||
\&\f(CW\*(C`inline\*(C'\fR is a standard keyword in \s-1ISO\s0 C99.
|
||||
.Ip "\fB\-fno-builtin\fR" 4
|
||||
.IX Item "-fno-builtin"
|
||||
Don't recognize builtin functions that do not begin with
|
||||
Don't recognize built-in functions that do not begin with
|
||||
\&\fB_\|_builtin_\fR as prefix.
|
||||
.Sp
|
||||
\&\s-1GCC\s0 normally generates special code to handle certain builtin functions
|
||||
\&\s-1GCC\s0 normally generates special code to handle certain built-in functions
|
||||
more efficiently; for instance, calls to \f(CW\*(C`alloca\*(C'\fR may become single
|
||||
instructions that adjust the stack directly, and calls to \f(CW\*(C`memcpy\*(C'\fR
|
||||
may become inline copy loops. The resulting code is often both smaller
|
||||
|
|
@ -949,9 +949,9 @@ of the functions by linking with a different library.
|
|||
.Sp
|
||||
In \*(C+, \fB\-fno-builtin\fR is always in effect. The \fB\-fbuiltin\fR
|
||||
option has no effect. Therefore, in \*(C+, the only way to get the
|
||||
optimization benefits of builtin functions is to call the function
|
||||
optimization benefits of built-in functions is to call the function
|
||||
using the \fB_\|_builtin_\fR prefix. The \s-1GNU\s0 \*(C+ Standard Library uses
|
||||
builtin functions to implement many functions (like
|
||||
built-in functions to implement many functions (like
|
||||
\&\f(CW\*(C`std::strchr\*(C'\fR), so that you automatically get efficient code.
|
||||
.Ip "\fB\-fhosted\fR" 4
|
||||
.IX Item "-fhosted"
|
||||
|
|
@ -1013,7 +1013,7 @@ representation of a character, and \fB\ea\fR produces a bell.
|
|||
.RS 4
|
||||
.Sp
|
||||
You may wish to use \fB\-fno-builtin\fR as well as \fB\-traditional\fR
|
||||
if your program uses names that are normally \s-1GNU\s0 C builtin functions for
|
||||
if your program uses names that are normally \s-1GNU\s0 C built-in functions for
|
||||
other purposes of its own.
|
||||
.Sp
|
||||
You cannot use \fB\-traditional\fR if you include any header files that
|
||||
|
|
@ -1097,12 +1097,12 @@ the negative form of \fB\-funsigned-char\fR. Likewise, the option
|
|||
.Ip "\fB\-fno-unsigned-bitfields\fR" 4
|
||||
.IX Item "-fno-unsigned-bitfields"
|
||||
.PD
|
||||
These options control whether a bitfield is signed or unsigned, when the
|
||||
These options control whether a bit-field is signed or unsigned, when the
|
||||
declaration does not use either \f(CW\*(C`signed\*(C'\fR or \f(CW\*(C`unsigned\*(C'\fR. By
|
||||
default, such a bitfield is signed, because this is consistent: the
|
||||
default, such a bit-field is signed, because this is consistent: the
|
||||
basic integer types such as \f(CW\*(C`int\*(C'\fR are signed types.
|
||||
.Sp
|
||||
However, when \fB\-traditional\fR is used, bitfields are all unsigned
|
||||
However, when \fB\-traditional\fR is used, bit-fields are all unsigned
|
||||
no matter what.
|
||||
.Ip "\fB\-fwritable-strings\fR" 4
|
||||
.IX Item "-fwritable-strings"
|
||||
|
|
@ -1268,7 +1268,7 @@ Disable pedantic warnings about constructs used in \s-1MFC\s0, such as implicit
|
|||
int and getting a pointer to member function via non-standard syntax.
|
||||
.Ip "\fB\-fno-nonansi-builtins\fR" 4
|
||||
.IX Item "-fno-nonansi-builtins"
|
||||
Disable builtin declarations of functions that are not mandated by
|
||||
Disable built-in declarations of functions that are not mandated by
|
||||
\&\s-1ANSI/ISO\s0 C. These include \f(CW\*(C`ffs\*(C'\fR, \f(CW\*(C`alloca\*(C'\fR, \f(CW\*(C`_exit\*(C'\fR,
|
||||
\&\f(CW\*(C`index\*(C'\fR, \f(CW\*(C`bzero\*(C'\fR, \f(CW\*(C`conjf\*(C'\fR, and other related functions.
|
||||
.Ip "\fB\-fno-operator-names\fR" 4
|
||||
|
|
@ -1386,7 +1386,7 @@ Do not warn about usage of deprecated features.
|
|||
.IX Item "-Wno-non-template-friend ( only)"
|
||||
Disable warnings when non-templatized friend functions are declared
|
||||
within a template. With the advent of explicit template specification
|
||||
support in g++, if the name of the friend is an unqualified-id (ie,
|
||||
support in g++, if the name of the friend is an unqualified-id (i.e.,
|
||||
\&\fBfriend foo(int)\fR), the \*(C+ language specification demands that the
|
||||
friend declare or define an ordinary, nontemplate function. (Section
|
||||
14.5.3). Before g++ implemented explicit specification, unqualified-ids
|
||||
|
|
@ -2031,10 +2031,10 @@ A function-like macro that appears without arguments.
|
|||
.Ip "\(bu" 4
|
||||
The unary plus operator.
|
||||
.Ip "\(bu" 4
|
||||
The `U' integer constant suffix, or the `F' or `L' floating point
|
||||
constant suffixes. (Traditonal C does support the `L' suffix on integer
|
||||
The \fBU\fR integer constant suffix, or the \fBF\fR or \fBL\fR floating point
|
||||
constant suffixes. (Traditional C does support the \fBL\fR suffix on integer
|
||||
constants.) Note, these suffixes appear in macros defined in the system
|
||||
headers of most modern systems, e.g. the _MIN/_MAX macros in limits.h.
|
||||
headers of most modern systems, e.g. the \fB_MIN\fR/\fB_MAX\fR macros in \f(CW\*(C`<limits.h>\*(C'\fR.
|
||||
Use of these macros in user code might normally lead to spurious
|
||||
warnings, however gcc's integrated preprocessor has enough context to
|
||||
avoid warning in these cases.
|
||||
|
|
@ -2402,7 +2402,7 @@ You can examine different profiling aspects without recompilation. Your
|
|||
executable will read a list of function names from file \fIbb.in\fR.
|
||||
Profiling starts when a function on the list is entered and stops when
|
||||
that invocation is exited. To exclude a function from profiling, prefix
|
||||
its name with `\-'. If a function name is not unique, you can
|
||||
its name with \fB-\fR. If a function name is not unique, you can
|
||||
disambiguate it by writing it in the form
|
||||
\&\fB/path/filename.d:functionname\fR. Your executable will write the
|
||||
available paths and filenames in file \fIbb.out\fR.
|
||||
|
|
@ -3342,7 +3342,7 @@ Treat floating point constant as single precision constant instead of
|
|||
implicitly converting it to double precision constant.
|
||||
.Ip "\fB\-frename-registers\fR" 4
|
||||
.IX Item "-frename-registers"
|
||||
Attempt to avoid false dependancies in scheduled code by making use
|
||||
Attempt to avoid false dependencies in scheduled code by making use
|
||||
of registers left over after register allocation. This optimization
|
||||
will most benefit processors with lots of registers. It can, however,
|
||||
make debugging impossible, since variables will no longer stay in
|
||||
|
|
@ -5507,11 +5507,11 @@ hardware floating is used.
|
|||
.IX Item "-mbit-align"
|
||||
.PD
|
||||
On System V.4 and embedded PowerPC systems do not (do) force structures
|
||||
and unions that contain bit fields to be aligned to the base type of the
|
||||
bit field.
|
||||
and unions that contain bit-fields to be aligned to the base type of the
|
||||
bit-field.
|
||||
.Sp
|
||||
For example, by default a structure containing nothing but 8
|
||||
\&\f(CW\*(C`unsigned\*(C'\fR bitfields of length 1 would be aligned to a 4 byte
|
||||
\&\f(CW\*(C`unsigned\*(C'\fR bit-fields of length 1 would be aligned to a 4 byte
|
||||
boundary and have a size of 4 bytes. By using \fB\-mno-bit-align\fR,
|
||||
the structure would be aligned to a 1 byte boundary and be one byte in
|
||||
size.
|
||||
|
|
@ -5741,7 +5741,7 @@ be allocated dynamically.
|
|||
.IX Item "-mfp-arg-in-fpregs"
|
||||
Use a calling sequence incompatible with the \s-1IBM\s0 calling convention in
|
||||
which floating point arguments are passed in floating point registers.
|
||||
Note that \f(CW\*(C`varargs.h\*(C'\fR and \f(CW\*(C`stdargs.h\*(C'\fR will not work with
|
||||
Note that \f(CW\*(C`varargs.h\*(C'\fR and \f(CW\*(C`stdarg.h\*(C'\fR will not work with
|
||||
floating point operands if this option is specified.
|
||||
.Ip "\fB\-mfp-arg-in-gregs\fR" 4
|
||||
.IX Item "-mfp-arg-in-gregs"
|
||||
|
|
@ -6157,7 +6157,7 @@ expense of more memory.
|
|||
.PD
|
||||
Control the size of \f(CW\*(C`long double\*(C'\fR type. i386 application binary interface
|
||||
specify the size to be 12 bytes, while modern architectures (Pentium and newer)
|
||||
preffer \f(CW\*(C`long double\*(C'\fR aligned to 8 or 16 byte boundary. This is
|
||||
prefer \f(CW\*(C`long double\*(C'\fR aligned to 8 or 16 byte boundary. This is
|
||||
impossible to reach with 12 byte long doubles in the array accesses.
|
||||
.Sp
|
||||
\&\fBWarning:\fR if you use the \fB\-m128bit-long-double\fR switch, the
|
||||
|
|
@ -6827,7 +6827,7 @@ Generate code for the \s-1SH4\s0 without a floating-point unit.
|
|||
.Ip "\fB\-m4\-single-only\fR" 4
|
||||
.IX Item "-m4-single-only"
|
||||
Generate code for the \s-1SH4\s0 with a floating-point unit that only
|
||||
supports single-precision arithmentic.
|
||||
supports single-precision arithmetic.
|
||||
.Ip "\fB\-m4\-single\fR" 4
|
||||
.IX Item "-m4-single"
|
||||
Generate code for the \s-1SH4\s0 assuming the floating-point unit is in
|
||||
|
|
@ -7372,7 +7372,7 @@ Allow arbitrary sized immediates in bit operations.
|
|||
.Ip "\fB\-mno-wide-bitfields\fR" 4
|
||||
.IX Item "-mno-wide-bitfields"
|
||||
.PD
|
||||
Always treat bitfields as int-sized.
|
||||
Always treat bit-fields as int-sized.
|
||||
.Ip "\fB\-m4byte-functions\fR" 4
|
||||
.IX Item "-m4byte-functions"
|
||||
.PD 0
|
||||
|
|
|
|||
|
|
@ -34,8 +34,6 @@
|
|||
@c -item/itemx, text after all (sub/sub)section titles, etc..
|
||||
@c -consider putting the lists of options on pp 17--> etc in columns or
|
||||
@c some such.
|
||||
@c -spellcheck
|
||||
@c -continuity of phrasing; ie, bit-field vs bitfield in rtl.texi
|
||||
@c -overfulls. do a search for "mew" in the files, and you will see
|
||||
@c overfulls that i noted but could not deal with.
|
||||
@c -have to add text: beginning of chapter 8
|
||||
|
|
@ -43,6 +41,14 @@
|
|||
@c
|
||||
@c anything else? --mew 10feb93
|
||||
|
||||
@c For consistency, use the following:
|
||||
@c - "bit-field" not "bitfield" or "bit field" (following the C and C++
|
||||
@c standards).
|
||||
@c - "built-in" as an adjective ("built-in function"), or sometimes
|
||||
@c "built in", not "builtin" (which isn't a word).
|
||||
@c - "front end" as a noun, "front-end" as an adjective (not yet
|
||||
@c consistently followed).
|
||||
|
||||
@macro gcctabopt{body}
|
||||
@code{\body\}
|
||||
@end macro
|
||||
|
|
@ -1422,13 +1428,13 @@ being incompatible with ISO C just to avoid an error for the example
|
|||
shown above.
|
||||
|
||||
@item
|
||||
Accesses to bitfields even in volatile objects works by accessing larger
|
||||
Accesses to bit-fields even in volatile objects works by accessing larger
|
||||
objects, such as a byte or a word. You cannot rely on what size of
|
||||
object is accessed in order to read or write the bitfield; it may even
|
||||
vary for a given bitfield according to the precise usage.
|
||||
object is accessed in order to read or write the bit-field; it may even
|
||||
vary for a given bit-field according to the precise usage.
|
||||
|
||||
If you care about controlling the amount of memory that is accessed, use
|
||||
volatile but do not use bitfields.
|
||||
volatile but do not use bit-fields.
|
||||
|
||||
@item
|
||||
GCC comes with shell scripts to fix certain known problems in system
|
||||
|
|
@ -1777,10 +1783,10 @@ the enumeration-valued object is inside a structure, and in that case
|
|||
you can specify a field width explicitly.
|
||||
|
||||
@item
|
||||
Making bitfields unsigned by default on particular machines where ``the
|
||||
Making bit-fields unsigned by default on particular machines where ``the
|
||||
ABI standard'' says to do so.
|
||||
|
||||
The ISO C standard leaves it up to the implementation whether a bitfield
|
||||
The ISO C standard leaves it up to the implementation whether a bit-field
|
||||
declared plain @code{int} is signed or not. This in effect creates two
|
||||
alternative dialects of C.
|
||||
|
||||
|
|
@ -1791,19 +1797,19 @@ dialect with @option{-fsigned-bitfields} and the unsigned dialect with
|
|||
@option{-funsigned-bitfields}. However, this leaves open the question of
|
||||
which dialect to use by default.
|
||||
|
||||
Currently, the preferred dialect makes plain bitfields signed, because
|
||||
Currently, the preferred dialect makes plain bit-fields signed, because
|
||||
this is simplest. Since @code{int} is the same as @code{signed int} in
|
||||
every other context, it is cleanest for them to be the same in bitfields
|
||||
every other context, it is cleanest for them to be the same in bit-fields
|
||||
as well.
|
||||
|
||||
Some computer manufacturers have published Application Binary Interface
|
||||
standards which specify that plain bitfields should be unsigned. It is
|
||||
standards which specify that plain bit-fields should be unsigned. It is
|
||||
a mistake, however, to say anything about this issue in an ABI. This is
|
||||
because the handling of plain bitfields distinguishes two dialects of C.
|
||||
because the handling of plain bit-fields distinguishes two dialects of C.
|
||||
Both dialects are meaningful on every type of machine. Whether a
|
||||
particular object file was compiled using signed bitfields or unsigned
|
||||
particular object file was compiled using signed bit-fields or unsigned
|
||||
is of no concern to other object files, even if they access the same
|
||||
bitfields in the same data structures.
|
||||
bit-fields in the same data structures.
|
||||
|
||||
A given program is written in one or the other of these two dialects.
|
||||
The program stands a chance to work on most any machine if it is
|
||||
|
|
@ -1812,7 +1818,7 @@ compiled with the wrong dialect.
|
|||
|
||||
Many users appreciate the GNU C compiler because it provides an
|
||||
environment that is uniform across machines. These users would be
|
||||
inconvenienced if the compiler treated plain bitfields differently on
|
||||
inconvenienced if the compiler treated plain bit-fields differently on
|
||||
certain machines.
|
||||
|
||||
Occasionally users write programs intended only for a particular machine
|
||||
|
|
@ -1822,16 +1828,16 @@ that machine. But such applications are rare. And users writing a
|
|||
program to run on more than one type of machine cannot possibly benefit
|
||||
from this kind of compatibility.
|
||||
|
||||
This is why GCC does and will treat plain bitfields in the same
|
||||
This is why GCC does and will treat plain bit-fields in the same
|
||||
fashion on all types of machines (by default).
|
||||
|
||||
There are some arguments for making bitfields unsigned by default on all
|
||||
There are some arguments for making bit-fields unsigned by default on all
|
||||
machines. If, for example, this becomes a universal de facto standard,
|
||||
it would make sense for GCC to go along with it. This is something
|
||||
to be considered in the future.
|
||||
|
||||
(Of course, users strongly concerned about portability should indicate
|
||||
explicitly in each bitfield whether it is signed or not. In this way,
|
||||
explicitly in each bit-field whether it is signed or not. In this way,
|
||||
they write programs which have the same meaning in both C dialects.)
|
||||
|
||||
@item
|
||||
|
|
@ -2942,7 +2948,7 @@ they're no longer needed. This saves disk space.
|
|||
@item bubblestrap
|
||||
Once bootstrapped, this incrementally rebuilds each of the three stages,
|
||||
one at a time. It does this by ``bubbling'' the stages up from their
|
||||
stubdirectories, rebuilding them, and copying them back to their
|
||||
subdirectories, rebuilding them, and copying them back to their
|
||||
subdirectories. This will allow you to, for example, quickly rebuild a
|
||||
bootstrapped compiler after changing the sources, without having to do a
|
||||
full bootstrap.
|
||||
|
|
@ -3825,7 +3831,7 @@ machine.
|
|||
@findex ONLY_INT_FIELDS
|
||||
@item ONLY_INT_FIELDS
|
||||
Define this macro to indicate that the host compiler only supports
|
||||
@code{int} bit fields, rather than other integral types, including
|
||||
@code{int} bit-fields, rather than other integral types, including
|
||||
@code{enum}, as do most C compilers.
|
||||
|
||||
@findex OBSTACK_CHUNK_SIZE
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@
|
|||
@settitle Installing GCC: Binaries
|
||||
@end ifset
|
||||
|
||||
@comment $Id: install.texi,v 1.22 2001/06/13 07:11:59 aoliva Exp $
|
||||
@comment $Id: install.texi,v 1.23 2001/06/13 13:07:28 jsm28 Exp $
|
||||
@c Copyright (C) 2001 Free Software Foundation, Inc.
|
||||
@c *** Converted to texinfo by Dean Wakerley, dean@wakerley.com
|
||||
|
||||
|
|
@ -475,7 +475,7 @@ Generic MACH thread support, known to work on NEXTSTEP.
|
|||
@item os2
|
||||
IBM OS/2 thread support.
|
||||
@item posix
|
||||
Generix POSIX thread support.
|
||||
Generic POSIX thread support.
|
||||
@item pthreads
|
||||
Same as @samp{posix}.
|
||||
@item single
|
||||
|
|
@ -605,7 +605,7 @@ English. Native Language Support is enabled by default if not doing a
|
|||
canadian cross build. The @option{--disable-nls} option disables NLS.
|
||||
|
||||
@item --with-included-gettext
|
||||
If NLS is enbled, the @option{--with-included-gettext} option causes the build
|
||||
If NLS is enabled, the @option{--with-included-gettext} option causes the build
|
||||
procedure to prefer its copy of GNU @code{gettext}.
|
||||
|
||||
@item --with-catgets
|
||||
|
|
@ -2173,7 +2173,7 @@ use NLS to support locale-specific representations of various data
|
|||
formats including floating-point numbers (e.g., @samp{.} vs @samp{,} for
|
||||
separating decimal fractions). There have been problems reported where
|
||||
GCC does not produce the same floating-point formats that the assembler
|
||||
expects. If one encouters this problem, set the @env{LANG}
|
||||
expects. If one encounters this problem, set the @env{LANG}
|
||||
environment variable to @samp{C} or @samp{En_US}.
|
||||
|
||||
By default, GCC for AIX 4.1 and above produces code that can be used on
|
||||
|
|
|
|||
|
|
@ -901,8 +901,8 @@ from declaring certain functions or defining certain macros that the
|
|||
ISO standard doesn't call for; this is to avoid interfering with any
|
||||
programs that might use these names for other things.
|
||||
|
||||
Functions which would normally be builtin but do not have semantics
|
||||
defined by ISO C (such as @code{alloca} and @code{ffs}) are not builtin
|
||||
Functions which would normally be built in but do not have semantics
|
||||
defined by ISO C (such as @code{alloca} and @code{ffs}) are not built-in
|
||||
functions with @option{-ansi} is used. @xref{Other Builtins,,Other
|
||||
built-in functions provided by GNU CC}, for details of the functions
|
||||
affected.
|
||||
|
|
@ -991,15 +991,15 @@ switch only affects the @code{asm} and @code{typeof} keywords, since
|
|||
|
||||
@item -fno-builtin
|
||||
@opindex fno-builtin
|
||||
@cindex builtin functions
|
||||
Don't recognize builtin functions that do not begin with
|
||||
@cindex built-in functions
|
||||
Don't recognize built-in functions that do not begin with
|
||||
@samp{__builtin_} as prefix. @xref{Other Builtins,,Other built-in
|
||||
functions provided by GNU CC}, for details of the functions affected,
|
||||
including those which are not builtin functions when @option{-ansi} or
|
||||
including those which are not built-in functions when @option{-ansi} or
|
||||
@option{-std} options for strict ISO C conformance are used because they
|
||||
do not have an ISO standard meaning.
|
||||
|
||||
GCC normally generates special code to handle certain builtin functions
|
||||
GCC normally generates special code to handle certain built-in functions
|
||||
more efficiently; for instance, calls to @code{alloca} may become single
|
||||
instructions that adjust the stack directly, and calls to @code{memcpy}
|
||||
may become inline copy loops. The resulting code is often both smaller
|
||||
|
|
@ -1009,9 +1009,9 @@ of the functions by linking with a different library.
|
|||
|
||||
In C++, @option{-fno-builtin} is always in effect. The @option{-fbuiltin}
|
||||
option has no effect. Therefore, in C++, the only way to get the
|
||||
optimization benefits of builtin functions is to call the function
|
||||
optimization benefits of built-in functions is to call the function
|
||||
using the @samp{__builtin_} prefix. The GNU C++ Standard Library uses
|
||||
builtin functions to implement many functions (like
|
||||
built-in functions to implement many functions (like
|
||||
@code{std::strchr}), so that you automatically get efficient code.
|
||||
|
||||
@item -fhosted
|
||||
|
|
@ -1098,7 +1098,7 @@ representation of a character, and @samp{\a} produces a bell.
|
|||
@end itemize
|
||||
|
||||
You may wish to use @option{-fno-builtin} as well as @option{-traditional}
|
||||
if your program uses names that are normally GNU C builtin functions for
|
||||
if your program uses names that are normally GNU C built-in functions for
|
||||
other purposes of its own.
|
||||
|
||||
You cannot use @option{-traditional} if you include any header files that
|
||||
|
|
@ -1192,12 +1192,12 @@ the negative form of @option{-funsigned-char}. Likewise, the option
|
|||
@opindex funsigned-bitfields
|
||||
@opindex fno-signed-bitfields
|
||||
@opindex fno-unsigned-bitfields
|
||||
These options control whether a bitfield is signed or unsigned, when the
|
||||
These options control whether a bit-field is signed or unsigned, when the
|
||||
declaration does not use either @code{signed} or @code{unsigned}. By
|
||||
default, such a bitfield is signed, because this is consistent: the
|
||||
default, such a bit-field is signed, because this is consistent: the
|
||||
basic integer types such as @code{int} are signed types.
|
||||
|
||||
However, when @option{-traditional} is used, bitfields are all unsigned
|
||||
However, when @option{-traditional} is used, bit-fields are all unsigned
|
||||
no matter what.
|
||||
|
||||
@item -fwritable-strings
|
||||
|
|
@ -1393,7 +1393,7 @@ int and getting a pointer to member function via non-standard syntax.
|
|||
|
||||
@item -fno-nonansi-builtins
|
||||
@opindex fno-nonansi-builtins
|
||||
Disable builtin declarations of functions that are not mandated by
|
||||
Disable built-in declarations of functions that are not mandated by
|
||||
ANSI/ISO C. These include @code{ffs}, @code{alloca}, @code{_exit},
|
||||
@code{index}, @code{bzero}, @code{conjf}, and other related functions.
|
||||
|
||||
|
|
@ -1537,7 +1537,7 @@ Do not warn about usage of deprecated features. @xref{Deprecated Features}.
|
|||
@opindex Wno-non-template-friend
|
||||
Disable warnings when non-templatized friend functions are declared
|
||||
within a template. With the advent of explicit template specification
|
||||
support in g++, if the name of the friend is an unqualified-id (ie,
|
||||
support in g++, if the name of the friend is an unqualified-id (i.e.,
|
||||
@samp{friend foo(int)}), the C++ language specification demands that the
|
||||
friend declare or define an ordinary, nontemplate function. (Section
|
||||
14.5.3). Before g++ implemented explicit specification, unqualified-ids
|
||||
|
|
@ -2302,10 +2302,10 @@ A function-like macro that appears without arguments.
|
|||
The unary plus operator.
|
||||
|
||||
@item
|
||||
The `U' integer constant suffix, or the `F' or `L' floating point
|
||||
constant suffixes. (Traditonal C does support the `L' suffix on integer
|
||||
The @samp{U} integer constant suffix, or the @samp{F} or @samp{L} floating point
|
||||
constant suffixes. (Traditional C does support the @samp{L} suffix on integer
|
||||
constants.) Note, these suffixes appear in macros defined in the system
|
||||
headers of most modern systems, e.g. the _MIN/_MAX macros in limits.h.
|
||||
headers of most modern systems, e.g. the @samp{_MIN}/@samp{_MAX} macros in @code{<limits.h>}.
|
||||
Use of these macros in user code might normally lead to spurious
|
||||
warnings, however gcc's integrated preprocessor has enough context to
|
||||
avoid warning in these cases.
|
||||
|
|
@ -2730,7 +2730,7 @@ You can examine different profiling aspects without recompilation. Your
|
|||
executable will read a list of function names from file @file{bb.in}.
|
||||
Profiling starts when a function on the list is entered and stops when
|
||||
that invocation is exited. To exclude a function from profiling, prefix
|
||||
its name with `-'. If a function name is not unique, you can
|
||||
its name with @samp{-}. If a function name is not unique, you can
|
||||
disambiguate it by writing it in the form
|
||||
@samp{/path/filename.d:functionname}. Your executable will write the
|
||||
available paths and filenames in file @file{bb.out}.
|
||||
|
|
@ -3742,7 +3742,7 @@ implicitly converting it to double precision constant.
|
|||
|
||||
@item -frename-registers
|
||||
@opindex frename-registers
|
||||
Attempt to avoid false dependancies in scheduled code by making use
|
||||
Attempt to avoid false dependencies in scheduled code by making use
|
||||
of registers left over after register allocation. This optimization
|
||||
will most benefit processors with lots of registers. It can, however,
|
||||
make debugging impossible, since variables will no longer stay in
|
||||
|
|
@ -4725,7 +4725,7 @@ contain startup files. If the target supports multilibs then the
|
|||
current multilib directory will be prepended to each of these paths.
|
||||
|
||||
@item %M
|
||||
Output the multilib directory with directory seperators replaced with
|
||||
Output the multilib directory with directory separators replaced with
|
||||
@samp{_}. If multilib directories are not set, or the multilib directory is
|
||||
@file{.} then this option emits nothing.
|
||||
|
||||
|
|
@ -6697,11 +6697,11 @@ hardware floating is used.
|
|||
@opindex mno-bit-align
|
||||
@opindex mbit-align
|
||||
On System V.4 and embedded PowerPC systems do not (do) force structures
|
||||
and unions that contain bit fields to be aligned to the base type of the
|
||||
bit field.
|
||||
and unions that contain bit-fields to be aligned to the base type of the
|
||||
bit-field.
|
||||
|
||||
For example, by default a structure containing nothing but 8
|
||||
@code{unsigned} bitfields of length 1 would be aligned to a 4 byte
|
||||
@code{unsigned} bit-fields of length 1 would be aligned to a 4 byte
|
||||
boundary and have a size of 4 bytes. By using @option{-mno-bit-align},
|
||||
the structure would be aligned to a 1 byte boundary and be one byte in
|
||||
size.
|
||||
|
|
@ -6950,7 +6950,7 @@ be allocated dynamically.
|
|||
@opindex mfp-arg-in-fpregs
|
||||
Use a calling sequence incompatible with the IBM calling convention in
|
||||
which floating point arguments are passed in floating point registers.
|
||||
Note that @code{varargs.h} and @code{stdargs.h} will not work with
|
||||
Note that @code{varargs.h} and @code{stdarg.h} will not work with
|
||||
floating point operands if this option is specified.
|
||||
|
||||
@item -mfp-arg-in-gregs
|
||||
|
|
@ -7395,7 +7395,7 @@ expense of more memory.
|
|||
@opindex m128bit-long-double
|
||||
Control the size of @code{long double} type. i386 application binary interface
|
||||
specify the size to be 12 bytes, while modern architectures (Pentium and newer)
|
||||
preffer @code{long double} aligned to 8 or 16 byte boundary. This is
|
||||
prefer @code{long double} aligned to 8 or 16 byte boundary. This is
|
||||
impossible to reach with 12 byte long doubles in the array accesses.
|
||||
|
||||
@strong{Warning:} if you use the @option{-m128bit-long-double} switch, the
|
||||
|
|
@ -8113,7 +8113,7 @@ Generate code for the SH4 without a floating-point unit.
|
|||
@item -m4-single-only
|
||||
@opindex m4-single-only
|
||||
Generate code for the SH4 with a floating-point unit that only
|
||||
supports single-precision arithmentic.
|
||||
supports single-precision arithmetic.
|
||||
|
||||
@item -m4-single
|
||||
@opindex m4-single
|
||||
|
|
@ -8719,7 +8719,7 @@ Allow arbitrary sized immediates in bit operations.
|
|||
@opindex mwide-bitfields
|
||||
@opindex mwide-bitfields
|
||||
@opindex mno-wide-bitfields
|
||||
Always treat bitfields as int-sized.
|
||||
Always treat bit-fields as int-sized.
|
||||
|
||||
@item -m4byte-functions
|
||||
@itemx -m4byte-functions
|
||||
|
|
|
|||
|
|
@ -2364,7 +2364,7 @@ point.
|
|||
|
||||
@cindex @code{extv} instruction pattern
|
||||
@item @samp{extv}
|
||||
Extract a bit field from operand 1 (a register or memory operand), where
|
||||
Extract a bit-field from operand 1 (a register or memory operand), where
|
||||
operand 2 specifies the width in bits and operand 3 the starting bit,
|
||||
and store it in operand 0. Operand 0 must have mode @code{word_mode}.
|
||||
Operand 1 may have mode @code{byte_mode} or @code{word_mode}; often
|
||||
|
|
@ -2383,8 +2383,8 @@ Like @samp{extv} except that the bit-field value is zero-extended.
|
|||
|
||||
@cindex @code{insv} instruction pattern
|
||||
@item @samp{insv}
|
||||
Store operand 3 (which must be valid for @code{word_mode}) into a bit
|
||||
field in operand 0, where operand 1 specifies the width in bits and
|
||||
Store operand 3 (which must be valid for @code{word_mode}) into a
|
||||
bit-field in operand 0, where operand 1 specifies the width in bits and
|
||||
operand 2 the starting bit. Operand 0 may have mode @code{byte_mode} or
|
||||
@code{word_mode}; often @code{word_mode} is allowed only for registers.
|
||||
Operands 1 and 2 must be valid for @code{word_mode}.
|
||||
|
|
@ -2844,7 +2844,7 @@ the first three are normally used by the generic mechanism.
|
|||
@cindex @code{builtin_setjmp_receiver} instruction pattern
|
||||
@item @samp{builtin_setjmp_receiver}
|
||||
This pattern, if defined, contains code needed at the site of an
|
||||
builtin setjmp that isn't needed at the site of a nonlocal goto. You
|
||||
built-in setjmp that isn't needed at the site of a nonlocal goto. You
|
||||
will not normally need to define this pattern. A typical reason why you
|
||||
might need this pattern is if some value, such as a pointer to a global
|
||||
table, must be restored. It takes one argument, which is the label
|
||||
|
|
@ -2915,7 +2915,7 @@ function.
|
|||
@item @samp{trap}
|
||||
This pattern, if defined, signals an error, typically by causing some
|
||||
kind of signal to be raised. Among other places, it is used by the Java
|
||||
frontend to signal `invalid array index' exceptions.
|
||||
front end to signal `invalid array index' exceptions.
|
||||
|
||||
@cindex @code{conditional_trap} instruction pattern
|
||||
@item @samp{conditional_trap}
|
||||
|
|
@ -3173,7 +3173,7 @@ provide low-overhead loop support. For example, the TI TMS320C3x/C4x
|
|||
DSPs have a block repeat instruction that loads special registers to
|
||||
mark the top and end of a loop and to count the number of loop
|
||||
iterations. This avoids the need for fetching and executing a
|
||||
@samp{dbra}-like instruction and avoids pipeline stalls asociated with
|
||||
@samp{dbra}-like instruction and avoids pipeline stalls associated with
|
||||
the jump.
|
||||
|
||||
GNU CC has three special named patterns to support low overhead looping,
|
||||
|
|
@ -3478,7 +3478,7 @@ that the pattern was not truly available. The calling routines in the
|
|||
compiler will try other strategies for code generation using other patterns.
|
||||
|
||||
Failure is currently supported only for binary (addition, multiplication,
|
||||
shifting, etc.) and bitfield (@code{extv}, @code{extzv}, and @code{insv})
|
||||
shifting, etc.) and bit-field (@code{extv}, @code{extzv}, and @code{insv})
|
||||
operations.
|
||||
@end table
|
||||
|
||||
|
|
@ -3590,7 +3590,7 @@ on this machine. So it must be copied into a register with
|
|||
@end smallexample
|
||||
|
||||
@strong{Note:} If the @code{define_expand} is used to serve a
|
||||
standard binary or unary arithmetic operation or a bitfield operation,
|
||||
standard binary or unary arithmetic operation or a bit-field operation,
|
||||
then the last insn it generates must not be a @code{code_label},
|
||||
@code{barrier} or @code{note}. It must be an @code{insn},
|
||||
@code{jump_insn} or @code{call_insn}. If you don't need a real insn
|
||||
|
|
|
|||
|
|
@ -216,23 +216,23 @@ The types are encoded in the following way:
|
|||
@tab @code{*}
|
||||
@item unknown type
|
||||
@tab @code{?}
|
||||
@item bitfields
|
||||
@tab @code{b} followed by the starting position of the bitfield, the type of the bitfield and the size of the bitfield (the bitfields encoding was changed from the NeXT's compiler encoding, see below)
|
||||
@item bit-fields
|
||||
@tab @code{b} followed by the starting position of the bit-field, the type of the bit-field and the size of the bit-field (the bit-fields encoding was changed from the NeXT's compiler encoding, see below)
|
||||
@end multitable
|
||||
|
||||
@c @sp 1
|
||||
|
||||
The encoding of bitfields has changed to allow bitfields to be properly
|
||||
The encoding of bit-fields has changed to allow bit-fields to be properly
|
||||
handled by the runtime functions that compute sizes and alignments of
|
||||
types that contain bitfields. The previous encoding contained only the
|
||||
size of the bitfield. Using only this information it is not possible to
|
||||
reliably compute the size occupied by the bitfield. This is very
|
||||
types that contain bit-fields. The previous encoding contained only the
|
||||
size of the bit-field. Using only this information it is not possible to
|
||||
reliably compute the size occupied by the bit-field. This is very
|
||||
important in the presence of the Boehm's garbage collector because the
|
||||
objects are allocated using the typed memory facility available in this
|
||||
collector. The typed memory allocation requires information about where
|
||||
the pointers are located inside the object.
|
||||
|
||||
The position in the bitfield is the position, counting in bits, of the
|
||||
The position in the bit-field is the position, counting in bits, of the
|
||||
bit closest to the beginning of the structure.
|
||||
|
||||
The non-atomic types are encoded as follows:
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ form uses nested parentheses to indicate the pointers in the internal form.
|
|||
|
||||
@menu
|
||||
* RTL Objects:: Expressions vs vectors vs strings vs integers.
|
||||
* RTL Classes:: Categories of RTL expresion objects, and their structure.
|
||||
* RTL Classes:: Categories of RTL expression objects, and their structure.
|
||||
* Accessors:: Macros to access expression operands or vector elts.
|
||||
* Flags:: Other flags in an RTL expression.
|
||||
* Machine Modes:: Describing the size and format of a datum.
|
||||
|
|
@ -29,7 +29,7 @@ form uses nested parentheses to indicate the pointers in the internal form.
|
|||
* Regs and Memory:: Expressions representing register contents or memory.
|
||||
* Arithmetic:: Expressions representing arithmetic on other expressions.
|
||||
* Comparisons:: Expressions representing comparison of expressions.
|
||||
* Bit Fields:: Expressions representing bitfields in memory or reg.
|
||||
* Bit-Fields:: Expressions representing bit-fields in memory or reg.
|
||||
* Vector Operations:: Expressions involving vector datatypes.
|
||||
* Conversions:: Extending, truncating, floating or fixing.
|
||||
* RTL Declarations:: Declaring volatility, constancy, etc.
|
||||
|
|
@ -149,10 +149,10 @@ An RTX code for a non-commutative binary operation, such as @code{MINUS},
|
|||
@code{DIV}, or @code{ASHIFTRT}.
|
||||
|
||||
@item b
|
||||
An RTX code for a bitfield operation. Currently only
|
||||
An RTX code for a bit-field operation. Currently only
|
||||
@code{ZERO_EXTRACT} and @code{SIGN_EXTRACT}. These have three inputs
|
||||
and are lvalues (so they can be used for insertion as well). @xref{Bit
|
||||
Fields}.
|
||||
and are lvalues (so they can be used for insertion as well).
|
||||
@xref{Bit-Fields}.
|
||||
|
||||
@item 3
|
||||
An RTX code for other three input operations. Currently only
|
||||
|
|
@ -338,7 +338,7 @@ to access them.
|
|||
@section Flags in an RTL Expression
|
||||
@cindex flags in RTL expression
|
||||
|
||||
RTL expressions contain several flags (one-bit bitfields) and other
|
||||
RTL expressions contain several flags (one-bit bit-fields) and other
|
||||
values that are used in certain types of expression. Most often they
|
||||
are accessed with the following macros:
|
||||
|
||||
|
|
@ -1732,21 +1732,21 @@ This is currently not valid for instruction patterns and is supported only
|
|||
for insn attributes. @xref{Insn Attributes}.
|
||||
@end table
|
||||
|
||||
@node Bit Fields
|
||||
@section Bit Fields
|
||||
@cindex bit fields
|
||||
@node Bit-Fields
|
||||
@section Bit-Fields
|
||||
@cindex bit-fields
|
||||
|
||||
Special expression codes exist to represent bitfield instructions.
|
||||
Special expression codes exist to represent bit-field instructions.
|
||||
These types of expressions are lvalues in RTL; they may appear
|
||||
on the left side of an assignment, indicating insertion of a value
|
||||
into the specified bit field.
|
||||
into the specified bit-field.
|
||||
|
||||
@table @code
|
||||
@findex sign_extract
|
||||
@cindex @code{BITS_BIG_ENDIAN}, effect on @code{sign_extract}
|
||||
@item (sign_extract:@var{m} @var{loc} @var{size} @var{pos})
|
||||
This represents a reference to a sign-extended bit field contained or
|
||||
starting in @var{loc} (a memory or register reference). The bit field
|
||||
This represents a reference to a sign-extended bit-field contained or
|
||||
starting in @var{loc} (a memory or register reference). The bit-field
|
||||
is @var{size} bits wide and starts at bit @var{pos}. The compilation
|
||||
option @code{BITS_BIG_ENDIAN} says which end of the memory unit
|
||||
@var{pos} counts from.
|
||||
|
|
@ -1766,7 +1766,7 @@ The mode @var{m} is the same as the mode that would be used for
|
|||
@findex zero_extract
|
||||
@item (zero_extract:@var{m} @var{loc} @var{size} @var{pos})
|
||||
Like @code{sign_extract} but refers to an unsigned or zero-extended
|
||||
bit field. The same sequence of bits are extracted, but they
|
||||
bit-field. The same sequence of bits are extracted, but they
|
||||
are filled to an entire word with zeros instead of by sign-extension.
|
||||
@end table
|
||||
|
||||
|
|
@ -1989,7 +1989,7 @@ Use the former expression to save space during the compilation.
|
|||
|
||||
If @var{lval} is a @code{parallel}, it is used to represent the case of
|
||||
a function returning a structure in multiple registers. Each element
|
||||
of the @code{paralllel} is an @code{expr_list} whose first operand is a
|
||||
of the @code{parallel} is an @code{expr_list} whose first operand is a
|
||||
@code{reg} and whose second operand is a @code{const_int} representing the
|
||||
offset (in bytes) into the structure at which the data in that register
|
||||
corresponds. The first element may be null to indicate that the structure
|
||||
|
|
@ -2680,7 +2680,7 @@ The second Haifa scheduling pass, for targets that can multiple issue,
|
|||
sets the mode of an insn to @code{TImode} when it is believed that the
|
||||
instruction begins an issue group. That is, when the instruction
|
||||
cannot issue simultaneously with the previous. This may be relied on
|
||||
by later passes, in particular machine-dependant reorg.
|
||||
by later passes, in particular machine-dependent reorg.
|
||||
|
||||
Here is a table of the extra fields of @code{insn}, @code{jump_insn}
|
||||
and @code{call_insn} insns:
|
||||
|
|
|
|||
|
|
@ -117,7 +117,7 @@ than C. If you do not define this macro, then the value of
|
|||
|
||||
@findex NO_BUILTIN_SIZE_TYPE
|
||||
@item NO_BUILTIN_SIZE_TYPE
|
||||
If this macro is defined, the preprocessor will not define the builtin macro
|
||||
If this macro is defined, the preprocessor will not define the built-in macro
|
||||
@code{__SIZE_TYPE__}. The macro @code{__SIZE_TYPE__} must then be defined
|
||||
by @code{CPP_SPEC} instead.
|
||||
|
||||
|
|
@ -127,7 +127,7 @@ be defined.
|
|||
|
||||
@findex NO_BUILTIN_PTRDIFF_TYPE
|
||||
@item NO_BUILTIN_PTRDIFF_TYPE
|
||||
If this macro is defined, the preprocessor will not define the builtin macro
|
||||
If this macro is defined, the preprocessor will not define the built-in macro
|
||||
@code{__PTRDIFF_TYPE__}. The macro @code{__PTRDIFF_TYPE__} must then be
|
||||
defined by @code{CPP_SPEC} instead.
|
||||
|
||||
|
|
@ -137,7 +137,7 @@ be defined.
|
|||
|
||||
@findex NO_BUILTIN_WCHAR_TYPE
|
||||
@item NO_BUILTIN_WCHAR_TYPE
|
||||
If this macro is defined, the preprocessor will not define the builtin macro
|
||||
If this macro is defined, the preprocessor will not define the built-in macro
|
||||
@code{__WCHAR_TYPE__}. The macro @code{__WCHAR_TYPE__} must then be
|
||||
defined by @code{CPP_SPEC} instead.
|
||||
|
||||
|
|
@ -147,7 +147,7 @@ be defined.
|
|||
|
||||
@findex NO_BUILTIN_WINT_TYPE
|
||||
@item NO_BUILTIN_WINT_TYPE
|
||||
If this macro is defined, the preprocessor will not define the builtin macro
|
||||
If this macro is defined, the preprocessor will not define the built-in macro
|
||||
@code{__WINT_TYPE__}. The macro @code{__WINT_TYPE__} must then be
|
||||
defined by @code{CPP_SPEC} instead.
|
||||
|
||||
|
|
@ -792,7 +792,7 @@ pointer is non-NULL it will be called once per function, before function
|
|||
compilation starts, in order to allow the target to perform any target
|
||||
specific initialisation of the @code{struct function} structure. It is
|
||||
intended that this would be used to initialise the @code{machine} of
|
||||
that struture.
|
||||
that structure.
|
||||
|
||||
@findex free_machine_status
|
||||
@item free_machine_status
|
||||
|
|
@ -1052,7 +1052,7 @@ make it all fit in fewer cache lines.
|
|||
|
||||
@findex EMPTY_FIELD_BOUNDARY
|
||||
@item EMPTY_FIELD_BOUNDARY
|
||||
Alignment in bits to be given to a structure bit field that follows an
|
||||
Alignment in bits to be given to a structure bit-field that follows an
|
||||
empty field such as @code{int : 0;}.
|
||||
|
||||
Note that @code{PCC_BITFIELD_TYPE_MATTERS} also affects the alignment
|
||||
|
|
@ -1075,16 +1075,16 @@ go slower in that case, define this macro as 0.
|
|||
@findex PCC_BITFIELD_TYPE_MATTERS
|
||||
@item PCC_BITFIELD_TYPE_MATTERS
|
||||
Define this if you wish to imitate the way many other C compilers handle
|
||||
alignment of bitfields and the structures that contain them.
|
||||
alignment of bit-fields and the structures that contain them.
|
||||
|
||||
The behavior is that the type written for a bitfield (@code{int},
|
||||
The behavior is that the type written for a bit-field (@code{int},
|
||||
@code{short}, or other integer type) imposes an alignment for the
|
||||
entire structure, as if the structure really did contain an ordinary
|
||||
field of that type. In addition, the bitfield is placed within the
|
||||
field of that type. In addition, the bit-field is placed within the
|
||||
structure so that it would fit within such a field, not crossing a
|
||||
boundary for it.
|
||||
|
||||
Thus, on most machines, a bitfield whose type is written as @code{int}
|
||||
Thus, on most machines, a bit-field whose type is written as @code{int}
|
||||
would not cross a four-byte boundary, and would force four-byte
|
||||
alignment for the whole structure. (The alignment used may not be four
|
||||
bytes; it is controlled by the other alignment parameters.)
|
||||
|
|
@ -1093,20 +1093,20 @@ If the macro is defined, its definition should be a C expression;
|
|||
a nonzero value for the expression enables this behavior.
|
||||
|
||||
Note that if this macro is not defined, or its value is zero, some
|
||||
bitfields may cross more than one alignment boundary. The compiler can
|
||||
bit-fields may cross more than one alignment boundary. The compiler can
|
||||
support such references if there are @samp{insv}, @samp{extv}, and
|
||||
@samp{extzv} insns that can directly reference memory.
|
||||
|
||||
The other known way of making bitfields work is to define
|
||||
The other known way of making bit-fields work is to define
|
||||
@code{STRUCTURE_SIZE_BOUNDARY} as large as @code{BIGGEST_ALIGNMENT}.
|
||||
Then every structure can be accessed with fullwords.
|
||||
|
||||
Unless the machine has bitfield instructions or you define
|
||||
Unless the machine has bit-field instructions or you define
|
||||
@code{STRUCTURE_SIZE_BOUNDARY} that way, you must define
|
||||
@code{PCC_BITFIELD_TYPE_MATTERS} to have a nonzero value.
|
||||
|
||||
If your aim is to make GCC use the same conventions for laying out
|
||||
bitfields as are used by another compiler, here is how to investigate
|
||||
bit-fields as are used by another compiler, here is how to investigate
|
||||
what the other compiler does. Compile and run this program:
|
||||
|
||||
@example
|
||||
|
|
@ -1140,7 +1140,7 @@ get from @code{PCC_BITFIELD_TYPE_MATTERS}.
|
|||
@findex BITFIELD_NBYTES_LIMITED
|
||||
@item BITFIELD_NBYTES_LIMITED
|
||||
Like PCC_BITFIELD_TYPE_MATTERS except that its effect is limited to
|
||||
aligning a bitfield within the structure.
|
||||
aligning a bit-field within the structure.
|
||||
|
||||
@findex MEMBER_TYPE_FORCES_BLK
|
||||
@item MEMBER_TYPE_FORCES_BLK (@var{field})
|
||||
|
|
@ -2646,7 +2646,7 @@ to be emitted.
|
|||
@findex SMALL_STACK
|
||||
@item SMALL_STACK
|
||||
Define this macro if the stack size for the target is very small. This
|
||||
has the effect of disabling gcc's builtin @samp{alloca}, though
|
||||
has the effect of disabling gcc's built-in @samp{alloca}, though
|
||||
@samp{__builtin_alloca} is not affected.
|
||||
@end table
|
||||
|
||||
|
|
@ -3638,7 +3638,7 @@ arguments. But usually, on such machines, nothing else has been pushed
|
|||
yet, because the function prologue itself does all the pushing.) This
|
||||
region is used on machines where an argument may be passed partly in
|
||||
registers and partly in memory, and, in some cases to support the
|
||||
features in @file{varargs.h} and @file{stdargs.h}.
|
||||
features in @file{varargs.h} and @file{stdarg.h}.
|
||||
|
||||
@item
|
||||
An area of memory used to save certain registers used by the function.
|
||||
|
|
@ -3793,7 +3793,7 @@ have already been extracted from it.) It might possibly be useful on
|
|||
some targets, but probably not.
|
||||
|
||||
If you do not define this macro, the target-independent code in the C++
|
||||
frontend will generate a less efficient heavyweight thunk that calls
|
||||
front end will generate a less efficient heavyweight thunk that calls
|
||||
@var{function} instead of jumping to it. The generic approach does
|
||||
not support varargs.
|
||||
@end table
|
||||
|
|
@ -4768,7 +4768,7 @@ the address has become legitimate.
|
|||
If you want to change only a part of @var{x}, one standard way of doing
|
||||
this is to use @code{copy_rtx}. Note, however, that is unshares only a
|
||||
single level of rtl. Thus, if the part to be changed is not at the
|
||||
top level, you'll need to replace first the top leve
|
||||
top level, you'll need to replace first the top level.
|
||||
It is not necessary for this macro to come up with a legitimate
|
||||
address; but often a machine-dependent strategy can generate better code.
|
||||
|
||||
|
|
@ -4954,7 +4954,7 @@ like:
|
|||
|
||||
@smallexample
|
||||
#define REVERSE_CONDITION(CODE, MODE) \
|
||||
((MODE) != CCFPmode ? reverse_condtion (CODE) \
|
||||
((MODE) != CCFPmode ? reverse_condition (CODE) \
|
||||
: reverse_condition_maybe_unordered (CODE))
|
||||
@end smallexample
|
||||
|
||||
|
|
@ -5232,7 +5232,7 @@ thing to use for a given mode. Defaults to the value of
|
|||
|
||||
@findex USE_STORE_POST_DECREMENT
|
||||
@item USE_STORE_POST_DECREMENT (@var{mode})
|
||||
A C expression used to determine whether a store postdeccrement is a good
|
||||
A C expression used to determine whether a store postdecrement is a good
|
||||
thing to use for a given mode. Defaults to the value of
|
||||
@code{HAVE_POST_DECREMENT}.
|
||||
|
||||
|
|
@ -5453,7 +5453,7 @@ STRING_CST node, and assign it to @samp{DECL_SECTION_NAME (@var{decl})}.
|
|||
@var{reloc} indicates whether the initial value of @var{exp} requires
|
||||
link-time relocations. If you do not define this macro, GCC will use
|
||||
the symbol name prefixed by @samp{.} as the section name. Note - this
|
||||
macro can now be called for unitialised data items as well as
|
||||
macro can now be called for uninitialised data items as well as
|
||||
initialised data and functions.
|
||||
@end table
|
||||
|
||||
|
|
@ -7355,7 +7355,7 @@ Here is another way of finding a particular type:
|
|||
@findex NO_DBX_FUNCTION_END
|
||||
@item NO_DBX_FUNCTION_END
|
||||
Some stabs encapsulation formats (in particular ECOFF), cannot handle the
|
||||
@code{.stabs "",N_FUN,,0,0,Lscope-function-1} gdb dbx extention construct.
|
||||
@code{.stabs "",N_FUN,,0,0,Lscope-function-1} gdb dbx extension construct.
|
||||
On those machines, define this macro to turn this feature off without
|
||||
disturbing the rest of the gdb extensions.
|
||||
|
||||
|
|
@ -7907,18 +7907,18 @@ of bits needed to represent the size of the object being shifted. When
|
|||
this macro is non-zero, the compiler will assume that it is safe to omit
|
||||
a sign-extend, zero-extend, and certain bitwise `and' instructions that
|
||||
truncates the count of a shift operation. On machines that have
|
||||
instructions that act on bitfields at variable positions, which may
|
||||
instructions that act on bit-fields at variable positions, which may
|
||||
include `bit test' instructions, a nonzero @code{SHIFT_COUNT_TRUNCATED}
|
||||
also enables deletion of truncations of the values that serve as
|
||||
arguments to bitfield instructions.
|
||||
arguments to bit-field instructions.
|
||||
|
||||
If both types of instructions truncate the count (for shifts) and
|
||||
position (for bitfield operations), or if no variable-position bitfield
|
||||
position (for bit-field operations), or if no variable-position bit-field
|
||||
instructions exist, you should define this macro.
|
||||
|
||||
However, on some machines, such as the 80386 and the 680x0, truncation
|
||||
only applies to shift operations and not the (real or pretended)
|
||||
bitfield operations. Define @code{SHIFT_COUNT_TRUNCATED} to be zero on
|
||||
bit-field operations. Define @code{SHIFT_COUNT_TRUNCATED} to be zero on
|
||||
such machines. Instead, add patterns to the @file{md} file that include
|
||||
the implied truncation of the shift instructions.
|
||||
|
||||
|
|
@ -8144,7 +8144,7 @@ Note that the use of @code{c_lex} is specific to the C and C++
|
|||
compilers. It will not work in the Java or Fortran compilers, or any
|
||||
other language compilers for that matter. Thus if @code{c_lex} is going
|
||||
to be called from target-specific code, it must only be done so when
|
||||
building hte C and C++ compilers. This can be done by defining the
|
||||
building the C and C++ compilers. This can be done by defining the
|
||||
variables @code{c_target_objs} and @code{cxx_target_objs} in the
|
||||
target entry in the @code{config.gcc} file. These variables should name
|
||||
the target-specific, language-specific object file which contains the
|
||||
|
|
@ -8236,7 +8236,7 @@ definition.
|
|||
@findex INSERT_ATTRIBUTES
|
||||
@item INSERT_ATTRIBUTES (@var{node}, @var{attr_ptr}, @var{prefix_ptr})
|
||||
Define this macro if you want to be able to add attributes to a decl
|
||||
when it is being created. This is normally useful for backends which
|
||||
when it is being created. This is normally useful for back ends which
|
||||
wish to implement a pragma by using the attributes which correspond to
|
||||
the pragma's effect. The @var{node} argument is the decl which is being
|
||||
created. The @var{attr_ptr} argument is a pointer to the attribute list
|
||||
|
|
@ -8455,7 +8455,7 @@ conditional execution instructions instead of a branch. A value of
|
|||
@findex IFCVT_MODIFY_TESTS
|
||||
@item IFCVT_MODIFY_TESTS
|
||||
A C expression to modify the tests in @code{TRUE_EXPR}, and
|
||||
@code{FALSE_EXPPR} for use in converting insns in @code{TEST_BB},
|
||||
@code{FALSE_EXPR} for use in converting insns in @code{TEST_BB},
|
||||
@code{THEN_BB}, @code{ELSE_BB}, and @code{JOIN_BB} basic blocks to
|
||||
conditional execution. Set either @code{TRUE_EXPR} or @code{FALSE_EXPR}
|
||||
to a null pointer if the tests cannot be converted.
|
||||
|
|
@ -8479,30 +8479,30 @@ converting code to conditional execution in the basic blocks
|
|||
|
||||
@findex MD_INIT_BUILTINS
|
||||
@item MD_INIT_BUILTINS
|
||||
Define this macro if you have any machine-specific builtin functions that
|
||||
Define this macro if you have any machine-specific built-in functions that
|
||||
need to be defined. It should be a C expression that performs the
|
||||
necessary setup.
|
||||
|
||||
Machine specific builtins can be useful to expand special machine
|
||||
Machine specific built-in functions can be useful to expand special machine
|
||||
instructions that would otherwise not normally be generated because
|
||||
they have no equivalent in the source language (for example, SIMD vector
|
||||
instructions or prefetch instructions).
|
||||
|
||||
To create a builtin function, call the function @code{builtin_function}
|
||||
which is defined by the language frontend. You can use any type nodes set
|
||||
To create a built-in function, call the function @code{builtin_function}
|
||||
which is defined by the language front end. You can use any type nodes set
|
||||
up by @code{build_common_tree_nodes} and @code{build_common_tree_nodes_2};
|
||||
only language frontends that use these two functions will use
|
||||
only language front ends that use these two functions will use
|
||||
@samp{MD_INIT_BUILTINS}.
|
||||
|
||||
@findex MD_EXPAND_BUILTIN
|
||||
@item MD_EXPAND_BUILTIN(@var{exp}, @var{target}, @var{subtarget}, @var{mode}, @var{ignore})
|
||||
|
||||
Expand a call to a machine specific builtin that was set up by
|
||||
Expand a call to a machine specific built-in function that was set up by
|
||||
@samp{MD_INIT_BUILTINS}. @var{exp} is the expression for the function call;
|
||||
the result should go to @var{target} if that is convenient, and have mode
|
||||
@var{mode} if that is convenient. @var{subtarget} may be used as the target
|
||||
for computing one of @var{exp}'s operands. @var{ignore} is nonzero if the value
|
||||
is to be ignored.
|
||||
This macro should return the result of the call to the builtin.
|
||||
This macro should return the result of the call to the built-in function.
|
||||
|
||||
@end table
|
||||
|
|
|
|||
Loading…
Reference in New Issue