-<p>A miscompilation occurs when a pass does not correctly transform a program,
-thus producing errors that are only noticed during execution. This is different
-from producing invalid LLVM code (i.e., code not in SSA form, using values
-before defining them, etc.) which the verifier will check for after a pass
-finishes its run.</p>
-
-<p>To debug a miscompilation, you should choose which program you wish to run
-the output through, e.g. C backend, the JIT, or LLC, and a selection of passes,
-one of which may be causing the error, and run, for example:</p>
-
-<pre>
- <b>bugpoint</b> -run-cbe [... optimization passes ...] file-to-test.bc
-</pre>
+<p>If llvm-gcc 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 particular, check
+to see if the program <a href="http://valgrind.org/">valgrind</a>s clean,
+passes purify, or some other memory checker tool. Many of the "LLVM bugs" that
+we have chased down ended up being bugs in the program being compiled, not
+ LLVM.</p>
+
+<p>Once you determine that the program itself is not buggy, you should choose
+which code generator you wish to compile the program with (e.g. C backend, the
+JIT, or LLC) and optionally a series of LLVM passes to run. For example:</p>
+
+<div class="doc_code">
+<p><tt>
+<b>bugpoint</b> -run-cbe [... optzn passes ...] file-to-test.bc --args -- [program arguments]</tt></p>
+</div>