[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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201619 91177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/docs/CommandGuide/llc.rst b/docs/CommandGuide/llc.rst
index 02ad798c8b66f2e04c224f3ec4e96fdebe1eb426..dddcbaed8f57727450f6c2e7bce1f2952a67ae34 100644 (file)
--- a/docs/CommandGuide/llc.rst
+++ b/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>
 

diff --git a/docs/CommandGuide/opt.rst b/docs/CommandGuide/opt.rst
index 179c297c2209835d82d19ddbfe46a9a8954075fe..3fed6845550a29e4b96a4bdc7a50aa5114fae72e 100644 (file)
--- a/docs/CommandGuide/opt.rst
+++ b/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
 

diff --git a/docs/DeveloperPolicy.rst b/docs/DeveloperPolicy.rst
index 4ebf0f7dd9175e4e96875eb7a5bb507493ffc383..b9ac57629e30330d33afb94de8b7e0682a51faa0 100644 (file)
--- a/docs/DeveloperPolicy.rst
+++ b/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.

diff --git a/docs/GetElementPtr.rst b/docs/GetElementPtr.rst
index 306a2a87effd13c85a857d77ef54ab5db52dd814..91025d883f27c409de90169bf2b796974622224e 100644 (file)
--- a/docs/GetElementPtr.rst
+++ b/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

diff --git a/docs/tutorial/LangImpl7.rst b/docs/tutorial/LangImpl7.rst
index a2e47b5f8a267c3f7a207ad2ad0b4869efa795be..849ce50060cc6b76a98f0fda280f926e31abda00 100644 (file)
--- a/docs/tutorial/LangImpl7.rst
+++ b/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.

diff --git a/docs/tutorial/LangImpl8.rst b/docs/tutorial/LangImpl8.rst
index 3534b2e0c931ca4a2c5cc4b2b4fe4fd04eafe56d..6f694931ef862ab47b3334c664da3f56488cd9d1 100644 (file)
--- a/docs/tutorial/LangImpl8.rst
+++ b/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

diff --git a/docs/tutorial/OCamlLangImpl7.rst b/docs/tutorial/OCamlLangImpl7.rst
index cfb49312c50faa362a927d79caa118d617d28899..98ea93f42f3f3d8ed83c5917b43e6377deae2b4b 100644 (file)
--- a/docs/tutorial/OCamlLangImpl7.rst
+++ b/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.

diff --git a/docs/tutorial/OCamlLangImpl8.rst b/docs/tutorial/OCamlLangImpl8.rst
index 3534b2e0c931ca4a2c5cc4b2b4fe4fd04eafe56d..6f694931ef862ab47b3334c664da3f56488cd9d1 100644 (file)
--- a/docs/tutorial/OCamlLangImpl8.rst
+++ b/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