This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Patch to remove trailing whitespace in manual


I've applied the following patch to remove trailing whitespace from files 
in gcc/doc.  It passes "make info" and "make dvi".

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Index: ChangeLog
===================================================================
RCS file: /cvs/gcc/gcc/gcc/ChangeLog,v
retrieving revision 2.6180
diff -u -r2.6180 ChangeLog
--- ChangeLog	5 Nov 2004 00:15:48 -0000	2.6180
+++ ChangeLog	5 Nov 2004 00:51:47 -0000
@@ -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: doc/c-tree.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/c-tree.texi,v
retrieving revision 1.65
diff -u -r1.65 c-tree.texi
--- doc/c-tree.texi	28 Oct 2004 00:20:41 -0000	1.65
+++ doc/c-tree.texi	5 Nov 2004 00:51:48 -0000
@@ -2170,7 +2170,7 @@
 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: doc/cfg.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/cfg.texi,v
retrieving revision 1.6
diff -u -r1.6 cfg.texi
--- doc/cfg.texi	17 Sep 2004 13:57:03 -0000	1.6
+++ doc/cfg.texi	5 Nov 2004 00:51:48 -0000
@@ -229,7 +229,7 @@
 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 @@
 @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: doc/extend.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/extend.texi,v
retrieving revision 1.229
diff -u -r1.229 extend.texi
--- doc/extend.texi	5 Nov 2004 00:18:49 -0000	1.229
+++ doc/extend.texi	5 Nov 2004 00:51:51 -0000
@@ -3310,14 +3310,14 @@
 @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 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 @@
 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: doc/gty.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/gty.texi,v
retrieving revision 1.18
diff -u -r1.18 gty.texi
--- doc/gty.texi	4 Nov 2004 16:11:30 -0000	1.18
+++ doc/gty.texi	5 Nov 2004 00:51:51 -0000
@@ -61,7 +61,7 @@
 @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: doc/install.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.324
diff -u -r1.324 install.texi
--- doc/install.texi	28 Oct 2004 01:00:29 -0000	1.324
+++ doc/install.texi	5 Nov 2004 00:51:53 -0000
@@ -1235,7 +1235,7 @@
 @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 @@
 
 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: doc/invoke.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/invoke.texi,v
retrieving revision 1.554
diff -u -r1.554 invoke.texi
--- doc/invoke.texi	30 Oct 2004 20:22:54 -0000	1.554
+++ doc/invoke.texi	5 Nov 2004 00:51:58 -0000
@@ -1834,7 +1834,7 @@
 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 @@
 @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 @@
 
 @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 @@
 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 @@
 
 @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 @@
 @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 @@
 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 @@
 @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 @@
 @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 @@
 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 @@
 @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: doc/md.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/md.texi,v
retrieving revision 1.115
diff -u -r1.115 md.texi
--- doc/md.texi	1 Nov 2004 18:50:20 -0000	1.115
+++ doc/md.texi	5 Nov 2004 00:52:00 -0000
@@ -919,7 +919,7 @@
 @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: doc/passes.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/passes.texi,v
retrieving revision 1.45
diff -u -r1.45 passes.texi
--- doc/passes.texi	28 Oct 2004 01:00:31 -0000	1.45
+++ doc/passes.texi	5 Nov 2004 00:52:00 -0000
@@ -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 @@
 @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 @@
 @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 @@
 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 @@
 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 @@
 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 @@
 
 @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 @@
 @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 @@
 @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 @@
 
 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 @@
 
 @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 @@
 
 @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 @@
 
 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 @@
 
 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 @@
 @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 @@
 
 @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 @@
 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 @@
 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 @@
 
 @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: doc/rtl.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/rtl.texi,v
retrieving revision 1.73
diff -u -r1.73 rtl.texi
--- doc/rtl.texi	9 Oct 2004 19:27:48 -0000	1.73
+++ doc/rtl.texi	5 Nov 2004 00:52:01 -0000
@@ -1772,7 +1772,7 @@
 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: doc/tm.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/tm.texi,v
retrieving revision 1.389
diff -u -r1.389 tm.texi
--- doc/tm.texi	4 Nov 2004 13:23:23 -0000	1.389
+++ doc/tm.texi	5 Nov 2004 00:52:05 -0000
@@ -5024,7 +5024,7 @@
 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: doc/tree-ssa.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/tree-ssa.texi,v
retrieving revision 1.12
diff -u -r1.12 tree-ssa.texi
--- doc/tree-ssa.texi	25 Sep 2004 22:11:02 -0000	1.12
+++ doc/tree-ssa.texi	5 Nov 2004 00:52:06 -0000
@@ -102,7 +102,7 @@
 
 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 @@
 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 @@
 @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 @@
 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 @@
 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 @@
 @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 @@
 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 @@
 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 @@
 
 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 @@
 
   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 @@
   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 @@
   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 @@
 
 @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 @@
 @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 @@
 @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; 
+  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; 
-    @} 
+  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 @@
 (@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]