From f7f33ced956cf048e3984f550f422d8a7532a1f8 Mon Sep 17 00:00:00 2001 From: Sean Silva Date: Tue, 18 Feb 2014 23:56:43 +0000 Subject: [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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201616 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/HowToSubmitABug.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) (limited to 'docs/HowToSubmitABug.rst') diff --git a/docs/HowToSubmitABug.rst b/docs/HowToSubmitABug.rst index 45be2826b3..702dc0c611 100644 --- a/docs/HowToSubmitABug.rst +++ b/docs/HowToSubmitABug.rst @@ -43,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 `. -* ``-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 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 `_ 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 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`` @@ -138,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 -- cgit v1.2.3