Merge tree-ssa-20020619-branch into mainline.

From-SVN: r81764

11 files changed, 2700 insertions, 562 deletions

diff --git a/gcc/doc/c-tree.texi b/gcc/doc/c-tree.texi
index 8cd059e..d99c568 100644
--- a/gcc/doc/c-tree.texi
+++ b/gcc/doc/c-tree.texi
@@ -438,7 +438,7 @@ suppose that there were a 24-bit integer type, but that alignment
 requirements for the ABI required 32-bit alignment.  Then,
 @code{TYPE_SIZE} would be an @code{INTEGER_CST} for 32, while
 @code{TYPE_PRECISION} would be 24.)  The integer type is unsigned if
-@code{TREE_UNSIGNED} holds; otherwise, it is signed.
+@code{TYPE_UNSIGNED} holds; otherwise, it is signed.
 
 The @code{TYPE_MIN_VALUE} is an @code{INTEGER_CST} for the smallest
 integer that may be represented by this type.  Similarly, the
@@ -457,7 +457,7 @@ Used to represent GCC built-in @code{__complex__} data types.  The
 @item ENUMERAL_TYPE
 Used to represent an enumeration type.  The @code{TYPE_PRECISION} gives
 (as an @code{int}), the number of bits used to represent the type.  If
-there are no negative enumeration constants, @code{TREE_UNSIGNED} will
+there are no negative enumeration constants, @code{TYPE_UNSIGNED} will
 hold.  The minimum and maximum enumeration constants may be obtained
 with @code{TYPE_MIN_VALUE} and @code{TYPE_MAX_VALUE}, respectively; each
 of these macros returns an @code{INTEGER_CST}.
@@ -856,13 +856,13 @@ entity.
 @item TREE_TYPE
 This macro returns the type of the entity declared.
 
-@item DECL_SOURCE_FILE
+@item TREE_FILENAME
 This macro returns the name of the file in which the entity was
 declared, as a @code{char*}.  For an entity declared implicitly by the
 compiler (like @code{__builtin_memcpy}), this will be the string
 @code{"<internal>"}.
 
-@item DECL_SOURCE_LINE
+@item TREE_LINENO
 This macro returns the line number at which the entity was declared, as
 an @code{int}.
 
@@ -1298,8 +1298,6 @@ This predicate holds if the function an overloaded
 @findex FOR_COND
 @findex FOR_EXPR
 @findex FOR_BODY
-@tindex FILE_STMT
-@findex FILE_STMT_FILENAME
 @tindex GOTO_STMT
 @findex GOTO_DESTINATION
 @findex GOTO_FAKE_P
@@ -1343,24 +1341,13 @@ the outermost block of the function, but it may also be a
 
 @subsubsection Statements
 
-There are tree nodes corresponding to all of the source-level statement
-constructs.  These are enumerated here, together with a list of the
-various macros that can be used to obtain information about them.  There
-are a few macros that can be used with all statements:
+There are tree nodes corresponding to all of the source-level
+statement constructs, used within the C and C++ frontends.  These are
+enumerated here, together with a list of the various macros that can
+be used to obtain information about them.  There are a few macros that
+can be used with all statements:
 
 @ftable @code
-@item STMT_LINENO
-This macro returns the line number for the statement.  If the statement
-spans multiple lines, this value will be the number of the first line on
-which the statement occurs.  Although we mention @code{CASE_LABEL} below
-as if it were a statement, they do not allow the use of
-@code{STMT_LINENO}.  There is no way to obtain the line number for a
-@code{CASE_LABEL}.
-
-Statements do not contain information about
-the file from which they came; that information is implicit in the
-@code{FUNCTION_DECL} from which the statements originate.
-
 @item STMT_IS_FULL_EXPR_P
 In C++, statements normally constitute ``full expressions''; temporaries
 created during a statement are destroyed when the statement is complete.
@@ -1523,11 +1510,6 @@ address is never taken.  (All such objects are interchangeable.)  The
 Used to represent an expression statement.  Use @code{EXPR_STMT_EXPR} to
 obtain the expression.
 
-@item FILE_STMT
-
-Used to record a change in filename within the body of a function.
-Use @code{FILE_STMT_FILENAME} to obtain the new filename.
-
 @item FOR_STMT
 
 Used to represent a @code{for} statement.  The @code{FOR_INIT_STMT} is
@@ -2213,9 +2195,9 @@ the @code{STMT_EXPR} does not yield a value, it's type will be
 
 @item BIND_EXPR
 These nodes represent local blocks.  The first operand is a list of
-temporary variables, connected via their @code{TREE_CHAIN} field.  These
-will never require cleanups.  The scope of these variables is just the
-body of the @code{BIND_EXPR}.  The body of the @code{BIND_EXPR} is the
+variables, connected via their @code{TREE_CHAIN} field.  These will
+never require cleanups.  The scope of these variables is just the body
+of the @code{BIND_EXPR}.  The body of the @code{BIND_EXPR} is the
 second operand.
 
 @item LOOP_EXPR
