Merging r261039:

[oota-llvm.git] / docs / Bugpoint.rst

diff --git a/docs/Bugpoint.rst b/docs/Bugpoint.rst
index 9ccf0cc2d9d66f8eee1d01f969a8e822960a35c9..6bd7ff99564ffd3631606211c159f7517cd7d5ba 100644 (file)
--- a/docs/Bugpoint.rst
+++ b/docs/Bugpoint.rst
@@ -1,5 +1,3 @@
-.. _bugpoint:
-
 ====================================
 LLVM bugpoint tool: design and usage
 ====================================
@@ -19,7 +17,7 @@ optimization (or combination of optimizations) that causes the crash, and reduce
 the file down to a small example which triggers the crash.
 
 For detailed case scenarios, such as debugging ``opt``, or one of the LLVM code
-generators, see `How To Submit a Bug Report document <HowToSubmitABug.html>`_.
+generators, see :doc:`HowToSubmitABug`.
 
 Design Philosophy
 =================
@@ -136,9 +134,9 @@ non-obvious ways.  Here are some hints and tips:
   It is often useful to capture the output of the program to file.  For example,
   in the C shell, you can run:
 
-  .. code-block:: bash
+  .. code-block:: console
 
-    bugpoint  ... |& tee bugpoint.log
+    $ bugpoint  ... |& tee bugpoint.log
 
   to get a copy of ``bugpoint``'s output in the file ``bugpoint.log``, as well
   as on your terminal.
@@ -210,7 +208,7 @@ point---a simple binary search may not be sufficient, as transformations that
 interact may require isolating more than one call.  In TargetLowering, use
 ``return SDNode();`` instead of ``return false;``.
 
-Now that that the number of transformations is down to a manageable number, try
+Now that the number of transformations is down to a manageable number, try
 examining the output to see if you can figure out which transformations are
 being done.  If that can be figured out, then do the usual debugging.  If which
 code corresponds to the transformation being performed isn't obvious, set a