OSDN Git Service

* doc/c-tree.texi, doc/cfg.texi, doc/extend.texi, doc/gty.texi,
authorjsm28 <jsm28@138bc75d-0d04-0410-961f-82ee72b054a4>
Fri, 5 Nov 2004 00:53:49 +0000 (00:53 +0000)
committerjsm28 <jsm28@138bc75d-0d04-0410-961f-82ee72b054a4>
Fri, 5 Nov 2004 00:53:49 +0000 (00:53 +0000)
doc/install.texi, doc/invoke.texi, doc/md.texi, doc/passes.texi,
doc/rtl.texi, doc/tm.texi, doc/tree-ssa.texi: Remove trailing
whitespace.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@90100 138bc75d-0d04-0410-961f-82ee72b054a4

12 files changed:
gcc/ChangeLog
gcc/doc/c-tree.texi
gcc/doc/cfg.texi
gcc/doc/extend.texi
gcc/doc/gty.texi
gcc/doc/install.texi
gcc/doc/invoke.texi
gcc/doc/md.texi
gcc/doc/passes.texi
gcc/doc/rtl.texi
gcc/doc/tm.texi
gcc/doc/tree-ssa.texi

index 239dcec..4516912 100644 (file)
@@ -1,3 +1,10 @@
+2004-11-05  Joseph S. Myers  <joseph@codesourcery.com>
+
+       * doc/c-tree.texi, doc/cfg.texi, doc/extend.texi, doc/gty.texi,
+       doc/install.texi, doc/invoke.texi, doc/md.texi, doc/passes.texi,
+       doc/rtl.texi, doc/tm.texi, doc/tree-ssa.texi: Remove trailing
+       whitespace.
+
 2004-11-04  Mark Mitchell  <mark@codesourcery.com>
 
        * config/arm/arm.c (arm_handle_notshared_attribute): New function.
index ac143f1..9cd582e 100644 (file)
@@ -2170,7 +2170,7 @@ variable is initialized, rather than assigned to subsequently.
 These nodes represent non-static data member accesses.  The first
 operand is the object (rather than a pointer to it); the second operand
 is the @code{FIELD_DECL} for the data member.  The third operand represents
-the byte offset of the field, but should not be used directly; call 
+the byte offset of the field, but should not be used directly; call
 @code{component_ref_field_offset} instead.
 
 @item COMPOUND_EXPR
index 2b3aec6..d83e992 100644 (file)
@@ -229,7 +229,7 @@ and many computed jumps may have @emph{very} dense flow graphs, so
 these edges need to be handled with special care.  During the earlier
 stages of the compilation process, GCC tries to avoid such dense flow
 graphs by factoring computed jumps.  For example, given the following
-series of jumps, 
+series of jumps,
 
 @smallexample
   goto *x;
@@ -580,7 +580,7 @@ be freely reused for other values when a register is dead.
 @findex REG_DEAD, REG_UNUSED
 The liveness information is stored partly in the RTL instruction
 stream and partly in the flow graph.  Local information is stored in
-the instruction stream: 
+the instruction stream:
 Each instruction may contain @code{REG_DEAD} notes representing that
 the value of a given register is no longer needed, or
 @code{REG_UNUSED} notes representing that the value computed by the
index 0e5e970..8f383b2 100644 (file)
@@ -3310,14 +3310,14 @@ above in recent GCC versions.
 @subsection ARM Type Attributes
 
 On those ARM targets that support @code{dllimport} (such as Symbian
-OS), you can use the @code{notshared} attribute to indicate that the 
+OS), you can use the @code{notshared} attribute to indicate that the
 virtual table and other similar data for a class should not be
 exported from a DLL.  For example:
 
 @smallexample
 class __declspec(notshared) C @{
 public:
-  __declspec(dllimport) C(); 
+  __declspec(dllimport) C();
   virtual void f();
 @}
 
@@ -3689,7 +3689,7 @@ int foo ()
   int result;
   asm ("magic stuff accessing an 'int' pointed to by '%1'"
         "=&d" (r) : "a" (y), "m" (*y));
-  return result;     
+  return result;
 @}
 @end smallexample
 
@@ -3790,10 +3790,10 @@ The @code{volatile} keyword indicates that the instruction has
 important side-effects.  GCC will not delete a volatile @code{asm} if
 it is reachable.  (The instruction can still be deleted if GCC can
 prove that control-flow will never reach the location of the
-instruction.)  Note that even a volatile @code{asm} instruction 
+instruction.)  Note that even a volatile @code{asm} instruction
 can be moved relative to other code, including across jump