diff --git a/gcc/doc/cfg.texi b/gcc/doc/cfg.texi
new file mode 100644
index 0000000..58a890c
--- /dev/null
+++ b/gcc/doc/cfg.texi
@@ -0,0 +1,614 @@
+@c -*-texinfo-*-
+@c Copyright (C) 2001, 2003, 2004 Free Software Foundation, Inc.
+@c This is part of the GCC manual.
+@c For copying conditions, see the file gcc.texi.
+
+@c ---------------------------------------------------------------------
+@c Control Flow Graph
+@c ---------------------------------------------------------------------
+
+@node Control Flow
+@chapter Control Flow Graph
+@cindex CFG, Control Flow Graph
+@findex basic-block.h
+
+A control flow graph (CFG) is a data structure built on top of the
+intermediate code representation (the RTL or @code{tree} instruction
+stream) abstracting the control flow behavior of a function that is
+being compiled.  The CFG is a directed graph where the vertices
+represent basic blocks and edges represent possible transfer of
+control flow from one basic block to another.  The data structures
+used to represent the control flow graph are defined in
+@file{basic-block.h}.
+
+@menu
+* Basic Blocks::           The definition and representation of basic blocks.
+* Edges::                  Types of edges and their representation.
+* Profile information::    Representation of frequencies and probabilities.
+* Maintaining the CFG::    Keeping the control flow graph and up to date.
+* Liveness information::   Using and maintaining liveness information.
+@end menu
+
+
+@node Basic Blocks
+@section Basic Blocks
+
+@cindex basic block
+@findex basic_block
+A basic block is a straight-line sequence of code with only one entry
+point and only one exit.  In GCC, basic blocks are represented using
+the @code{basic_block} data type.
+
+@findex next_bb, prev_bb, FOR_EACH_BB
+Two pointer members of the @code{basic_block} structure are the
+pointers @code{next_bb} and @code{prev_bb}.  These are used to keep
+doubly linked chain of basic blocks in the same order as the
+underlying instruction stream.  The chain of basic blocks is updated
+transparently by the provided API for manipulating the CFG.  The macro
+@code{FOR_EACH_BB} can be used to visit all the basic blocks in
+lexicographical order.  Dominator traversals are also possible using
+@code{walk_dominator_tree}.
+
+@findex BASIC_BLOCK
+The @code{BASIC_BLOCK} array contains all basic blocks in an
+unspecified order.  Each @code{basic_block} structure has a field
+that holds a unique integer identifier @code{index} that is the
+index of the block in the @code{BASIC_BLOCK} array.
+The total number of basic blocks in the function is
+@code{n_basic_blocks}.  Both the basic block indices and
+the total number of basic blocks may vary during the compilation
+process, as passes reorder, create, duplicate, and destroy basic
+blocks.  The index for any block should never be greater than
+@code{last_basic_block}.
+
+@findex ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR
+Special basic blocks represent possible entry and exit points of a
+function.  These blocks are called @code{ENTRY_BLOCK_PTR} and
+@code{EXIT_BLOCK_PTR}.  These blocks do not contain any code, and are
+not elements of the @code{BASIC_BLOCK} array.  Therefore they have
+been assigned unique, negative index numbers.
+
+Each @code{basic_block} also contains pointers to the first
+instruction (the @dfn{head}) and the last instruction (the @dfn{tail})
+or @dfn{end} of the instruction stream contained in a basic block.  In
+fact, since the @code{basic_block} data type is used to represent
+blocks in both major intermediate representations of GCC (@code{tree}
+and RTL), there are pointers to the head and end of a basic block for
+both representations.
+
+@findex NOTE_INSN_BASIC_BLOCK, CODE_LABEL, notes
+For RTL, these pointers are @code{rtx head, end}.  In the RTL function
+representation, the head pointer always points either to a
+@code{NOTE_INSN_BASIC_BLOCK} or to a @code{CODE_LABEL}, if present.
+In the RTL representation of a function, the instruction stream
+contains not only the ``real'' instructions, but also @dfn{notes}.
+Any function that moves or duplicates the basic blocks needs
+to take care of updating of these notes.  Many of these notes expect
+that the instruction stream consists of linear regions, making such
+updates difficult.   The @code{NOTE_INSN_BASIC_BLOCK} note is the only
+kind of note that may appear in the instruction stream contained in a
+basic block.  The instruction stream of a basic block always follows a
+@code{NOTE_INSN_BASIC_BLOCK},  but zero or more @code{CODE_LABEL}
+nodes can precede the block note.   A basic block ends by control flow
+instruction or last instruction before following @code{CODE_LABEL} or
+@code{NOTE_INSN_BASIC_BLOCK}.  A @code{CODE_LABEL} cannot appear in
+the instruction stream of a basic block.
+
+@findex can_fallthru
+@cindex table jump
+In addition to notes, the jump table vectors are also represented as
+``pseudo-instructions'' inside the insn stream.  These vectors never
+appear in the basic block and should always be placed just after the
+table jump instructions referencing them.  After removing the
+table-jump it is often difficult to eliminate the code computing the
+address and referencing the vector, so cleaning up these vectors is
+postponed until after liveness analysis.   Thus the jump table vectors
+may appear in the insn stream unreferenced and without any purpose.
+Before any edge is made @dfn{fall-thru}, the existence of such
+construct in the way needs to be checked by calling
+@code{can_fallthru} function.
+
+@cindex block statement iterators
+For the @code{tree} representation, the head and end of the basic block
+are being pointed to by the @code{stmt_list} field, but this special
+@code{tree} should never be referenced directly.  Instead, at the tree
+level abstract containers and iterators are used to access statements
+and expressions in basic blocks.  These iterators are called
+@dfn{block statement iterators} (BSIs).  Grep for @code{^bsi}
+in the various @file{tree-*} files.
+The following snippet will pretty-print all the statements of the
+program in the GIMPLE representation.
+
+@example
+FOR_EACH_BB (bb)
+  @{
+     block_stmt_iterator si;
+
+     for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (&si))
+       @{
+          tree stmt = bsi_stmt (si);
+          print_generic_stmt (stderr, stmt, 0);
+       @}
+  @}
+@end example
+
+
+@node Edges
+@section Edges
+
+@cindex edge in the flow graph
+@findex edge
+Edges represent possible control flow transfers from the end of some
+basic block A to the head of another basic block B.  We say that A is
+a predecessor of B, and B is a successor of A.  Edges are represented
+in GCC with the @code{edge} data type.  Each @code{edge} acts as a
+link between two basic blocks: the @code{src} member of an edge
+points to the predecessor basic block of the @code{dest} basic block.
+The members @code{pred} and @code{succ} of the @code{basic_block} data
+type point to single linked lists of edges to the predecessors and
+successorts of the block.  The edges are linked via the
+@code{succ_next} and @code{pred_next} members of the @code{edge} data
+type.
+
+@findex fall-thru
+There are various reasons why control flow may transfer from one block
+to another.  One possibility is that some instruction, for example a
+@code{CODE_LABEL}, in a linearized instruction stream just always
+starts a new basic block.  In this case a @dfn{fall-thru} edge links
+the basic block to the first following basic block.  But there are
+several other reasons why edges may be created.  The @code{flags}
+field of the @code{edge} data type is used to store information
+about the type of edge we are dealing with.  Each edge is of one of
+the following types:
+
+@table @emph
+@item jump
+No type flags are set for edges corresponding to jump instructions.
+These edges are used for unconditional or conditional jumps and in
+RTL also for table jumps.  They are the easiest to manipulate as they
+may be freely redirected when the flow graph is not in SSA form.
+
+@item fall-thru
+@findex EDGE_FALLTHRU, force_nonfallthru
+Fall-thru edges are present in case where the basic block may continue
+execution to the following one without branching.  These edges have
+the @code{EDGE_FALLTHRU} flag set. Unlike other types of edges, these
+edges must come into the basic block immediately following in the
+instruction stream.  The function @code{force_nonfallthru} is
+available to insert an unconditional jump in the case that redirection
+is needed.  Note that this may require creation of a new basic block.
+
+@item exception handling
+@cindex exception handling
+@findex EDGE_ABNORMAL, EDGE_EH
+Exception handling edges represent possible control transfers from a
+trapping instruction to an exception handler.  The definition of
+``trapping'' varies.  In C++, only function calls can throw, but for
+Java, exceptions like division by zero or segmentation fault are
+defined and thus each instruction possibly throwing this kind of
+exception needs to be handled as control flow instruction.  Exception
+edges have the @code{EDGE_ABNORMAL} and @code{EDGE_EH} flags set.
+
+@findex purge_dead_edges
+When updating the instruction stream it is easy to change possibly
+trapping instruction to non-trapping, by simply removing the exception
+edge. The opposite conversion is difficult, but should not happen
+anyway.  The edges can be eliminated via @code{purge_dead_edges} call.
+
+@findex REG_EH_REGION, EDGE_ABNORMAL_CALL
+In the RTL representation, the destination of an exception edge is
+specified by @code{REG_EH_REGION} note attached to the insn.
+In case of a trapping call the @code{EDGE_ABNORMAL_CALL} flag is set
+too.  In the @code{tree} representation, this extra flag is not set.
+
+@findex may_trap_p, tree_could_trap_p
+In the RTL representation, the predicate @code{may_trap_p} may be used
+to check whether instruction still may trap or not.  For the tree
+representation, the @code{tree_could_trap_p} predicate is available,
+but this predicate only checks for possible memory traps, as in
+dereferencing an invalid pointer location.
+
+
+@item sibling calls
+@cindex sibling call
+@findex EDGE_ABNORMAL, EDGE_SIBCALL
+Sibling calls or tail calls terminate the function in a non-standard
+way and thus an edge to the exit must be present.
+@code{EDGE_SIBCALL} and @code{EDGE_ABNORMAL} are set in such case.
+These edges only exist in the RTL representation.
+
+@item computed jumps
+@cindex computed jump
+@findex EDGE_ABNORMAL
+Computed jumps contain edges to all labels in the function referenced
+from the code.  All those edges have @code{EDGE_ABNORMAL} flag set.
+The edges used to represent computed jumps often cause compile time
+performance problems, since functions consisting of many taken labels
+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, 
+
+@example
+  goto *x;
+  [ ... ]
+
+  goto *x;
+  [ ... ]
+
+  goto *x;
+  [ ... ]
+@end example
+
+@noindent
+factoring the computed jumps results in the following code sequence
+which has a much simpler flow graph:
+
+@example
+  goto y;
+  [ ... ]
+
+  goto y;
+  [ ... ]
+
+  goto y;
+  [ ... ]
+
+y:
+  goto *x;
+@end example
+
+However, the classic problem with this transformation is that it has a
+runtime cost in there resulting code: An extra jump.  Therefore, the
+computed jumps are un-factored in the later passes of the compiler.
+Be aware of that when you work on passes in that area.  There have
+been numerous examples already where the compile time for code with
+unfactored computed jumps caused some serious headaches.
+
+@item nonlocal goto handlers
+@cindex nonlocal goto handler
+@findex EDGE_ABNORMAL, EDGE_ABNORMAL_CALL
+GCC allows nested functions to return into caller using a @code{goto}
+to a label passed to as an argument to the callee.  The labels passed
+to nested functions contain special code to cleanup after function
+call.  Such sections of code are referred to as ``nonlocal goto
+receivers''.  If a function contains such nonlocal goto receivers, an
+edge from the call to the label is created with the
+@code{EDGE_ABNORMAL} and @code{EDGE_ABNORMAL_CALL} flags set.
+
+@item function entry points
+@cindex function entry point, alternate function entry point
+@findex LABEL_ALTERNATE_NAME
+By definition, execution of function starts at basic block 0, so there
+is always an edge from the @code{ENTRY_BLOCK_PTR} to basic block 0.
+There is no @code{tree} representation for alternate entry points at
+this moment.  In RTL, alternate entry points are specified by
+@code{CODE_LABEL} with @code{LABEL_ALTERNATE_NAME} defined.  This
+feature is currently used for multiple entry point prologues and is
+limited to post-reload passes only.  This can be used by back-ends to
+emit alternate prologues for functions called from different contexts.
+In future full support for multiple entry functions defined by Fortran
+90 needs to be implemented.
+
+@item function exits
+In the pre-reload representation a function terminates after the last
+instruction in the insn chain and no explicit return instructions are
+used.  This corresponds to the fall-thru edge into exit block.  After
+reload, optimal RTL epilogues are used that use explicit (conditional)
+return instructions that are represented by edges with no flags set.
+
+@end table
+
+
+@node Profile information
+@section Profile information
+
+@cindex profile representation
+In many cases a compiler must make a choice whether to trade speed in
+one part of code for speed in another, or to trade code size for code
+speed.  In such cases it is useful to know information about how often
+some given block will be executed.  That is the purpose for
+maintaining profile within the flow graph.
+GCC can handle profile information obtained through @dfn{profile
+feedback}, but it can also  estimate branch probabilities based on
+statics and heuristics.
+
+@cindex profile feedback
+The feedback based profile is produced by compiling the program with
+instrumentation, executing it on a train run and reading the numbers
+of executions of basic blocks and edges back to the compiler while
+re-compiling the program to produce the final executable.  This method
+provides very accurate information about where a program spends most
+of its time on the train run.  Whether it matches the average run of
+course depends on the choice of train data set, but several studies
+have shown that the behavior of a program usually changes just
+marginally over different data sets.
+
+@cindex Static profile estimation
+@cindex branch prediction
+@findex predict.def
+When profile feedback is not available, the compiler may be asked to
+attempt to predict the behavior of each branch in the program using a
+set of heuristics (see @file{predict.def} for details) and compute
+estimated frequencies of each basic block by propagating the
+probabilities over the graph.
+
+@findex frequency, count, BB_FREQ_BASE
+Each @code{basic_block} contains two integer fields to represent
+profile information: @code{frequency} and @code{count}.  The
+@code{frequency} is an estimation how often is basic block executed
+within a function.  It is represented as an integer scaled in the
+range from 0 to @code{BB_FREQ_BASE}.  The most frequently executed
+basic block in function is initially set to @code{BB_FREQ_BASE} and
+the rest of frequencies are scaled accordingly.  During optimization,
+the frequency of the most frequent basic block can both decrease (for
+instance by loop unrolling) or grow (for instance by cross-jumping
+optimization), so scaling sometimes has to be performed multiple
+times.
+
+@findex gcov_type
+The @code{count} contains hard-counted numbers of execution measured
+during training runs and is nonzero only when profile feedback is
+available.  This value is represented as the host's widest integer
+(typically a 64 bit integer) of the special type @code{gcov_type}.
+
+Most optimization passes can use only the frequency information of a
+basic block, but a few passes may want to know hard execution counts.
+The frequencies should always match the counts after scaling, however
+during updating of the profile information numerical error may
+accumulate into quite large errors.
+
+@findex REG_BR_PROB_BASE, EDGE_FREQUENCY
+Each edge also contains a branch probability field: an integer in the
+range from 0 to @code{REG_BR_PROB_BASE}.  It represents probability of
+passing control from the end of the @code{src} basic block to the
+@code{dest} basic block, i.e. the probability that control will flow
+along this edge.   The @code{EDGE_FREQUENCY} macro is available to
+compute how frequently a given edge is taken. There is a @code{count}
+field for each edge as well, representing same information as for a
+basic block.
+
+The basic block frequencies are not represented in the instruction
+stream, but in the RTL representation the edge frequencies are
+represented for conditional jumps (via the @code{REG_BR_PROB}
+macro) since they are used when instructions are output to the
+assembly file and the flow graph is no longer maintained.
+
+@cindex reverse probability
+The probability that control flow arrives via a given edge to its
+destination basic block is called @dfn{reverse probability} and is not
+directly represented, but it may be easily computed from frequencies
+of basic blocks.
+
+@findex redirect_edge_and_branch
+Updating profile information is a delicate task that can unfortunately
+not be easily integrated with the CFG manipulation API.  Many of the
+functions and hooks to modify the CFG, such as
+@code{redirect_edge_and_branch}, do not have enough information to
+easily update the profile, so updating it is in the majority of cases
+left up to the caller.  It is difficult to uncover bugs in the profile
+updating code, because they manifest themselves only by producing
+worse code, and checking profile consistency is not possible because
+of numeric error accumulation.  Hence special attention needs to be
+given to this issue in each pass that modifies the CFG.
+
+@findex REG_BR_PROB_BASE, BB_FREQ_BASE, count
+It is important to point out that @code{REG_BR_PROB_BASE} and
+@code{BB_FREQ_BASE} are both set low enough to be possible to compute
+second power of any frequency or probability in the flow graph, it is
+not possible to even square the @code{count} field, as modern CPUs are
+fast enough to execute $2^32$ operations quickly.
+
+
+@node Maintaining the CFG
+@section Maintaining the CFG
+@findex cfghooks.h
+
+An important task of each compiler pass is to keep both the control
+flow graph and all profile information up-to-date.  Reconstruction of
+the control flow graph after each pass is not an option, since it may be
+very expensive and lost profile information cannot be reconstructed at
+all.
+
+GCC has two major intermediate representations, and both use the
+@code{basic_block} and @code{edge} data types to represent control
+flow.  Both representations share as much of the CFG maintenance code
+as possible.  For each representation, a set of @dfn{hooks} is defined
+so that each representation can provide its own implementation of CFG
+manipulation routines when necessary.  These hooks are defined in
+@file{cfghooks.h}.  There are hooks for almost all common CFG
+manipulations, including block splitting and merging, edge redirection
+and creating and deleting basic blocks.  These hooks should provide
+everything you need to maintain and manipulate the CFG in both the RTL
+and @code{tree} representation.
+
+At the moment, the basic block boundaries are maintained transparently
+when modifying instructions, so there rarely is a need to move them
+manually (such as in case someone wants to output instruction outside
+basic block explicitly).
+Often the CFG may be better viewed as integral part of instruction
+chain, than structure built on the top of it.  However, in principle
+the control flow graph for the @code{tree} representation is
+@emph{not} an integral part of the representation, in that a function
+tree may be expanded without first building a  flow graph for the
+@code{tree} representation at all.  This happens when compiling
+without any @code{tree} optimization enabled.  When the @code{tree}
+optimizations are enabled and the instruction stream is rewritten in
+SSA form, the CFG is very tightly coupled with the instruction stream.
+In particular, statement insertion and removal has to be done with
+care.  In fact, the whole @code{tree} representation can not be easily
+used or maintained without proper maintenance of the CFG
+simultaneously.
+
+@findex BLOCK_FOR_INSN, bb_for_stmt
+In the RTL representation, each instruction has a
+@code{BLOCK_FOR_INSN} value that represents pointer to the basic block
+that contains the instruction.  In the @code{tree} representation, the
+function @code{bb_for_stmt} returns a pointer to the basic block
+containing the queried statement.
+
+@cindex block statement iterators
+When changes need to be applied to a function in its @code{tree}
+representation, @dfn{block statement iterators} should be used.  These
+iterators provide an integrated abstraction of the flow graph and the
+instruction stream.  Block statement iterators iterators are
+constructed using the @code{block_stmt_iterator} data structure and
+several modifier are available, including the following:
+
+@table @code
+@item bsi_start
+@findex bsi_start
+This function initializes a @code{block_stmt_iterator} that points to
+the first non-empty statement in a basic block.
+
+@item bsi_last
+@findex bsi_last
+This function initializes a @code{block_stmt_iterator} that points to
+the last statement in a basic block.
+
+@item bsi_end_p
+@findex bsi_end_p
+This predicate is @code{true} if a @code{block_stmt_iterator}
+represents the end of a basic block.
+
+@item bsi_next
+@findex bsi_next
+This function takes a @code{block_stmt_iterator} and makes it point to
+its successor.
+
+@item bsi_prev
+@item bsi_prev
+This function takes a @code{block_stmt_iterator} and makes it point to
+its predecessor.
+
+@item bsi_insert_after
+@findex bsi_insert_after
+This function inserts a statement after the @code{block_stmt_iterator}
+passed in.  The final parameter determines whether the statement
+iterator is updated to point to the newly inserted statement, or left
+pointing to the original statement.
+
+@item bsi_insert_before
+@findex bsi_insert_before
+This function inserts a statement before the @code{block_stmt_iterator}
+passed in.  The final parameter determines whether the statement
+iterator is updated to point to the newly inserted statement, or left
+pointing to the original  statement.
+
+@item bsi_remove
+This function removes the @code{block_stmt_iterator} passed in and
+rechains the remaining statements in a basic block, if any.
+
+@end table
+
+@findex BB_HEAD, BB_END
+In the RTL representation, the macros @code{BB_HEAD} and @code{BB_END}
+may be used to get the head and end @code{rtx} of a basic block.  No
+abstract iterators are defined for traversing the insn chain, but you
+can just use @code{NEXT_INSN} and @code{PREV_INSN} instead.  See
+@xref{Insns}.
+
+@findex purge_dead_edges
+Usually a code manipulating pass simplifies the instruction stream and
+the flow of control, possibly eliminating some edges.  This may for
+example happen when a conditional jump is replaced with an
+unconditional jump, but also when simplifying possibly trapping
+instruction to non-trapping while compiling Java.  Updating of edges
+is not transparent and each optimization pass is required to do so
+manually.  However only few cases occur in practice.  The pass may
+call @code{purge_dead_edges} on a given basic block to remove
+superfluous edges, if any.
+
+@findex redirect_edge_and_branch, redirect_jump
+Another common scenario is redirection of branch instructions, but
+this is best modeled as redirection of edges in the control flow graph
+and thus use of @code{redirect_edge_and_branch} is preferred over more
+low level functions, such as @code{redirect_jump} that operate on RTL
+chain only.  The CFG hooks defined in @file{cfghooks.h} should provide
+the complete API required for manipulating and maintaining the CFG.
+
+@findex find_sub_basic_blocks, split_block
+It is also possible that a pass has to insert control flow instruction
+into the middle of a basic block, thus creating an entry point in the
+middle of the basic block, which is impossible by definition: The
+block must be split to make sure it only has one entry point, i.e. the
+head of the basic block.  In the RTL representation, the
+@code{find_sub_basic_blocks} may be used to split existing basic block
+and add necessary edges.  The CFG hook @code{split_block} may be used
+when an instruction in the middle of a basic block has to become the
+target of a jump or branch instruction.
+
+@findex insert_insn_on_edge, commit_edge_insertions
+@findex bsi_insert_on_edge, bsi_commit_edge_inserts
+@cindex edge splitting
+For a global optimizer, a common operation is to split edges in the
+flow graph and insert instructions on them.  In the RTL
+representation, this can be easily done using the
+@code{insert_insn_on_edge} function that emits an instruction
+``on the edge'', caching it for a later @code{commit_edge_insertions}
+call that will take care of moving the inserted instructions off the
+edge into the instruction stream contained in a basic block.  This
+includes the creation of new basic blocks where needed.  In the
+@code{tree} representation, the equivalent functions are
+@code{bsi_insert_on_edge} which inserts a block statement
+iterator on an edge, and @code{bsi_commit_edge_inserts} which flushes
+the instruction to actual instruction stream.
+
+While debugging the optimization pass, an @code{verify_flow_info}
+function may be useful to find bugs in the control flow graph updating
+code.
+
+Note that at present, the representation of control flow in the
+@code{tree} representation is discarded before expanding to RTL.
+Long term the CFG should be maintained and ``expanded'' to the
+RTL representation along with the function @code{tree} itself.
+
+
+@node Liveness information
+@section Liveness information
+@cindex Liveness representation
+Liveness information is useful to determine whether some register is
+``live'' at given point of program, i.e. that it contains a value that
+may be used at a later point in the program.  This information is
+used, for instance, during register allocation, as the pseudo
+registers only need to be assigned to a unique hard register or to a
+stack slot if they are live.  The hard registers and stack slots may
+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: 
+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
+instruction is never used.  The second is useful for instructions
+computing multiple values at once.
+
+@findex global_live_at_start, global_live_at_end
+Global liveness information is stored in the control flow graph.
+Each basic block contains two bitmaps, @code{global_live_at_start} and
+@code{global_live_at_end} representing liveness of each register at
+the entry and exit of the basic block.  The file @code{flow.c}
+contains functions to compute liveness of each register at any given
+place in the instruction stream using this information.
+
+@findex BB_DIRTY, clear_bb_flags, update_life_info_in_dirty_blocks
+Liveness is expensive to compute and thus it is desirable to keep it
+up to date during code modifying passes.  This can be easily
+accomplished using the @code{flags} field of a basic block.  Functions
+modifying the instruction stream automatically set the @code{BB_DIRTY}
+flag of a modifies basic block, so the pass may simply
+use@code{clear_bb_flags} before doing any modifications and then ask
+the data flow module to have liveness updated via the
+@code{update_life_info_in_dirty_blocks} function.
+
+This scheme works reliably as long as no control flow graph
+transformations are done.  The task of updating liveness after control
+flow graph changes is more difficult as normal iterative data flow
+analysis may produce invalid results or get into an infinite cycle
+when the initial solution is not below the desired one.  Only simple
+transformations, like splitting basic blocks or inserting on edges,
+are safe, as functions to implement them already know how to update
+liveness information locally.
diff --git a/gcc/doc/gccint.texi b/gcc/doc/gccint.texi
index 7ce5dde..5dbe1f7 100644
--- a/gcc/doc/gccint.texi
+++ b/gcc/doc/gccint.texi
@@ -140,6 +140,8 @@ Additional tutorial information is linked to from
 * Passes::          Order of passes, what they do, and what each file is for.
 * Trees::           The source representation used by the C and C++ front ends.
 * RTL::             The intermediate representation that most passes work on.
+* Control Flow::    Maintaining and manipulating the control flow graph.
+* Tree SSA::        Analysis and optimization of the tree representation.
 * Machine Desc::    How to write machine description instruction patterns.
 * Target Macros::   How to write the machine description C macros and functions.
 * Host Config::     Writing the @file{xm-@var{machine}.h} file.
@@ -168,7 +170,9 @@ Additional tutorial information is linked to from
 @include sourcebuild.texi
 @include passes.texi
 @include c-tree.texi
+@include tree-ssa.texi
 @include rtl.texi
