Re: [PATCH doc] Fix typos in the manual.

[Richard Guenther <richard dot guenther at gmail dot com>]

On Tue, Dec 21, 2010 at 7:59 AM, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> Tested 'make html info pdf'. ?OK for trunk?

Ok.

Thanks,
Richard.

> Note that objc.texi had a couple of typos in code snippets
> (unsigneld and typdef).
>
> Thanks,
> Ralf
>
> Fix typos in the manual.
>
> 2010-12-19 ?Ralf Wildenhues ?<Ralf.Wildenhues@gmx.de>
>
> ? ? ? ?* gcc/doc/extend.texi (Function Attributes, Volatiles):
> ? ? ? ?Fix typos.
> ? ? ? ?* gcc/doc/install.texi (Prerequisites, Specific): Likewise.
> ? ? ? ?* gcc/doc/invoke.texi (C Dialect Options, Debugging Options)
> ? ? ? ?(Optimize Options, i386 and x86-64 Options, MicroBlaze Options)
> ? ? ? ?(RS/6000 and PowerPC Options, RX Options, Code Gen Options):
> ? ? ? ?Likewise.
> ? ? ? ?* gcc/doc/objc.texi (Method signatures)
> ? ? ? ?(Fast enumeration protocol): Likewise.
> ? ? ? ?* gcc/doc/tm.texi.in (Run-time Target, Register Arguments)
> ? ? ? ?(Scheduling, Macros for Initialization, Misc): Likewise.
> ? ? ? ?* gcc/doc/tm.texi: Renerate.
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 90f8b7a..1ac1d8d 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -2692,24 +2692,24 @@ an inlined PLT.
> ?@item leaf
> ?@cindex @code{leaf} function attribute
> ?Calls to external functions with this attribute must return to the current
> -compilation unit only by return or by exception handling. In particular, leaf
> -functions are not allowed to call callback function passed to it from current
> +compilation unit only by return or by exception handling. ?In particular, leaf
> +functions are not allowed to call callback function passed to it from the current
> ?compilation unit or directly call functions exported by the unit or longjmp
> -into the unit. ?Still leaf function might call functions from other complation
> -units and thus they are not neccesarily leaf in the sense that they contains no
> +into the unit. ?Leaf function might still call functions from other compilation
> +units and thus they are not necessarily leaf in the sense that they contain no
> ?function calls at all.
>
> ?The attribute is intended for library functions to improve dataflow analysis.
> -Compiler takes the hint that any data not escaping current compilation unit can
> -not be used or modified by the leaf function. ?For example, function @code{sin}
> -is leaf, function @code{qsort} is not.
> +The compiler takes the hint that any data not escaping the current compilation unit can
> +not be used or modified by the leaf function. ?For example, the @code{sin} function
> +is a leaf function, but @code{qsort} is not.
>
> -Note that the leaf functions might invoke signals and signal handlers might be
> -defined in the current compilation unit and use static variables. Only
> +Note that leaf functions might invoke signals and signal handlers might be
> +defined in the current compilation unit and use static variables. ?The only
> ?compliant way to write such a signal handler is to declare such variables
> ?@code{volatile}.
>
> -The attribute has no effect on functions defined within current compilation
> +The attribute has no effect on functions defined within the current compilation
> ?unit. ?This is to allow easy merging of multiple compilation units into one,
> ?for example, by using the link time optimization. ?For this reason the
> ?attribute is not allowed on types to annotate indirect calls.
> @@ -3589,16 +3589,16 @@ away so that a longer more expensive calling sequence is required.
>
> ?@item cpu=@var{CPU}
> ?@cindex @code{target("cpu=@var{CPU}")} attribute
> -Specify the architecture to generate code for in compiling the
> -function. ?If you select @code{"target("cpu=power7)"} attribute when
> +Specify the architecture to generate code for when compiling the
> +function. ?If you select the @code{"target("cpu=power7)"} attribute when
> ?generating 32-bit code, VSX and Altivec instructions are not generated
> ?unless you use the @option{-mabi=altivec} option on the command line.
>
> ?@item tune=@var{TUNE}
> ?@cindex @code{target("tune=@var{TUNE}")} attribute
> -Specify the architecture to tune for in compiling the function. ?If
> +Specify the architecture to tune for when compiling the function. ?If
> ?you do not specify the @code{target("tune=@var{TUNE}")} attribute and
> -you do specifiy the @code{target("cpu=@var{CPU}")} attribute,
> +you do specify the @code{target("cpu=@var{CPU}")} attribute,
> ?compilation will tune for the @var{CPU} architecture, and not the
> ?default tuning specified on the command line.
> ?@end table
> @@ -5358,14 +5358,14 @@ the single copy in the library.
>
> ?C has the concept of volatile objects. ?These are normally accessed by
> ?pointers and used for accessing hardware or inter-thread
> -communication. ?The standard encourage compilers to refrain from
> +communication. ?The standard encourages compilers to refrain from
> ?optimizations concerning accesses to volatile objects, but leaves it
> ?implementation defined as to what constitutes a volatile access. ?The
> ?minimum requirement is that at a sequence point all previous accesses
> ?to volatile objects have stabilized and no subsequent accesses have
> ?occurred. ?Thus an implementation is free to reorder and combine
> ?volatile accesses which occur between sequence points, but cannot do
> -so for accesses across a sequence point. ?The use of volatiles does
> +so for accesses across a sequence point. ?The use of volatile does
> ?not allow you to violate the restriction on updating objects multiple
> ?times between two sequence points.
>
> @@ -5394,7 +5394,7 @@ asm volatile ("" : : : "memory");
> ?vobj = 1;
> ?@end smallexample
>
> -A scalar volatile object is read, when it is accessed in a void context:
> +A scalar volatile object is read when it is accessed in a void context:
>
> ?@smallexample
> ?volatile int *src = @var{somevalue};
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index c8571ec..f990b74 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -450,7 +450,7 @@ and not using @option{--disable-symvers}.
> ?Necessary when targetting Solaris 2 with Sun @command{ld}, building
> ?@samp{libstdc++}, and not using @option{--disable-symvers}. ?A helper
> ?scripts needs @samp{Glob.pm}, which is missing from @command{perl} 5.005
> -included in Solaris~8. ?The bundled @command{perl} in Solaris~9 and up
> +included in Solaris@tie{}8. ?The bundled @command{perl} in Solaris@tie{}9 and up
> ?works.
> ?Used by various scripts to generate some files included in SVN (mainly
> ?Unicode-related and rarely changing) from source tables.
> @@ -3539,10 +3539,10 @@ recommended to use the GNU assembler instead. ?There is no bundled
> ?version, but the current version, from GNU binutils 2.20.1, is known to
> ?work.
>
> -Solaris~2/x86 doesn't support the execution of SSE/SSE2 instructions
> -before Solaris~9 4/04, even if the CPU supports them. ?Programs will
> +Solaris@tie{}2/x86 doesn't support the execution of SSE/SSE2 instructions
> +before Solaris@tie{}9 4/04, even if the CPU supports them. ?Programs will
> ?receive @code{SIGILL} if they try. ?The fix is available both in
> -Solaris~9 Update~6 and kernel patch 112234-12 or newer. ?There is no
> +Solaris@tie{}9 Update@tie{}6 and kernel patch 112234-12 or newer. ?There is no
> ?corresponding patch for Solaris 8. ?To avoid this problem,
> ?@option{-march} defaults to @samp{pentiumpro} on Solaris 8 and 9. ?If
> ?you have the patch installed, you can configure GCC with an appropriate
> @@ -4228,23 +4228,23 @@ There are patches for Solaris 8 (117350-12 or newer for SPARC,
> ?117351-12 or newer for Intel) and Solaris 9 (117171-11 or newer for
> ?SPARC, 117172-11 or newer for Intel) that address this problem.
>
> -Solaris~8 provides an alternate implementation of the thread libraries,
> +Solaris@tie{}8 provides an alternate implementation of the thread libraries,
> ?@samp{libpthread} and @samp{libthread}. ?They are required for TLS
> -support and have been made the default in Solaris~9, so they are always
> -used on Solaris~8.
> +support and have been made the default in Solaris@tie{}9, so they are always
> +used on Solaris@tie{}8.
>
> -Thread-local storage (TLS) is supported in Solaris~8 and 9, but requires
> +Thread-local storage (TLS) is supported in Solaris@tie{}8 and 9, but requires
> ?some patches. ?The @samp{libthread} patches provide the
> ?@code{__tls_get_addr} (SPARC, 64-bit x86) resp.@ @code{___tls_get_addr}
> -(32-bit x86) functions. ?On Solaris~8, you need 108993-26 or newer on
> -SPARC, 108994-26 or newer on Intel. ?On Solaris~9, the necessary support
> -on SPARC is present since FCS, while 114432-05 or newer is reqired on
> -Intel. ?Additionally, on Solaris~8, patch 109147-14 or newer on SPARC or
> +(32-bit x86) functions. ?On Solaris@tie{}8, you need 108993-26 or newer on
> +SPARC, 108994-26 or newer on Intel. ?On Solaris@tie{}9, the necessary support
> +on SPARC is present since FCS, while 114432-05 or newer is required on
> +Intel. ?Additionally, on Solaris@tie{}8, patch 109147-14 or newer on SPARC or
> ?109148-22 or newer on Intel are required for the Sun @command{ld} and
> -runtime linker (@command{ld.so.1}) support. ?Again, Solaris~9/SPARC
> +runtime linker (@command{ld.so.1}) support. ?Again, Solaris@tie{}9/SPARC
> ?works since FCS, while 113986-02 is required on Intel. ?The linker
> ?patches must be installed even if GNU @command{ld} is used. Sun
> -@command{as} in Solaris~8 and 9 doesn't support the necessary
> +@command{as} in Solaris@tie{}8 and 9 doesn't support the necessary
> ?relocations, so GNU @command{as} must be used. ?The @command{configure}
> ?script checks for those prerequisites and automatically enables TLS
> ?support if they are met. ?Although those minimal patch versions should
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 8349651..03d5d3d 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -1699,7 +1699,7 @@ have support for @option{-pthread}.
> ?@opindex fms-extensions
> ?Accept some non-standard constructs used in Microsoft header files.
>
> -It allows for c++ that member-names in structures can be similiar
> +In C++ code, this allows member names in structures to be similar
> ?to previous types declarations.
>
> ?@smallexample
> @@ -4844,7 +4844,7 @@ allocation before or after interprocedural optimization.
> ?@opindex fstack-usage
> ?Makes the compiler output stack usage information for the program, on a
> ?per-function basis. ?The filename for the dump is made by appending
> -@file{.su} to the AUXNAME. ?AUXNAME is generated from the name of
> +@file{.su} to the @var{auxname}. ?@var{auxname} is generated from the name of
> ?the output file, if explicitly specified and it is not an executable,
> ?otherwise it is the basename of the source file. ?An entry is made up
> ?of three fields:
> @@ -4952,15 +4952,15 @@ more closely, if you do not optimize.
>
> ?@item -fdbg-cnt-list
> ?@opindex fdbg-cnt-list
> -Print the name and the counter upperbound for all debug counters.
> +Print the name and the counter upper bound for all debug counters.
>
> ?@item -fdbg-cnt=@var{counter-value-list}
> ?@opindex fdbg-cnt
> -Set the internal debug counter upperbound. @var{counter-value-list}
> +Set the internal debug counter upper bound. ?@var{counter-value-list}
> ?is a comma-separated list of @var{name}:@var{value} pairs
> -which sets the upperbound of each debug counter @var{name} to @var{value}.
> -All debug counters have the initial upperbound of @var{UINT_MAX},
> -thus dbg_cnt() returns true always unless the upperbound is set by this option.
> +which sets the upper bound of each debug counter @var{name} to @var{value}.
> +All debug counters have the initial upper bound of @var{UINT_MAX},
> +thus dbg_cnt() returns true always unless the upper bound is set by this option.
> ?e.g. With -fdbg-cnt=dce:10,tail_call:0
> ?dbg_cnt(dce) will return true only for first 10 invocations
> ?and dbg_cnt(tail_call) will return false always.
> @@ -7500,7 +7500,7 @@ The only important thing to keep in mind is that to enable link-time
> ?optimizations the @option{-flto} flag needs to be passed to both the
> ?compile and the link commands.
>
> -To make whole program optimization effective, it is necesary to make
> +To make whole program optimization effective, it is necessary to make
> ?certain whole program assumptions. ?The compiler needs to know
> ?what functions and variables can be accessed by libraries and runtime
> ?outside of the link time optimized unit. ?When supported by the linker,
> @@ -8332,7 +8332,7 @@ late inlining.
> ?@item comdat-sharing-probability
> ?@itemx comdat-sharing-probability
> ?Probability (in percent) that C++ inline function with comdat visibility
> -will be shared acroess multiple compilation units. ?The default value is 20.
> +will be shared across multiple compilation units. ?The default value is 20.
>
> ?@item min-vect-loop-bound
> ?The minimum number of iterations under which a loop will not get vectorized
> @@ -8342,8 +8342,8 @@ to allow vectorization. ?The default value is 0.
>
> ?@item gcse-cost-distance-ratio
> ?Scaling factor in calculation of maximum distance an expression
> -can be moved by GCSE optimizations. ?This is currently supported only in
> -code hoisting pass. ?The bigger the ratio, the more agressive code hoisting
> +can be moved by GCSE optimizations. ?This is currently supported only in the
> +code hoisting pass. ?The bigger the ratio, the more aggressive code hoisting
> ?will be with simple expressions, i.e., the expressions which have cost
> ?less than @option{gcse-unrestricted-cost}. ?Specifying 0 will disable
> ?hoisting of simple expressions. ?The default value is 10.
> @@ -8352,7 +8352,7 @@ hoisting of simple expressions. ?The default value is 10.
> ?Cost, roughly measured as the cost of a single typical machine
> ?instruction, at which GCSE optimizations will not constrain
> ?the distance an expression can travel. ?This is currently
> -supported only in code hoisting pass. ?The lesser the cost,
> +supported only in the code hoisting pass. ?The lesser the cost,
> ?the more aggressive code hoisting will be. ?Specifying 0 will
> ?allow all expressions to travel unrestricted distances.
> ?The default value is 3.
> @@ -8812,12 +8812,12 @@ parameter in order to perform devirtualization.
> ?stores per a single formal parameter of a function.
>
> ?@item lto-partitions
> -Specify desired nuber of partitions produced during WHOPR copmilation.
> -Number of partitions should exceed number of CPUs used for compilatoin.
> -Default value is 32.
> +Specify desired number of partitions produced during WHOPR compilation.
> +The number of partitions should exceed the number of CPUs used for compilation.
> +The default value is 32.
>
> ?@item lto-minpartition
> -Size of minimal paritition for WHOPR (in estimated instructions).
> +Size of minimal partition for WHOPR (in estimated instructions).
> ?This prevents expenses of splitting very small programs into too many
> ?partitions.
>
> @@ -12339,10 +12339,10 @@ the system libraries and startup modules.
> ?@item -mvect8-ret-in-mem
> ?@opindex mvect8-ret-in-mem
> ?Return 8-byte vectors in memory instead of MMX registers. ?This is the
> -default on Solaris~8 and 9 and VxWorks to match the ABI of the Sun
> +default on Solaris@tie{}8 and 9 and VxWorks to match the ABI of the Sun
> ?Studio compilers until version 12. ?Later compiler versions (starting
> -with Studio 12 Update~1) follow the ABI used by other x86 targets, which
> -is the default on Solaris~10 and later. ?@emph{Only} use this option if
> +with Studio 12 Update@tie{}1) follow the ABI used by other x86 targets, which
> +is the default on Solaris@tie{}10 and later. ?@emph{Only} use this option if
> ?you need to remain compatible with existing code produced by those
> ?previous compiler versions or older versions of GCC.
>
> @@ -13938,7 +13938,7 @@ This option is deprecated. ?Use @option{-fno-zero-initialized-in-bss} instead.
> ?Use features of and schedule code for given CPU.
> ?Supported values are in the format @samp{v@var{X}.@var{YY}.@var{Z}},
> ?where @var{X} is a major version, @var{YY} is the minor version, and
> -@var{Z} is compatiblity code. ?Example values are @samp{v3.00.a},
> +@var{Z} is compatibility code. ?Example values are @samp{v3.00.a},
> ?@samp{v4.00.b}, @samp{v5.00.a}, @samp{v5.00.b}, @samp{v5.00.b}, @samp{v6.00.a}.
>
> ?@item -mxl-soft-mul
> @@ -13975,7 +13975,7 @@ Use multiply high instructions for high part of 32x32 multiply.
>
> ?@item -mxl-float-convert
> ?@opindex mxl-float-convert
> -Use hardware floating point converstion instructions.
> +Use hardware floating point conversion instructions.
>
> ?@item -mxl-float-sqrt
> ?@opindex mxl-float-sqrt
> @@ -16066,9 +16066,9 @@ roots.
> ?@opindex mrecip=opt
> ?This option allows to control which reciprocal estimate instructions
> ?may be used. ?@var{opt} is a comma separated list of options, that may
> -be preceeded by a @code{!} to invert the option:
> +be preceded by a @code{!} to invert the option:
> ?@code{all}: enable all estimate instructions,
> -@code{default}: enable the default instructions, equvalent to @option{-mrecip},
> +@code{default}: enable the default instructions, equivalent to @option{-mrecip},
> ?@code{none}: disable all estimate instructions, equivalent to @option{-mno-recip};
> ?@code{div}: enable the reciprocal approximation instructions for both single and double precision;
> ?@code{divf}: enable the single precision reciprocal approximation instructions;
> @@ -16178,7 +16178,7 @@ selected.
> ?@opindex mbig-endian-data
> ?@opindex mlittle-endian-data
> ?Store data (but not code) in the big-endian format. ?The default is
> -@option{-mlittle-endian-data}, ie to store data in the little endian
> +@option{-mlittle-endian-data}, i.e.@: to store data in the little endian
> ?format.
>
> ?@item -msmall-data-limit=@var{N}
> @@ -18123,7 +18123,7 @@ code, provide near-perfect API export and prevent symbol clashes.
> ?It is @strong{strongly} recommended that you use this in any shared objects
> ?you distribute.
>
> -Despite the nomenclature, @code{default} always means public ie;
> +Despite the nomenclature, @code{default} always means public; i.e.,
> ?available to be linked against from outside the shared object.
> ?@code{protected} and @code{internal} are pretty useless in real-world
> ?usage so the only other commonly used option will be @code{hidden}.
> @@ -18151,7 +18151,7 @@ the declarations you wish to set visibility for with (for example)
> ?@samp{#pragma GCC visibility pop}.
> ?Bear in mind that symbol visibility should be viewed @strong{as
> ?part of the API interface contract} and thus all new code should
> -always specify visibility when it is not the default ie; declarations
> +always specify visibility when it is not the default; i.e., declarations
> ?only for use within the local DSO should @strong{always} be marked explicitly
> ?as hidden as so to avoid PLT indirection overheads---making this
> ?abundantly clear also aids readability and self-documentation of the code.
> diff --git a/gcc/doc/objc.texi b/gcc/doc/objc.texi
> index ed5d390..f824372 100644
> --- a/gcc/doc/objc.texi
> +++ b/gcc/doc/objc.texi
> @@ -553,7 +553,7 @@ functions are part of the public ``API'' and are the preferred way to
> ?interact with method signatures from user code.
>
> ?But if you need to debug a problem with method signatures and need to
> -know how they are implemented (ie, the ``ABI''), read on.
> +know how they are implemented (i.e., the ``ABI''), read on.
>
> ?Methods have their ``signature'' encoded and made available to the
> ?runtime. ?The ``signature'' encodes all the information required to
> @@ -1026,13 +1026,13 @@ enumeration, you need to have it implement the method
> ?@smallexample
> ?- (unsigned long) countByEnumeratingWithState: (NSFastEnumerationState *)state
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? objects: (id *)objects
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?count: (unsigneld long)len;
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?count: (unsigned long)len;
> ?@end smallexample
>
> ?where @code{NSFastEnumerationState} must be defined in your code as follows:
>
> ?@smallexample
> -typdef struct
> +typedef struct
> ?@{
> ? unsigned long state;
> ? id ? ? ? ? ? ?*itemsPtr;
> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> index da8d14b..b13ddfb 100644
> --- a/gcc/doc/tm.texi
> +++ b/gcc/doc/tm.texi
> @@ -748,7 +748,7 @@ options to enable at particular sets of optimization levels. ?These
> ?options are processed once
> ?just after the optimization level is determined and before the remainder
> ?of the command options have been parsed, so may be overridden by other
> -options passed explicily.
> +options passed explicitly.
>
> ?This processing is run once at program startup and when the optimization
> ?options are changed via @code{#pragma GCC optimize} or by using the
> @@ -4224,7 +4224,7 @@ required.
> ?@end defmac
>
> ?@deftypefn {Target Hook} {unsigned int} TARGET_FUNCTION_ARG_BOUNDARY (enum machine_mode @var{mode}, const_tree @var{type})
> -This hook returns the the alignment boundary, in bits, of an argument
> +This hook returns the alignment boundary, in bits, of an argument
> ?with the specified mode and type. ?The default hook returns
> ?@code{PARM_BOUNDARY} for all arguments.
> ?@end deftypefn
> @@ -4337,7 +4337,7 @@ SSE registers for floating point operations. ?On such targets, a good
> ?strategy may be to return nonzero from this hook for @code{INTEGRAL_MODE_P}
> ?machine modes but zero for the SSE register classes.
>
> -The default version of this hook retuns false for any mode. ?It is always
> +The default version of this hook returns false for any mode. ?It is always
> ?safe to redefine this hook to return with a nonzero value. ?But if you
> ?unnecessarily define it, you will reduce the amount of optimizations
> ?that can be performed in some cases. ?If you do not define this hook
> @@ -6640,11 +6640,11 @@ round of multipass scheduling.
> ?@end deftypefn
>
> ?@deftypefn {Target Hook} void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT (void *@var{data})
> -This hook initilizes target-specific data used in multipass scheduling.
> +This hook initializes target-specific data used in multipass scheduling.
> ?@end deftypefn
>
> ?@deftypefn {Target Hook} void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI (void *@var{data})
> -This hook finilizes target-specific data used in multipass scheduling.
> +This hook finalizes target-specific data used in multipass scheduling.
> ?@end deftypefn
>
> ?@deftypefn {Target Hook} int TARGET_SCHED_DFA_NEW_CYCLE (FILE *@var{dump}, int @var{verbose}, rtx @var{insn}, int @var{last_clock}, int @var{clock}, int *@var{sort_p})
> @@ -8437,7 +8437,7 @@ to execute @command{nm}. ?The default is to search the path normally for
> ?@command{collect2} calls @command{nm} to scan object files for static
> ?constructors and destructors and LTO info. ?By default, @option{-n} is
> ?passed. ?Define @code{NM_FLAGS} to a C string constant if other options
> -are needed to get the same output formut as GNU @command{nm -n}
> +are needed to get the same output format as GNU @command{nm -n}
> ?produces.
> ?@end defmac
>
> @@ -10510,7 +10510,7 @@ condition code values with less instructions than the corresponding
> ?machines, define the appropriate patterns. ?Use the names @code{incscc}
> ?and @code{decscc}, respectively, for the patterns which perform
> ?@code{plus} or @code{minus} operations on condition code values. ?See
> -@file{rs6000.md} for some examples. ?The GNU Superoptizer can be used to
> +@file{rs6000.md} for some examples. ?The GNU Superoptimizer can be used to
> ?find such instruction sequences on other machines.
>
> ?If this macro is not defined, the default value, 1, is used. ?You need
> diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
> index 050b163..f78eba9 100644
> --- a/gcc/doc/tm.texi.in
> +++ b/gcc/doc/tm.texi.in
> @@ -742,7 +742,7 @@ options to enable at particular sets of optimization levels. ?These
> ?options are processed once
> ?just after the optimization level is determined and before the remainder
> ?of the command options have been parsed, so may be overridden by other
> -options passed explicily.
> +options passed explicitly.
>
> ?This processing is run once at program startup and when the optimization
> ?options are changed via @code{#pragma GCC optimize} or by using the
> @@ -4212,7 +4212,7 @@ required.
> ?@end defmac
>
> ?@hook TARGET_FUNCTION_ARG_BOUNDARY
> -This hook returns the the alignment boundary, in bits, of an argument
> +This hook returns the alignment boundary, in bits, of an argument
> ?with the specified mode and type. ?The default hook returns
> ?@code{PARM_BOUNDARY} for all arguments.
> ?@end deftypefn
> @@ -4325,7 +4325,7 @@ SSE registers for floating point operations. ?On such targets, a good
> ?strategy may be to return nonzero from this hook for @code{INTEGRAL_MODE_P}
> ?machine modes but zero for the SSE register classes.
>
> -The default version of this hook retuns false for any mode. ?It is always
> +The default version of this hook returns false for any mode. ?It is always
> ?safe to redefine this hook to return with a nonzero value. ?But if you
> ?unnecessarily define it, you will reduce the amount of optimizations
> ?that can be performed in some cases. ?If you do not define this hook
> @@ -6622,11 +6622,11 @@ round of multipass scheduling.
> ?@end deftypefn
>
> ?@hook TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT
> -This hook initilizes target-specific data used in multipass scheduling.
> +This hook initializes target-specific data used in multipass scheduling.
> ?@end deftypefn
>
> ?@hook TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI
> -This hook finilizes target-specific data used in multipass scheduling.
> +This hook finalizes target-specific data used in multipass scheduling.
> ?@end deftypefn
>
> ?@hook TARGET_SCHED_DFA_NEW_CYCLE
> @@ -8407,7 +8407,7 @@ to execute @command{nm}. ?The default is to search the path normally for
> ?@command{collect2} calls @command{nm} to scan object files for static
> ?constructors and destructors and LTO info. ?By default, @option{-n} is
> ?passed. ?Define @code{NM_FLAGS} to a C string constant if other options
> -are needed to get the same output formut as GNU @command{nm -n}
> +are needed to get the same output format as GNU @command{nm -n}
> ?produces.
> ?@end defmac
>
> @@ -10468,7 +10468,7 @@ condition code values with less instructions than the corresponding
> ?machines, define the appropriate patterns. ?Use the names @code{incscc}
> ?and @code{decscc}, respectively, for the patterns which perform
> ?@code{plus} or @code{minus} operations on condition code values. ?See
> -@file{rs6000.md} for some examples. ?The GNU Superoptizer can be used to
> +@file{rs6000.md} for some examples. ?The GNU Superoptimizer can be used to
> ?find such instruction sequences on other machines.
>
> ?If this macro is not defined, the default value, 1, is used. ?You need
>