-instructions.  For example, on many targets there is a system 
-register which can be set to control the rounding mode of 
+instructions.  For example, on many targets there is a system
+register which can be set to control the rounding mode of
 floating point operations.  You might try
 setting it with a volatile @code{asm}, like this PowerPC example:
 
index dafad02..cf4bde7 100644 (file)
@@ -61,7 +61,7 @@ static GTY(()) int @var{counter};        /* @r{save counter in a PCH} */
 @end smallexample
 
 The parser understands simple typedefs such as
-@code{typedef struct @var{tag} *@var{name};} and 
+@code{typedef struct @var{tag} *@var{name};} and
 @code{typedef int @var{name};}.
 These don't need to be marked.
 
index acd4805..ff013a7 100644 (file)
@@ -1235,7 +1235,7 @@ The following options apply to the build of the Fortran front end.
 @itemx --with-mpfr=@var{pathname}
 @itemx --with-gmp-dir=@var{pathname}
 @itemx --with-mpfr-dir=@var{pathname}
-If you don't have GMP (the GNU Multiple Precision library) and the MPFR 
+If you don't have GMP (the GNU Multiple Precision library) and the MPFR
 Libraries installed in a standard location and you want to build the Fortran
 front-end, you can explicitly specify the directory where they are installed
 (@samp{--with-gmp=gmpinstalldir}, @samp{--with-mpfr=mpfrinstalldir}) or where
@@ -2751,7 +2751,7 @@ needed whenever @env{CC} is used.
 
 Specifically, options that determine the runtime architecture must be
 in @env{CC} to correctly select the target for the build.  It is also
-convenient to place many other compiler options in @env{CC}.  For example, 
+convenient to place many other compiler options in @env{CC}.  For example,
 @env{CC="cc -Ac +DA2.0W -Wp,-H16376 -D_CLASSIC_TYPES -D_HPUX_SOURCE"}
 can be used to bootstrap the GCC 3.3 branch with the HP compiler in
 64-bit K&R/bundled mode.  The @option{+DA2.0W} option will result in
index 15e7316..b5074f9 100644 (file)
@@ -1834,7 +1834,7 @@ Objective-C and Objective-C++ programs; you can use the other options with
 any language supported by GCC@.
 
 Note that since Objective-C is an extension of the C language, Objective-C