+@include cfg.texi
 @include md.texi
 @include tm.texi
 @include hostconfig.texi
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index a70b66b..599b917 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -429,11 +429,11 @@ components.
 Please refer to our @uref{http://gcc.gnu.org/releases.html,,releases web page}
 for information on how to obtain GCC@.
 
-The full distribution includes the C, C++, Objective-C, Fortran, Java,
-and Ada (in case of GCC 3.1 and later) compilers.  The full distribution
-also includes runtime libraries for C++, Objective-C, Fortran, and Java.
-In GCC 3.0 and later versions, GNU compiler testsuites are also included
-in the full distribution.
+The full distribution includes the C, C++, Objective-C, Fortran 77, Fortran
+(in case of GCC 3.5 and later), Java, and Ada (in case of GCC 3.1 and later)
+compilers.  The full distribution also includes runtime libraries for C++,
+Objective-C, Fortran 77, Fortran, and Java.  In GCC 3.0 and later versions,
+GNU compiler testsuites are also included in the full distribution.
 
 If you choose to download specific components, you must download the core
 GCC distribution plus any language specific distributions you wish to
@@ -1029,7 +1029,8 @@ their runtime libraries should be built.  For a list of valid values for
 grep language= */config-lang.in
 @end smallexample
 Currently, you can use any of the following:
-@code{ada}, @code{c}, @code{c++}, @code{f77}, @code{java}, @code{objc}.
+@code{ada}, @code{c}, @code{c++}, @code{f77}, @code{f95}, @code{java},
+@code{objc}.
 Building the Ada compiler has special requirements, see below.@*
 If you do not pass this flag, all languages available in the @file{gcc}
 sub-tree will be configured.  Re-defining @code{LANGUAGES} when calling
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ff1e34a..3144fd1 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -245,11 +245,24 @@ in the following sections.
 @gccoptlist{-d@var{letters}  -dumpspecs  -dumpmachine  -dumpversion @gol
 -fdump-unnumbered  -fdump-translation-unit@r{[}-@var{n}@r{]} @gol
 -fdump-class-hierarchy@r{[}-@var{n}@r{]} @gol
+-fdump-tree-all @gol
 -fdump-tree-original@r{[}-@var{n}@r{]}  @gol
 -fdump-tree-optimized@r{[}-@var{n}@r{]} @gol
 -fdump-tree-inlined@r{[}-@var{n}@r{]} @gol
+-fdump-tree-cfg -fdump-tree-vcg -fdump-tree-alias @gol
+-fdump-tree-ch @gol
+-fdump-tree-ssa@r{[}-@var{n}@r{]} -fdump-tree-pre@r{[}-@var{n}@r{]} @gol
+-fdump-tree-ccp@r{[}-@var{n}@r{]} -fdump-tree-dce@r{[}-@var{n}@r{]} @gol
+-fdump-tree-gimple@r{[}-raw@r{]} -fdump-tree-mudflap@r{[}-@var{n}@r{]} @gol
+-fdump-tree-dom@r{[}-@var{n}@r{]} @gol
+-fdump-tree-dse@r{[}-@var{n}@r{]} @gol
+-fdump-tree-phiopt@r{[}-@var{n}@r{]} @gol
+-fdump-tree-forwprop@r{[}-@var{n}@r{]} @gol
+-fdump-tree-copyrename@r{[}-@var{n}@r{]} @gol
+-fdump-tree-nrv @gol
+-fdump-tree-sra@r{[}-@var{n}@r{]} @gol
 -feliminate-dwarf2-dups -feliminate-unused-debug-types @gol
--feliminate-unused-debug-symbols -fmem-report -fprofile-arcs @gol
+-feliminate-unused-debug-symbols -fmem-report -fprofile-arcs -ftree-based-profiling @gol
 -frandom-seed=@var{string} -fsched-verbose=@var{n} @gol
 -ftest-coverage  -ftime-report -fvar-tracking @gol
 -g  -g@var{level}  -gcoff -gdwarf-2 @gol
@@ -263,6 +276,7 @@ in the following sections.
 @xref{Optimize Options,,Options that Control Optimization}.
 @gccoptlist{-falign-functions=@var{n}  -falign-jumps=@var{n} @gol
 -falign-labels=@var{n}  -falign-loops=@var{n}  @gol
+-fbounds-check -fmudflap -fmudflapth -fmudflapir @gol
 -fbranch-probabilities -fprofile-values -fvpt -fbranch-target-load-optimize @gol
 -fbranch-target-load-optimize2 -fbtr-bb-exclusive @gol
 -fcaller-saves  -fcprop-registers @gol
@@ -296,6 +310,9 @@ in the following sections.
 -fstrength-reduce  -fstrict-aliasing  -ftracer  -fthread-jumps @gol
 -funroll-all-loops  -funroll-loops  -fpeel-loops @gol
 -funswitch-loops  -fold-unroll-loops  -fold-unroll-all-loops @gol
+-ftree-pre  -ftree-ccp  -ftree-dce  @gol
+-ftree-dominator-opts -ftree-dse -ftree-copyrename @gol
+-ftree-ch -ftree-sra -ftree-ter -ftree-lrs @gol
 --param @var{name}=@var{value}
 -O  -O0  -O1  -O2  -O3  -Os}
 
@@ -754,6 +771,10 @@ preprocessor).
 Fortran source code which must be preprocessed with a RATFOR
 preprocessor (not included with GCC)@.
 
+@item @var{file}.f90
+@itemx @var{file}.f95
+Fortran 90/95 source code which should not be preprocessed.
+
 @xref{Overall Options,,Options Controlling the Kind of Output, g77,
 Using and Porting GNU Fortran}, for more details of the handling of
 Fortran input files.
@@ -807,6 +828,7 @@ objective-c  objective-c-header  objc-cpp-output
 assembler  assembler-with-cpp
 ada
 f77  f77-cpp-input  ratfor
+f95
 java
 treelang
 @end smallexample
@@ -3214,6 +3236,17 @@ executed.  When an arc is the only exit or only entrance to a block, the
 instrumentation code can be added to the block; otherwise, a new basic
 block must be created to hold the instrumentation code.
 
+@item -ftree-based-profiling
+@opindex ftree-based-profiling
+This option is used in addition to @option{-fprofile-arcs} or
+@option{-fbranch-probabilities} to control whether those optimizations
+are performed on a tree-based or rtl-based internal representation.
+If you use this option when compiling with @option{-fprofile-arcs},
+you must also use it when compiling later with @option{-fbranch-probabilities}.
+Currently the tree-based optimization is in an early stage of
+development, and this option is recommended only for those people
+working on improving it.
+
 @need 2000
 @item -ftest-coverage
 @opindex ftest-coverage
@@ -3409,8 +3442,8 @@ to the source file name.  If the @samp{-@var{options}} form is used,
 @var{options} controls the details of the dump as described for the
 @option{-fdump-tree} options.
 
-@item -fdump-tree-@var{switch} @r{(C++ only)}
-@itemx -fdump-tree-@var{switch}-@var{options} @r{(C++ only)}
+@item -fdump-tree-@var{switch} @r{(C and C++ only)}
+@itemx -fdump-tree-@var{switch}-@var{options} @r{(C and C++ only)}
 @opindex fdump-tree
 Control the dumping at various stages of processing the intermediate
 language tree to a file.  The file name is generated by appending a switch
@@ -3427,20 +3460,133 @@ changes according to the environment and source file. Its primary use
 is for tying up a dump file with a debug environment.
 @item slim
 Inhibit dumping of members of a scope or body of a function merely
-because that scope has been reached. Only dump such items when they
-are directly reachable by some other path.
+because that scope has been reached.  Only dump such items when they
+are directly reachable by some other path.  When dumping pretty-printed
+trees, this option inhibits dumping the bodies of control structures.
+@item raw
+Print a raw representation of the tree.  By default, trees are
+pretty-printed into a C-like representation.
+@item details
+Enable more detailed dumps (not honored by every dump option).
+@item stats
+Enable dumping various statistics about the pass (not honored by every dump
+option).
+@item blocks
+Enable showing basic block boundaries (disabled in raw dumps).
+@item vops
+Enable showing virtual operands for every statement.
+@item lineno
+Enable showing line numbers for statements.
+@item uid
+Enable showing the unique ID (@code{DECL_UID}) for each variable.
 @item all
-Turn on all options.
+Turn on all options, except @option{raw}, @option{slim} and @option{lineno}.
 @end table
 
 The following tree dumps are possible:
 @table @samp
+
 @item original
 Dump before any tree based optimization, to @file{@var{file}.original}.
+
 @item optimized
 Dump after all tree based optimization, to @file{@var{file}.optimized}.
+
 @item inlined
 Dump after function inlining, to @file{@var{file}.inlined}.
+
+@item gimple
+@opindex fdump-tree-gimple
+Dump each function before and after the gimplification pass to a file.  The
+file name is made by appending @file{.gimple} to the source file name.
+
+@item cfg
+@opindex fdump-tree-cfg
+Dump the control flow graph of each function to a file.  The file name is
+made by appending @file{.cfg} to the source file name.
+
+@item vcg
+@opindex fdump-tree-vcg
+Dump the control flow graph of each function to a file in VCG format.  The
+file name is made by appending @file{.vcg} to the source file name.  Note
+that if the file contains more than one function, the generated file cannot
+be used directly by VCG.  You will need to cut and paste each function's
+graph into its own separate file first.
+
+@item ch
+@opindex fdump-tree-ch
+Dump each function after copying loop headers.  The file name is made by
+appending @file{.ch} to the source file name.
+
+@item ssa
+@opindex fdump-tree-ssa
+Dump SSA related information to a file.  The file name is made by appending
+@file{.ssa} to the source file name.
+
+@item alias
+@opindex fdump-tree-alias
+Dump aliasing information for each function.  The file name is made by
+appending @file{.alias} to the source file name.
+
+@item ccp
+@opindex fdump-tree-ccp
+Dump each function after CCP.  The file name is made by appending
+@file{.ccp} to the source file name.
+
+@item pre
+@opindex fdump-tree-pre
+Dump trees after partial redundancy elimination.  The file name is made
+by appending @file{.pre} to the source file name.
+
+@item dce
+@opindex fdump-tree-dce
+Dump each function after dead code elimination.  The file name is made by
+appending @file{.dce} to the source file name.
+
+@item mudflap
+@opindex fdump-tree-mudflap
+Dump each function after adding mudflap instrumentation.  The file name is
+made by appending @file{.mudflap} to the source file name.
+
+@item sra
+@opindex fdump-tree-sra
+Dump each function after performing scalar replacement of aggregates.  The
+file name is made by appending @file{.sra} to the source file name.
+
+@item dom
+@opindex fdump-tree-dom
+Dump each function after applying dominator tree optimizations.  The file
+name is made by appending @file{.dom} to the source file name.
+
+@item dse
+@opindex fdump-tree-dse
+Dump each function after applying dead store elimination.  The file
+name is made by appending @file{.dse} to the source file name.
+
+@item phiopt
+@opindex fdump-tree-phiopt
+Dump each function after optimizing PHI nodes into straightline code.  The file
+name is made by appending @file{.phiopt} to the source file name.
+
+@item forwprop
+@opindex fdump-tree-forwprop
+Dump each function after forward propagating single use variables.  The file
+name is made by appending @file{.forwprop} to the source file name.
+
+@item copyrename
+@opindex fdump-tree-copyrename
+Dump each function after applying the copy rename optimization.  The file
+name is made by appending @file{.copyrename} to the source file name.
+
+@item nrv
+@opindex fdump-tree-nrv
+Dump each function after applying the named return value optimization on
+generic trees.  The file name is made by appending @file{.nrv} to the source
+file name.
+
+@item all
+@opindex fdump-tree-all
+Enable all the available tree dumps with the flags provided in this option.
 @end table
 
 @item -frandom-seed=@var{string}
@@ -3900,6 +4046,39 @@ assumptions based on that.
 
 The default is @option{-fzero-initialized-in-bss}.
 
+@item -fbounds-check
+@opindex fbounds-check
+For front-ends that support it, generate additional code to check that
+indices used to access arrays are within the declared range.  This is
+currently only supported by the Java and Fortran front-ends, where
+this option defaults to true and false respectively.
+
+@item -fmudflap -fmudflapth -fmudflapir
+@opindex fmudflap
+@opindex fmudflapth
+@opindex fmudflapir
+@cindex bounds checking
+@cindex mudflap
+For front-ends that support it (C and C++), instrument all risky
+pointer/array dereferencing operations, some standard library
+string/heap functions, and some other associated constructs with
+range/validity tests.  Modules so instrumented should be immune to
+buffer overflows, invalid heap use, and some other classes of C/C++
+programming errors.  The instrumentation relies on a separate runtime
+library (@file{libmudflap}), which will be linked into a program if
+@option{-fmudflap} is given at link time.  Run-time behavior of the
+instrumented program is controlled by the @env{MUDFLAP_OPTIONS}
+environment variable.  See @code{env MUDFLAP_OPTIONS=-help a.out}
+for its options.
+
+Use @option{-fmudflapth} instead of @option{-fmudflap} to compile and to
+link if your program is multi-threaded.  Use @option{-fmudflapir}, in
+addition to @option{-fmudflap} or @option{-fmudflapth}, if
+instrumentation should ignore pointer reads.  This produces less
+instrumentation (and therefore faster execution) and still provides
+some protection against outright memory corrupting writes, but allows
+erroneously read data to propagate within a program.
+
 @item -fstrength-reduce
 @opindex fstrength-reduce
 Perform the optimizations of loop strength reduction and
@@ -4159,6 +4338,76 @@ those which have no call-preserved registers to use instead.
 
 Enabled at levels @option{-O2}, @option{-O3}, @option{-Os}.
 
+@item -ftree-pre
+Perform Partial Redundancy Elimination (PRE) on trees.  This flag is
+enabled by default at -O and higher.
+
+@item -ftree-ccp
+Perform sparse conditional constant propagation (CCP) on trees.  This flag
+is enabled by default at -O and higher.
+
+@item -ftree-dce
+Perform dead code elimination (DCE) on trees.  This flag is enabled by
+default at -O and higher.
+
+@item -ftree-dominator-opts
+Perform dead code elimination (DCE) on trees.  This flag is enabled by
+default at -O and higher.
+
+@item -ftree-ch
+Perform loop header copying on trees.  This is beneficial since it increases
+effectivity of code motion optimizations.  It also saves one jump.  This flag
+is enabled by default at -O and higher.  It is not enabled for -Os, since it
+usually increases code size.
+
+@item -ftree-sra
+Perform scalar replacement of aggregates.  This pass replaces structure
+references with scalars to prevent committing structures to memory too
+early.  This flag is enabled by default at -O and higher.
+
+@item -ftree-copyrename
+Perform copy renaming on trees.  This pass attempts to rename compiler 
+temporaries to other variables at copy locations, usually resulting in 
+variable names which more closely resemble the original variables.  This flag 
+is enabled by default at -O and higher.
+
+@item -ftree-ter
+Perform temporary expression replacement during the SSA->normal phase.  Single
+use/single def temporaries are replaced at their use location with their 
+defining expression.  This results in non-GIMPLE code, but gives the expanders 
+much more complex trees to work on resulting in better RTL generation.  This is
+enabled by default at -O and higher.
+
+@item -ftree-lrs
+Perform live range splitting during the SSA->normal phase.  Distinct live 
+ranges of a variable are split into unique variables, allowing for better 
+optimization later.  This is enabled by default at -O and higher.
+
+@item -ftracer
+@opindex ftracer
+Perform tail duplication to enlarge superblock size. This transformation
+simplifies the control flow of the function allowing other optimizations to do
+better job.
+
+@item -funroll-loops
+@opindex funroll-loops
+Unroll loops whose number of iterations can be determined at compile
+time or upon entry to the loop.  @option{-funroll-loops} implies both
+@option{-fstrength-reduce} and @option{-frerun-cse-after-loop}.  This
+option makes code larger, and may or may not make it run faster.
+
+@item -funroll-all-loops
+@opindex funroll-all-loops
+Unroll all loops, even if their number of iterations is uncertain when
+the loop is entered.  This usually makes programs run more slowly.
+@option{-funroll-all-loops} implies the same options as
+@option{-funroll-loops},
+
+@item -fprefetch-loop-arrays
+@opindex fprefetch-loop-arrays
+If supported by the target machine, generate instructions to prefetch
+memory to improve the performance of loops that access large arrays.
+
 @item -fmove-all-movables
 @opindex fmove-all-movables
 Forces all invariant computations in loops to be moved
@@ -4820,6 +5069,27 @@ Specifies maximal overall growth of the compilation unit caused by inlining.
 This parameter is ignored when @option{-funit-at-a-time} is not used.
 The default value is 150.
 
+@item max-inline-insns-recursive
+@itemx max-inline-insns-recursive-auto
+Specifies maximum number of instructions out-of-line copy of self recursive inline
+function can grow into by performing recursive inlining.
+
+For functions declared inline @option{--param max-inline-insns-recursive} is
+taken into acount.  For function not declared inline, recursive inlining
+happens only when @option{-finline-functions} (included in @option{-O3}) is
+enabled and @option{--param max-inline-insns-recursive-auto} is used.  The
+default value is 500.
+
+@item max-inline-recursive-depth
+@itemx max-inline-recursive-depth-auto
+Specifies maximum recursion depth used by the recursive inlining.
+
+For functions declared inline @option{--param max-inline-recursive-depth} is
+taken into acount.  For function not declared inline, recursive inlining
+happens only when @option{-finline-functions} (included in @option{-O3}) is
+enabled and @option{--param max-inline-recursive-depth-auto} is used.  The
+default value is 500.
+
 @item max-inline-insns-rtl
 For languages that use the RTL inliner (this happens at a later stage
 than tree inlining), you can set the maximum allowable size (counted
@@ -4904,6 +5174,22 @@ order to make tracer effective.
 
 Maximum number of basic blocks on path that cse considers.  The default is 10.
 
+@item global-var-threshold
+
+Counts the number of function calls (N) and the number of
+call-clobbered variables (V).  If NxV is larger than this limit, a
+single artificial variable will be created to represent all the
+call-clobbered variables at function call sites.  This artificial
+variable will then be made to alias every call-clobbered variable.
+(done as int * size_t on the host machine; beware overflow).
+
+@item max-aliased-vops
+
+Maxiumum number of virtual operands allowed to represent aliases
+before triggering the alias grouping heuristic.  Alias grouping
+reduces compile times and memory consumption needed for aliasing at
+the expense of precision loss in alias information.
+
 @item ggc-min-expand
 
 GCC uses a garbage collector to manage its own memory allocation.  This
diff --git a/gcc/doc/passes.texi b/gcc/doc/passes.texi
index 5962c53..b5a69d8 100644
--- a/gcc/doc/passes.texi
+++ b/gcc/doc/passes.texi
@@ -1,3 +1,5 @@
+@c markers: CROSSREF BUG TODO
+
 @c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
 @c 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
 @c This is part of the GCC manual.
@@ -9,131 +11,441 @@
 @cindex files and passes of the compiler
 @cindex compiler passes and files
 
-@cindex top level of compiler
-The overall control structure of the compiler is in @file{toplev.c}.  This
-file is responsible for initialization, decoding arguments, opening and
-closing files, and sequencing the passes.  Routines for emitting
-diagnostic messages are defined in @file{diagnostic.c}.  The files
-@file{pretty-print.h} and @file{pretty-print.c} provide basic support
-for language-independent pretty-printing.
-
-@cindex parsing pass
-The parsing pass is invoked only once, to parse the entire input.  A
-high level tree representation is then generated from the input,
-one function at a time.  This tree code is then transformed into RTL
-intermediate code, and processed.  The files involved in transforming
-the trees into RTL are @file{expr.c}, @file{expmed.c}, and
-@file{stmt.c}.
-@c Note, the above files aren't strictly the only files involved. It's
-@c all over the place (function.c, final.c,etc).  However, those are
-@c the files that are supposed to be directly involved, and have
-@c their purpose listed as such, so i've only listed them.
-The order of trees that are processed, is not
-necessarily the same order they are generated from
-the input, due to deferred inlining, and other considerations.
-
-@findex rest_of_compilation
+This chapter is dedicated to giving an overview of the optimization and
+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.
+
+@menu
+* Parsing pass::         The language front end turns text into bits.
+* Gimplification pass::  The bits are turned into something we can optimize.
+* Pass manager::	 Sequencing the optimization passes.
+* Tree-SSA passes::      Optimizations on a high-level representation.
+* RTL passes::           Optimizations on a low-level representation.
+@end menu
+
+@node Parsing pass
+@section Parsing pass
+@cindex GENERIC
+@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 
+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
+private representation.
+
+@cindex GIMPLE
+@cindex gimplification
+@cindex gimplifier
+@cindex language-independent intermediate 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 
+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 
+nodes directly to GIMPLE (CROSSREF) before passing the function off to
+be compiled.
+The Fortran front end converts from a private representation to GENERIC,
+which is later lowered to GIMPLE when the function is compiled.  Which
+route to choose probably depends on how well GENERIC (plus extensions)
+can be made to match up with the source language and necessary parsing
+data structures.
+
+BUG: Gimplification must occur before nested function lowering,
+and nested function lowering must be done by the front end before
+passing the data off to cgraph.
+
+TODO: Cgraph should control nested function lowering.  It would
+only be invoked when it is certain that the outer-most function
+is used.
+
+TODO: Cgraph needs a gimplify_function callback.  It should be
+invoked when (1) it is certain that the function is used, (2)
+warning flags specified by the user require some amount of
+compilation in order to honor, (3) the language indicates that
+semantic analysis is not complete until gimplification occurs.
+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 
+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
+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{defintions} be passed to the middle-end.  For
+complete debug information, function, data and type declarations 
+should all be passed as well.
+
 @findex rest_of_decl_compilation
-Each time the parsing pass reads a complete function definition or
-top-level declaration, it calls either the function
-@code{rest_of_compilation}, or the function
-@code{rest_of_decl_compilation} in @file{toplev.c}, which are
-responsible for all further processing necessary, ending with output of
-the assembler language.  All other compiler passes run, in sequence,
-within @code{rest_of_compilation}.  When that function returns from
-compiling a function definition, the storage used for that function
-definition's compilation is entirely freed, unless it is an inline
-function, or was deferred for some reason (this can occur in
-templates, for example).
-(@pxref{Inline,,An Inline Function is As Fast As a Macro,gcc,Using the
-GNU Compiler Collection (GCC)}).
-
-Here is a list of all the passes of the compiler and their source files.
-Also included is a description of where debugging dumps can be requested
-with @option{-d} options.
+@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 
+@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}.
+
+TODO: I know rest_of_compilation currently has all sorts of
+rtl-generation semantics.  I plan to move all code generation
+bits (both tree and rtl) to compile_function.  Should we hide
+cgraph from the front ends and move back to rest_of_compilation
+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 
+definitions immediately or queue them for later processing.
+
+@node Gimplification pass
+@section Gimplification pass
+
+@cindex gimplification
+@cindex GIMPLE
+@dfn{Gimplification} is a whimsical term for the process of converting
+the intermediate representation of a function into the GIMPLE language
+(CROSSREF).  The term stuck, and so words like ``gimplification,''
+``gimplify,'' ``gimplifier'' and the like are sprinkled throughout this
+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 
+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.
+
+@findex gimplify_function_tree
+@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 
+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
+invoke the @code{lang_hooks.gimplify_expr} callback.
+
+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 
+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.
+If the callback encounters an error during the transformation (because
+the front end is relying on the gimplification process to finish
+semantic checks), it should return @code{GS_ERROR}.
+
+@node Pass manager
+@section Pass manager
+
+The pass manager is located in @file{passes.c} and @file{passes.h}.
+Its job is to run all of the individual passes in the correct order,
+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 
+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.
+
+The actuality doesn't completely live up to the theory at present.
+Command-line switches and @code{timevar_id_t} enumerations must still
+be defined elsewhere.  The pass manager validates constraints but does
+not attempt to (re-)generate data structures or lower intermediate
+language form based on the requirements of the next pass.  Nevertheless,
+what is present is useful, and a far sight better than nothing at all.
+
+TODO: describe the global variables set up by the pass manager,
+and a brief description of how a new pass should use it.
+I need to look at what info rtl passes use first...
+
+@node Tree-SSA passes
+@section Tree-SSA passes
+
+The following briefly describes the tree optimization passes that are
+run after gimplification and what source files they are located in.
 
 @itemize @bullet
-@item
-Parsing.  This pass reads the entire text of a function definition,
-constructing a high level tree representation.  (Because of the semantic
-analysis that takes place during this pass, it does more than is
-formally considered to be parsing.)
-
-The tree representation does not entirely follow C syntax, because it is
-intended to support other languages as well.
-
-Language-specific data type analysis is also done in this pass, and every
-tree node that represents an expression has a data type attached.
-Variables are represented as declaration nodes.
-
-The language-independent source files for parsing are
-@file{tree.c}, @file{fold-const.c}, and @file{stor-layout.c}.
-There are also header files @file{tree.h} and @file{tree.def}
-which define the format of the tree representation.
-
-C preprocessing, for language front ends, that want or require it, is
-performed by cpplib, which is covered in separate documentation.  In
-particular, the internals are covered in @xref{Top, ,Cpplib internals,
-cppinternals, Cpplib Internals}.
-
-The source files to parse C are found in the toplevel directory, and
-by convention are named @file{c-*}.  Some of these are also used by
-the other C-like languages: @file{c-common.c},
-@file{c-common.def},
-@file{c-format.c},
-@file{c-opts.c},
-@file{c-pragma.c},
-@file{c-semantics.c},
-@file{c-lex.c},
-@file{c-incpath.c},
-@file{c-ppoutput.c},
-@file{c-cppbuiltin.c},
-@file{c-common.h},
-@file{c-dump.h},
-@file{c.opt},
-@file{c-incpath.h}
-and
-@file{c-pragma.h},
-
-Files specific to each language are in subdirectories named after the
-language in question, like @file{ada}, @file{objc}, @file{cp} (for C++).
-
-@cindex Tree optimization
-@item
-Tree optimization.   This is the optimization of the tree
-representation, before converting into RTL code.
-
-@cindex inline on trees, automatic
-Currently, the main optimization performed here is tree-based
-inlining.
-This is implemented in @file{tree-inline.c} and used by both C and C++.
-Note that tree based inlining turns off rtx based inlining (since it's more
-powerful, it would be a waste of time to do rtx based inlining in
-addition).
-
-@cindex constant folding
-@cindex arithmetic simplifications
-@cindex simplifications, arithmetic
-Constant folding and some arithmetic simplifications are also done
-during this pass, on the tree representation.
-The routines that perform these tasks are located in @file{fold-const.c}.
-
-@cindex RTL generation
-@item
-RTL generation.  This is the conversion of syntax tree into RTL code.
+@item Remove useless statements
+
+This pass is an extremely simple sweep across the gimple code in which
+we identify obviously dead code and remove it.  Here we do things like
+simplify @code{if} statements with constant conditions, remove
+exception handling constructs surrounding code that obviously cannot
+throw, remove lexical bindings that contain no variables, and other
+assorted simplistic cleanups.  The idea is to get rid of the obvious
+stuff quickly rather than wait until later when it's more work to get
+rid of it.  This pass is located in @file{tree-cfg.c} and described by
+@code{pass_remove_useless_stmts}.
+
+@item Mudflap declaration registration
+
+If mudflap (@pxref{Optimize Options,,-fmudflap -fmudflapth
+-fmudflapir,gcc.info,Using the GNU Compiler Collection (GCC)}) is
+enabled, we generate code to register some variable declarations with
+the mudflap runtime.  Specifically, the runtime tracks the lifetimes of
+those variable declarations that have their addresses taken, or whose
+bounds are unknown at compile time (@code{extern}).  This pass generates
+new exception handling constructs (@code{try}/@code{finally}), and so
+must run before those are lowered.  In addition, the pass enqueues
+declarations of static variables whose lifetimes extend to the entire
+program.  The pass is located in @file{tree-mudflap.c} and is described
+by @code{pass_mudflap_1}.
+
+@item Lower control flow
+
+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 
+@code{pass_lower_cf}.
+
+@item Lower exception handling control flow
+
+This pass decomposes high-level exception handling constructs
+(@code{TRY_FINALLY_EXPR} and @code{TRY_CATCH_EXPR}) into a form
+that explicitly represents the control flow involved.  After this
+pass, @code{lookup_stmt_eh_region} will return a non-negative
+number for any statement that may have EH control flow semantics;
+examine @code{tree_can_throw_internal} or @code{tree_can_throw_external}
+for exact semantics.  Exact control flow may be extracted from
+@code{foreach_reachable_handler}.  The EH region nesting tree is defined
+in @file{except.h} and built in @file{except.c}.  The lowering pass
+itself is in @file{tree-eh.c} and is described by @code{pass_lower_eh}.
+
+@item Build the control flow graph
+
+This pass decomposes a function into basic blocks and creates all of
+the edges that connect them.  It is located in @file{tree-cfg.c} and
+is described by @code{pass_build_cfg}.
+
+@item Find all referenced variables
+
+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
+SSA rewriting routines.  The pass is located in @file{tree-dfa.c}
+and is described by @code{pass_referenced_vars}.
+
+@item Points-to analysis
+
+This pass constructs flow-insensitive alias analysis information.
+The pass is located in @file{tree-alias-common.c} and described by
+@code{pass_build_pta}.
+
+@item Enter static single assignment form
+
+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 occurences 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}.
+
+@item Warn for uninitialized variables
+
+This pass scans the function for uses of @code{SSA_NAME}s that
+are fed by default definition.  For non-parameter variables, such
+uses are uninitialized.  The pass is run twice, before and after
+optimization.  In the first pass we only warn for uses that are
+positively uninitialized; in the second pass we warn for uses that
+are possibly uninitialized.  The pass is located in @file{tree-ssa.c}
+and is defined by @code{pass_early_warn_uninitialized} and
+@code{pass_late_warn_uninitialized}.
+
+@item Dead code elimination
+
+This pass scans the function for statements without side effects whose
+result is unused.  It does not do memory life analysis, so any value
+that is stored in memory is considered used.  The pass is run multiple
+times throughout the optimization process.  It is located in
+@file{tree-ssa-dce.c} and is described by @code{pass_dce}.
+
+@item Dominator optimizations
+
+This pass performs trivial dominator-based copy and constant propagation,
+expression simplification, and jump threading.  It is run multiple times
+throughout the optimization process.  It it located in @file{tree-ssa-dom.c}
+and is described by @code{pass_dominator}.
+
+@item Redundant phi elimination
+
+This pass removes phi nodes for which all of the arguments are the same
+value, excluding feedback.  Such degenerate forms are typically created
+by removing unreachable code.  The pass is run multiple times throughout
+the optimization process.  It is located in @file{tree-ssa.c} and is
+described by @code{pass_redundant_phi}.o
+
+@item Forward propagation of single-use variables
+
+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 
+@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 
+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 
+@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 
+@code{pass_phiopt}.
+
+@item May-alias optimization
+
+This pass performs a flow sensitive SSA-based points-to analysis.
+The resulting may-alias, must-alias, and escape analysis information
+is used to promote variables from in-memory addressable objects to
+non-aliased variables that can be renamed into SSA form.  We also
+update the @code{VDEF}/@code{VUSE} memory tags for non-renamable
+aggregates so that we get fewer false kills.  The pass is located
+in @file{tree-ssa-alias.c} and is described by @code{pass_may_alias}.
+
+@item Profiling
+
+This pass rewrites the function in order to collect runtime block
+and value profiling data.  Such data may be fed back into the compiler
+on a subsequent run so as to allow optimization based on expected
+execution frequencies.  The pass is located in @file{predict.c} and
+is described by @code{pass_profile}.
+
+@item Lower complex arithmetic
+
+This pass rewrites complex arithmetic operations into their component
+scalar arithmetic operations.  The pass is located in @file{tree-complex.c}
+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 
+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}.
+
+@item Dead store elimination
+
+This pass eliminates stores to memory that are subsequently overwritten
+by another store, without any intervening loads.  The pass is located
+in @file{tree-ssa-dse.c} and is described by @code{pass_dse}.
+
+@item Tail recursion elimination
+
+This pass transforms tail recursion into a loop.  It is located in
+@file{tree-tailcall.c} and is described by @code{pass_tail_recursion}.
+
+@item Partial redundancy elimination
+
+This pass eliminates partially redundant computations, as well as
+performing load motion.  The pass is located in @file{tree-ssa-pre.c}
+and is described by @code{pass_pre}.
+
+@item Loop optimization
+
+TODO: Presumably we're going to do something with loops here.  At
+present we don't, and this is a placeholder.  The pass is located
+in @file{tree-ssa-loop.c} and is described by @code{pass_loop}.
 
