run. This is useful if you are debugging programs which depend on non-LLVM
libraries (such as the X or curses libraries) to run.
+=item B<--append-exit-code>=I<{true,false}>
+
+Append the test programs exit code to the output file so that a change in exit
+code is considered a test failure. Defaults to false.
+
=item B<--args> I<program args>
Pass all arguments specified after -args to the test program whenever it runs.
options starting with C<-> to be part of the B<--tool-args> option, not as
options to B<bugpoint> itself. (See B<--args>, above.)
-=item B<--check-exit-code>=I<{true,false}>
+=item B<--safe-tool-args> I<tool args>
+
+Pass all arguments specified after B<--safe-tool-args> to the "safe" execution
+tool.
+
+=item B<--gcc-tool-args> I<gcc tool args>
+
+Pass all arguments specified after B<--gcc-tool-args> to the invocation of
+B<gcc>.
+
+=item B<--opt-args> I<opt args>
-Assume a non-zero exit code or core dump from the test program is a failure.
-Defaults to true.
+Pass all arguments specified after B<--opt-args> to the invocation of B<opt>.
=item B<--disable-{dce,simplifycfg}>
Continually randomize the specified passes and run them on the test program
until a bug is found or the user kills B<bugpoint>.
-=item B<--help>
+=item B<-help>
Print a summary of command line options.
Load the dynamic object F<plugin> into B<bugpoint> itself. This object should
register new optimization passes. Once loaded, the object will add new command
line options to enable various optimizations. To see the new complete list of
-optimizations, use the B<--help> and B<--load> options together; for example:
+optimizations, use the B<-help> and B<--load> options together; for example:
- bugpoint --load myNewPass.so --help
+ bugpoint --load myNewPass.so -help
=item B<--mlimit> F<megabytes>
Whenever the test program produces output on its standard output stream, it
should match the contents of F<filename> (the "reference output"). If you
do not use this option, B<bugpoint> will attempt to generate a reference output
-by compiling the program with the C backend and running it.
+by compiling the program with the "safe" backend and running it.
=item B<--profile-info-file> F<filename>
Profile file loaded by B<--profile-loader>.
-=item B<--run-{int,jit,llc,cbe}>
+=item B<--run-{int,jit,llc,cbe,custom}>
Whenever the test program is compiled, B<bugpoint> should generate code for it
using the specified code generator. These options allow you to choose the
-interpreter, the JIT compiler, the static native code compiler, or the C
-backend, respectively.
+interpreter, the JIT compiler, the static native code compiler, the C
+backend, or a custom command (see B<--exec-command>) respectively.
+
+=item B<--safe-{llc,cbe,custom}>
+
+When debugging a code generator, B<bugpoint> should use the specified code
+generator as the "safe" code generator. This is a known-good code generator
+used to generate the "reference output" if it has not been provided, and to
+compile portions of the program that as they are excluded from the testcase.
+These options allow you to choose the
+static native code compiler, the C backend, or a custom command,
+(see B<--exec-command>) respectively. The interpreter and the JIT backends
+cannot currently be used as the "safe" backends.
+
+=item B<--exec-command> I<command>
+
+This option defines the command to use with the B<--run-custom> and
+B<--safe-custom> options to execute the bitcode testcase. This can
+be useful for cross-compilation.
+
+=item B<--safe-path> I<path>
+
+This option defines the path to the command to execute with the
+B<--safe-{int,jit,llc,cbe,custom}>
+option.
=back
projects / oota-llvm.git / blobdiff