-compilations may also use options specific to the C front-end (e.g., 
+compilations may also use options specific to the C front-end (e.g.,
 @option{-Wtraditional}).  Similarly, Objective-C++ compilations may use
 C++-specific options (e.g., @option{-Wabi}).
 
@@ -3516,7 +3516,7 @@ loop optimization pass, to @file{@var{file}.06.loop}.  @option{-dL} and
 @itemx -fdump-rtl-sms
 @opindex dm
 @opindex fdump-rtl-sms
-Dump after modulo scheduling, to @file{@var{file}.20.sms}. 
+Dump after modulo scheduling, to @file{@var{file}.20.sms}.
 
 @item -dM
 @itemx -fdump-rtl-mach
@@ -3842,7 +3842,7 @@ file name.
 
 @item vect
 @opindex fdump-tree-vect
-Dump each function after applying vectorization of loops.  The file name is 
+Dump each function after applying vectorization of loops.  The file name is
 made by appending @file{.vect} to the source file name.
 
 @item all
@@ -4650,7 +4650,7 @@ Perform loop optimizations on trees.  This flag is enabled by default
 at @option{-O} and higher.
 
 @item -ftree-loop-linear
-Perform linear loop transformations on tree. This flag can improve cache 
+Perform linear loop transformations on tree. This flag can improve cache
 performance and allow further loop optimizations to take place.
 
 @item -ftree-lim
@@ -4733,7 +4733,7 @@ This optimization is enabled by default.
 
 @item -fvariable-expansion-in-unroller
 @opindex -fvariable-expansion-in-unroller
-With this option, the compiler will create multiple copies of some 
+With this option, the compiler will create multiple copies of some
 local variables when unrolling a loop which can result in superior code.
 
 @item -fprefetch-loop-arrays
@@ -7252,14 +7252,14 @@ Emit debugging information for all symbols and types.
 @item -mone-byte-bool
 @opindex -mone-byte-bool
 Override the defaults for @samp{bool} so that @samp{sizeof(bool)==1}.
-By default @samp{sizeof(bool)} is @samp{4} when compiling for 
+By default @samp{sizeof(bool)} is @samp{4} when compiling for
 Darwin/PowerPC and @samp{1} when compiling for Darwin/x86, so this
 option has no effect on x86.
 
 @strong{Warning:} The @option{-mone-byte-bool} switch causes GCC
 to generate code that is not binary compatible with code generated
 without that switch.  Using this switch may require recompiling all
-other modules in a program, including system libraries.  Use this 
+other modules in a program, including system libraries.  Use this
 switch to conform to a non-default data model.
 
 @item -mfix-and-continue
@@ -10837,18 +10837,18 @@ In order to provide a backchain the address of the caller's frame
 is stored within the callee's stack frame.
 A backchain may be needed to allow debugging using tools that do not understand
 DWARF-2 call frame information.
-For @option{-mno-backchain} no backchain is maintained at all which is the 
-default. 
-If one of the other options is present the backchain pointer is placed either 
+For @option{-mno-backchain} no backchain is maintained at all which is the
+default.
+If one of the other options is present the backchain pointer is placed either
 on top of the stack frame  (@option{-mkernel-backchain}) or on
 the bottom (@option{-mbackchain}).
 Beside the different backchain location @option{-mkernel-backchain}
 also changes stack frame layout breaking the ABI. This option
 is intended to be used for code which internally needs a backchain but has
-to get by with a limited stack size e.g.@: the linux kernel. 
+to get by with a limited stack size e.g.@: the linux kernel.
 Internal unwinding code not using DWARF-2 info has to be able to locate the
 return address of a function. That will be eased be the fact that
-the return address of a function is placed two words below the backchain 
+the return address of a function is placed two words below the backchain
 pointer.
 
 @item -msmall-exec
@@ -10936,8 +10936,8 @@ hardware floating point is used.
 @opindex mwarn-framesize
 Emit a warning if the current function exceeds the given frame size.  Because
 this is a compile time check it doesn't need to be a real problem when the program
-runs.  It is intended to identify functions which most probably cause 
-a stack overflow.  It is useful to be used in an environment with limited stack 
+runs.  It is intended to identify functions which most probably cause
+a stack overflow.  It is useful to be used in an environment with limited stack
 size e.g.@: the linux kernel.
 
 @item -mwarn-dynamicstack
@@ -10951,11 +10951,11 @@ sized arrays.  This is generally a bad idea with a limited stack size.
 @opindex mstack-size
 These arguments always have to be used in conjunction.  If they are present the s390
 back end emits additional instructions in the function prologue which trigger a trap
-if the stack size is @var{stack-guard} bytes above the @var{stack-size} 
-(remember that the stack on s390 grows downward).  These options are intended to 
-be used to help debugging stack overflow problems.  The additionally emitted code 
-cause only little overhead and hence can also be used in production like systems 
-without greater performance degradation.  The given values have to be exact 
+if the stack size is @var{stack-guard} bytes above the @var{stack-size}
+(remember that the stack on s390 grows downward).  These options are intended to
+be used to help debugging stack overflow problems.  The additionally emitted code
+cause only little overhead and hence can also be used in production like systems
+without greater performance degradation.  The given values have to be exact
 powers of 2 and @var{stack-size} has to be greater than @var{stack-guard}.
 In order to be efficient the extra code makes the assumption that the stack starts
 at an address aligned to the value given by @var{stack-size}.
@@ -12181,7 +12181,7 @@ load times of shared object libraries, produce more optimized
 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;
 available to be linked against from outside the shared object.
 @code{protected} and @code{internal} are pretty useless in real-world
@@ -12190,7 +12190,7 @@ The default if @option{-fvisibility} isn't specified is
 @code{default}, i.e., make every
 symbol public---this causes the same behavior as previous versions of
 GCC.
-     
+
 A good explanation of the benefits offered by ensuring ELF
 symbols have the correct visibility is given by ``How To Write
 Shared Libraries'' by Ulrich Drepper (which can be found at
index 5b5b03e..e01bd31 100644 (file)
@@ -919,7 +919,7 @@ logical operators, which have the semantics of the C operators
 @end table
 
 @item
-An optional block of C code, which should execute 
+An optional block of C code, which should execute
 @samp{@w{return true}} if the predicate is found to match and
 @samp{@w{return false}} if it does not.  It must not have any side
 effects.  The predicate arguments, @var{op} and @var{mode}, are
index 2d3396a..f3714cb 100644 (file)
@@ -12,7 +12,7 @@
 @cindex compiler passes and files
 
 This chapter is dedicated to giving an overview of the optimization and
-code generation passes of the compiler.  In the process, it describes 
+code generation passes of the compiler.  In the process, it describes
 some of the language front end interface, though this description is no
 where near complete.
 
@@ -30,7 +30,7 @@ where near complete.
 @findex lang_hooks.parse_file
 The language front end is invoked only once, via
 @code{lang_hooks.parse_file}, to parse the entire input.  The language
-front end may use any intermediate language representation deemed 
+front end may use any intermediate language representation deemed
 appropriate.  The C front end uses GENERIC trees (CROSSREF), plus
 a double handful of language specific tree codes defined in
 @file{c-common.def}.  The Fortran front end uses a completely different
@@ -43,10 +43,10 @@ private representation.
 @cindex intermediate representation lowering
 @cindex lowering, language-dependent intermediate representation
 At some point the front end must translate the representation used in the
-front end to a representation understood by the language-independent 
+front end to a representation understood by the language-independent
 portions of the compiler.  Current practice takes one of two forms.
 The C front end manually invokes the gimplifier (CROSSREF) on each function,
-and uses the gimplifier callbacks to convert the language-specific tree 
+and uses the gimplifier callbacks to convert the language-specific tree
 nodes directly to GIMPLE (CROSSREF) before passing the function off to
 be compiled.
 The Fortran front end converts from a private representation to GENERIC,
@@ -72,7 +72,7 @@ Hum... this sounds overly complicated.  Perhaps we should just
 have the front end gimplify always; in most cases it's only one
 function call.
 
-The front end needs to pass all function definitions and top level 
+The front end needs to pass all function definitions and top level
 declarations off to the middle-end so that they can be compiled and
 emitted to the object file.  For a simple procedural language, it is
 usually most convenient to do this as each top level declaration or
@@ -80,14 +80,14 @@ definition is seen.  There is also a distinction to be made between
 generating functional code and generating complete debug information.
 The only thing that is absolutely required for functional code is that
 function and data @emph{definitions} be passed to the middle-end.  For
-complete debug information, function, data and type declarations 
+complete debug information, function, data and type declarations
 should all be passed as well.
 
 @findex rest_of_decl_compilation
 @findex rest_of_type_compilation
 @findex cgraph_finalize_function
 In any case, the front end needs each complete top-level function or
-data declaration, and each data definition should be passed to 
+data declaration, and each data definition should be passed to
 @code{rest_of_decl_compilation}.  Each complete type definition should
 be passed to @code{rest_of_type_compilation}.  Each function definition
 should be passed to @code{cgraph_finalize_function}.
@@ -100,7 +100,7 @@ as the official interface?  Possibly we should rename all three
 interfaces such that the names match in some meaningful way and
 that is more descriptive than "rest_of".
 
-The middle-end will, at its option, emit the function and data 
+The middle-end will, at its option, emit the function and data
 definitions immediately or queue them for later processing.
 
 @node Gimplification pass
@@ -116,7 +116,7 @@ section of code.
 
 @cindex GENERIC
 While a front end may certainly choose to generate GIMPLE directly if
-it chooses, this can be a moderately complex process unless the 
+it chooses, this can be a moderately complex process unless the
 intermediate language used by the front end is already fairly simple.
 Usually it is easier to generate GENERIC trees plus extensions
 and let the language-independent gimplifier do most of the work.
@@ -125,7 +125,7 @@ and let the language-independent gimplifier do most of the work.
 @findex gimplify_expr
 @findex lang_hooks.gimplify_expr
 The main entry point to this pass is @code{gimplify_function_tree}
-located in @file{gimplify.c}.  From here we process the entire 
+located in @file{gimplify.c}.  From here we process the entire
 function gimplifying each statement in turn.  The main workhorse
 for this pass is @code{gimplify_expr}.  Approximately everything
 passes through here at least once, and it is from here that we
@@ -135,7 +135,7 @@ The callback should examine the expression in question and return
 @code{GS_UNHANDLED} if the expression is not a language specific
 construct that requires attention.  Otherwise it should alter the
 expression in some way to such that forward progress is made toward
-producing valid GIMPLE.  If the callback is certain that the 
+producing valid GIMPLE.  If the callback is certain that the
 transformation is complete and the expression is valid GIMPLE, it
 should return @code{GS_ALL_DONE}.  Otherwise it should return
 @code{GS_OK}, which will cause the expression to be processed again.
@@ -152,7 +152,7 @@ and take care of standard bookkeeping that applies to every pass.
 
 The theory of operation is that each pass defines a structure that
 represents everything we need to know about that pass---when it
-should be run, how it should be run, what intermediate language 
+should be run, how it should be run, what intermediate language
 form or on-the-side data structures it needs.  We register the pass
 to be run in some particular order, and the pass manager arranges
 for everything to happen in the correct order.
@@ -203,13 +203,13 @@ by @code{pass_mudflap_1}.
 
 @item Lower control flow
 
-This pass flattens @code{if} statements (@code{COND_EXPR}) and 
+This pass flattens @code{if} statements (@code{COND_EXPR}) and
 and moves lexical bindings (@code{BIND_EXPR}) out of line.  After
 this pass, all @code{if} statements will have exactly two @code{goto}
 statements in its @code{then} and @code{else} arms.  Lexical binding
 information for each statement will be found in @code{TREE_BLOCK} rather
 than being inferred from its position under a @code{BIND_EXPR}.  This
-pass is found in @file{gimple-low.c} and is described by 
+pass is found in @file{gimple-low.c} and is described by
 @code{pass_lower_cf}.
 
 @item Lower exception handling control flow
@@ -233,7 +233,7 @@ is described by @code{pass_build_cfg}.
 
 @item Find all referenced variables
 
-This pass walks the entire function and collects an array of all 
+This pass walks the entire function and collects an array of all
 variables referenced in the function, @code{referenced_vars}.  The
 index at which a variable is found in the array is used as a UID
 for the variable within this function.  This data is needed by the
@@ -244,8 +244,8 @@ and is described by @code{pass_referenced_vars}.
 
 This pass rewrites the function such that it is in SSA form.  After
 this pass, all @code{is_gimple_reg} variables will be referenced by
-@code{SSA_NAME}, and all occurrences of other variables will be 
-annotated with @code{VDEFS} and @code{VUSES}; phi nodes will have 
+@code{SSA_NAME}, and all occurrences of other variables will be
+annotated with @code{VDEFS} and @code{VUSES}; phi nodes will have
 been inserted as necessary for each basic block.  This pass is
 located in @file{tree-ssa.c} and is described by @code{pass_build_ssa}.
 
@@ -287,23 +287,23 @@ described by @code{pass_redundant_phi}.o
 
 This pass attempts to remove redundant computation by substituting
 variables that are used once into the expression that uses them and
-seeing if the result can be simplified.  It is located in 
+seeing if the result can be simplified.  It is located in
 @file{tree-ssa-forwprop.c} and is described by @code{pass_forwprop}.
 
 @item Copy Renaming
 
-This pass attempts to change the name of compiler temporaries involved in 
+This pass attempts to change the name of compiler temporaries involved in
 copy operations such that SSA->normal can coalesce the copy away. When compiler
 temporaries are copies of user variables, it also renames the compiler
-temporary to the user variable resulting in better use of user symbols.  It is 
-located in @file{tree-ssa-copyrename.c} and is described by 
+temporary to the user variable resulting in better use of user symbols.  It is
+located in @file{tree-ssa-copyrename.c} and is described by
 @code{pass_copyrename}.
 
 @item PHI node optimizations
 
 This pass recognizes forms of phi inputs that can be represented as
 conditional expressions and rewrites them into straight line code.
-It is located in @file{tree-ssa-phiopt.c} and is described by 
+It is located in @file{tree-ssa-phiopt.c} and is described by
 @code{pass_phiopt}.
 
 @item May-alias optimization
@@ -333,7 +333,7 @@ and is described by @code{pass_lower_complex}.
 @item Scalar replacement of aggregates
 
 This pass rewrites suitable non-aliased local aggregate variables into
-a set of scalar variables.  The resulting scalar variables are 
+a set of scalar variables.  The resulting scalar variables are
 rewritten into SSA form, which allows subsequent optimization passes
 to do a significantly better job with them.  The pass is located in
 @file{tree-sra.c} and is described by @code{pass_sra}.
@@ -410,7 +410,7 @@ by @code{pass_ccp}.
 
 @item Folding builtin functions
 
-This pass simplifies builtin functions, as applicable, with constant 
+This pass simplifies builtin functions, as applicable, with constant
 arguments or with inferrable string lengths.  It is located in
 @file{tree-ssa-ccp.c} and is described by @code{pass_fold_builtins}.
 
@@ -440,7 +440,7 @@ data and control flow problem is solved.  The code transformation
 requires target support, and so is delayed until RTL.  In the
 meantime @code{CALL_EXPR_TAILCALL} is set indicating the possibility.
 The pass is located in @file{tree-tailcall.c} and is described by
-@code{pass_tail_calls}.  The RTL transformation is handled by 
+@code{pass_tail_calls}.  The RTL transformation is handled by
 @code{fixup_tail_calls} in @file{calls.c}.
 
 @item Warn for function return without value
@@ -516,13 +516,13 @@ for this pass is located within @file{except.c}.
 This pass removes unreachable code, simplifies jumps to next, jumps to
 jump, jumps across jumps, etc.  The pass is run multiple times.
 For historical reasons, it is occasionally referred to as the ``jump
-optimization pass''.  The bulk of the code for this pass is in 
+optimization pass''.  The bulk of the code for this pass is in
 @file{cfgcleanup.c}, and there are support routines in @file{cfgrtl.c}
 and @file{jump.c}.
 
 @item Common subexpression elimination
 
-This pass removes redundant computation within basic blocks, and 
+This pass removes redundant computation within basic blocks, and
 optimizes addressing modes based on cost.  The pass is run twice.
 The source is located in @file{cse.c}.
 
@@ -617,12 +617,12 @@ completely target-specific.  The source is located in @file{lcm.c}.
 
 @cindex modulo scheduling
 @cindex sms, swing, software pipelining
-@item Modulo scheduling 
+@item Modulo scheduling
 
-This pass looks at innermost loops and reorders their instructions 
-by overlapping different iterations.  Modulo scheduling is performed 
+This pass looks at innermost loops and reorders their instructions
+by overlapping different iterations.  Modulo scheduling is performed
 immediately before instruction scheduling.
-The pass is located in (@file{modulo-sched.c}).  
+The pass is located in (@file{modulo-sched.c}).
 
 @item Instruction scheduling
 
index 3a72c16..84a2340 100644 (file)
@@ -1772,7 +1772,7 @@ saturates at the maximum signed value representable in @var{m};
 This expression represents the sum of @var{x} and the low-order bits
 of @var{y}.  It is used with @code{high} (@pxref{Constants}) to
 represent the typical two-instruction sequence used in RISC machines
-to reference a global memory location.  
+to reference a global memory location.
 
 The number of low order bits is machine-dependent but is
 normally the number of bits in a @code{Pmode} item minus the number of
index fd51833..ae7599b 100644 (file)
@@ -5024,7 +5024,7 @@ you define this macro, the compiler will use it instead of
 A C expression which is nonzero if @var{x} (assumed to be a @code{reg} RTX)
 is suitable for use as a base register in base plus index operand addresses,
 accessing memory in mode @var{mode}.  It may be either a suitable hard
-register or a pseudo register that has been allocated such a hard register. 
+register or a pseudo register that has been allocated such a hard register.
 You should define this macro if base plus index addresses have different
 requirements than other base register uses.
 @end defmac
index b5b9ad9..68c4f56 100644 (file)
@@ -102,7 +102,7 @@ place of the container.
 
 The compiler pass which lowers GENERIC to GIMPLE is referred to as the
 @samp{gimplifier}.  The gimplifier works recursively, replacing complex
-statements with sequences of simple statements.  
+statements with sequences of simple statements.
 
 @c Currently, the only way to
 @c tell whether or not an expression is in GIMPLE form is by recursively
@@ -195,7 +195,7 @@ GIMPLE rvalue (@code{is_gimple_val}), i.e.@: a constant or a register
 variable.  More complex operands are factored out into temporaries, so
 that
 @smallexample
-  a = b + c + d 
+  a = b + c + d
 @end smallexample
 becomes
 @smallexample
@@ -293,7 +293,7 @@ Most statements will be assignment statements, represented by
 @code{MODIFY_EXPR}.  A @code{CALL_EXPR} whose value is ignored can
 also be a statement.  No other C expressions can appear at statement level;
 a reference to a volatile object is converted into a @code{MODIFY_EXPR}.
-In GIMPLE form, type of @code{MODIFY_EXPR} is not meaningful. Instead, use type 
+In GIMPLE form, type of @code{MODIFY_EXPR} is not meaningful. Instead, use type
 of LHS or RHS.
 
 There are also several varieties of complex statements.
@@ -318,7 +318,7 @@ expressed using the @code{BIND_EXPR} code, which in previous versions of
 GCC was primarily used for the C statement-expression extension.
 
 Variables in a block are collected into @code{BIND_EXPR_VARS} in
-declaration order.  Any runtime initialization is moved out of 
+declaration order.  Any runtime initialization is moved out of
 @code{DECL_INITIAL} and into a statement in the controlled block.  When
 gimplifying from C or C++, this initialization replaces the
 @code{DECL_STMT}.
@@ -328,7 +328,7 @@ refers to variables initialized earlier in the block.  To handle this, we
 currently split the block at that point, and move the VLA into a new, inner
 @code{BIND_EXPR}.  This strategy may change in the future.
 
-@code{DECL_SAVED_TREE} for a GIMPLE function will always be a 
+@code{DECL_SAVED_TREE} for a GIMPLE function will always be a
 @code{BIND_EXPR} which contains declarations for the temporary variables
 used in the function.
 
@@ -422,7 +422,7 @@ edge.
 @cindex GIMPLE Exception Handling
 
 Other exception handling constructs are represented using
-@code{TRY_CATCH_EXPR}.  The handler operand of a @code{TRY_CATCH_EXPR} 
+@code{TRY_CATCH_EXPR}.  The handler operand of a @code{TRY_CATCH_EXPR}
 can be a normal statement to be executed if the controlled block throws an
 exception, or it can have one of two special forms:
 
@@ -711,7 +711,7 @@ operands, they are organized into arrays associated inside each
 statement's annotation.  Each element in an operand array is a pointer
 to a @code{VAR_DECL}, @code{PARM_DECL} or @code{SSA_NAME} tree node.
 This provides a very convenient way of examining and replacing
-operands.  
+operands.
 
 Data flow analysis and optimization is done on all tree nodes
 representing variables.  Any node for which @code{SSA_VAR_P} returns
@@ -755,12 +755,12 @@ In contrast, virtual operands are used with variables that can have
 a partial or ambiguous reference. This includes structures, arrays,
 globals, and aliased variables. In these cases, we have two types of
 definitions. For globals, structures, and arrays, we can determine from
-a statement whether a variable of these types has a killing definition. 
+a statement whether a variable of these types has a killing definition.
 If the variable does, then the statement is marked as having a
 @dfn{must definition} of that variable. However, if a statement is only
 defining a part of the variable (i.e.@: a field in a structure), or if we
 know that a statement might define the variable but we cannot say for sure,
-then we mark that statement as having a @dfn{may definition}.  For 
+then we mark that statement as having a @dfn{may definition}.  For
 instance, given
 
 @smallexample
@@ -814,9 +814,9 @@ incorrect assumptions about them.
 
 Operands are collected by @file{tree-ssa-operands.c}.  They are stored
 inside each statement's annotation and can be accessed with
-@code{DEF_OPS}, @code{USE_OPS}, @code{V_MAY_DEF_OPS}, 
-@code{V_MUST_DEF_OPS} and @code{VUSE_OPS}. The following are all the 
-accessor macros available to access USE operands.  To access all the 
+@code{DEF_OPS}, @code{USE_OPS}, @code{V_MAY_DEF_OPS},
+@code{V_MUST_DEF_OPS} and @code{VUSE_OPS}. The following are all the
+accessor macros available to access USE operands.  To access all the
 other operand arrays, just change the name accordingly:
 
 @defmac USE_OPS (@var{ann})
@@ -858,7 +858,7 @@ print_ops (tree stmt)
 
   get_stmt_operands (stmt);
   ann = stmt_ann (stmt);
-  
+
   defs = DEF_OPS (ann);
   for (i = 0; i < NUM_DEFS (defs); i++)
     print_generic_expr (stderr, DEF_OP (defs, i), 0);
@@ -866,7 +866,7 @@ print_ops (tree stmt)
   uses = USE_OPS (ann);
   for (i = 0; i < NUM_USES (uses); i++)
     print_generic_expr (stderr, USE_OP (uses, i), 0);
-  
+
   v_may_defs = V_MAY_DEF_OPS (ann);
   for (i = 0; i < NUM_V_MAY_DEFS (v_may_defs); i++)
     @{
@@ -877,7 +877,7 @@ print_ops (tree stmt)
   v_must_defs = V_MUST_DEF_OPS (ann);
   for (i = 0; i < NUM_V_MUST_DEFS (v_must_defs); i++)
     print_generic_expr (stderr, V_MUST_DEF_OP (v_must_defs, i), 0);
-  
+
   vuses = VUSE_OPS (ann);
   for (i = 0; i < NUM_VUSES (vuses); i++)
     print_generic_expr (stderr, VUSE_OP (vuses, i), 0);
@@ -914,23 +914,23 @@ print_ops (tree stmt)
 
 @enumerate
 @item Determine whether you are need to see the operand pointers, or just the
-    trees, and choose the appropriate macro: 
+    trees, and choose the appropriate macro:
 
 @smallexample
-Need            Macro: 
-----            ------- 
-use_operand_p   FOR_EACH_SSA_USE_OPERAND 
-def_operand_p   FOR_EACH_SSA_DEF_OPERAND 
-tree            FOR_EACH_SSA_TREE_OPERAND 
+Need            Macro:
+----            -------
+use_operand_p   FOR_EACH_SSA_USE_OPERAND
+def_operand_p   FOR_EACH_SSA_DEF_OPERAND
+tree            FOR_EACH_SSA_TREE_OPERAND
 @end smallexample
 
 @item You need to declare a variable of the type you are interested
     in, and an ssa_op_iter structure which serves as the loop
-    controlling variable. 
+    controlling variable.
 
 @item Determine which operands you wish to use, and specify the flags of
     those you are interested in.  They are documented in
-    @file{tree-ssa-operands.h}: 
+    @file{tree-ssa-operands.h}:
 
 @smallexample
 #define SSA_OP_USE              0x01    /* Real USE operands.  */
@@ -950,22 +950,22 @@ tree            FOR_EACH_SSA_TREE_OPERAND
 @end enumerate
 
 So if you want to look at the use pointers for all the @code{USE} and
-@code{VUSE} operands, you would do something like: 
+@code{VUSE} operands, you would do something like:
 
 @smallexample
-  use_operand_p use_p; 
-  ssa_op_iter iter; 
+  use_operand_p use_p;
+  ssa_op_iter iter;
 
   FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE))
-    @{ 
-      process_use_ptr (use_p); 
-    @} 
+    @{
+      process_use_ptr (use_p);
+    @}
 @end smallexample
 
 The @code{_TREE_} macro is basically the same as the @code{USE} and
 @code{DEF} macros, only with the use or def dereferenced via
 @code{USE_FROM_PTR (use_p)} and @code{DEF_FROM_PTR (def_p)}. Since we
-aren't using operand pointers, use and defs flags can be mixed. 
+aren't using operand pointers, use and defs flags can be mixed.
 
 @smallexample
   tree var;
@@ -983,22 +983,22 @@ Note that @code{V_MAY_DEFS} are broken into 2 flags, one for the
 @code{V_MAY_DEFS} together, there is a fourth iterator macro for this,
 which returns both a def_operand_p and a use_operand_p for each
 @code{V_MAY_DEF} in the statement. Note that you don't need any flags for
-this one. 
+this one.
 
 @smallexample
-  use_operand_p use_p; 
-  def_operand_p def_p; 
-  ssa_op_iter iter; 
-
-  FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter) 
-    @{ 
-      my_code; 
-    @} 
+  use_operand_p use_p;
+  def_operand_p def_p;
+  ssa_op_iter iter;
+
+  FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter)
+    @{
+      my_code;
+    @}
 @end smallexample
 
 
 There are many examples in the code as well, as well as the
-documentation in @file{tree-ssa-operands.h}. 
+documentation in @file{tree-ssa-operands.h}.
 
 
 @node SSA
@@ -1127,7 +1127,7 @@ Calls function @var{fn} at each reaching definition found.  Function
 (@var{def_stmt}) and a generic pointer to whatever state information
 that @var{fn} may want to maintain (@var{data}).  Function @var{fn} is
 able to stop the walk by returning @code{true}, otherwise in order to
-continue the walk, @var{fn} should return @code{false}.  
+continue the walk, @var{fn} should return @code{false}.
 
 Note, that if @var{def_stmt} is a @code{PHI} node, the semantics are
 slightly different.  For each argument @var{arg} of the PHI node, this