[llvm] r201616 - [docs] Nuke some references to llvm-gcc

[Sean Silva]

Author: silvas
Date: Tue Feb 18 17:56:43 2014
New Revision: 201616

URL: http://llvm.org/viewvc/llvm-project?rev=201616&view=rev
Log:
[docs] Nuke some references to llvm-gcc

>From a cursory look it seems like all the described commandline options
and such apply to clang just fine, but I'd appreciate a second opinion.

Modified:
    llvm/trunk/docs/HowToSubmitABug.rst

Modified: llvm/trunk/docs/HowToSubmitABug.rst
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/HowToSubmitABug.rst?rev=201616&r1=201615&r2=201616&view=diff
==============================================================================
--- llvm/trunk/docs/HowToSubmitABug.rst (original)
+++ llvm/trunk/docs/HowToSubmitABug.rst Tue Feb 18 17:56:43 2014
@@ -43,15 +43,15 @@ the LLVM libraries (e.g. the optimizer o
 problems.
 
 To figure out which component is crashing (the front-end, optimizer or code
-generator), run the ``llvm-gcc`` command line as you were when the crash
+generator), run the ``clang`` command line as you were when the crash
 occurred, but with the following extra command line options:
 
-* ``-O0 -emit-llvm``: If ``llvm-gcc`` still crashes when passed these
+* ``-O0 -emit-llvm``: If ``clang`` still crashes when passed these
   options (which disable the optimizer and code generator), then the crash
   is in the front-end.  Jump ahead to the section on :ref:`front-end bugs
   <front-end>`.
 
-* ``-emit-llvm``: If ``llvm-gcc`` crashes with this option (which disables
+* ``-emit-llvm``: If ``clang`` crashes with this option (which disables
   the code generator), you found an optimizer bug.  Jump ahead to
   `compile-time optimization bugs`_.
 
@@ -64,12 +64,12 @@ occurred, but with the following extra c
 Front-end bugs
 --------------
 
-If the problem is in the front-end, you should re-run the same ``llvm-gcc``
+If the problem is in the front-end, you should re-run the same ``clang``
 command that resulted in the crash, but add the ``-save-temps`` option.
 The compiler will crash again, but it will leave behind a ``foo.i`` file
 (containing preprocessed C source code) and possibly ``foo.s`` for each
 compiled ``foo.c`` file. Send us the ``foo.i`` file, along with the options
-you passed to ``llvm-gcc``, and a brief description of the error it caused.
+you passed to ``clang``, and a brief description of the error it caused.
 
 The `delta <http://delta.tigris.org/>`_ tool helps to reduce the
 preprocessed file down to the smallest amount of code that still replicates
@@ -92,7 +92,7 @@ Then run:
    opt -std-compile-opts -debug-pass=Arguments foo.bc -disable-output
 
 This command should do two things: it should print out a list of passes, and
-then it should crash in the same way as llvm-gcc.  If it doesn't crash, please
+then it should crash in the same way as clang.  If it doesn't crash, please
 follow the instructions for a `front-end bug`_.
 
 If this does crash, then you should be able to debug this with the following
@@ -111,9 +111,9 @@ submit the "foo.bc" file and the list of
 Code generator bugs
 -------------------
 
-If you find a bug that crashes llvm-gcc in the code generator, compile your
+If you find a bug that crashes clang in the code generator, compile your
 source file to a .bc file by passing "``-emit-llvm -c -o foo.bc``" to
-llvm-gcc (in addition to the options you already pass).  Once your have
+clang (in addition to the options you already pass).  Once your have
 foo.bc, one of the following commands should fail:
 
 #. ``llc foo.bc``
@@ -138,7 +138,7 @@ the "foo.bc" file and the option that ll
 Miscompilations
 ===============
 
-If llvm-gcc successfully produces an executable, but that executable
+If clang successfully produces an executable, but that executable
 doesn't run right, this is either a bug in the code or a bug in the
 compiler.  The first thing to check is to make sure it is not using
 undefined behavior (e.g. reading a variable before it is defined). In