+2001-06-25 Joseph S. Myers <jsm28@cam.ac.uk>
+
+ * doc/c-tree.texi, doc/contrib.texi, doc/extend.texi,
+ doc/gcc.texi, doc/gcov.texi, doc/install.texi, doc/invoke.texi,
+ doc/md.texi, doc/rtl.texi, doc/tm.texi: Be more consistent about
+ the use of "GCC" and related terms.
+ * doc/gcc.1, doc/gcov.1: Regenerate.
+
2001-06-24 Joseph S. Myers <jsm28@cam.ac.uk>
* doc/extend.texi, doc/gcc.texi, doc/install-old.texi,
tree node as input. In other words, there is a type-system for trees,
but it is not reflected in the C type-system.
-For safety, it is useful to configure G++ with @option{--enable-checking}.
+For safety, it is useful to configure GCC with @option{--enable-checking}.
Although this results in a significant performance penalty (since all
tree types are checked at run-time), and is therefore inappropriate in a
release version, it is extremely helpful during the development process.
loop changes.
@item
-Paul Eggert for random hacking all over gcc.
+Paul Eggert for random hacking all over GCC.
@item
Mark Elbrecht for various DJGPP improvements.
@opindex pedantic
GNU C provides several language features not found in ISO standard C.
-(The @option{-pedantic} option directs GNU CC to print a warning message if
+(The @option{-pedantic} option directs GCC to print a warning message if
any of these features is used.) To test for the availability of these
features in conditional compilation, check for a predefined macro
-@code{__GNUC__}, which is always defined under GNU CC.
+@code{__GNUC__}, which is always defined under GCC.
These extensions are available in C and Objective-C. Most of them are
also available in C++. @xref{C++ Extensions,,Extensions to the
does not refer to anything that has gone out of scope, you should be
safe.
-GNU CC implements taking the address of a nested function using a
+GCC implements taking the address of a nested function using a
technique called @dfn{trampolines}. A paper describing them is
available as @uref{http://people.debian.org/~karlheg/Usenix88-lexic.pdf}.
if the machine supports fullword-to-doubleword a widening multiply
instruction. Division and shifts are open-coded only on machines that
provide special support. The operations that are not open-coded use
-special library routines that come with GNU CC.
+special library routines that come with GCC.
There may be pitfalls when you use @code{long long} types for function
arguments, unless you declare function prototypes. If a function
@code{conj} and @code{conjl}, declared in @code{<complex.h>} and also
provided as built-in functions by GCC.
-GNU CC can allocate complex automatic variables in a noncontiguous
+GCC can allocate complex automatic variables in a noncontiguous
fashion; it's even possible for the real part to be in a register while
the imaginary part is on the stack (or vice-versa). None of the
supported debugging info formats has a way to represent noncontiguous
-allocation like this, so GNU CC describes a noncontiguous complex
+allocation like this, so GCC describes a noncontiguous complex
variable as if it were two separate variables of noncomplex type.
If the variable's actual name is @code{foo}, the two fictitious
variables are named @code{foo$real} and @code{foo$imag}. You can
@cindex @code{noreturn} function attribute
@item noreturn
A few standard library functions, such as @code{abort} and @code{exit},
-cannot return. GNU CC knows this automatically. Some programs define
+cannot return. GCC knows this automatically. Some programs define
their own functions that never return. You can declare them
@code{noreturn} to tell the compiler this fact. For example,
It does not make sense for a @code{noreturn} function to have a return
type other than @code{void}.
-The attribute @code{noreturn} is not implemented in GNU C versions
+The attribute @code{noreturn} is not implemented in GCC versions
earlier than 2.5. An alternative way to declare that a function does
not return, which works in the current version and in some older
versions, is as follows:
depending on volatile memory or other system resource, that may change between
two consecutive calls (such as @code{feof} in a multithreading environment).
-The attribute @code{pure} is not implemented in GNU C versions earlier
+The attribute @code{pure} is not implemented in GCC versions earlier
than 2.96.
@cindex @code{const} function attribute
@item const
@code{const}. It does not make sense for a @code{const} function to
return @code{void}.
-The attribute @code{const} is not implemented in GNU C versions earlier
+The attribute @code{const} is not implemented in GCC versions earlier
than 2.5. An alternative way to declare that a function has no side
effects, which works in the current version and in some older versions,
is as follows:
@opindex ffreestanding
The @code{format} attribute allows you to identify your own functions
-which take format strings as arguments, so that GNU CC can check the
+which take format strings as arguments, so that GCC can check the
calls to these functions for errors. The compiler always (unless
@option{-ffreestanding} is used) checks formats
for the standard library functions @code{printf}, @code{fprintf},
string argument (starting from 1).
The @code{format-arg} attribute allows you to identify your own
-functions which modify format strings, so that GNU CC can check the
+functions which modify format strings, so that GCC can check the
calls to @code{printf}, @code{scanf}, @code{strftime} or @code{strfmon}
type function whose operands are a call to one of your own function.
The compiler always treats @code{gettext}, @code{dgettext}, and
@item unused
This attribute, attached to a function, means that the function is meant
-to be possibly unused. GNU CC will not produce a warning for this
+to be possibly unused. GCC will not produce a warning for this
function. GNU C++ does not currently support this attribute as
definitions without parameters are valid in C++.
@item no_check_memory_usage
@cindex @code{no_check_memory_usage} function attribute
@opindex fcheck-memory-usage
-The @code{no_check_memory_usage} attribute causes GNU CC to omit checks
+The @code{no_check_memory_usage} attribute causes GCC to omit checks
of memory references when it generates code for that function. Normally
if you specify @option{-fcheck-memory-usage} (see @pxref{Code Gen
-Options}), GNU CC generates calls to support routines before most memory
+Options}), GCC generates calls to support routines before most memory
accesses to permit support code to record usage and detect uses of
-uninitialized or unallocated storage. Since GNU CC cannot handle
+uninitialized or unallocated storage. Since GCC cannot handle
@code{asm} statements properly they are not allowed in such functions.
-If you declare a function with this attribute, GNU CC will not generate
+If you declare a function with this attribute, GCC will not generate
memory checking code for that function, permitting the use of @code{asm}
statements without having to compile that function with different
options. This also allows you to write support routines of your own if
@item nocommon
@cindex @code{nocommon} attribute
@opindex fno-common
-This attribute specifies requests GNU CC not to place a variable
+This attribute specifies requests GCC not to place a variable
``common'' but instead to allocate space for it directly. If you
-specify the @option{-fno-common} flag, GNU CC will do this for all
+specify the @option{-fno-common} flag, GCC will do this for all
variables.
Specifying the @code{nocommon} attribute for a variable provides an
@noindent
Use the @code{section} attribute with an @emph{initialized} definition
-of a @emph{global} variable, as shown in the example. GNU CC issues
+of a @emph{global} variable, as shown in the example. GCC issues
a warning and otherwise ignores the @code{section} attribute in
uninitialized variable declarations.
@item unused
This attribute, attached to a variable, means that the variable is meant
-to be possibly unused. GNU CC will not produce a warning for this
+to be possibly unused. GCC will not produce a warning for this
variable.
@item weak
@item unused
When attached to a type (including a @code{union} or a @code{struct}),
this attribute means that variables of that type are meant to appear
-possibly unused. GNU CC will not produce a warning for any variables of
+possibly unused. GCC will not produce a warning for any variables of
that type, even if the variable appears to do nothing. This is often
the case with lock or thread classes, which are usually defined and then
not referenced, but contain constructors and destructors that have
@cindex open coding
@cindex macros, inline alternative
-By declaring a function @code{inline}, you can direct GNU CC to
+By declaring a function @code{inline}, you can direct GCC to
integrate that function's code into the code for its callers. This
makes execution faster by eliminating the function-call overhead; in
addition, if any of the actual argument values are constant, their known
@cindex member fns, automatically @code{inline}
@cindex C++ member fns, automatically @code{inline}
@opindex fno-default-inline
-GNU CC automatically inlines member functions defined within the class
+GCC automatically inlines member functions defined within the class
body of C++ programs even if they are not explicitly declared
@code{inline}. (You can override this with @option{-fno-default-inline};
@pxref{C++ Dialect Options,,Options Controlling C++ Dialect}.)
When a function is both inline and @code{static}, if all calls to the
function are integrated into the caller, and the function's address is
never used, then the function's own assembler code is never referenced.
-In this case, GNU CC does not actually output assembler code for the
+In this case, GCC does not actually output assembler code for the
function, unless you specify the option @option{-fkeep-inline-functions}.
Some calls cannot be integrated for various reasons (in particular,
calls that precede the function's definition cannot be integrated, and
specified, but eventually the default will be @option{-std=gnu99} and
that will implement the C99 semantics, though it does not do so yet.)
-GNU C does not inline any functions when not optimizing. It is not
+GCC does not inline any functions when not optimizing. It is not
clear whether it is better to inline or not, in this case, but we found
that a correct implementation when not optimizing was difficult. So we
did the easy thing, and turned it off.
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, GCC
will use the register as the output of the @code{asm}, and then store
that register into the output.
-The ordinary output operands must be write-only; GNU CC will assume that
+The ordinary output operands must be write-only; GCC will assume that
the values in these operands before the instruction are dead and need
not be generated. Extended asm supports input-output or read-write
operands. Use the constraint character @samp{+} to indicate such an
@end example
Various optimizations or reloading could cause operands 0 and 1 to be in
-different registers; GNU CC knows no reason not to do so. For example, the
+different registers; GCC knows no reason not to do so. For example, the
compiler might find a copy of the value of @code{foo} in one register and
use it for operand 1, but generate the output operand 0 in a different
register (copying it afterward to @code{foo}'s own address). Of course,
since the register for operand 1 is not even mentioned in the assembler
-code, the result will not work, but GNU CC can't tell that.
+code, the result will not work, but GCC can't tell that.
Some instructions clobber specific hard registers. To describe this,
write a third colon after the input operands, followed by the names of
operand. Note that if all the output operands you specify are for this
purpose (and hence unused), you will then also need to specify
@code{volatile} for the @code{asm} construct, as described below, to
-prevent GNU CC from deleting the @code{asm} statement as unused.
+prevent GCC from deleting the @code{asm} statement as unused.
If you refer to a particular hardware register from the assembler code,
you will probably have to list the register after the third colon to
assembler code, you must write @samp{%%} in the input.
If your assembler instruction can alter the condition code register, add
-@samp{cc} to the list of clobbered registers. GNU CC on some machines
+@samp{cc} to the list of clobbered registers. GCC on some machines
represents the condition codes as a specific hardware register;
@samp{cc} serves to name this register. On other machines, the
condition code is handled differently, and specifying @samp{cc} has no
If your assembler instruction modifies memory in an unpredictable
fashion, add @samp{memory} to the list of clobbered registers. This
-will cause GNU CC to not keep memory values cached in registers across
+will cause GCC to not keep memory values cached in registers across
the assembler instruction. You will also want to add the
@code{volatile} keyword if the memory affected is not listed in the
inputs or outputs of the @code{asm}, as the @samp{memory} clobber does
: "r9", "r10");
@end example
-Unless an output operand has the @samp{&} constraint modifier, GNU CC
+Unless an output operand has the @samp{&} constraint modifier, GCC
may allocate it in the same register as an unrelated input operand, on
the assumption the inputs are consumed before the outputs are produced.
This assumption may be false if the assembler code actually consists of
argument to an @code{int} variable named @code{__arg} would warn about
using a pointer unless the caller explicitly casts it.
-If an @code{asm} has output operands, GNU CC assumes for optimization
+If an @code{asm} has output operands, GCC assumes for optimization
purposes the instruction has no side effects except to change the output
operands. This does not mean instructions with a side effect cannot be
used, but you must be careful, because the compiler may eliminate them
@end example
@noindent
-If you write an @code{asm} instruction with no outputs, GNU CC will know
+If you write an @code{asm} instruction with no outputs, GCC will know
the instruction has side-effects and will not delete the instruction or
move it outside of loops.
It is up to you to make sure that the assembler names you choose do not
conflict with any other assembler symbols. Also, you must not use a
-register name; that would produce completely invalid assembler code. GNU
-CC does not as yet have the ability to store static variables in registers.
+register name; that would produce completely invalid assembler code. GCC
+does not as yet have the ability to store static variables in registers.
Perhaps that will be added.
@node Explicit Reg Vars
leaves the compiler too few available registers to compile certain
functions.
-This option does not guarantee that GNU CC will generate code that has
+This option does not guarantee that GCC will generate code that has
this variable in the register you specify at all times. You may not
code an explicit reference to this register in an @code{asm} statement
and assume it will always refer to this variable.
@cindex @code{__PRETTY_FUNCTION__} identifier
@cindex @code{__func__} identifier
-GNU CC predefines two magic identifiers to hold the name of the current
+GCC predefines two magic identifiers to hold the name of the current
function. The identifier @code{__FUNCTION__} holds the name of the function
as it appears in the source. The identifier @code{__PRETTY_FUNCTION__}
holds the name of the function pretty printed in a language specific
meaning inside a function, since the preprocessor does not do anything
special with the identifier @code{__FUNCTION__}.
-GNU CC also supports the magic word @code{__func__}, defined by the
+GCC also supports the magic word @code{__func__}, defined by the
ISO standard C99:
@display
@end deftypefn
@node Other Builtins
-@section Other built-in functions provided by GNU CC
+@section Other built-in functions provided by GCC
@cindex built-in functions
@findex __builtin_isgreater
@findex __builtin_isgreaterequal
@findex strspn
@findex strstr
-GNU CC provides a large number of built-in functions other than the ones
+GCC provides a large number of built-in functions other than the ones
mentioned above. Some of these are for internal use in the processing
of exceptions or variable-length argument lists and will not be
documented here because they may change from time to time; we do not
The remaining functions are provided for optimization purposes.
@opindex fno-builtin
-GNU CC includes built-in versions of many of the functions in the
+GCC includes built-in versions of many of the functions in the
standard C library. The versions prefixed with @code{__builtin_} will
always be treated as having the same meaning as the C library function
even if you specify the @option{-fno-builtin} (@pxref{C Dialect Options})
@code{__builtin_}, except that the version for @code{sqrt} is called
@code{__builtin_fsqrt}.
-GNU CC provides built-in versions of the ISO C99 floating point
+GCC provides built-in versions of the ISO C99 floating point
comparison macros (that avoid raising exceptions for unordered
operands): @code{__builtin_isgreater}, @code{__builtin_isgreaterequal},
@code{__builtin_isless}, @code{__builtin_islessequal},
@deftypefn {Built-in Function} int __builtin_constant_p (@var{exp})
You can use the built-in function @code{__builtin_constant_p} to
determine if a value is known to be constant at compile-time and hence
-that GNU CC can perform constant-folding on expressions involving that
+that GCC can perform constant-folding on expressions involving that
value. The argument of the function is the value to test. The function
returns the integer 1 if the argument is known to be a compile-time
constant and 0 if it is not known to be a compile-time constant. A
return of 0 does not indicate that the value is @emph{not} a constant,
-but merely that GNU CC cannot prove it is a constant with the specified
+but merely that GCC cannot prove it is a constant with the specified
value of the @option{-O} option.
You would typically use this function in an embedded application where
You may use this built-in function in either a macro or an inline
function. However, if you use it in an inlined function and pass an
-argument of the function as the argument to the built-in, GNU CC will
+argument of the function as the argument to the built-in, GCC will
never return 1 when you call the inline function with a string constant
or compound literal (@pxref{Compound Literals}) and will not return 1
when you pass a constant numeric value to the inline function unless you
@end example
With C, such expressions are rvalues, and as rvalues cause a read of
-the object, gcc interprets this as a read of the volatile being pointed
+the object, GCC interprets this as a read of the volatile being pointed
to. The C++ standard specifies that such expressions do not undergo
lvalue to rvalue conversion, and that the type of the dereferenced
object may be incomplete. The C++ standard does not specify explicitly
that it is this lvalue to rvalue conversion which is responsible for
causing an access. However, there is reason to believe that it is,
because otherwise certain simple expressions become undefined. However,
-because it would surprise most programmers, g++ treats dereferencing a
+because it would surprise most programmers, G++ treats dereferencing a
pointer to volatile object of complete type in a void context as a read
-of the object. When the object has incomplete type, g++ issues a
+of the object. When the object has incomplete type, G++ issues a
warning.
@example
the first case, you must force a conversion to rvalue with, for instance
a static cast, @code{static_cast<S>(*ptr1)}.
-When using a reference to volatile, g++ does not treat equivalent
+When using a reference to volatile, G++ does not treat equivalent
expressions as accesses to volatiles, but instead issues a warning that
no volatile is accessed. The rationale for this is that otherwise it
becomes difficult to determine where volatile access occur, and not
.\" Automatically generated by Pod::Man version 1.16
-.\" Sat Jun 16 09:19:37 2001
+.\" Mon Jun 25 00:14:37 2001
.\"
.\" Standard preamble:
.\" ======================================================================
.\" ======================================================================
.\"
.IX Title "GCC 1"
-.TH GCC 1 "gcc-3.1" "2001-06-16" "GNU"
+.TH GCC 1 "gcc-3.1" "2001-06-25" "GNU"
.UC
.SH "NAME"
gcc \- \s-1GNU\s0 project C and \*(C+ compiler
.Sh "Options Controlling C Dialect"
.IX Subsection "Options Controlling C Dialect"
The following options control the dialect of C (or languages derived
-from C, such as \*(C+ and Objective C) that the compiler accepts:
+from C, such as \*(C+ and Objective-C) that the compiler accepts:
.Ip "\fB\-ansi\fR" 4
.IX Item "-ansi"
In C mode, support all \s-1ISO\s0 C89 programs. In \*(C+ mode,
the output device's aspect (e.g. its width, ...). The options described
below can be used to control the diagnostic messages formatting
algorithm, e.g. how many characters per line, how often source location
-information should be reported. Right now, only the \*(C+ front-end can
+information should be reported. Right now, only the \*(C+ front end can
honor these options. However it is expected, in the near future, that
-the remaining front-ends would be able to digest them correctly.
+the remaining front ends would be able to digest them correctly.
.Ip "\fB\-fmessage-length=\fR\fIn\fR" 4
.IX Item "-fmessage-length=n"
Try to format error messages so that they fit on lines of about \fIn\fR
characters. The default is 72 characters for g++ and 0 for the rest of
-the front-ends supported by \s-1GCC\s0. If \fIn\fR is zero, then no
+the front ends supported by \s-1GCC\s0. If \fIn\fR is zero, then no
line-wrapping will be done; each error message will appear on a single
line.
.Ip "\fB\-fdiagnostics-show-location=once\fR" 4
statement, which in this example is \f(CW\*(C`if (b)\*(C'\fR. This is often not
what the programmer expected, as illustrated in the above example by
indentation the programmer chose. When there is the potential for this
-confusion, \s-1GNU\s0 C will issue a warning when this flag is specified.
+confusion, \s-1GCC\s0 will issue a warning when this flag is specified.
To eliminate the warning, add explicit braces around the innermost
\&\f(CW\*(C`if\*(C'\fR statement so there is no way the \f(CW\*(C`else\*(C'\fR could belong to
the enclosing \f(CW\*(C`if\*(C'\fR. The resulting code would look like this:
.IX Item "-funsafe-math-optimizations"
Allow optimizations for floating-point arithmetic that (a) assume
that arguments and results are valid and (b) may violate \s-1IEEE\s0 or
-\&\s-1ANSI\s0 standards.
+\&\s-1ANSI\s0 standards. When used at link-time, it may include libraries
+or startup files that change the default \s-1FPU\s0 control word or other
+similar optimizations.
.Sp
This option should never be turned on by any \fB\-O\fR option since
it can result in incorrect output for programs which depend on
.Ip "\fB\-lobjc\fR" 4
.IX Item "-lobjc"
You need this special case of the \fB\-l\fR option in order to
-link an Objective C program.
+link an Objective-C program.
.Ip "\fB\-nostartfiles\fR" 4
.IX Item "-nostartfiles"
Do not use the standard system startup files when linking.
a preceding store instruction. Such reordering violates
sequential consistency of volatile memory references, when there
are multiple processors. When consistency must be guaranteed,
-\&\s-1GNU\s0 C generates special instructions, as needed, to force
+\&\s-1GCC\s0 generates special instructions, as needed, to force
execution in the proper order.
.Sp
The \s-1MC88100\s0 processor does not reorder memory references and so
-always provides sequential consistency. However, by default, \s-1GNU\s0
-C generates the special instructions to guarantee consistency
+always provides sequential consistency. However, by default, \s-1GCC\s0
+generates the special instructions to guarantee consistency
even when you use \fB\-m88100\fR, so that the code may be run on an
\&\s-1MC88110\s0 processor. If you intend to run your code only on the
\&\s-1MC88100\s0 processor, you may use \fB\-mno-serialize-volatile\fR.
.Sp
Some models of the \s-1MC88100\s0 processor fail to trap upon integer
division by zero under certain conditions. By default, when
-compiling code that might be run on such a processor, \s-1GNU\s0 C
+compiling code that might be run on such a processor, \s-1GCC\s0
generates code that explicitly checks for zero-valued divisors
and traps with exception number 503 when one is detected. Use of
mno-check-zero-division suppresses such checking for code
generated to run on an \s-1MC88100\s0 processor.
.Sp
-\&\s-1GNU\s0 C assumes that the \s-1MC88110\s0 processor correctly detects all
+\&\s-1GCC\s0 assumes that the \s-1MC88110\s0 processor correctly detects all
instances of integer division by zero. When \fB\-m88110\fR is
specified, both \fB\-mcheck-zero-division\fR and
\&\fB\-mno-check-zero-division\fR are ignored, and no explicit checks for
div) traps to the operating system on a negative operand. The
operating system transparently completes the operation, but at a
large cost in execution time. By default, when compiling code
-that might be run on an \s-1MC88100\s0 processor, \s-1GNU\s0 C emulates signed
+that might be run on an \s-1MC88100\s0 processor, \s-1GCC\s0 emulates signed
integer division using the unsigned integer division instruction
divu), thereby avoiding the large penalty of a trap to the
operating system. Such emulation has its own, smaller, execution
\&\s-1GCC\s0 to make only one \s-1TOC\s0 entry for every file. When you specify this
option, \s-1GCC\s0 will produce code that is slower and larger but which
uses extremely little \s-1TOC\s0 space. You may wish to use this option
-only on files that contain less frequently executed code.
+only on files that contain less frequently executed code.
.Ip "\fB\-maix64\fR" 4
.IX Item "-maix64"
.PD 0
.Ip "\fB\-fexceptions\fR" 4
.IX Item "-fexceptions"
Enable exception handling. Generates extra code needed to propagate
-exceptions. For some targets, this implies \s-1GNU\s0 \s-1CC\s0 will generate frame
+exceptions. For some targets, this implies \s-1GCC\s0 will generate frame
unwind information for all functions, which can produce significant data
size overhead, although it does not affect execution. If you do not
-specify this option, \s-1GNU\s0 \s-1CC\s0 will enable it by default for languages like
+specify this option, \s-1GCC\s0 will enable it by default for languages like
\&\*(C+ which normally require exception handling, and disable it for
languages like C that do not normally require it. However, you may need
to enable this option when compiling C code that needs to interoperate
\&\fB\-fcheck-memory-usage\fR without \fB\-fprefix-function-name\fR.
.Sp
If you specify this option, you can not use the \f(CW\*(C`asm\*(C'\fR or
-\&\f(CW\*(C`_\|_asm_\|_\*(C'\fR keywords in functions with memory checking enabled. \s-1GNU\s0
-\&\s-1CC\s0 cannot understand what the \f(CW\*(C`asm\*(C'\fR statement may do, and therefore
+\&\f(CW\*(C`_\|_asm_\|_\*(C'\fR keywords in functions with memory checking enabled. \s-1GCC\s0
+cannot understand what the \f(CW\*(C`asm\*(C'\fR statement may do, and therefore
cannot generate the appropriate code, so it will reject it. However, if
-you specify the function attribute \f(CW\*(C`no_check_memory_usage\*(C'\fR, \s-1GNU\s0 \s-1CC\s0 will disable memory checking within a
+you specify the function attribute \f(CW\*(C`no_check_memory_usage\*(C'\fR, \s-1GCC\s0 will disable memory checking within a
function; you may use \f(CW\*(C`asm\*(C'\fR statements inside such functions. You
may have an inline expansion of a non-checked function within a checked
-function; in that case \s-1GNU\s0 \s-1CC\s0 will not generate checks for the inlined
+function; in that case \s-1GCC\s0 will not generate checks for the inlined
function's memory accesses.
.Sp
If you move your \f(CW\*(C`asm\*(C'\fR statements to non-checked inline functions
when this prefix is combined with the name of a subprogram, but you can
specify a prefix that ends with a slash if you wish.
.Sp
-If \fB\s-1GCC_EXEC_PREFIX\s0\fR is not set, \s-1GNU\s0 \s-1CC\s0 will attempt to figure out
+If \fB\s-1GCC_EXEC_PREFIX\s0\fR is not set, \s-1GCC\s0 will attempt to figure out
an appropriate prefix to use based on the pathname it was invoked with.
.Sp
If \s-1GCC\s0 cannot find the subprogram using the specified prefix, it
@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.
+@c - "GCC" for the GNU Compiler Collection, both generally
+@c and as the GNU C Compiler in the context of compiling C;
+@c "G++" for the C++ compiler; "gcc" and "g++" (lowercase),
+@c marked up with @command, for the commands for compilation when the
+@c emphasis is on those; "GNU C" and "GNU C++" for language dialects;
+@c and try to avoid the older term "GNU CC".
@macro gcctabopt{body}
@code{\body\}
in a hosted implementation.
@opindex ffreestanding
-GNU CC aims towards being usable as a conforming freestanding
+GCC aims towards being usable as a conforming freestanding
implementation, or as the compiler for a conforming hosted
implementation. By default, it will act as the compiler for a hosted
implementation, defining @code{__STDC_HOSTED__} as @code{1} and
linking and startup. @xref{C Dialect Options,,Options Controlling C
Dialect}.
-GNU CC does not provide the library facilities required only of hosted
+GCC does not provide the library facilities required only of hosted
implementations, nor yet all the facilities required by C99 of
freestanding implementations; to use the facilities of a hosted
environment, you will need to find them elsewhere (for example, in the
and with certain linkers, assemblers and debuggers.
* External Bugs:: Problems compiling certain programs.
* Incompatibilities:: GCC is incompatible with traditional C.
-* Fixed Headers:: GNU C uses corrected versions of system header files.
+* Fixed Headers:: GCC uses corrected versions of system header files.
This is necessary, but doesn't always work smoothly.
-* Standard Libraries:: GNU C uses the system C library, which might not be
+* Standard Libraries:: GCC uses the system C library, which might not be
compliant with the ISO C standard.
* Disappointments:: Regrettable things we can't change, but not quite bugs.
* C++ Misunderstandings:: Common misunderstandings with GNU C++.
@node Interoperation
@section Interoperation
-This section lists various difficulties encountered in using GNU C or
-GNU C++ together with other compilers or with the assemblers, linkers,
+This section lists various difficulties encountered in using GCC
+together with other compilers or with the assemblers, linkers,
libraries and debuggers on certain systems.
@itemize @bullet
Objective-C does not work on the RS/6000.
@item
-GNU C++ does not do name mangling in the same way as other C++
+G++ does not do name mangling in the same way as other C++
compilers. This means that object files compiled with one compiler
cannot be used with another.
@code{double *} to a function compiled with GCC, dereferencing the
pointer may cause a fatal signal.
-One way to solve this problem is to compile your entire program with GNU
-CC. Another solution is to modify the function that is compiled with
+One way to solve this problem is to compile your entire program with GCC.
+Another solution is to modify the function that is compiled with
Sun CC to copy the argument into a local variable; local variables
are always properly aligned. A third solution is to modify the function
that uses the pointer to dereference it via the following function
There are several noteworthy incompatibilities between GNU C and K&R
(non-ISO) versions of C. The @option{-traditional} option
eliminates many of these incompatibilities, @emph{but not all}, by
-telling GNU C to behave like a K&R C compiler.
+telling GCC to behave like a K&R C compiler.
@itemize @bullet
@cindex string constants
If you use the @option{-W} option with the @option{-O} option, you will
get a warning when GCC thinks such a problem might be possible.
-The @option{-traditional} option directs GNU C to put variables in
+The @option{-traditional} option directs GCC to put variables in
the stack by default, rather than in registers, in functions that
call @code{setjmp}. This results in the behavior found in
traditional C compilers.
In some other C compilers, a @code{extern} declaration affects all the
rest of the file even if it happens within a block.
-The @option{-traditional} option directs GNU C to treat all @code{extern}
+The @option{-traditional} option directs GCC to treat all @code{extern}
declarations as global, like traditional compilers.
@item
@cindex preprocessing tokens
@cindex preprocessing numbers
@item
-GNU C complains about program fragments such as @samp{0x74ae-0x4000}
+GCC complains about program fragments such as @samp{0x74ae-0x4000}
which appear to be two hexadecimal constants separated by the minus
operator. Actually, this string is a single @dfn{preprocessing token}.
Each such token must correspond to one token in C. Since this does not,
-GNU C prints an error message. Although it may appear obvious that what
+GCC prints an error message. Although it may appear obvious that what
is meant is an operator and two values, the ISO C standard specifically
requires that this be treated as erroneous.
Please follow these guidelines so we can study your patches efficiently.
If you don't follow these guidelines, your information might still be
-useful, but using it will take extra work. Maintaining GNU C is a lot
+useful, but using it will take extra work. Maintaining GCC is a lot
of work in the best of circumstances, and we can't keep up unless you do
your best to help.
but is not portable to other systems. The compiler option @samp{/NAMES}
also provides control over global name handling.
-Function and variable names are handled somewhat differently with GNU
-C++. The GNU C++ compiler performs @dfn{name mangling} on function
+Function and variable names are handled somewhat differently with G++.
+The GNU C++ compiler performs @dfn{name mangling} on function
names, which means that it adds information to the function name to
describe the data types of the arguments that the function takes. One
result of this is that the name of a function can become very long.
.\" Automatically generated by Pod::Man version 1.16
-.\" Thu Jun 14 10:58:24 2001
+.\" Mon Jun 25 00:14:36 2001
.\"
.\" Standard preamble:
.\" ======================================================================
.\" ======================================================================
.\"
.IX Title "GCOV 1"
-.TH GCOV 1 "gcc-3.1" "2001-06-14" "GNU"
+.TH GCOV 1 "gcc-3.1" "2001-06-25" "GNU"
.UC
.SH "NAME"
gcov \- coverage testing tool
gcov [\fB\-b\fR] [\fB\-c\fR] [\fB\-v\fR] [\fB\-n\fR] [\fB\-l\fR] [\fB\-f\fR] [\fB\-o\fR \fIdirectory\fR] \fIsourcefile\fR
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
-\&\fBgcov\fR is a test coverage program. Use it in concert with \s-1GNU\s0
-\&\s-1CC\s0 to analyze your programs to help create more efficient, faster
+\&\fBgcov\fR is a test coverage program. Use it in concert with \s-1GCC\s0
+to analyze your programs to help create more efficient, faster
running code. You can use \fBgcov\fR as a profiling tool to help
discover where your optimization efforts will best affect your code. You
can also use \fBgcov\fR along with the other profiling tool,
timing information you can use along with the information you get from
\&\fBgcov\fR.
.PP
-\&\fBgcov\fR works only on code compiled with \s-1GNU\s0 \s-1CC\s0. It is not
+\&\fBgcov\fR works only on code compiled with \s-1GCC\s0. It is not
compatible with any other profiling or test coverage mechanism.
.SH "OPTIONS"
.IX Header "OPTIONS"
\&\fI.bbg\fR, and \fI.da\fR files in this directory.
.PP
When using \fBgcov\fR, you must first compile your program with two
-special \s-1GNU\s0 \s-1CC\s0 options: \fB\-fprofile-arcs \-ftest-coverage\fR.
+special \s-1GCC\s0 options: \fB\-fprofile-arcs \-ftest-coverage\fR.
This tells the compiler to generate additional information needed by
gcov (basically a flow graph of the program) and also includes
additional code in the object files for generating the extra profiling
.Sh "Using \fBgcov\fP with \s-1GCC\s0 Optimization"
.IX Subsection "Using gcov with GCC Optimization"
If you plan to use \fBgcov\fR to help optimize your code, you must
-first compile your program with two special \s-1GNU\s0 \s-1CC\s0 options:
+first compile your program with two special \s-1GCC\s0 options:
\&\fB\-fprofile-arcs \-ftest-coverage\fR. Aside from that, you can use any
-other \s-1GNU\s0 \s-1CC\s0 options; but if you want to prove that every single line
+other \s-1GCC\s0 options; but if you want to prove that every single line
in your program was executed, you should not compile with optimization
at the same time. On some machines the optimizer can eliminate some
simple code lines by combining them with other lines. For example, code
@node Gcov
@chapter @command{gcov}: a Test Coverage Program
-@command{gcov} is a tool you can use in conjunction with @sc{gnu} CC to
+@command{gcov} is a tool you can use in conjunction with GCC to
test code coverage in your programs.
This chapter describes version 1.5 of @command{gcov}.
@section Introduction to @command{gcov}
@c man begin DESCRIPTION
-@command{gcov} is a test coverage program. Use it in concert with @sc{gnu}
-CC to analyze your programs to help create more efficient, faster
+@command{gcov} is a test coverage program. Use it in concert with GCC
+to analyze your programs to help create more efficient, faster
running code. You can use @command{gcov} as a profiling tool to help
discover where your optimization efforts will best affect your code. You
can also use @command{gcov} along with the other profiling tool,
timing information you can use along with the information you get from
@command{gcov}.
-@command{gcov} works only on code compiled with @sc{gnu} CC. It is not
+@command{gcov} works only on code compiled with GCC. It is not
compatible with any other profiling or test coverage mechanism.
@c man end
@need 3000
When using @command{gcov}, you must first compile your program with two
-special @sc{gnu} CC options: @samp{-fprofile-arcs -ftest-coverage}.
+special GCC options: @samp{-fprofile-arcs -ftest-coverage}.
This tells the compiler to generate additional information needed by
gcov (basically a flow graph of the program) and also includes
additional code in the object files for generating the extra profiling
@section Using @command{gcov} with GCC Optimization
If you plan to use @command{gcov} to help optimize your code, you must
-first compile your program with two special @sc{gnu} CC options:
+first compile your program with two special GCC options:
@samp{-fprofile-arcs -ftest-coverage}. Aside from that, you can use any
-other @sc{gnu} CC options; but if you want to prove that every single line
+other GCC options; but if you want to prove that every single line
in your program was executed, you should not compile with optimization
at the same time. On some machines the optimizer can eliminate some
simple code lines by combining them with other lines. For example, code
contain data stored in a platform-independent method.
The @file{.bb} and @file{.bbg} files are generated when the source file
-is compiled with the @sc{gnu} CC @option{-ftest-coverage} option. The
+is compiled with the GCC @option{-ftest-coverage} option. The
@file{.bb} file contains a list of source files (including headers),
functions within those files, and line numbers corresponding to each
basic block in the source file.
correctly.
The @file{.da} file is generated when a program containing object files
-built with the @sc{gnu} CC @option{-fprofile-arcs} option is executed. A
+built with the GCC @option{-fprofile-arcs} option is executed. A
separate @file{.da} file is created for each source file compiled with
this option, and the name of the @file{.da} file is stored as an
absolute pathname in the resulting object file. This path name is
@settitle Installing GCC: Binaries
@end ifset
-@comment $Id: install.texi,v 1.32 2001/06/21 19:00:08 pme Exp $
+@comment $Id: install.texi,v 1.33 2001/06/23 23:41:59 jsm28 Exp $
@c Copyright (C) 2001 Free Software Foundation, Inc.
@c *** Converted to texinfo by Dean Wakerley, dean@wakerley.com
get extensive testing; building where @var{objdir} is a subdirectory
of @var{srcdir} is unsupported.
-If you have built GNU CC previously in the same directory for a
+If you have built GCC previously in the same directory for a
different target machine, do @samp{make distclean} to delete all files
that might be invalid. One of the files this deletes is
@file{Makefile}; if @samp{make distclean} complains that @file{Makefile}
internal consistency checks. This does not change the generated code,
but adds error checking within the compiler. This will slow down the
compiler and may only work properly if you are building the compiler
-with GNU C. This is on by default when building from CVS or snapshots,
+with GCC. This is on by default when building from CVS or snapshots,
but off for releases. More control over the checks may be had by
specifying @var{list}; the categories of checks available are
@samp{misc}, @samp{tree}, @samp{gc}, @samp{rtl} and @samp{gcac}. The
The @code{as1750} assembler requires the file @file{ms1750.inc}, which is
found in the directory @file{config/1750a}.
-GNU CC produced the same sections as the Fairchild F9450 C Compiler,
+GCC produced the same sections as the Fairchild F9450 C Compiler,
namely:
@table @code
The smallest addressable unit is 16 bits (BITS_PER_UNIT is 16). This
means that type @code{char} is represented with a 16-bit word per character.
The 1750A's ``Load/Store Upper/Lower Byte'' instructions are not used by
-GNU CC.
+GCC.
@html
</p>
% CC=gcc -Wa,-oldas @var{srcdir}/configure [@var{target}] [@var{options}]
@end example
-GNU CC writes a @samp{.verstamp} directive to the assembler output file
+GCC writes a @samp{.verstamp} directive to the assembler output file
unless it is built as a cross-compiler. It gets the version to use from
the system header file @file{/usr/include/stamp.h}. If you install a
new version of DEC Unix, you should rebuild GCC to pick up the new version
@option{-save-temps}, you will have to manually delete the @samp{.i} and
@samp{.s} files after each series of compilations.
-GNU CC now supports both the native (ECOFF) debugging format used by DBX
+GCC now supports both the native (ECOFF) debugging format used by DBX
and GDB and an encapsulated STABS format for use only with GDB. See the
discussion of the @option{--with-stabs} option of @file{configure} above
for more information on these formats and how to select them.
There is a bug in DEC's assembler that produces incorrect line numbers
for ECOFF format when the @samp{.align} directive is used. To work
-around this problem, GNU CC will not emit such alignment directives
+around this problem, GCC will not emit such alignment directives
while writing ECOFF format debugging information even if optimization is
being performed. Unfortunately, this has the very undesirable
side-effect that code addresses when @option{-O} is specified are
Please have a look at our @uref{binaries.html,,binaries page}.
-You cannot install GNU C by itself on MSDOS; it will not compile under
+You cannot install GCC by itself on MSDOS; it will not compile under
any MSDOS compiler except itself. You need to get the complete
compilation package DJGPP, which includes binaries as well as sources,
and includes all the necessary compilation tools and libraries.
@end html
@heading @anchor{elxsi-elxsi-bsd}elxsi-elxsi-bsd
The Elxsi's C compiler has known limitations that prevent it from
-compiling GNU C. Please contact @email{mrs@@cygnus.com} for more details.
+compiling GCC. Please contact @email{mrs@@cygnus.com} for more details.
@html
</p>
<hr>
@end html
@heading @anchor{*-lynx-lynxos}*-lynx-lynxos
-LynxOS 2.2 and earlier comes with GNU CC 1.x already installed as
+LynxOS 2.2 and earlier comes with GCC 1.x already installed as
@file{/bin/gcc}. You should compile with this instead of @file{/bin/cc}.
-You can tell GNU CC to use the GNU assembler and linker, by specifying
+You can tell GCC to use the GNU assembler and linker, by specifying
@samp{--with-gnu-as --with-gnu-ld} when configuring. These will produce
-COFF format object files and executables; otherwise GNU CC will use the
+COFF format object files and executables; otherwise GCC will use the
installed tools, which produce @file{a.out} format executables.
@html
@end html
@heading @anchor{m68000-hp-bsd}m68000-hp-bsd
HP 9000 series 200 running BSD. Note that the C compiler that comes
-with this system cannot compile GNU CC; contact @email{law@@cygnus.com}
-to get binaries of GNU CC for bootstrapping.
+with this system cannot compile GCC; contact @email{law@@cygnus.com}
+to get binaries of GCC for bootstrapping.
@html
</p>
Apple Macintosh running A/UX.
You may configure GCC to use either the system assembler and
linker or the GNU assembler and linker. You should use the GNU configuration
-if you can, especially if you also want to use GNU C++. You enabled
+if you can, especially if you also want to use G++. You enabled
that configuration with + the @option{--with-gnu-as} and @option{--with-gnu-ld}
options to @code{configure}.
Note the C compiler that comes
-with this system cannot compile GNU CC. You can find binaries of GNU CC
+with this system cannot compile GCC. You can find binaries of GCC
for bootstrapping on @code{jagubox.gsfc.nasa.gov}.
You will also a patched version of @file{/bin/ld} there that
raises some of the arbitrary limits found in the original.
<hr>
@end html
@heading @anchor{m68k-att-sysv}m68k-att-sysv
-AT&T 3b1, a.k.a. 7300 PC. This version of GNU CC cannot
+AT&T 3b1, a.k.a. 7300 PC. This version of GCC cannot
be compiled with the system C compiler, which is too buggy.
You will need to get a previous version of GCC and use it to
bootstrap. Binaries are available from the OSU-CIS archive, at
<hr>
@end html
@heading @anchor{m68k-bull-sysv}m68k-bull-sysv
-Bull DPX/2 series 200 and 300 with BOS-2.00.45 up to BOS-2.01. GNU CC works
+Bull DPX/2 series 200 and 300 with BOS-2.00.45 up to BOS-2.01. GCC works
either with native assembler or GNU assembler. You can use
GNU assembler with native coff generation by providing @option{--with-gnu-as} to
the configure script or use GNU assembler with dbx-in-coff encapsulation
The Unos assembler is named @code{casm} instead of @code{as}. For some
strange reason linking @file{/bin/as} to @file{/bin/casm} changes the
-behavior, and does not work. So, when installing GNU CC, you should
+behavior, and does not work. So, when installing GCC, you should
install the following script as @file{as} in the subdirectory where
the passes of GCC are installed:
@end example
The default Unos library is named @file{libunos.a} instead of
-@file{libc.a}. To allow GNU CC to function, either change all
+@file{libc.a}. To allow GCC to function, either change all
references to @option{-lc} in @file{gcc.c} to @option{-lunos} or link
@file{/lib/libc.a} to @file{/lib/libunos.a}.
@cindex @code{alloca}, for Unos
-When compiling GNU CC with the standard compiler, to overcome bugs in
+When compiling GCC with the standard compiler, to overcome bugs in
the support of @code{alloca}, do not use @option{-O} when making stage 2.
Then use the stage 2 compiler with @option{-O} to make the stage 3
compiler. This compiler will have the same characteristics as the usual
@end html
@heading @anchor{m68k-hp-hpux}m68k-hp-hpux
HP 9000 series 300 or 400 running HP-UX. HP-UX version 8.0 has a bug in
-the assembler that prevents compilation of GNU CC. This
+the assembler that prevents compilation of GCC. This
bug manifests itself during the first stage of compilation, while
building @file{libgcc2.a}:
suggests you encountered a problem with the standard C compiler; the
stage 3 and 4 compilers may be usable.
-It is best, however, to use an older version of GNU CC for bootstrapping
+It is best, however, to use an older version of GCC for bootstrapping
if you have one.
@html
The @option{-noasmopt} option can be useful for testing whether a problem
is due to erroneous assembler reordering. Even if a problem does not go
away with @option{-noasmopt}, it may still be due to assembler
-reordering---perhaps GNU CC itself was miscompiled as a result.
+reordering---perhaps GCC itself was miscompiled as a result.
To enable debugging under Irix 5, you must use GNU as 2.5 or later,
and use the @option{--with-gnu-as} configure option when configuring gcc.
@end html
@heading @anchor{ns32k-utek}ns32k-utek
UTEK ns32000 system (``merlin''). The C compiler that comes with this
-system cannot compile GNU CC; contact @samp{tektronix!reed!mason} to get
-binaries of GNU CC for bootstrapping.
+system cannot compile GCC; contact @samp{tektronix!reed!mason} to get
+binaries of GCC for bootstrapping.
@html
@end html
@heading @anchor{romp-*-aos}romp-*-aos, romp-*-mach
The only operating systems supported for the IBM RT PC are AOS and
-MACH. GNU CC does not support AIX running on the RT. We recommend you
-compile GNU CC with an earlier version of itself; if you compile GNU CC
+MACH. GCC does not support AIX running on the RT. We recommend you
+compile GCC with an earlier version of itself; if you compile GCC
with @code{hc}, the Metaware compiler, it will work, but you will get
mismatches between the stage 2 and stage 3 compilers in various files.
These errors are minor differences in some floating-point constants and
debugging information.
The system's compiler runs out of capacity when compiling @file{stmt.c}
-in GNU CC. You can work around this by building @file{cpp} in GNU CC
+in GCC. You can work around this by building @file{cpp} in GCC
first, then use that instead of the system's preprocessor with the
system's C compiler to compile @file{stmt.c}. Here is how:
chmod +x /lib/cpp
@end smallexample
-The system's compiler produces bad code for some of the GNU CC
+The system's compiler produces bad code for some of the GCC
optimization files. So you must build the stage 2 compiler without
optimization. Then build a stage 3 compiler with optimization.
That executable should work. Here are the necessary commands:
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
+built-in functions provided by GCC}, for details of the functions
affected.
@item -std=
@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,
+functions provided by GCC}, for details of the functions affected,
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.
statement, which in this example is @code{if (b)}. This is often not
what the programmer expected, as illustrated in the above example by
indentation the programmer chose. When there is the potential for this
-confusion, GNU C will issue a warning when this flag is specified.
+confusion, GCC will issue a warning when this flag is specified.
To eliminate the warning, add explicit braces around the innermost
@code{if} statement so there is no way the @code{else} could belong to
the enclosing @code{if}. The resulting code would look like this:
a preceding store instruction. Such reordering violates
sequential consistency of volatile memory references, when there
are multiple processors. When consistency must be guaranteed,
-GNU C generates special instructions, as needed, to force
+GCC generates special instructions, as needed, to force
execution in the proper order.
The MC88100 processor does not reorder memory references and so
-always provides sequential consistency. However, by default, GNU
-C generates the special instructions to guarantee consistency
+always provides sequential consistency. However, by default, GCC
+generates the special instructions to guarantee consistency
even when you use @option{-m88100}, so that the code may be run on an
MC88110 processor. If you intend to run your code only on the
MC88100 processor, you may use @option{-mno-serialize-volatile}.
Some models of the MC88100 processor fail to trap upon integer
division by zero under certain conditions. By default, when
-compiling code that might be run on such a processor, GNU C
+compiling code that might be run on such a processor, GCC
generates code that explicitly checks for zero-valued divisors
and traps with exception number 503 when one is detected. Use of
mno-check-zero-division suppresses such checking for code
generated to run on an MC88100 processor.
-GNU C assumes that the MC88110 processor correctly detects all
+GCC assumes that the MC88110 processor correctly detects all
instances of integer division by zero. When @option{-m88110} is
specified, both @option{-mcheck-zero-division} and
@option{-mno-check-zero-division} are ignored, and no explicit checks for
div) traps to the operating system on a negative operand. The
operating system transparently completes the operation, but at a
large cost in execution time. By default, when compiling code
-that might be run on an MC88100 processor, GNU C emulates signed
+that might be run on an MC88100 processor, GCC emulates signed
integer division using the unsigned integer division instruction
divu), thereby avoiding the large penalty of a trap to the
operating system. Such emulation has its own, smaller, execution
@item -fexceptions
@opindex fexceptions
Enable exception handling. Generates extra code needed to propagate
-exceptions. For some targets, this implies GNU CC will generate frame
+exceptions. For some targets, this implies GCC will generate frame
unwind information for all functions, which can produce significant data
size overhead, although it does not affect execution. If you do not
-specify this option, GNU CC will enable it by default for languages like
+specify this option, GCC will enable it by default for languages like
C++ which normally require exception handling, and disable it for
languages like C that do not normally require it. However, you may need
to enable this option when compiling C code that needs to interoperate
@option{-fcheck-memory-usage} without @option{-fprefix-function-name}.
If you specify this option, you can not use the @code{asm} or
-@code{__asm__} keywords in functions with memory checking enabled. GNU
-CC cannot understand what the @code{asm} statement may do, and therefore
+@code{__asm__} keywords in functions with memory checking enabled. GCC
+cannot understand what the @code{asm} statement may do, and therefore
cannot generate the appropriate code, so it will reject it. However, if
you specify the function attribute @code{no_check_memory_usage}
-(@pxref{Function Attributes}), GNU CC will disable memory checking within a
+(@pxref{Function Attributes}), GCC will disable memory checking within a
function; you may use @code{asm} statements inside such functions. You
may have an inline expansion of a non-checked function within a checked
-function; in that case GNU CC will not generate checks for the inlined
+function; in that case GCC will not generate checks for the inlined
function's memory accesses.
If you move your @code{asm} statements to non-checked inline functions
when this prefix is combined with the name of a subprogram, but you can
specify a prefix that ends with a slash if you wish.
-If @env{GCC_EXEC_PREFIX} is not set, GNU CC will attempt to figure out
+If @env{GCC_EXEC_PREFIX} is not set, GCC will attempt to figure out
an appropriate prefix to use based on the pathname it was invoked with.
If GCC cannot find the subprogram using the specified prefix, it
@node Running Protoize
@section Running Protoize
-The program @code{protoize} is an optional part of GNU C. You can use
+The program @code{protoize} is an optional part of GCC. You can use
it to add prototypes to a program, thus converting the program to ISO
C in one respect. The companion program @code{unprotoize} does the
reverse: it removes argument types from any prototypes that are found.
For an operand that must be a register, @var{predicate} should be
@code{"register_operand"}. Using @code{"general_operand"} would be
valid, since the reload pass would copy any non-register operands
-through registers, but this would make GNU CC do extra work, it would
+through registers, but this would make GCC do extra work, it would
prevent invariant operands (such as constant) from being removed from
loops, and it would prevent the register allocator from doing the best
possible job. On RISC machines, it is usually most efficient to allow
and the last is the address of the label, to be placed in the
location for the incoming static chain.
-On most machines you need not define this pattern, since GNU CC will
+On most machines you need not define this pattern, since GCC will
already generate the correct code, which is to load the frame pointer
and static chain, restore the stack (using the
@samp{restore_stack_nonlocal} pattern, if defined), and jump indirectly
@cindex @code{nonlocal_goto_receiver} instruction pattern
@item @samp{nonlocal_goto_receiver}
This pattern, if defined, contains code needed at the target of a
-nonlocal goto after the code already generated by GNU CC. You will not
+nonlocal goto after the code already generated by GCC. 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 when the frame pointer is restored. Note that a nonlocal
@cindex jump instruction patterns
@cindex defining jump instruction patterns
-For most machines, GNU CC assumes that the machine has a condition code.
+For most machines, GCC assumes that the machine has a condition code.
A comparison insn sets the condition code, recording the results of both
signed and unsigned comparison of the given operands. A separate branch
insn tests the condition code and branches or not according its value.
otherwise output a signed compare. When the branch itself is output, you
can treat signed and unsigned branches identically.
-The reason you can do this is that GNU CC always generates a pair of
+The reason you can do this is that GCC always generates a pair of
consecutive RTL insns, possibly separated by @code{note} insns, one to
set the condition code and one to test it, and keeps the pair inviolate
until the end.
@samp{dbra}-like instruction and avoids pipeline stalls associated with
the jump.
-GNU CC has three special named patterns to support low overhead looping,
+GCC has three special named patterns to support low overhead looping,
@samp{decrement_and_branch_until_zero}, @samp{doloop_begin}, and
@samp{doloop_end}. The first pattern,
@samp{decrement_and_branch_until_zero}, is not emitted during RTL
@item
The condition, a string containing a C expression. This expression is
used to express how the availability of this pattern depends on
-subclasses of target machine, selected by command-line options when GNU
-CC is run. This is just like the condition of a @code{define_insn} that
+subclasses of target machine, selected by command-line options when GCC
+is run. This is just like the condition of a @code{define_insn} that
has a standard name. Therefore, the condition (if present) may not
depend on the data in the insn being matched, but only the
target-machine-type flags. The compiler needs to test these conditions
A true operand, which needs to be specified in order to generate RTL from
the pattern, should be described with a @code{match_operand} in its first
occurrence in the RTL template. This enters information on the operand's
-predicate into the tables that record such things. GNU CC uses the
+predicate into the tables that record such things. GCC uses the
information to preload the operand into a register if that is required for
valid RTL code. If the operand is referred to more than once, subsequent
references should use @code{match_dup}.
@item CONSTANT_POOL_ADDRESS_P (@var{x})
Nonzero in a @code{symbol_ref} if it refers to part of the current
function's ``constants pool''. These are addresses close to the
-beginning of the function, and GNU CC assumes they can be addressed
+beginning of the function, and GCC assumes they can be addressed
directly (perhaps with the help of base registers). Stored in the
@code{unchanging} field and printed as @samp{/u}.
@item (const_double:@var{m} @var{addr} @var{i0} @var{i1} @dots{})
Represents either a floating-point constant of mode @var{m} or an
integer constant too large to fit into @code{HOST_BITS_PER_WIDE_INT}
-bits but small enough to fit within twice that number of bits (GNU CC
+bits but small enough to fit within twice that number of bits (GCC
does not provide a mechanism to represent even larger constants). In
the latter case, @var{m} will be @code{VOIDmode}.
the inputs unless the @samp{&} constraint is specified for the selected
alternative (@pxref{Modifiers}). You can clobber either a specific hard
register, a pseudo register, or a @code{scratch} expression; in the
-latter two cases, GNU CC will allocate a hard register that is available
+latter two cases, GCC will allocate a hard register that is available
there for use as a temporary.
For instructions that require a temporary register, you should use
compiler.
People frequently have the idea of using RTL stored as text in a file as
-an interface between a language front end and the bulk of GNU CC. This
+an interface between a language front end and the bulk of GCC. This
idea is not feasible.
-GNU CC was designed to use RTL internally only. Correct RTL for a given
+GCC was designed to use RTL internally only. Correct RTL for a given
program is very dependent on the particular target machine. And the RTL
does not contain all the information about the program.
-The proper way to interface GNU CC to a new language front end is with
+The proper way to interface GCC to a new language front end is with
the ``tree'' data structure, described in the files @file{tree.h} and
@file{tree.def}. The documentation for this structure (@pxref{Trees})
is incomplete.
@end example
You must provide this macro on machines where the addresses in a
-dispatch table are relative to the table's own address. If defined, GNU
-CC will also use this macro on all machines when producing PIC.
+dispatch table are relative to the table's own address. If defined, GCC
+will also use this macro on all machines when producing PIC.
@var{body} is the body of the ADDR_DIFF_VEC; it is provided so that the
mode and flags can be read.
@item DBX_BLOCKS_FUNCTION_RELATIVE
Define this macro if the value of a symbol describing the scope of a
block (@code{N_LBRAC} or @code{N_RBRAC}) should be relative to the start
-of the enclosing function. Normally, GNU C uses an absolute address.
+of the enclosing function. Normally, GCC uses an absolute address.
@findex DBX_USE_BINCL
@item DBX_USE_BINCL
-Define this macro if GNU C should generate @code{N_BINCL} and
+Define this macro if GCC should generate @code{N_BINCL} and
@code{N_EINCL} stabs for included header files, as on Sun systems. This
-macro also directs GNU C to output a type number as a pair of a file
-number and a type number within the file. Normally, GNU C does not
+macro also directs GCC to output a type number as a pair of a file
+number and a type number within the file. Normally, GCC does not
generate @code{N_BINCL} or @code{N_EINCL} stabs, and it outputs a single
number for a type number.
@end table
projects / gcc.git / commitdiff