-@cindex target-parameter-dependent code
-This is where the bulk of target-parameter-dependent code is found,
-since often it is necessary for strategies to apply only when certain
-standard kinds of instructions are available.  The purpose of named
-instruction patterns is to provide this information to the RTL
-generation pass.
+@item Conditional constant propagation
 
-@cindex tail recursion optimization
-Optimization is done in this pass for @code{if}-conditions that are
-comparisons, boolean operations or conditional expressions.  Tail
-recursion is detected at this time also.  Decisions are made about how
-best to arrange loops and how to output @code{switch} statements.
+This pass relaxes a lattice of values in order to identify those
+that must be constant even in the presence of conditional branches.
+The pass is located in @file{tree-ssa-ccp.c} and is described
+by @code{pass_ccp}.
+
+@item Folding builtin functions
+
+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}.
+
+@item Split critical edges
+
+This pass identifies critical edges and inserts empty basic blocks
+such that the edge is no longer critical.  The pass is located in
+@file{tree-cfg.c} and is described by @code{pass_split_crit_edges}.
+
+@item Partial redundancy elimination
+
+This pass answers the question ``given a hypothetical temporary
+variable, what expressions could we eliminate?''  It is located
+in @file{tree-ssa-pre.c} and is described by @code{pass_pre}.
+
+@item Control dependence dead code elimination
+
+This pass is a stronger form of dead code elimination that can
+eliminate unnecessary control flow statements.   It is located
+in @file{tree-ssa-dce.c} and is described by @code{pass_cd_dce}.
+
+@item Tail call elimination
+
+This pass identifies function calls that may be rewritten into
+jumps.  No code transformation is actually applied here, but the
+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{fixup_tail_calls} in @file{calls.c}.
+
+@item Warn for function return without value
+
+For non-void functions, this pass locates return statements that do
+not specify a value and issues a warning.  Such a statement may have
+been injected by falling off the end of the function.  This pass is
+run last so that we have as much time as possible to prove that the
+statement is not reachable.  It is located in @file{tree-cfg.c} and
+is described by @code{pass_warn_function_return}.
+
+@item Mudflap statement annotation
+
+If mudflap is enabled, we rewrite some memory accesses with code to
+validate that the memory access is correct.  In particular, expressions
+involving pointer dereferences (@code{INDIRECT_REF}, @code{ARRAY_REF},
+etc.) are replaced by code that checks the selected address range
+against the mudflap runtime's database of valid regions.  This check
+includes an inline lookup into a direct-mapped cache, based on
+shift/mask operations of the pointer value, with a fallback function
+call into the runtime.  The pass is located in @file{tree-mudflap.c} and
+is described by @code{pass_mudflap_2}.
+
+@item Leave static single assignment form
+
+This pass rewrites the function such that it is in normal form.  At
+the same time, we eliminate as many single-use temporaries as possible,
+so the intermediate language is no longer GIMPLE, but GENERIC.  The
+pass is located in @file{tree-ssa.c} and is described by @code{pass_del_ssa}.
+@end itemize
+
+@node RTL passes
+@section RTL passes
+
+The following briefly describes the rtl generation and optimization
+passes that are run after tree optimization.
+
+@itemize @bullet
+@item RTL generation
 
 @c Avoiding overfull is tricky here.
 The source files for RTL generation include
