[OCaml] Add -g on DEBUG_SYMBOLS=1, not ENABLE_OPTIMIZED.

[oota-llvm.git] / docs / HowToSubmitABug.rst

diff --git a/docs/HowToSubmitABug.rst b/docs/HowToSubmitABug.rst
index ff2d649ce33c8c2dbb45ba1100566e0e4e1cfdd2..9f997d2757dd967854599329ca30c73935f62c7b 100644 (file)
--- a/docs/HowToSubmitABug.rst
+++ b/docs/HowToSubmitABug.rst
@@ -1,11 +1,7 @@
-.. _how-to-submit-a-bug-report:
-
 ================================
 How to submit an LLVM bug report
 ================================
 
-.. sectionauthor:: Chris Lattner <sabre@nondot.org> and Misha Brukman <http://misha.brukman.net>
-
 Introduction - Got bugs?
 ========================
 
@@ -47,15 +43,15 @@ the LLVM libraries (e.g. the optimizer or code generator) that has
 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`_.
 
@@ -68,12 +64,12 @@ occurred, but with the following extra command line options:
 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
@@ -93,10 +89,10 @@ Then run:
 
 .. code-block:: bash
 
-   opt -std-compile-opts -debug-pass=Arguments foo.bc -disable-output
+   opt -O3 -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
@@ -115,9 +111,9 @@ submit the "foo.bc" file and the list of passes printed by ``opt``.
 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``
@@ -142,7 +138,7 @@ the "foo.bc" file and the option that llc crashes with.
 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