contrib.texi, [...]: Capitalize "gcc", "g++" and "g77" or mark up with appropriate markup.
* doc/contrib.texi, doc/extend.texi, doc/gcov.texi, doc/install.texi, doc/invoke.texi, doc/makefile.texi, doc/sourcebuild.texi, doc/tm.texi, doc/trouble.texi: Capitalize "gcc", "g++" and "g77" or mark up with appropriate markup. Adjust wording and grammar. From-SVN: r79482
This commit is contained in:
parent
ae2bcd98fa
commit
2dd7696088
@ -1,3 +1,11 @@
|
||||
2004-03-14 Joseph S. Myers <jsm@polyomino.org.uk>
|
||||
|
||||
* doc/contrib.texi, doc/extend.texi, doc/gcov.texi,
|
||||
doc/install.texi, doc/invoke.texi, doc/makefile.texi,
|
||||
doc/sourcebuild.texi, doc/tm.texi, doc/trouble.texi: Capitalize
|
||||
"gcc", "g++" and "g77" or mark up with appropriate markup. Adjust
|
||||
wording and grammar.
|
||||
|
||||
2004-03-14 Roger Sayle <roger@eyesopen.com>
|
||||
|
||||
* alias.c (get_alias_set): Replace calls via (*lang_hooks.foo) ()
|
||||
|
@ -197,7 +197,7 @@ DJ Delorie for the DJGPP port, build and libiberty maintenance, and
|
||||
various bug fixes.
|
||||
|
||||
@item
|
||||
Gabriel Dos Reis for contributions to g++, contributions and
|
||||
Gabriel Dos Reis for contributions to G++, contributions and
|
||||
maintenance of GCC diagnostics infrastructure, libstdc++-v3,
|
||||
including valarray<>, complex<>, maintaining the numerics library
|
||||
(including that pesky <limits> :-) and keeping up-to-date anything
|
||||
@ -319,7 +319,7 @@ fixes.
|
||||
Dara Hazeghi for wading through myriads of target-specific bug reports.
|
||||
|
||||
@item
|
||||
Kate Hedstrom for staking the g77 folks with an initial testsuite.
|
||||
Kate Hedstrom for staking the G77 folks with an initial testsuite.
|
||||
|
||||
@item
|
||||
Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 work, loop
|
||||
@ -401,7 +401,7 @@ Geoffrey Keating for his ongoing work to make the PPC work for GNU/Linux
|
||||
and his automatic regression tester.
|
||||
|
||||
@item
|
||||
Brendan Kehoe for his ongoing work with g++ and for a lot of early work
|
||||
Brendan Kehoe for his ongoing work with G++ and for a lot of early work
|
||||
in just about every part of libstdc++.
|
||||
|
||||
@item
|
||||
@ -437,7 +437,7 @@ Thomas Koenig for various bug fixes.
|
||||
Bruce Korb for the new and improved fixincludes code.
|
||||
|
||||
@item
|
||||
Benjamin Kosnik for his g++ work and for leading the libstdc++-v3 effort.
|
||||
Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 effort.
|
||||
|
||||
@item
|
||||
Charles LaBrec contributed the support for the Integrated Solutions
|
||||
@ -527,7 +527,7 @@ powerpc, haifa, ECOFF debug support, and other assorted hacking.
|
||||
|
||||
@item
|
||||
Jason Merrill for his direction via the steering committee and leading
|
||||
the g++ effort.
|
||||
the G++ effort.
|
||||
|
||||
@item
|
||||
David Miller for his direction via the steering committee, lots of
|
||||
@ -778,7 +778,7 @@ testsuite entries.
|
||||
Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique.
|
||||
|
||||
@item
|
||||
Richard Stallman, for writing the original gcc and launching the GNU project.
|
||||
Richard Stallman, for writing the original GCC and launching the GNU project.
|
||||
|
||||
@item
|
||||
Jan Stein of the Chalmers Computer Society provided support for
|
||||
@ -797,7 +797,7 @@ Graham Stott for various infrastructure improvements.
|
||||
John Stracke for his Java HTTP protocol fixes.
|
||||
|
||||
@item
|
||||
Mike Stump for his Elxsi port, g++ contributions over the years and more
|
||||
Mike Stump for his Elxsi port, G++ contributions over the years and more
|
||||
recently his vxworks contributions
|
||||
|
||||
@item
|
||||
|
@ -1769,7 +1769,7 @@ struct point ptarray[10] = @{ [2].y = yv2, [2].x = xv2, [0].x = xv0 @};
|
||||
If the same field is initialized multiple times, it will have value from
|
||||
the last initialization. If any such overridden initialization has
|
||||
side-effect, it is unspecified whether the side-effect happens or not.
|
||||
Currently, gcc will discard them and issue a warning.
|
||||
Currently, GCC will discard them and issue a warning.
|
||||
|
||||
@node Case Ranges
|
||||
@section Case Ranges
|
||||
@ -2323,11 +2323,11 @@ by another module.
|
||||
@item internal
|
||||
Internal visibility is like hidden visibility, but with additional
|
||||
processor specific semantics. Unless otherwise specified by the psABI,
|
||||
gcc defines internal visibility to mean that the function is @emph{never}
|
||||
GCC defines internal visibility to mean that the function is @emph{never}
|
||||
called from another module. Note that hidden symbols, while they cannot
|
||||
be referenced directly by other modules, can be referenced indirectly via
|
||||
function pointers. By indicating that a symbol cannot be called from
|
||||
outside the module, gcc may for instance omit the load of a PIC register
|
||||
outside the module, GCC may for instance omit the load of a PIC register
|
||||
since it is known that the calling function loaded the correct value.
|
||||
@end table
|
||||
|
||||
@ -4657,13 +4657,13 @@ A floating point value, as wide as a DI mode integer, usually 64 bits.
|
||||
@end table
|
||||
|
||||
Specifying a combination that is not valid for the current architecture
|
||||
will cause gcc to synthesize the instructions using a narrower mode.
|
||||
will cause GCC to synthesize the instructions using a narrower mode.
|
||||
For example, if you specify a variable of type @code{V4SI} and your
|
||||
architecture does not allow for this specific SIMD type, gcc will
|
||||
architecture does not allow for this specific SIMD type, GCC will
|
||||
produce code that uses 4 @code{SIs}.
|
||||
|
||||
The types defined in this manner can be used with a subset of normal C
|
||||
operations. Currently, gcc will allow using the following operators
|
||||
operations. Currently, GCC will allow using the following operators
|
||||
on these types: @code{+, -, *, /, unary minus, ^, |, &, ~}@.
|
||||
|
||||
The operations behave like C++ @code{valarrays}. Addition is defined as
|
||||
@ -7734,7 +7734,7 @@ an rvalue.
|
||||
@cindex restricted references
|
||||
@cindex restricted this pointer
|
||||
|
||||
As with gcc, g++ understands the C99 feature of restricted pointers,
|
||||
As with the C front end, G++ understands the C99 feature of restricted pointers,
|
||||
specified with the @code{__restrict__}, or @code{__restrict} type
|
||||
qualifier. Because you cannot compile C++ by specifying the @option{-std=c99}
|
||||
language flag, @code{restrict} is not a keyword in C++.
|
||||
@ -8014,11 +8014,11 @@ compiled separately.
|
||||
@end table
|
||||
|
||||
When used with GNU ld version 2.8 or later on an ELF system such as
|
||||
GNU/Linux or Solaris 2, or on Microsoft Windows, g++ supports the
|
||||
Borland model. On other systems, g++ implements neither automatic
|
||||
GNU/Linux or Solaris 2, or on Microsoft Windows, G++ supports the
|
||||
Borland model. On other systems, G++ implements neither automatic
|
||||
model.
|
||||
|
||||
A future version of g++ will support a hybrid model whereby the compiler
|
||||
A future version of G++ will support a hybrid model whereby the compiler
|
||||
will emit any instantiations for which the template definition is
|
||||
included in the compile, and store template definitions and
|
||||
instantiation context information into the object file for the rest.
|
||||
@ -8089,7 +8089,7 @@ compile it without @option{-fno-implicit-templates} so you get all of the
|
||||
instances required by your explicit instantiations (but not by any
|
||||
other files) without having to specify them as well.
|
||||
|
||||
g++ has extended the template instantiation syntax given in the ISO
|
||||
G++ has extended the template instantiation syntax given in the ISO
|
||||
standard to allow forward declaration of explicit instantiations
|
||||
(with @code{extern}), instantiation of the compiler support data for a
|
||||
template class (i.e.@: the vtable) without instantiating any of its
|
||||
@ -8104,7 +8104,7 @@ static template class Foo<int>;
|
||||
@end smallexample
|
||||
|
||||
@item
|
||||
Do nothing. Pretend g++ does implement automatic instantiation
|
||||
Do nothing. Pretend G++ does implement automatic instantiation
|
||||
management. Code written for the Borland model will work fine, but
|
||||
each translation unit will contain instances of each of the templates it
|
||||
uses. In a large program, this can lead to an unacceptable amount of code
|
||||
@ -8306,10 +8306,10 @@ that are now deprecated:
|
||||
@table @code
|
||||
@item -fexternal-templates
|
||||
@itemx -falt-external-templates
|
||||
These are two of the many ways for g++ to implement template
|
||||
These are two of the many ways for G++ to implement template
|
||||
instantiation. @xref{Template Instantiation}. The C++ standard clearly
|
||||
defines how template definitions have to be organized across
|
||||
implementation units. g++ has an implicit instantiation mechanism that
|
||||
implementation units. G++ has an implicit instantiation mechanism that
|
||||
should work just fine for standard-conforming code.
|
||||
|
||||
@item -fstrict-prototype
|
||||
@ -8321,20 +8321,20 @@ it is required for backwards compatibility @xref{Backwards Compatibility}.
|
||||
@end table
|
||||
|
||||
The named return value extension has been deprecated, and is now
|
||||
removed from g++.
|
||||
removed from G++.
|
||||
|
||||
The use of initializer lists with new expressions has been deprecated,
|
||||
and is now removed from g++.
|
||||
and is now removed from G++.
|
||||
|
||||
Floating and complex non-type template parameters have been deprecated,
|
||||
and are now removed from g++.
|
||||
and are now removed from G++.
|
||||
|
||||
The implicit typename extension has been deprecated and is now
|
||||
removed from g++.
|
||||
removed from G++.
|
||||
|
||||
The use of default arguments in function pointers, function typedefs and
|
||||
and other places where they are not permitted by the standard is
|
||||
deprecated and will be removed from a future version of g++.
|
||||
deprecated and will be removed from a future version of G++.
|
||||
|
||||
@node Backwards Compatibility
|
||||
@section Backwards Compatibility
|
||||
|
@ -339,7 +339,7 @@ the execution counts for individual blocks that end on that line. After each
|
||||
block, the branch and call counts of the block will be shown, if the
|
||||
@option{-b} option is given.
|
||||
|
||||
Because of the way gcc instruments calls, a call count can be shown
|
||||
Because of the way GCC instruments calls, a call count can be shown
|
||||
after a line with no individual blocks.
|
||||
As you can see, line 13 contains a basic block that was not executed.
|
||||
|
||||
|
@ -884,7 +884,7 @@ On some systems, this is the default.
|
||||
|
||||
In general, the best (and, in many cases, the only known) threading
|
||||
model available will be configured for use. Beware that on some
|
||||
systems, gcc has not been taught what threading models are generally
|
||||
systems, GCC has not been taught what threading models are generally
|
||||
available for the system. In this case, @option{--enable-threads} is an
|
||||
alias for @option{--enable-threads=single}.
|
||||
|
||||
@ -1172,7 +1172,7 @@ will be run on these files to make them compatible with GCC.
|
||||
|
||||
@item --without-headers
|
||||
Tells GCC not use any target headers from a libc when building a cross
|
||||
compiler. When crossing to GNU/Linux, you need the headers so gcc
|
||||
compiler. When crossing to GNU/Linux, you need the headers so GCC
|
||||
can build the exception handling for libgcc.
|
||||
See @uref{http://www.objsw.com/CrossGCC/,,CrossGCC} for more information
|
||||
on this option.
|
||||
@ -1908,7 +1908,7 @@ Output from running @file{@var{srcdir}/config.guess}. Do not send us
|
||||
that file itself, just the one-line output from running it.
|
||||
|
||||
@item
|
||||
The output of @samp{gcc -v} for your newly installed gcc.
|
||||
The output of @samp{gcc -v} for your newly installed @command{gcc}.
|
||||
This tells us which version of GCC you built and the options you passed to
|
||||
configure.
|
||||
|
||||
|
@ -2655,7 +2655,7 @@ 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 @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
|
||||
warnings, however GCC's integrated preprocessor has enough context to
|
||||
avoid warning in these cases.
|
||||
|
||||
@item
|
||||
@ -2704,7 +2704,7 @@ Use of ISO C style function definitions. This warning intentionally is
|
||||
because these ISO C features will appear in your code when using
|
||||
libiberty's traditional C compatibility macros, @code{PARAMS} and
|
||||
@code{VPARAMS}. This warning is also bypassed for nested functions
|
||||
because that feature is already a gcc extension and thus not relevant to
|
||||
because that feature is already a GCC extension and thus not relevant to
|
||||
traditional C compatibility.
|
||||
@end itemize
|
||||
|
||||
@ -3522,12 +3522,12 @@ gcc -nostdlib @var{files}@dots{} `gcc -print-libgcc-file-name`
|
||||
@item -print-search-dirs
|
||||
@opindex print-search-dirs
|
||||
Print the name of the configured installation directory and a list of
|
||||
program and library directories gcc will search---and don't do anything else.
|
||||
program and library directories @command{gcc} will search---and don't do anything else.
|
||||
|
||||
This is useful when gcc prints the error message
|
||||
This is useful when @command{gcc} prints the error message
|
||||
@samp{installation problem, cannot exec cpp0: No such file or directory}.
|
||||
To resolve this you either need to put @file{cpp0} and the other compiler
|
||||
components where gcc expects to find them, or you can set the environment
|
||||
components where @command{gcc} expects to find them, or you can set the environment
|
||||
variable @env{GCC_EXEC_PREFIX} to the directory where you installed them.
|
||||
Don't forget the trailing '/'.
|
||||
@xref{Environment Variables}.
|
||||
@ -3762,7 +3762,7 @@ Enabled at level @option{-O3}.
|
||||
|
||||
@item -finline-limit=@var{n}
|
||||
@opindex finline-limit
|
||||
By default, gcc limits the size of functions that can be inlined. This flag
|
||||
By default, GCC limits the size of functions that can be inlined. This flag
|
||||
allows the control of this limit for functions that are explicitly marked as
|
||||
inline (i.e., marked with the inline keyword or defined within the class
|
||||
definition in c++). @var{n} is the size of functions that can be inlined in
|
||||
@ -4171,7 +4171,7 @@ other, a few use both.
|
||||
@opindex fno-guess-branch-probability
|
||||
Do not guess branch probabilities using a randomized model.
|
||||
|
||||
Sometimes gcc will opt to use a randomized model to guess branch
|
||||
Sometimes GCC will opt to use a randomized model to guess branch
|
||||
probabilities, when none are available from either profiling feedback
|
||||
(@option{-fprofile-arcs}) or @samp{__builtin_expect}. This means that
|
||||
different runs of the compiler on the same program may produce different
|
||||
@ -4470,7 +4470,7 @@ The default is @option{-fno-rounding-math}.
|
||||
|
||||
This option is experimental and does not currently guarantee to
|
||||
disable all GCC optimizations that are affected by rounding mode.
|
||||
Future versions of gcc may provide finer control of this setting
|
||||
Future versions of GCC may provide finer control of this setting
|
||||
using C99's @code{FENV_ACCESS} pragma. This command line option
|
||||
will be used to specify the default state for @code{FENV_ACCESS}.
|
||||
|
||||
@ -4714,7 +4714,7 @@ needlessly consume memory and resources.
|
||||
|
||||
@item max-inline-insns-single
|
||||
Several parameters control the tree inliner used in gcc.
|
||||
This number sets the maximum number of instructions (counted in gcc's
|
||||
This number sets the maximum number of instructions (counted in GCC's
|
||||
internal representation) in a single function that the tree inliner
|
||||
will consider for inlining. This only affects functions declared
|
||||
inline and methods implemented in a class declaration (C++).
|
||||
@ -8084,7 +8084,7 @@ call any such function. If called, the function must take the same
|
||||
arguments as the common @code{_flush_func()}, that is, the address of the
|
||||
memory range for which the cache is being flushed, the size of the
|
||||
memory range, and the number 3 (to flush both caches). The default
|
||||
depends on the target gcc was configured for, but commonly is either
|
||||
depends on the target GCC was configured for, but commonly is either
|
||||
@samp{_flush_func} or @samp{__cpu_flush}.
|
||||
|
||||
@item -mbranch-likely
|
||||
@ -8235,7 +8235,7 @@ This is the default choice for the x86-64 compiler.
|
||||
Attempt to utilize both instruction sets at once. This effectively double the
|
||||
amount of available registers and on chips with separate execution units for
|
||||
387 and SSE the execution resources too. Use this option with care, as it is
|
||||
still experimental, because the gcc register allocator does not model separate
|
||||
still experimental, because the GCC register allocator does not model separate
|
||||
functional units well resulting in instable performance.
|
||||
@end table
|
||||
|
||||
@ -8461,7 +8461,7 @@ on thread-safe exception handling must compile and link all code with the
|
||||
@opindex mno-align-stringops
|
||||
Do not align destination of inlined string operations. This switch reduces
|
||||
code size and improves performance in case the destination is already aligned,
|
||||
but gcc don't know about it.
|
||||
but GCC doesn't know about it.
|
||||
|
||||
@item -minline-all-stringops
|
||||
@opindex minline-all-stringops
|
||||
@ -8666,7 +8666,7 @@ building a shared library. It is the default when GCC is configured,
|
||||
explicitly or implicitly, with the GNU linker. This option does not
|
||||
have any affect on which ld is called, it only changes what parameters
|
||||
are passed to that ld. The ld that is called is determined by the
|
||||
@option{--with-ld} configure option, gcc's program search path, and
|
||||
@option{--with-ld} configure option, GCC's program search path, and
|
||||
finally by the user's @env{PATH}. The linker used by GCC can be printed
|
||||
using @samp{which `gcc -print-prog-name=ld`}.
|
||||
|
||||
@ -8678,7 +8678,7 @@ links. It is the default when GCC is configured, explicitly or
|
||||
implicitly, with the HP linker. This option does not have any affect on
|
||||
which ld is called, it only changes what parameters are passed to that
|
||||
ld. The ld that is called is determined by the @option{--with-ld}
|
||||
configure option, gcc's program search path, and finally by the user's
|
||||
configure option, GCC's program search path, and finally by the user's
|
||||
@env{PATH}. The linker used by GCC can be printed using @samp{which
|
||||
`gcc -print-prog-name=ld`}.
|
||||
|
||||
|
@ -71,7 +71,7 @@ Note that running the testsuite may require additional tools be
|
||||
installed, such as TCL or dejagnu.
|
||||
|
||||
@item bootstrap
|
||||
Builds gcc three times---once with the native compiler, once with the
|
||||
Builds GCC three times---once with the native compiler, once with the
|
||||
native-built compiler it just built, and once with the compiler it built
|
||||
the second time. In theory, the last two should produce the same
|
||||
results, which @samp{make compare} can check. Each step of this process
|
||||
|
@ -1133,7 +1133,7 @@ about a specific optimization:
|
||||
|
||||
@table @code
|
||||
@item tool
|
||||
tool being tested, e.g., gcc
|
||||
tool being tested, e.g., @command{gcc}
|
||||
|
||||
@item profile_option
|
||||
options used to generate profile data
|
||||
|
@ -3299,7 +3299,7 @@ See the PowerPC's SPE target for an example.
|
||||
|
||||
Define this macro if the target's representation for dwarf registers
|
||||
used in .eh_frame or .debug_frame is different from that used in other
|
||||
debug info sections. Given a gcc hard register number, this macro
|
||||
debug info sections. Given a GCC hard register number, this macro
|
||||
should return the .eh_frame register number. The default is
|
||||
@code{DBX_REGISTER_NUMBER (@var{regno})}.
|
||||
|
||||
@ -3308,7 +3308,7 @@ should return the .eh_frame register number. The default is
|
||||
@defmac DWARF2_FRAME_REG_OUT (@var{regno}, @var{for_eh})
|
||||
|
||||
Define this macro to map register numbers held in the call frame info
|
||||
that gcc has collected using @code{DWARF_FRAME_REGNUM} to those that
|
||||
that GCC has collected using @code{DWARF_FRAME_REGNUM} to those that
|
||||
should be output in .debug_frame (@code{@var{for_eh}} is zero) and
|
||||
.eh_frame (@code{@var{for_eh}} is nonzero). The default is to
|
||||
return @code{@var{regno}}.
|
||||
@ -4659,7 +4659,7 @@ Here is an explanation of implicit calls to library routines.
|
||||
@defmac DECLARE_LIBRARY_RENAMES
|
||||
This macro, if defined, should expand to a piece of C code that will get
|
||||
expanded when compiling functions for libgcc.a. It can be used to
|
||||
provide alternate names for gcc's internal library functions if there
|
||||
provide alternate names for GCC's internal library functions if there
|
||||
are ABI-mandated names that the compiler should provide.
|
||||
@end defmac
|
||||
|
||||
@ -8331,7 +8331,7 @@ target specific attribute attached to it, it will not be inlined.
|
||||
@cindex MIPS coprocessor-definition macros
|
||||
|
||||
The MIPS specification allows MIPS implementations to have as many as 4
|
||||
coprocessors, each with as many as 32 private registers. gcc supports
|
||||
coprocessors, each with as many as 32 private registers. GCC supports
|
||||
accessing these registers and transferring values between the registers
|
||||
and memory using asm-ized variables. For example:
|
||||
|
||||
|
@ -1113,7 +1113,7 @@ unspecified whether @samp{Base::operator=} is called more than once when
|
||||
the implicit copy-assignment for Derived objects is invoked (as it is
|
||||
inside @samp{func} in the example).
|
||||
|
||||
g++ implements the ``intuitive'' algorithm for copy-assignment: assign all
|
||||
G++ implements the ``intuitive'' algorithm for copy-assignment: assign all
|
||||
direct bases, then assign all members. In that algorithm, the virtual
|
||||
base subobject can be encountered more than once. In the example, copying
|
||||
proceeds in the following order: @samp{val}, @samp{name} (via
|
||||
|
Loading…
Reference in New Issue
Block a user