@@ -157,105 +469,32 @@ generated from the machine description by the programs @code{genflags}
 and @code{gencodes}, tell this pass which standard names are available
 for use and which patterns correspond to them.
 
-Aside from debugging information output, none of the following passes
-refers to the tree structure representation of the function (only
-part of which is saved).
-
-@cindex inline on rtx, automatic
-The decision of whether the function can and should be expanded inline
-in its subsequent callers is made at the end of rtl generation.  The
-function must meet certain criteria, currently related to the size of
-the function and the types and number of parameters it has.  Note that
-this function may contain loops, recursive calls to itself
-(tail-recursive functions can be inlined!), gotos, in short, all
-constructs supported by GCC@.  The file @file{integrate.c} contains
-the code to save a function's rtl for later inlining and to inline that
-rtl when the function is called.  The header file @file{integrate.h}
-is also used for this purpose.
-
-@opindex dr
-The option @option{-dr} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.rtl} to
-the input file name.
-
-@c Should the exception handling pass be talked about here?
-
-@cindex sibling call optimization
-@item
-Sibling call optimization.   This pass performs tail recursion
-elimination, and tail and sibling call optimizations.  The purpose of
-these optimizations is to reduce the overhead of function calls,
-whenever possible.
+@item Generate exception handling landing pads
 
-The source file of this pass is @file{sibcall.c}
+This pass generates the glue that handles communication between the
+exception handling library routines and the exception handlers within
+the function.  Entry points in the function that are invoked by the
+exception handling library are called @dfn{landing pads}.  The code
+for this pass is located within @file{except.c}.
 
-@opindex di
-The option @option{-di} causes a debugging dump of the RTL code after
-this pass is run.  This dump file's name is made by appending
-@samp{.sibling} to the input file name.
+@item Cleanup control flow graph
 
-@cindex jump optimization
-@cindex unreachable code
-@cindex dead code
-@item
-Jump optimization.  This pass simplifies jumps to the following
-instruction, jumps across jumps, and jumps to jumps.  It deletes
-unreferenced labels and unreachable code, except that unreachable code
-that contains a loop is not recognized as unreachable in this pass.
-(Such loops are deleted later in the basic block analysis.)  It also
-converts some code originally written with jumps into sequences of
-instructions that directly set values from the results of comparisons,
-if the machine has such instructions.
-
-Jump optimization is performed two or three times.  The first time is
-immediately following RTL generation.  The second time is after CSE,
-but only if CSE says repeated jump optimization is needed.  The
-last time is right before the final pass.  That time, cross-jumping
-and deletion of no-op move instructions are done together with the
-optimizations described above.
-
-The source file of this pass is @file{jump.c}.
-
-@opindex dj
-The option @option{-dj} causes a debugging dump of the RTL code after
-this pass is run for the first time.  This dump file's name is made by
-appending @samp{.jump} to the input file name.
-
-
-@cindex register use analysis
-@item
-Register scan.  This pass finds the first and last use of each
-register, as a guide for common subexpression elimination.  Its source
-is in @file{regclass.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 
+@file{cfgcleanup.c}, and there are support routines in @file{cfgrtl.c}
+and @file{jump.c}.
 
-@cindex jump threading
-@item
-@opindex fthread-jumps
-Jump threading.  This pass detects a condition jump that branches to an
-identical or inverse test.  Such jumps can be @samp{threaded} through
-the second conditional test.  The source code for this pass is in
-@file{jump.c}.  This optimization is only performed if
-@option{-fthread-jumps} is enabled.
-
-@cindex common subexpression elimination
-@cindex constant propagation
-@item
-Common subexpression elimination.  This pass also does constant
-propagation.  Its source files are @file{cse.c}, and @file{cselib.c}.
-If constant  propagation causes conditional jumps to become
-unconditional or to become no-ops, jump optimization is run again when
-CSE is finished.
-
-@opindex ds
-The option @option{-ds} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.cse} to
-the input file name.
-
-@cindex global common subexpression elimination
-@cindex constant propagation
-@cindex copy propagation
-@item
-Global common subexpression elimination.  This pass performs two
+@item Common subexpression elimination
+
+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}.
+
+@item Global common subexpression elimination.
+
+This pass performs two
 different types of GCSE  depending on whether you are optimizing for
 size or not (LCM based GCSE tends to increase code size for a gain in
 speed, while Morel-Renvoise based GCSE does not).
@@ -270,193 +509,119 @@ based GCSE also does loop invariant code motion.  We also perform load
 and store motion when optimizing for speed.
 Regardless of which type of GCSE is used, the GCSE pass also performs
 global constant and  copy propagation.
-
 The source file for this pass is @file{gcse.c}, and the LCM routines
 are in @file{lcm.c}.
 
-@opindex dG
-The option @option{-dG} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.gcse} to
-the input file name.
+@item Loop optimization
 
-@cindex loop optimization
-@cindex code motion
-@cindex strength-reduction
-@item
-Loop optimization.  This pass moves constant expressions out of loops,
+This pass moves constant expressions out of loops,
 and optionally does strength-reduction and loop unrolling as well.
 Its source files are @file{loop.c} and @file{unroll.c}, plus the header
 @file{loop.h} used for communication between them.  Loop unrolling uses
 some functions in @file{integrate.c} and the header @file{integrate.h}.
 Loop dependency analysis routines are contained in @file{dependence.c}.
 
-Second loop optimization pass takes care of basic block level optimizations --
-unrolling, peeling and unswitching loops. The source files are
-@file{cfgloopanal.c} and @file{cfgloopmanip.c} containing generic loop
-analysis and manipulation code, @file{loop-init.c} with initialization and
-finalization code, @file{loop-unswitch.c} for loop unswitching and
-@file{loop-unroll.c} for loop unrolling and peeling.
+A second loop optimization pass takes care of basic block level
+optimizations---unrolling, peeling and unswitching loops. The source
+files are @file{cfgloopanal.c} and @file{cfgloopmanip.c} containing
+generic loop analysis and manipulation code, @file{loop-init.c} with
+initialization and finalization code, @file{loop-unswitch.c} for loop
+unswitching and @file{loop-unroll.c} for loop unrolling and peeling.
 
-@opindex dL
-The option @option{-dL} causes a debugging dump of the RTL code after
-these passes.  The dump file names are made by appending @samp{.loop} and
-@samp{.loop2} to the input file name.
+@item Jump bypassing
 
-@cindex jump bypassing
-@item
-Jump bypassing.  This pass is an aggressive form of GCSE that transforms
-the control flow graph of a function by propagating constants into
-conditional branch instructions.
+This pass is an aggressive form of GCSE that transforms the control
+flow graph of a function by propagating constants into conditional
+branch instructions.  The source file for this pass is @file{gcse.c}.
 
-The source file for this pass is @file{gcse.c}.
+@item If conversion
 
-@opindex dG
-The option @option{-dG} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.bypass}
-to the input file name.
+This pass attempts to replace conditional branches and surrounding
+assignments with arithmetic, boolean value producing comparison
+instructions, and conditional move instructions.  In the very last
+invocation after reload, it will generate predicated instructions
+when supported by the target.  The pass is located in @file{ifcvt.c}.
 
-@cindex web construction
-@item
-Simple optimization pass that splits independent uses of each pseudo
-increasing effect of other optimizations.  This can improve effect of the
-other transformation, such as CSE or register allocation.
-Its source files are @file{web.c}.
+@item Web construction
 
-@opindex dZ
-The option @option{-dZ} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.web} to
-the input file name.
+This pass splits independent uses of each pseudo-register.  This can
+improve effect of the other transformation, such as CSE or register
+allocation.  Its source files are @file{web.c}.
 
-@item
-@opindex frerun-cse-after-loop
-If @option{-frerun-cse-after-loop} was enabled, a second common
-subexpression elimination pass is performed after the loop optimization
-pass.  Jump threading is also done again at this time if it was specified.
-
-@opindex dt
-The option @option{-dt} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.cse2} to
-the input file name.
-
-@cindex data flow analysis
-@cindex analysis, data flow
-@cindex basic blocks
-@item
-Data flow analysis (@file{flow.c}).  This pass divides the program
-into basic blocks (and in the process deletes unreachable loops); then
-it computes which pseudo-registers are live at each point in the
-program, and makes the first instruction that uses a value point at
-the instruction that computed the value.
-
-@cindex autoincrement/decrement analysis
-This pass also deletes computations whose results are never used, and
-combines memory references with add or subtract instructions to make
-autoincrement or autodecrement addressing.
-
-@opindex df
-The option @option{-df} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.flow} to
-the input file name.  If stupid register allocation is in use, this
-dump file reflects the full results of such allocation.
-
-@cindex instruction combination
-@item
-Instruction combination (@file{combine.c}).  This pass attempts to
-combine groups of two or three instructions that are related by data
-flow into single instructions.  It combines the RTL expressions for
-the instructions by substitution, simplifies the result using algebra,
-and then attempts to match the result against the machine description.
-
-@opindex dc
-The option @option{-dc} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.combine}
-to the input file name.
-
-@cindex if conversion
-@item
-If-conversion is a transformation that transforms control dependencies
-into data dependencies (IE it transforms conditional code into a
-single control stream).
-It is implemented in the file @file{ifcvt.c}.
+@item Life analysis
 
-@opindex dE
-The option @option{-dE} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.ce} to
-the input file name.
+This pass computes which pseudo-registers are live at each point in
+the program, and makes the first instruction that uses a value point
+at the instruction that computed the value.  It then deletes
+computations whose results are never used, and combines memory
+references with add or subtract instructions to make autoincrement or
+autodecrement addressing.  The pass is located in @file{flow.c}.
 
-@cindex register movement
-@item
-Register movement (@file{regmove.c}).  This pass looks for cases where
-matching constraints would force an instruction to need a reload, and
-this reload would be a register-to-register move.  It then attempts
-to change the registers used by the instruction to avoid the move
-instruction.
-
-@opindex dN
-The option @option{-dN} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.regmove}
-to the input file name.
-
-@cindex instruction scheduling
-@cindex scheduling, instruction
-@item
-Instruction scheduling (@file{sched.c}).  This pass looks for
-instructions whose output will not be available by the time that it is
-used in subsequent instructions.  (Memory loads and floating point
-instructions often have this behavior on RISC machines).  It re-orders
-instructions within a basic block to try to separate the definition and
-use of items that otherwise would cause pipeline stalls.
-
-Instruction scheduling is performed twice.  The first time is immediately
-after instruction combination and the second is immediately after reload.
-
-@opindex dS
-The option @option{-dS} causes a debugging dump of the RTL code after this
-pass is run for the first time.  The dump file's name is made by
-appending @samp{.sched} to the input file name.
-
-@cindex register allocation
-@item
-Register allocation.  These passes make sure that all occurrences of pseudo
-registers are eliminated, either by allocating them to a hard register,
-replacing them by an equivalent expression (e.g.@: a constant) or by placing
+@item Instruction combination
+
+This pass attempts to combine groups of two or three instructions that
+are related by data flow into single instructions.  It combines the
+RTL expressions for the instructions by substitution, simplifies the
+result using algebra, and then attempts to match the result against
+the machine description.  The pass is located in @file{combine.c}.
+
+@item Register movement
+
+This pass looks for cases where matching constraints would force an
+instruction to need a reload, and this reload would be a
+register-to-register move.  It then attempts to change the registers
+used by the instruction to avoid the move instruction.
+The pass is located in @file{regmove.c}.
+
+@item Optimize mode switching
+
+This pass looks for instructions that require the processor to be in a
+specific ``mode'' and minimizes the number of mode changes required to
+satisfy all users.  What these modes are, and what they apply to are
+completely target-specific.  The source is located in @file{lcm.c}.
+
+@item Instruction scheduling
+
+This pass looks for instructions whose output will not be available by
+the time that it is used in subsequent instructions.  Memory loads and
+floating point instructions often have this behavior on RISC machines.
+It re-orders instructions within a basic block to try to separate the
+definition and use of items that otherwise would cause pipeline
+stalls.  This pass is performed twice, before and after register
+allocation.  The pass is located in @file{haifa-sched.c},
+@file{sched-deps.c}, @file{sched-ebb.c}, @file{sched-rgn.c} and
+@file{sched-vis.c}.
+
+@item Register allocation
+
+These passes make sure that all occurrences of pseudo registers are
+eliminated, either by allocating them to a hard register, replacing
+them by an equivalent expression (e.g.@: a constant) or by placing
 them on the stack.  This is done in several subpasses:
 
 @itemize @bullet
-@cindex register class preference pass
 @item
 Register class preferencing.  The RTL code is scanned to find out
 which register class is best for each pseudo register.  The source
 file is @file{regclass.c}.
 
-@cindex local register allocation
 @item
-Local register allocation (@file{local-alloc.c}).  This pass allocates
-hard registers to pseudo registers that are used only within one basic
-block.  Because the basic block is linear, it can use fast and
-powerful techniques to do a very good job.
-
-@opindex dl
-The option @option{-dl} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.lreg} to
-the input file name.
+Local register allocation.  This pass allocates hard registers to
+pseudo registers that are used only within one basic block.  Because
+the basic block is linear, it can use fast and powerful techniques to
+do a decent job.  The source is located in @file{local-alloc.c}.
 
-@cindex global register allocation
 @item
-Global register allocation (@file{global.c}).  This pass
-allocates hard registers for the remaining pseudo registers (those
-whose life spans are not contained in one basic block).
+Global register allocation.  This pass allocates hard registers for
+the remaining pseudo registers (those whose life spans are not
+contained in one basic block).  The pass is located in @file{global.c}.
 
-@cindex graph coloring register allocation
-@opindex fnew-ra
-@opindex dl
 @item
 Graph coloring register allocator.  The files @file{ra.c}, @file{ra-build.c},
 @file{ra-colorize.c}, @file{ra-debug.c}, @file{ra-rewrite.c} together with
 the header @file{ra.h} contain another register allocator, which is used
 when the option @option{-fnew-ra} is given.  In that case it is run instead
-of the above mentioned local and global register allocation passes, and the
-option @option{-dl} causes a debugging dump of its work.
+of the above mentioned local and global register allocation passes.
 
 @cindex reloading
 @item
@@ -474,165 +639,65 @@ instructions to save and restore call-clobbered registers around calls.
 
 Source files are @file{reload.c} and @file{reload1.c}, plus the header
 @file{reload.h} used for communication between them.
-
-@opindex dg
-The option @option{-dg} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.greg} to
-the input file name.
 @end itemize
 
-@cindex instruction scheduling
-@cindex scheduling, instruction
-@item
-Instruction scheduling is repeated here to try to avoid pipeline stalls
-due to memory loads generated for spilled pseudo registers.
+@item Basic block reordering
 
-@opindex dR
-The option @option{-dR} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.sched2}
-to the input file name.
+This pass implements profile guided code positioning.  If profile
+information is not available, various types of static analysis are
+performed to make the predictions normally coming from the profile
+feedback (IE execution frequency, branch probability, etc).  It is
+implemented in the file @file{bb-reorder.c}, and the various
+prediction routines are in @file{predict.c}.
 
