+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.
@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
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.
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
@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}.
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
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:
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}.
@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
@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.
@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.
@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
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.
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
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.
@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.
@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
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
is used in a void context. An example would be,
@example
-volatile int *src = <somevalue>;
+volatile int *src = @var{somevalue};
*src;
@end example
@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
.\" Automatically generated by Pod::Man version 1.16
-.\" Thu Jun 14 10:58:24 2001
+.\" Thu Jun 14 22:41:32 2001
.\"
.\" Standard preamble:
.\" ======================================================================
\&\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="
\&\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
.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"
.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
.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"
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
.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
.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.
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.
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
.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.
.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"
.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
.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
.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
@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
@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
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
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.
@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
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
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
@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.
@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
@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
@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
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
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
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.
@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
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
@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
@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
@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.
@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
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.
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}.
@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
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.
@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.
@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
@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
@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
@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
@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
@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}.
@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
@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}
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,
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
@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
@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:
@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.
* 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.
@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
@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:
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.
@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
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
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:
@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.
@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.
@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.
@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.
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
@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
@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.)
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
@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})
@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
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.
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
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.
@smallexample
#define REVERSE_CONDITION(CODE, MODE) \
- ((MODE) != CCFPmode ? reverse_condtion (CODE) \
+ ((MODE) != CCFPmode ? reverse_condition (CODE) \
: reverse_condition_maybe_unordered (CODE))
@end smallexample
@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}.
@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
@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.
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.
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
@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
@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.
@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
git://gcc.gnu.org / gcc.git / commitdiff