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

[Sean Silva]

This was PR18871 btw.


On Tue, Feb 18, 2014 at 6:56 PM, Sean Silva <silvas at purdue.edu> wrote:

> 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
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140218/5e46323e/attachment.html>