-@cindex basic block reordering
-@cindex reordering, block
-@item
-Basic block reordering.  This pass implements profile guided code
-positioning.  If profile information is not available, various types of
-static analysis are performed to make the predictions normally coming
-from the profile feedback (IE execution frequency, branch probability,
-etc).  It is implemented in the file @file{bb-reorder.c}, and the
-various prediction routines are in @file{predict.c}.
-
-@opindex dB
-The option @option{-dB} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.bbro} to
-the input file name.
-
-@cindex variable tracking
-@item
-Variable tracking.  This pass computes where the variables are stored at each
+@item Variable tracking
+
+This pass computes where the variables are stored at each
 position in code and generates notes describing the variable locations
 to RTL code.  The location lists are then generated according to these
 notes to debug information if the debugging information format supports
 location lists.
 
-@opindex dV
-The option @option{-dV} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.vartrack}
-to the input file name.
+@item Delayed branch scheduling
 
-@cindex delayed branch scheduling
-@cindex scheduling, delayed branch
-@item
-Delayed branch scheduling.  This optional pass attempts to find
-instructions that can go into the delay slots of other instructions,
-usually jumps and calls.  The source file name is @file{reorg.c}.
+This optional pass attempts to find instructions that can go into the
+delay slots of other instructions, usually jumps and calls.  The
+source file name is @file{reorg.c}.
 
-@opindex dd
-The option @option{-dd} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.dbr}
-to the input file name.
+@item Branch shortening
+
+On many RISC machines, branch instructions have a limited range.
+Thus, longer sequences of instructions must be used for long branches.
+In this pass, the compiler figures out what how far each instruction
+will be from each other instruction, and therefore whether the usual
+instructions, or the longer sequences, must be used for each branch.
+
+@item Register-to-stack conversion
 
-@cindex branch shortening
-@item
-Branch shortening.  On many RISC machines, branch instructions have a
-limited range.  Thus, longer sequences of instructions must be used for
-long branches.  In this pass, the compiler figures out what how far each
-instruction will be from each other instruction, and therefore whether
-the usual instructions, or the longer sequences, must be used for each
-branch.
-
-@cindex register-to-stack conversion
-@item
 Conversion from usage of some hard registers to usage of a register
 stack may be done at this point.  Currently, this is supported only
 for the floating-point registers of the Intel 80387 coprocessor.   The
 source file name is @file{reg-stack.c}.
 
-@opindex dk
-The options @option{-dk} causes a debugging dump of the RTL code after
-this pass.  This dump file's name is made by appending @samp{.stack}
-to the input file name.
+@item Final
 
-@cindex final pass
-@cindex peephole optimization
-@item
-Final.  This pass outputs the assembler code for the function.  It is
-also responsible for identifying spurious test and compare
-instructions.  Machine-specific peephole optimizations are performed
-at the same time.  The function entry and exit sequences are generated
-directly as assembler code in this pass; they never exist as RTL@.
-
-The source files are @file{final.c} plus @file{insn-output.c}; the
-latter is generated automatically from the machine description by the
-tool @file{genoutput}.  The header file @file{conditions.h} is used
-for communication between these files.
-
-@cindex debugging information generation
-@item
-Debugging information output.  This is run after final because it must
-output the stack slot offsets for pseudo registers that did not get
-hard registers.  Source files are @file{dbxout.c} for DBX symbol table
-format, @file{sdbout.c} for SDB symbol table format,  @file{dwarfout.c}
-for DWARF symbol table format, files @file{dwarf2out.c} and
-@file{dwarf2asm.c} for DWARF2 symbol table format, and @file{vmsdbgout.c}
-for VMS debug symbol table format.
-@end itemize
+This pass outputs the assembler code for the function.  The source files
+are @file{final.c} plus @file{insn-output.c}; the latter is generated
+automatically from the machine description by the tool @file{genoutput}.
+The header file @file{conditions.h} is used for communication between
+these files.  If mudflap is enabled, the queue of deferred declarations
+and any addressed constants (e.g., string literals) is processed by
+@code{mudflap_finish_file} into a synthetic constructor function
+containing calls into the mudflap runtime.
 
-Some additional files are used by all or many passes:
+@item Debugging information output
 
-@itemize @bullet
-@item
-Every pass uses @file{machmode.def} and @file{machmode.h} which define
-the machine modes.
-
-@item
-Several passes use @file{real.h}, which defines the default
-representation of floating point constants and how to operate on them.
+This is run after final because it must output the stack slot offsets
+for pseudo registers that did not get hard registers.  Source files
+are @file{dbxout.c} for DBX symbol table format, @file{sdbout.c} for
+SDB symbol table format, @file{dwarfout.c} for DWARF symbol table
+format, files @file{dwarf2out.c} and @file{dwarf2asm.c} for DWARF2
+symbol table format, and @file{vmsdbgout.c} for VMS debug symbol table
+format.
 
-@item
-All the passes that work with RTL use the header files @file{rtl.h}
-and @file{rtl.def}, and subroutines in file @file{rtl.c}.  The tools
-@code{gen*} also use these files to read and work with the machine
-description RTL@.
-
-@item
-All the tools that read the machine description use support routines
-found in @file{gensupport.c}, @file{errors.c}, and @file{read-rtl.c}.
-
-@findex genconfig
-@item
-Several passes refer to the header file @file{insn-config.h} which
-contains a few parameters (C macro definitions) generated
-automatically from the machine description RTL by the tool
-@code{genconfig}.
-
-@cindex instruction recognizer
-@item
-Several passes use the instruction recognizer, which consists of
-@file{recog.c} and @file{recog.h}, plus the files @file{insn-recog.c}
-and @file{insn-extract.c} that are generated automatically from the
-machine description by the tools @file{genrecog} and
-@file{genextract}.
-
-@item
-Several passes use the header files @file{regs.h} which defines the
-information recorded about pseudo register usage, and @file{basic-block.h}
-which defines the information recorded about basic blocks.
-
-@item
-@file{hard-reg-set.h} defines the type @code{HARD_REG_SET}, a bit-vector
-with a bit for each hard register, and some macros to manipulate it.
-This type is just @code{int} if the machine has few enough hard registers;
-otherwise it is an array of @code{int} and some of the macros expand
-into loops.
-
-@item
-Several passes use instruction attributes.  A definition of the
-attributes defined for a particular machine is in file
-@file{insn-attr.h}, which is generated from the machine description by
-the program @file{genattr}.  The file @file{insn-attrtab.c} contains
-subroutines to obtain the attribute values for insns and information
-about processor pipeline characteristics for the instruction
-scheduler.  It is generated from the machine description by the
-program @file{genattrtab}.
 @end itemize
diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index 746bca5..c5e8d33 100644
--- a/gcc/doc/rtl.texi
+++ b/gcc/doc/rtl.texi
@@ -722,7 +722,6 @@ computation performed by this instruction, i.e., one that
 This flag is required for exception handling support on targets with RTL
 prologues.
 
-@findex RTX_INTEGRATED_P
 @cindex @code{insn} and @samp{/i}
 @cindex @code{call_insn} and @samp{/i}
 @cindex @code{jump_insn} and @samp{/i}
@@ -732,8 +731,6 @@ prologues.
 @cindex @code{const} and @samp{/i}
 @cindex @code{note} and @samp{/i}
 @cindex @code{integrated}, in @code{insn}, @code{call_insn}, @code{jump_insn}, @code{barrier}, @code{code_label}, @code{insn_list}, @code{const}, and @code{note}
-@item RTX_INTEGRATED_P (@var{x})
-Nonzero in an @code{insn}, @code{call_insn}, @code{jump_insn}, @code{barrier},
 @code{code_label}, @code{insn_list}, @code{const}, or @code{note} if it
 resulted from an in-line function call.
 Stored in the @code{integrated} field and printed as @samp{/i}.
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 8868d19..03a450a 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -54,6 +54,9 @@ Headers for the @code{libiberty} library.
 The Ada runtime library.
 
 @item libf2c
+The Fortran 77 runtime library.
+
+@item libgfortran
 The Fortran runtime library.
 
 @item libffi
@@ -700,6 +703,10 @@ If defined, a space-separated list of files that should be scanned by
 gengtype.c to generate the garbage collection tables and routines for
 this language.  This excludes the files that are common to all front
 ends. @xref{Type Information}.
+@item need_gmp
+If defined  to @samp{yes}, this frontend requires the GMP library.
+Enables configure tests for GMP, which set @code{GMPLIBS} and
+@code{GMPINC} appropriately.
 
 @end table
 
diff --git a/gcc/doc/standards.texi b/gcc/doc/standards.texi
index b8a44d4..df14c0f 100644
--- a/gcc/doc/standards.texi
+++ b/gcc/doc/standards.texi
@@ -186,7 +186,10 @@ GNAT Reference Manual}, for information on standard
 conformance and compatibility of the Ada compiler.
 
 @xref{Language,,The GNU Fortran Language, g77, Using and Porting GNU
-Fortran}, for details of the Fortran language supported by GCC@.
+Fortran}, for details of the Fortran language supported by @command{g77}.
+
+@xref{Standards,,Standards, gfortran, The GNU Fortran 95 Compiler}, for details
+of standards supported by @command{gfortran}.
 
 @xref{Compatibility,,Compatibility with the Java Platform, gcj, GNU gcj},
 for details of compatibility between @command{gcj} and the Java Platform.
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 85515bf..339dc7a 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -8781,16 +8781,6 @@ being called, in @code{call} RTL expressions.  On most machines this
 should be @code{QImode}.
 @end defmac
 
-@defmac INTEGRATE_THRESHOLD (@var{decl})
-A C expression for the maximum number of instructions above which the
-function @var{decl} should not be inlined.  @var{decl} is a
-@code{FUNCTION_DECL} node.
-
-The default definition of this macro is 64 plus 8 times the number of
-arguments that the function accepts.  Some people think a larger
-threshold should be used on RISC machines.
-@end defmac
-
 @defmac STDC_0_IN_SYSTEM_HEADERS
 In normal operation, the preprocessor expands @code{__STDC__} to the
 constant 1, to signify that GCC conforms to ISO Standard C@.  On some
