Remove references to gccld and gccas, adjusting the documentation to

mention llvm-ld and opt instead (if appropriate).

llvm-svn: 34094

1 files changed, 4 insertions, 4 deletions

diff --git a/llvm/docs/Bugpoint.html b/llvm/docs/Bugpoint.html
index 1f295336706..43d237d094e 100644
--- a/llvm/docs/Bugpoint.html
+++ b/llvm/docs/Bugpoint.html
@@ -38,13 +38,13 @@
 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>
@@ -114,7 +114,7 @@ Otherwise, there is no problem <tt>bugpoint</tt> can debug.</p>
 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