passes. It can be used to debug three types of failures: optimizer crashes,
miscompilations by optimizers, or bad native code generation (including problems
in the static and JIT compilers). It aims to reduce large test cases to small,
-useful ones. For example, if <tt>gccas</tt> crashes while optimizing a
+useful ones. For example, if <tt>opt</tt> crashes while optimizing a
file, it will identify the optimization (or combination of optimizations) that
causes the crash, and reduce the file down to a small example which triggers the
crash.</p>
-<p>For detailed case scenarios, such as debugging <tt>gccas</tt>,
-<tt>gccld</tt>, or one of the LLVM code generators, see <a
+<p>For detailed case scenarios, such as debugging <tt>opt</tt>,
+<tt>llvm-ld</tt>, or one of the LLVM code generators, see <a
href="HowToSubmitABug.html">How To Submit a Bug Report document</a>.</p>
</div>
as it can to reduce the list of passes (for optimizer crashes) and the size of
the test program. First, <tt>bugpoint</tt> figures out which combination of
optimizer passes triggers the bug. This is useful when debugging a problem
-exposed by <tt>gccas</tt>, for example, because it runs over 38 passes.</p>
+exposed by <tt>opt</tt>, for example, because it runs over 38 passes.</p>
<p>Next, <tt>bugpoint</tt> tries removing functions from the test program, to
reduce its size. Usually it is able to reduce a test program to a single
<tt>bugpoint</tt> deletes any individual LLVM instructions whose absence does
not eliminate the failure. At the end, <tt>bugpoint</tt> should tell you what
passes crash, give you a bytecode file, and give you instructions on how to
-reproduce the failure with <tt>opt</tt>, <tt>analyze</tt>, or <tt>llc</tt>.</p>
+reproduce the failure with <tt>opt</tt> or <tt>llc</tt>.</p>
</div>