diff --git a/gcc/doc/tree-ssa.texi b/gcc/doc/tree-ssa.texi
new file mode 100644
index 0000000..56ccd61
--- /dev/null
+++ b/gcc/doc/tree-ssa.texi
@@ -0,0 +1,1189 @@
+@c Copyright (c) 2004 Free Software Foundation, Inc.
+@c Free Software Foundation, Inc.
+@c This is part of the GCC manual.
+@c For copying conditions, see the file gcc.texi.
+
+@c ---------------------------------------------------------------------
+@c Tree SSA
+@c ---------------------------------------------------------------------
+
+@node Tree SSA
+@chapter Analysis and Optimization of GIMPLE Trees
+@cindex Tree SSA
+@cindex Optimization infrastructure for GIMPLE
+
+GCC uses three main intermediate languages to represent the program
+during compilation: GENERIC, GIMPLE and RTL@.  GENERIC is a
+language-independent representation generated by each front end.  It
+is used to serve as an interface between the parser and optimizer.
+GENERIC is a common representation that is able to represent programs
+written in all the languages supported by GCC@.
+
+GIMPLE and RTL are used to optimize the program.  GIMPLE is used for
+target and language independent optimizations (e.g., inlining,
+constant propagation, tail call elimination, redundancy elimination,
+etc).  Much like GENERIC, GIMPLE is a language independent, tree based
+representation. However, it differs from GENERIC in that the GIMPLE
+grammar is more restrictive: expressions contain no more than 3
+operands (except function calls), it has no control flow structures
+and expressions with side-effects are only allowed on the right hand
+side of assignments.  See the chapter describing GENERIC and GIMPLE
+for more details.
+
+This chapter describes the data structures and functions used in the
+GIMPLE optimizers (also known as ``tree optimizers'' or ``middle
+end'').  In particular, it focuses on all the macros, data structures,
+functions and programming constructs needed to implement optimization
+passes for GIMPLE@.
+
+@menu
+* GENERIC::		A high-level language-independent representation.
+* GIMPLE::              A lower-level factored tree representation.
+* Annotations::		Attributes for statements and variables.
+* Statement Operands::	Variables referenced by GIMPLE statements.
+* SSA::			Static Single Assignment representation.
+* Alias analysis::	Representing aliased loads and stores.
+@end menu
+
+@node GENERIC
+@section GENERIC
+@cindex GENERIC
+
+The purpose of GENERIC is simply to provide a language-independent way of
+representing an entire function in trees.  To this end, it was necessary to
+add a few new tree codes to the back end, but most everything was already
+there.  If you can express it with the codes in @code{gcc/tree.def}, it's
+GENERIC.
+
+Early on, there was a great deal of debate about how to think about
+statements in a tree IL.  In GENERIC, a statement is defined as any
+expression whose value, if any, is ignored.  A statement will always
+have @code{TREE_SIDE_EFFECTS} set (or it will be discarded), but a
+non-statement expression may also have side effects.  A
+@code{CALL_EXPR}, for instance.
+
+It would be possible for some local optimizations to work on the
+GENERIC form of a function; indeed, the adapted tree inliner works
+fine on GENERIC, but the current compiler performs inlining after
+lowering to GIMPLE (a restricted form described in the next section).
+Indeed, currently the frontends perform this lowering before handing
+off to @code{tree_rest_of_compilation}, but this seems inelegant.
+
+If necessary, a front end can use some language-dependent tree codes
+in its GENERIC representation, so long as it provides a hook for
+converting them to GIMPLE and doesn't expect them to work with any
+(hypothetical) optimizers that run before the conversion to GIMPLE.
+The intermediate representation used while parsing C and C++ looks
+very little like GENERIC, but the C and C++ gimplifier hooks are
+perfectly happy to take it as input and spit out GIMPLE.
+
+@node GIMPLE
+@section GIMPLE
+@cindex GIMPLE
+
+GIMPLE is a simplified subset of GENERIC for use in optimization.  The
+particular subset chosen (and the name) was heavily influenced by the
+SIMPLE IL used by the McCAT compiler project at McGill University,
+though we have made some different choices.  For one thing, SIMPLE
+doesn't support @code{goto}; a production compiler can't afford that
+kind of restriction.
+
+GIMPLE retains much of the structure of the parse trees: lexical
+scopes are represented as containers, rather than markers.  However,
+expressions are broken down into a 3-address form, using temporary
+variables to hold intermediate values.  Also, control structures are
+lowered to gotos.
+
+In GIMPLE no container node is ever used for its value; if a
+@code{COND_EXPR} or @code{BIND_EXPR} has a value, it is stored into a
+temporary within the controlled blocks, and that temporary is used in
+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.  
+
+@c Currently, the only way to
+@c tell whether or not an expression is in GIMPLE form is by recursively
+@c examining it; in the future there will probably be a flag to help avoid
+@c redundant work.  FIXME FIXME
+
+@menu
+* Interfaces::
+* Temporaries::
+* GIMPLE Expressions::
+* Statements::
+* GIMPLE Example::
+* Rough GIMPLE Grammar::
+@end menu
+
+@node Interfaces
+@subsection Interfaces
+@cindex gimplification
+
+The tree representation of a function is stored in
+@code{DECL_SAVED_TREE}.  It is lowered to GIMPLE by a call to
+@code{gimplify_function_tree}.
+
+If a front end wants to include language-specific tree codes in the tree
+representation which it provides to the back end, it must provide a
+definition of @code{LANG_HOOKS_GIMPLIFY_EXPR} which knows how to
+convert the front end trees to GIMPLE.  Usually such a hook will involve
+much of the same code for expanding front end trees to RTL.  This function
+can return fully lowered GIMPLE, or it can return GENERIC trees and let the
+main gimplifier lower them the rest of the way; this is often simpler.
+
+The C and C++ front ends currently convert directly from front end
+trees to GIMPLE, and hand that off to the back end rather than first
+converting to GENERIC.  Their gimplifier hooks know about all the
+@code{_STMT} nodes and how to convert them to GENERIC forms.  There
+was some work done on a genericization pass which would run first, but
+the existence of @code{STMT_EXPR} meant that in order to convert all
+of the C statements into GENERIC equivalents would involve walking the
+entire tree anyway, so it was simpler to lower all the way.  This
+might change in the future if someone writes an optimization pass
+which would work better with higher-level trees, but currently the
+optimizers all expect GIMPLE.
+
+A front end which wants to use the tree optimizers (and already has
+some sort of whole-function tree representation) only needs to provide
+a definition of @code{LANG_HOOKS_GIMPLIFY_EXPR}, call
+@code{gimplify_function_tree} to lower to GIMPLE, and then hand off to
+@code{tree_rest_of_compilation} to compile and output the function.
+
+You can tell the compiler to dump a C-like representation of the GIMPLE
+form with the flag @code{-fdump-tree-gimple}.
+
+@node Temporaries
+@subsection Temporaries
+@cindex Temporaries
+
+When gimplification encounters a subexpression which is too complex, it
+creates a new temporary variable to hold the value of the subexpression,
+and adds a new statement to initialize it before the current statement.
+These special temporaries are known as @samp{expression temporaries}, and are
+allocated using @code{get_formal_tmp_var}.  The compiler tries to
+always evaluate identical expressions into the same temporary, to simplify
+elimination of redundant calculations.
+
+We can only use expression temporaries when we know that it will not be
+reevaluated before its value is used, and that it will not be otherwise
+modified@footnote{These restrictions are derived from those in Morgan 4.8.}.
+Other temporaries can be allocated using
+@code{get_initialized_tmp_var} or @code{create_tmp_var}.
+
+Currently, an expression like @code{a = b + 5} is not reduced any
+further.  We tried converting it to something like
+@smallexample
+  T1 = b + 5;
+  a = T1;
+@end smallexample
+but this bloated the representation for minimal benefit.  However, a
+variable which must live in memory cannot appear in an expression; its
+value is explicitly loaded into a temporary first.  Similarly, storing
+the value of an expression to a memory variable goes through a
+temporary.
+
+@node GIMPLE Expressions
+@subsection Expressions
+@cindex GIMPLE Expressions
+
+In general, expressions in GIMPLE consist of an operation and the
+appropriate number of simple operands; these operands must either be a
+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 
+@end smallexample
+becomes
+@smallexample
+  T1 = b + c;
+  a = T1 + d;
+@end smallexample
+
+The same rule holds for arguments to a @code{CALL_EXPR}.
+
+The target of an assignment is usually a variable, but can also be an
+@code{INDIRECT_REF} or a compound lvalue as described below.
+
+@menu
+* Compound Expressions::
+* Compound Lvalues::
+* Conditional Expressions::
+* Logical Operators::
+@end menu
+
+@node Compound Expressions
+@subsubsection Compound Expressions
+@cindex Compound Expressions
+
+The left-hand side of a C comma expression is simply moved into a separate
+statement.
+
+@node Compound Lvalues
+@subsubsection Compound Lvalues
+@cindex Compound Lvalues
+
+Currently compound lvalues involving array and structure field references
+are not broken down; an expression like @code{a.b[2] = 42} is not reduced
+any further (though complex array subscripts are).  This restriction is a
+workaround for limitations in later optimizers; if we were to convert this
+to
+
+@smallexample
+  T1 = &a.b;
+  T1[2] = 42;
+@end smallexample
+
+alias analysis would not remember that the reference to @code{T1[2]} came
+by way of @code{a.b}, so it would think that the assignment could alias
+another member of @code{a}; this broke @code{struct-alias-1.c}.  Future
+optimizer improvements may make this limitation unnecessary.
+
+@node Conditional Expressions
+@subsubsection Conditional Expressions
+@cindex Conditional Expressions
+
+A C @code{?:} expression is converted into an @code{if} statement with
+each branch assigning to the same temporary.  So,
+
+@smallexample
+  a = b ? c : d;
+@end smallexample
+becomes
+@smallexample
+  if (b)
+    T1 = c;
+  else
+    T1 = d;
+  a = T1;
+@end smallexample
+
+Note that in GIMPLE, @code{if} statements are also represented using
+@code{COND_EXPR}, as described below.
+
+@node Logical Operators
+@subsubsection Logical Operators
+@cindex Logical Operators
+
+Except when they appear in the condition operand of a @code{COND_EXPR},
+logical `and' and `or' operators are simplified as follows:
+@code{a = b && c} becomes
+
+@smallexample
+  T1 = (bool)b;
+  if (T1)
+    T1 = (bool)c;
+  a = T1;
+@end smallexample
+
+Note that @code{T1} in this example cannot be an expression temporary,
+because it has two different assignments.
+
+@node Statements
+@subsection Statements
+@cindex Statements
+
+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}.
+
+There are also several varieties of complex statements.
+
+@menu
+* Blocks::
+* Statement Sequences::
+* Empty Statements::
+* Loops::
+* Selection Statements::
+* Jumps::
+* Cleanups::
+* GIMPLE Exception Handling::
+@end menu
+
+@node Blocks
+@subsubsection Blocks
+@cindex Blocks
+
+Block scopes and the variables they declare in GENERIC and GIMPLE are
+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 
+@code{DECL_INITIAL} and into a statement in the controlled block.  When
+gimplifying from C or C++, this initialization replaces the
+@code{DECL_STMT}.
+
+Variable-length arrays (VLAs) complicate this process, as their size often
+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{BIND_EXPR} which contains declarations for the temporary variables
+used in the function.
+
+A C++ program will usually contain more @code{BIND_EXPR}s than there are
+syntactic blocks in the source code, since several C++ constructs have
+implicit scopes associated with them.  On the other hand, although the C++
+front end uses pseudo-scopes to handle cleanups for objects with
+destructors, these don't translate into the GIMPLE form; multiple
+declarations at the same level use the same BIND_EXPR.
+
+@node Statement Sequences
+@subsubsection Statement Sequences
+@cindex Statement Sequences
+
+Multiple statements at the same nesting level are collected into a
+@code{STATEMENT_LIST}.  Statement lists are modified and traversed
+using the interface in @samp{tree-iterator.h}.
+
+@node Empty Statements
+@subsubsection Empty Statements
+@cindex Empty Statements
+
+Whenever possible, statements with no effect are discarded.  But if they
+are nested within another construct which cannot be discarded for some
+reason, they are instead replaced with an empty statement, generated by
+@code{build_empty_stmt}.  Initially, all empty statements were shared,
+after the pattern of the Java front end, but this caused a lot of trouble in
+practice.
+
+An empty statement is represented as @code{(void)0}.
+
+@node Loops
+@subsubsection Loops
+@cindex Loops
+
+At one time loops were expressed in GIMPLE using @code{LOOP_EXPR}, but
+now they are lowered to explicit gotos.
+
+@node Selection Statements
+@subsubsection Selection Statements
+@cindex Selection Statements
+
+A simple selection statement, such as the C @code{if} statement, is
+expressed in GIMPLE using a void @code{COND_EXPR}.  If only one branch is
+used, the other is filled with an empty statement.
+
+Normally, the condition expression is reduced to a simple comparison.  If
+it is a shortcut (@code{&&} or @code{||}) expression, however, we try to
+break up the @code{if} into multiple @code{if}s so that the implied shortcut
+is taken directly, much like the transformation done by @code{do_jump} in
+the RTL expander.
+
+A @code{SWITCH_EXPR} in GIMPLE contains the condition and a
+@code{TREE_VEC} of @code{CASE_LABEL_EXPR}s describing the case values
+and corresponding @code{LABEL_DECL}s to jump to.  The body of the
+@code{switch} is moved after the @code{SWITCH_EXPR}.
+
+@node Jumps
+@subsubsection Jumps
+@cindex Jumps
+
+Other jumps are expressed by either @code{GOTO_EXPR} or @code{RETURN_EXPR}.
+
+The operand of a @code{GOTO_EXPR} must be either a label or a variable
+containing the address to jump to.
+
+The operand of a @code{RETURN_EXPR} is either @code{NULL_TREE} or a
+@code{MODIFY_EXPR} which sets the return value.  It would be nice to
+move the @code{MODIFY_EXPR} into a separate statement, but the special
+return semantics in @code{expand_return} make that difficult.  It may
+still happen in the future, perhaps by moving most of that logic into
+@code{expand_assignment}.
+
+@node Cleanups
+@subsubsection Cleanups
+@cindex Cleanups
+
+Destructors for local C++ objects and similar dynamic cleanups are
+represented in GIMPLE by a @code{TRY_FINALLY_EXPR}.  When the controlled
+block exits, the cleanup is run.
+
+@code{TRY_FINALLY_EXPR} complicates the flow graph, since the cleanup
+needs to appear on every edge out of the controlled block; this
+reduces our freedom to move code across these edges.  Therefore, the
+EH lowering pass which runs before most of the optimization passes
+eliminates these expressions by explicitly adding the cleanup to each
+edge.
+
+@node GIMPLE Exception Handling
+@subsubsection Exception Handling
+@cindex GIMPLE Exception Handling
+
+Other exception handling constructs are represented using
+@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:
+
+@enumerate
+@item A @code{CATCH_EXPR} executes its handler if the thrown exception
+  matches one of the allowed types.  Multiple handlers can be
+  expressed by a sequence of @code{CATCH_EXPR} statements.
+@item An @code{EH_FILTER_EXPR} executes its handler if the thrown
+  exception does not match one of the allowed types.
+@end enumerate
+
+Currently throwing an exception is not directly represented in GIMPLE,
+since it is implemented by calling a function.  At some point in the future
+we will want to add some way to express that the call will throw an
+exception of a known type.
+
+Just before running the optimizers, the compiler lowers the high-level
+EH constructs above into a set of @samp{goto}s, magic labels, and EH
+regions.  Continuing to unwind at the end of a cleanup is represented
+with a @code{RESX_EXPR}.
+
+@node GIMPLE Example
+@subsection GIMPLE Example
+@cindex GIMPLE Example
+
+@smallexample
+struct A @{ A(); ~A(); @};
+
+int i;
+int g();
+void f()
+@{
+  A a;
+  int j = (--i, i ? 0 : 1);
+
+  for (int x = 42; x > 0; --x)
+    @{
+      i += g()*4 + 32;
+    @}
+@}
+@end smallexample
+
+becomes
+
+@smallexample
+void f()
+@{
+  int i.0;
+  int T.1;
+  int iftmp.2;
+  int T.3;
+  int T.4;
+  int T.5;
+  int T.6;
+
+  @{
+    struct A a;
+    int j;
+
+    __comp_ctor (&a);
+    try
+      @{
+        i.0 = i;
+        T.1 = i.0 - 1;
+        i = T.1;
+        i.0 = i;
+        if (i.0 == 0)
+          iftmp.2 = 1;
+        else
+          iftmp.2 = 0;
+        j = iftmp.2;
+        @{
+          int x;
+
+          x = 42;
+          goto test;
+          loop:;
+
+          T.3 = g ();
+          T.4 = T.3 * 4;
+          i.0 = i;
+          T.5 = T.4 + i.0;
+          T.6 = T.5 + 32;
+          i = T.6;
+          x = x - 1;
+
+          test:;
+          if (x > 0)
+            goto loop;
+          else
+            goto break_;
+          break_:;
+        @}
+      @}
+    finally
+      @{
+        __comp_dtor (&a);
+      @}
+  @}
+@}
+@end smallexample
+
+@node Rough GIMPLE Grammar
+@subsection Rough GIMPLE Grammar
+@cindex Rough GIMPLE Grammar
+
+@smallexample
+function:
+  FUNCTION_DECL
+    DECL_SAVED_TREE -> block
+block:
+  BIND_EXPR
+    BIND_EXPR_VARS -> DECL chain
+    BIND_EXPR_BLOCK -> BLOCK
+    BIND_EXPR_BODY 
+      -> compound-stmt
+compound-stmt:
+  COMPOUND_EXPR
+    op0 -> non-compound-stmt
+    op1 -> stmt
+stmt: compound-stmt
+  | non-compound-stmt
+non-compound-stmt:
+  block
+  | if-stmt
+  | switch-stmt
+  | jump-stmt
+  | label-stmt
+  | try-stmt
+  | modify-stmt
+  | call-stmt
+if-stmt:
+  COND_EXPR
+    op0 -> condition
+    op1 -> stmt
+    op2 -> stmt
+switch-stmt:
+  SWITCH_EXPR
+    op0 -> val
+    op1 -> NULL_TREE
+    op2 -> TREE_VEC of CASE_LABEL_EXPRs
+jump-stmt:
+    GOTO_EXPR
+      op0 -> LABEL_DECL | '*' ID
+  | RETURN_EXPR
+      op0 -> modify-stmt
+             | NULL_TREE
+label-stmt:
+  LABEL_EXPR
+      op0 -> LABEL_DECL
+try-stmt:
+  TRY_CATCH_EXPR
+    op0 -> stmt
+    op1 -> handler
+  | TRY_FINALLY_EXPR
+    op0 -> stmt
+    op1 -> stmt
+handler:
+  catch-seq
+  | EH_FILTER_EXPR
+  | stmt
+catch-seq:
+  CATCH_EXPR
+  | COMPOUND_EXPR
+      op0 -> CATCH_EXPR
+      op1 -> catch-seq
+modify-stmt:
+  MODIFY_EXPR
+    op0 -> lhs
+    op1 -> rhs
+call-stmt: CALL_EXPR
+  op0 -> _DECL | '&' _DECL
+  op1 -> arglist
+arglist:
+  NULL_TREE
+  | TREE_LIST
+      op0 -> val
+      op1 -> arglist
+
+varname : compref | _DECL
+lhs: varname | '*' _DECL
+pseudo-lval: _DECL | '*' _DECL
+compref :
+  COMPONENT_REF
+    op0 -> compref | pseudo-lval
+  | ARRAY_REF
+    op0 -> compref | pseudo-lval
+    op1 -> val
+
+condition : val | val relop val
+val : _DECL | CONST
+
+rhs: varname | CONST
+   | '*' _DECL
+   | '&' varname
+   | call_expr
+   | unop val
+   | val binop val
+   | '(' cast ')' val
+
+unop: '+' | '-' | '!' | '~'
+
+binop: relop | '-' | '+' | '/' | '*'
+  | '%' | '&' | '|' | '<<' | '>>' | '^'
+
+relop: All tree codes of class '<'
+@end smallexample
+
+@node Annotations
+@section Annotations
+@cindex annotations
+
+The optimizers need to associate attributes with statements and
+variables during the optimization process.  For instance, we need to
+know what basic block does a statement belong to or whether a variable
+has aliases.  All these attributes are stored in data structures
+called annotations which are then linked to the field @code{ann} in
+@code{struct tree_common}.
+
+Presently, we define annotations for statements (@code{stmt_ann_t}),
+variables (@code{var_ann_t}) and SSA names (@code{ssa_name_ann_t}).
+Annotations are defined and documented in @file{tree-flow.h}.
+
+
+@node Statement Operands
+@section Statement Operands
+@cindex operands
+@cindex virtual operands
+@cindex real operands
+@findex get_stmt_operands
+@findex modify_stmt
+
+Almost every GIMPLE statement will contain a reference to a variable
+or memory location.  Since statements come in different shapes and
+sizes, their operands are going to be located at various spots inside
+the statement's tree.  To facilitate access to the statement's
+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.  
+
+Data flow analysis and optimization is done on all tree nodes
+representing variables.  Any node for which @code{SSA_VAR_P} returns
+nonzero is considered when scanning statement operands.  However, not
+all @code{SSA_VAR_P} variables are processed in the same way.  For the
+purposes of optimization, we need to distinguish between references to
+local scalar variables and references to globals, statics, structures,
+arrays, aliased variables, etc.  The reason is simple, the compiler
+can gather complete data flow information for a local scalar.  On the
+other hand, a global variable may be modified by a function call, it
+may not be possible to keep track of all the elements of an array or
+the fields of a structure, etc.
+
+The operand scanner gathers two kinds of operands: @dfn{real} and
+@dfn{virtual}.  An operand for which @code{is_gimple_reg} returns true
+is considered real, otherwise it is a virtual operand.  We also
+distinguish between uses and definitions.  An operand is used if its
+value is loaded by the statement (e.g., the operand at the RHS of an
+assignment).  If the statement assigns a new value to the operand, the
+operand is considered a definition (e.g., the operand at the LHS of
+an assignment).
+
+Virtual and real operands also have very different data flow
+properties.  Real operands are unambiguous references to the
+full object that they represent.  For instance, given
+
+@smallexample
+@{
+  int a, b;
+  a = b
+@}
+@end smallexample
+
+Since @code{a} and @code{b} are non-aliased locals, the statement
+@code{a = b} will have one real definition and one real use because
+variable @code{b} is completely modified with the contents of
+variable @code{a}.  Real definition are also known as @dfn{killing
+definitions}.  Similarly, the use of @code{a} reads all its bits.
+
+In contrast, virtual operands represent partial or ambiguous
+references to a variable.  For instance, given
+
+@smallexample
+@{
+  int a, b, *p;
+
+  if (...)
+    p = &a;
+  else
+    p = &b;
+  *p = 5;
+  return *p;
+@}
+@end smallexample
+
+The assignment @code{*p = 5} may be a definition of @code{a} or
+@code{b}.  If we cannot determine statically where @code{p} is
+pointing to at the time of the store operation, we create virtual
+definitions to mark that statement as a potential definition site for
+@code{a} and @code{b}.  Memory loads are similarly marked with virtual
+use operands.  Virtual operands are shown in tree dumps right before
+the statement that contains them.  To request a tree dump with virtual
+operands, use the @option{-vops} option to @option{-fdump-tree}:
+
+@smallexample
+@{
+  int a, b, *p;
+
+  if (...)
+    p = &a;
+  else
+    p = &b;
+  # a = VDEF <a>
+  # b = VDEF <b>
+  *p = 5;
+
+  # VUSE <a>
+  # VUSE <b>
+  return *p;
+@}
+@end smallexample
+
+Notice that @code{VDEF} operands have two copies of the referenced
+variable.  This indicates that this is not a killing definition of
+that variable.  In this case we refer to it as a @dfn{may definition}
+or @dfn{aliased store}.  The presence of the second copy of the
+variable in the @code{VDEF} operand will become important when the
+function is converted into SSA form.  This will be used to link all
+the non-killing definitions to prevent optimizations from making
+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{VDEF_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})
+Returns the array of operands used by the statement with annotation
+@var{ann}.
+@end defmac
+
+@defmac STMT_USE_OPS (@var{stmt})
+Alternate version of USE_OPS that takes the statement @var{stmt} as
+input.
+@end defmac
+
+@defmac NUM_USES (@var{ops})
+Return the number of USE operands in array @var{ops}.
+@end defmac
+
+@defmac USE_OP_PTR (@var{ops}, @var{i})
+Return a pointer to the @var{i}th operand in array @var{ops}.
+@end defmac
+
+@defmac USE_OP (@var{ops}, @var{i})
+Return the @var{i}th operand in array @var{ops}.
+@end defmac
+
+The following function shows how to print all the operands of a given
+statement:
+
+@smallexample
+void
+print_ops (tree stmt)
+@{
+  vuse_optype vuses;
+  vdef_optype vdefs;
+  def_optype defs;
+  use_optype uses;
+  stmt_ann_t ann;
+  size_t i;
+
+  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);
+
+  uses = USE_OPS (ann);
+  for (i = 0; i < NUM_USES (uses); i++)
+    print_generic_expr (stderr, USE_OP (uses, i), 0);
+  
+  vdefs = VDEF_OPS (ann);
+  for (i = 0; i < NUM_VDEFS (vdefs); i++)
+    print_generic_expr (stderr, VDEF_OP (vdefs, i), 0);
+  
+  vuses = VUSE_OPS (ann);
+  for (i = 0; i < NUM_VUSES (vuses); i++)
+    print_generic_expr (stderr, VUSE_OP (vuses, i), 0);
+@}
+@end smallexample
+
+To collect the operands, you first need to call
+@code{get_stmt_operands}.  Since that is a potentially expensive
+operation, statements are only scanned if they have been marked
+modified by a call to @code{modify_stmt}.  So, if your pass replaces
+operands in a statement, make sure to call @code{modify_stmt}.
+
+
+@node SSA
+@section Static Single Assignment
+@cindex SSA
+@cindex static single assignment
+
+Most of the tree optimizers rely on the data flow information provided
+by the Static Single Assignment (SSA) form.  We implement the SSA form
+as described in @cite{R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and
+K. Zadeck. Efficiently Computing Static Single Assignment Form and the
+Control Dependence Graph. ACM Transactions on Programming Languages
+and Systems, 13(4):451-490, October 1991}.
+
+The SSA form is based on the premise that program variables are
+assigned in exactly one location in the program.  Multiple assignments
+to the same variable create new versions of that variable.  Naturally,
+actual programs are seldom in SSA form initially because variables
+tend to be assigned multiple times.  The compiler modifies the program
+representation so that every time a variable is assigned in the code,
+a new version of the variable is created.  Different versions of the
+same variable are distinguished by subscripting the variable name with
+its version number.  Variables used in the right-hand side of
+expressions are renamed so that their version number matches that of
+the most recent assignment.
+
+We represent variable versions using @code{SSA_NAME} nodes.  The
+renaming process in @file{tree-ssa.c} wraps every real and
+virtual operand with an @code{SSA_NAME} node which contains
+the version number and the statement that created the
+@code{SSA_NAME}.  Only definitions and virtual definitions may
+create new @code{SSA_NAME} nodes.
+
+Sometimes, flow of control makes it impossible to determine what is the
+most recent version of a variable.  In these cases, the compiler
+inserts an artificial definition for that variable called
+@dfn{PHI function} or @dfn{PHI node}.  This new definition merges
+all the incoming versions of the variable to create a new name
+for it.  For instance,
+
+@smallexample
+if (...)
+  a_1 = 5;
+else if (...)
+  a_2 = 2;
+else
+  a_3 = 13;
+
+# a_4 = PHI <a_1, a_2, a_3>
+return a_4;
+@end smallexample
+
+Since it is not possible to determine which of the three branches
+will be taken at runtime, we don't know which of @code{a_1},
+@code{a_2} or @code{a_3} to use at the return statement.  So, the
+SSA renamer creates a new version @code{a_4} which is assigned
+the result of ``merging'' @code{a_1}, @code{a_2} and @code{a_3}.
+Hence, PHI nodes mean ``one of these operands.  I don't know
+which''.
+
+The following macros can be used to examine PHI nodes
+
+@defmac	PHI_RESULT (@var{phi})
+Returns the @code{SSA_NAME} created by PHI node @var{phi} (i.e.,
+@var{phi}'s LHS).
+@end defmac
+
+@defmac	PHI_NUM_ARGS (@var{phi})
+Returns the number of arguments in @var{phi}.  This number is exactly
+the number of incoming edges to the basic block holding @var{phi}@.
+@end defmac
+
+@defmac	PHI_ARG_ELT (@var{phi}, @var{i})
+Returns a tuple representing the @var{i}th argument of @var{phi}@.
+Each element of this tuple contains an @code{SSA_NAME} @var{var} and
+the incoming edge through which @var{var} flows.
+@end defmac
+
+@defmac	PHI_ARG_EDGE (@var{phi}, @var{i})
+Returns the incoming edge for the @var{i}th argument of @var{phi}.
+@end defmac
+
+@defmac	PHI_ARG_DEF (@var{phi}, @var{i})
+Returns the @code{SSA_NAME} for the @var{i}th argument of @var{phi}.
+@end defmac
+
+
+@subsection Preserving the SSA form
+@findex vars_to_rename
+@cindex preserving SSA form
+Some optimization passes make changes to the function that
+invalidate the SSA property.  This can happen when a pass has
+added new variables or changed the program so that variables that
+were previously aliased aren't anymore.
+
+Whenever something like this happens, the affected variables must
+be renamed into SSA form again.  To do this, you should mark the
+new variables in the global bitmap @code{vars_to_rename}.  Once
+your pass has finished, the pass manager will invoke the SSA
+renamer to put the program into SSA once more.
+
+@subsection Examining @code{SSA_NAME} nodes
+@cindex examining SSA_NAMEs
+
+The following macros can be used to examine @code{SSA_NAME} nodes
+
+@defmac SSA_NAME_DEF_STMT (@var{var})
+Returns the statement @var{s} that creates the @code{SSA_NAME}
+@var{var}.  If @var{s} is an empty statement (i.e., @code{IS_EMPTY_STMT
+(@var{s})} returns @code{true}), it means that the first reference to
+this variable is a USE or a VUSE@.
+@end defmac
+
+@defmac SSA_NAME_VERSION (@var{var})
+Returns the version number of the @code{SSA_NAME} object @var{var}.
+@end defmac
+
+
+@subsection Walking use-def chains
+
+@deftypefn {Tree SSA function} void walk_use_def_chains (@var{var}, @var{fn}, @var{data})
+
+Walks use-def chains starting at the @code{SSA_NAME} node @var{var}.
+Calls function @var{fn} at each reaching definition found.  Function
+@var{FN} takes three arguments: @var{var}, its defining statement
+(@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}.  
+
+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
+function will:
+
+@enumerate
+@item	Walk the use-def chains for @var{arg}.
+@item	Call @code{FN (@var{arg}, @var{phi}, @var{data})}.
+@end enumerate
+
+Note how the first argument to @var{fn} is no longer the original
+variable @var{var}, but the PHI argument currently being examined.
+If @var{fn} wants to get at @var{var}, it should call
+@code{PHI_RESULT} (@var{phi}).
+@end deftypefn
+
+@subsection Walking the dominator tree
+
+@deftypefn {Tree SSA function} void walk_dominator_tree (@var{walk_data}, @var{bb})
+
+This function walks the dominator tree for the current CFG calling a
+set of callback functions defined in @var{struct dom_walk_data} in
+@file{domwalk.h}.  The call back functions you need to define give you
+hooks to execute custom code at various points during traversal:
+
+@enumerate
+@item Once to initialize any local data needed while processing
+      @var{bb} and its children.  This local data is pushed into an
+      internal stack which is automatically pushed and popped as the
+      walker traverses the dominator tree.
+
+@item Once before traversing all the statements in the @var{bb}.
+
+@item Once for every statement inside @var{bb}.
+
+@item Once after traversing all the statements and before recursing
+      into @var{bb}'s dominator children.
+
+@item It then recurses into all the dominator children of @var{bb}.
+
+@item After recursing into all the dominator children of @var{bb} it
+      can, optionally, traverse every statement in @var{bb} again
+      (i.e., repeating steps 2 and 3).
+
+@item Once after walking the statements in @var{bb} and @var{bb}'s
+      dominator children.  At this stage, the block local data stack
+      is popped.
+@end enumerate
+@end deftypefn
+
+@node Alias analysis
+@section Alias analysis
+@cindex alias
+@cindex flow-sensitive alias analysis
+@cindex flow-insensitive alias analysis
+
+Alias analysis proceeds in 3 main phases:
+
+@enumerate
+@item	Points-to and escape analysis.
+
+This phase walks the use-def chains in the SSA web looking for
+three things:
+
+	@itemize @bullet
+	@item	Assignments of the form @code{P_i = &VAR}
+	@item	Assignments of the form P_i = malloc()
+	@item	Pointers and ADDR_EXPR that escape the current function.
+	@end itemize
+
+The concept of `escaping' is the same one used in the Java world.
+When a pointer or an ADDR_EXPR escapes, it means that it has been
+exposed outside of the current function.  So, assignment to
+global variables, function arguments and returning a pointer are
+all escape sites.
+
+This is where we are currently limited.  Since not everything is
+renamed into SSA, we lose track of escape properties when a
+pointer is stashed inside a field in a structure, for instance.
+In those cases, we are assuming that the pointer does escape.
+
+We use escape analysis to determine whether a variable is
+call-clobbered.  Simply put, if an ADDR_EXPR escapes, then the
+variable is call-clobbered.  If a pointer P_i escapes, then all
+the variables pointed-to by P_i (and its memory tag) also escape.
+
+@item	Compute flow-sensitive aliases
+
+We have two classes of memory tags.  Memory tags associated with
+the pointed-to data type of the pointers in the program.  These
+tags are called ``type memory tag'' (TMT).  The other class are
+those associated with SSA_NAMEs, called ``name memory tag'' (NMT).
+The basic idea is that when adding operands for an INDIRECT_REF
+*P_i, we will first check whether P_i has a name tag, if it does
+we use it, because that will have more precise aliasing
+information.  Otherwise, we use the standard type tag.
+
+In this phase, we go through all the pointers we found in
+points-to analysis and create alias sets for the name memory tags
+associated with each pointer P_i.  If P_i escapes, we mark
+call-clobbered the variables it points to and its tag.
+
+
+@item	Compute flow-insensitive aliases
+
+This pass will compare the alias set of every type memory tag and
+every addressable variable found in the program.  Given a type
+memory tag TMT and an addressable variable V@.  If the alias sets
+of TMT and V conflict (as computed by may_alias_p), then V is
+marked as an alias tag and added to the alias set of TMT@.
+@end enumerate
+
+For instance, consider the following function:
+
+@example
+foo (int i)
+@{
+  int *p, *q, a, b;
+
+  if (i > 10)
+    p = &a;
+  else
+    q = &b;
+
+  *p = 3;
+  *q = 5;
+  a = b + 2;
+  return *p;
+@}
+@end example
+
+After aliasing analysis has finished, the type memory tag for
+pointer @code{p} will have two aliases, namely variables @code{a} and
+@code{b}.
+Every time pointer @code{p} is dereferenced, we want to mark the
+operation as a potential reference to @code{a} and @code{b}.
+
+@example
+foo (int i)
+@{
+  int *p, a, b;
+
+  if (i_2 > 10)
+    p_4 = &a;
+  else
+    p_6 = &b;
+  # p_1 = PHI <p_4(1), p_6(2)>;
+
+  # a_7 = VDEF <a_3>;
+  # b_8 = VDEF <b_5>;
+  *p_1 = 3;
+
+  # a_9 = VDEF <a_7>
+  # VUSE <b_8>
+  a_9 = b_8 + 2;
+
+  # VUSE <a_9>;
+  # VUSE <b_8>;
+  return *p_1;
+@}
+@end example
+
+In certain cases, the list of may aliases for a pointer may grow
+too large.  This may cause an explosion in the number of virtual
+operands inserted in the code.  Resulting in increased memory
+consumption and compilation time.
+
+When the number of virtual operands needed to represent aliased
+loads and stores grows too large (configurable with @option{--param
+max-aliased-vops}), alias sets are grouped to avoid severe
+compile-time slow downs and memory consumption.  The alias
+grouping heuristic proceeds as follows:
+
+@enumerate
+@item Sort the list of pointers in decreasing number of contributed
+virtual operands.
+
+@item Take the first pointer from the list and reverse the role
+of the memory tag and its aliases.  Usually, whenever an
+aliased variable Vi is found to alias with a memory tag
+T, we add Vi to the may-aliases set for T@.  Meaning that
+after alias analysis, we will have:
+
+@smallexample
+may-aliases(T) = @{ V1, V2, V3, ..., Vn @}
+@end smallexample
+
+This means that every statement that references T, will get
+@code{n} virtual operands for each of the Vi tags.  But, when
+alias grouping is enabled, we make T an alias tag and add it
+to the alias set of all the Vi variables:
+
+@smallexample
+may-aliases(V1) = @{ T @}
+may-aliases(V2) = @{ T @}
+...
+may-aliases(Vn) = @{ T @}
+@end smallexample
+
+This has two effects: (a) statements referencing T will only get
+a single virtual operand, and, (b) all the variables Vi will now
+appear to alias each other.  So, we lose alias precision to
+improve compile time.  But, in theory, a program with such a high
+level of aliasing should not be very optimizable in the first
+place.
+
+@item Since variables may be in the alias set of more than one
+memory tag, the grouping done in step (2) needs to be extended
+to all the memory tags that have a non-empty intersection with
+the may-aliases set of tag T@.  For instance, if we originally
+had these may-aliases sets:
+
+@smallexample
+may-aliases(T) = @{ V1, V2, V3 @}
+may-aliases(R) = @{ V2, V4 @}
+@end smallexample
+
+In step (2) we would have reverted the aliases for T as:
+
+@smallexample
+may-aliases(V1) = @{ T @}
+may-aliases(V2) = @{ T @}
+may-aliases(V3) = @{ T @}
+@end smallexample
+
+But note that now V2 is no longer aliased with R@.  We could
+add R to may-aliases(V2), but we are in the process of
+grouping aliases to reduce virtual operands so what we do is
+add V4 to the grouping to obtain:
+
+@smallexample
+may-aliases(V1) = @{ T @}
+may-aliases(V2) = @{ T @}
+may-aliases(V3) = @{ T @}
+may-aliases(V4) = @{ T @}
+@end smallexample
+
+@item If the total number of virtual operands due to aliasing is
+still above the threshold set by max-alias-vops, go back to (2).
+@end enumerate