[docs] Clean up some more llvm-gcc stuff

Some references to llvm-gcc were so crusty that I wasn't sure how to
proceed and so I've left them intact.

I also slipped in a quick peephole fix to use a :doc: link instead of
raw HTML link.

llvm-svn: 201619

docs/CommandGuide/llc.rst

@@ -45,7 +45,7 @@ End-user Options
 
  Generate code at different optimization levels.  These correspond to the
  ``-O0``, ``-O1``, ``-O2``, and ``-O3`` optimization levels used by
- :program:`llvm-gcc` and :program:`clang`.
+ :program:`clang`.
 
 .. option:: -mtriple=<target triple>
 

docs/CommandGuide/opt.rst

@@ -65,9 +65,8 @@ OPTIONS
 .. option:: -std-compile-opts
 
  This is short hand for a standard list of *compile time optimization* passes.
- This is typically used to optimize the output from the llvm-gcc front end.  It
- might be useful for other front end compilers as well.  To discover the full
- set of options available, use the following command:
+ It might be useful for other front end compilers as well.  To discover the
+ full set of options available, use the following command:
 
  .. code-block:: sh
 

docs/DeveloperPolicy.rst

@@ -212,13 +212,10 @@ features added.  Some tips for getting your testcase approved:
   directory. The appropriate sub-directory should be selected (see the
   :doc:`Testing Guide <TestingGuide>` for details).
 
-* Test cases should be written in `LLVM assembly language <LangRef.html>`_
-  unless the feature or regression being tested requires another language
-  (e.g. the bug being fixed or feature being implemented is in the llvm-gcc C++
-  front-end, in which case it must be written in C++).
+* Test cases should be written in :doc:`LLVM assembly language <LangRef>`.
 
 * Test cases, especially for regressions, should be reduced as much as possible,
-  by `bugpoint <Bugpoint.html>`_ or manually. It is unacceptable to place an
+  by :doc:`bugpoint <Bugpoint>` or manually. It is unacceptable to place an
   entire failing program into ``llvm/test`` as this creates a *time-to-test*
   burden on all developers. Please keep them short.
 
@@ -517,12 +514,12 @@ to move code from (e.g.)  libc++ to the LLVM core without concern, but that code
 cannot be moved from the LLVM core to libc++ without the copyright owner's
 permission.
 
-Note that the LLVM Project does distribute llvm-gcc and dragonegg, **which are
-GPL.** This means that anything "linked" into llvm-gcc must itself be compatible
+Note that the LLVM Project does distribute dragonegg, **which is
+GPL.** This means that anything "linked" into dragonegg must itself be compatible
 with the GPL, and must be releasable under the terms of the GPL.  This implies
-that **any code linked into llvm-gcc and distributed to others may be subject to
+that **any code linked into dragonegg and distributed to others may be subject to
 the viral aspects of the GPL** (for example, a proprietary code generator linked
-into llvm-gcc must be made available under the GPL).  This is not a problem for
+into dragonegg must be made available under the GPL).  This is not a problem for
 code already distributed under a more liberal license (like the UIUC license),
 and GPL-containing subprojects are kept in separate SVN repositories whose
 LICENSE.txt files specifically indicate that they contain GPL code.

docs/GetElementPtr.rst

@@ -77,7 +77,7 @@ therefore be indexed and requires an index operand. Consider this example:
   ...
   munge(Array);
 
-In this "C" example, the front end compiler (llvm-gcc) will generate three GEP
+In this "C" example, the front end compiler (Clang) will generate three GEP
 instructions for the three indices through "P" in the assignment statement.  The
 function argument ``P`` will be the first operand of each of these GEP
 instructions.  The second operand indexes through that pointer.  The third

docs/tutorial/LangImpl7.rst

@@ -237,7 +237,7 @@ strongly recommend that you use this technique for building SSA form,
 unless there is an extremely good reason not to. Using this technique
 is:
 
--  Proven and well tested: llvm-gcc and clang both use this technique
+-  Proven and well tested: clang uses this technique
    for local mutable variables. As such, the most common clients of LLVM
    are using this to handle a bulk of their variables. You can be sure
    that bugs are found fast and fixed early.

docs/tutorial/LangImpl8.rst

@@ -72,7 +72,7 @@ For example, try adding:
    info <../SourceLevelDebugging.html>`_ which is understood by common
    debuggers like GDB. Adding support for debug info is fairly
    straightforward. The best way to understand it is to compile some
-   C/C++ code with "``llvm-gcc -g -O0``" and taking a look at what it
+   C/C++ code with "``clang -g -O0``" and taking a look at what it
    produces.
 -  **exception handling support** - LLVM supports generation of `zero
    cost exceptions <../ExceptionHandling.html>`_ which interoperate with

docs/tutorial/OCamlLangImpl7.rst

@@ -237,7 +237,7 @@ strongly recommend that you use this technique for building SSA form,
 unless there is an extremely good reason not to. Using this technique
 is:
 
--  Proven and well tested: llvm-gcc and clang both use this technique
+-  Proven and well tested: clang uses this technique
    for local mutable variables. As such, the most common clients of LLVM
    are using this to handle a bulk of their variables. You can be sure
    that bugs are found fast and fixed early.

docs/tutorial/OCamlLangImpl8.rst

@@ -72,7 +72,7 @@ For example, try adding:
    info <../SourceLevelDebugging.html>`_ which is understood by common
    debuggers like GDB. Adding support for debug info is fairly
    straightforward. The best way to understand it is to compile some
-   C/C++ code with "``llvm-gcc -g -O0``" and taking a look at what it
+   C/C++ code with "``clang -g -O0``" and taking a look at what it
    produces.
 -  **exception handling support** - LLVM supports generation of `zero
    cost exceptions <../ExceptionHandling.html>`_ which interoperate with