built atop the C language bindings, and user programs can link with them as
such:
# Bytecode
ocamlc -cc g++ llvm.cma llvmbitwriter.cma -o example example.ml
# Native
ocamlopt -cc g++ llvm.cmxa llvmbitwriter.cmxa -o example.opt example.ml
The vmcore.ml test exercises most/all of the APIs thus far bound. Unfortunately,
they're not yet numerous enough to write hello world. But:
$ cat example.ml
(* example.ml *)
open Llvm
open Llvm_bitwriter
let _ =
let filename = Sys.argv.(1) in
let m = create_module filename in
let v = make_int_constant i32_type 42 false in
let g = define_global "hello_world" v m in
if not (write_bitcode_file m filename) then exit 1;
dispose_module m;
$ ocamlc -cc g++ llvm.cma llvm_bitwriter.cma -o example example.ml
File "example.ml", line 11, characters 6-7:
Warning Y: unused variable g.
$ ./example example.bc
$ llvm-dis < example.bc
; ModuleID = '<stdin>'
@hello_world = global i32 42 ; <i32*> [#uses=0]
The ocaml test cases provide effective tests for the C interfaces.
llvm-svn: 42093
that cannot be suppressed and cannot be redirected:
they are dumped in the current working directory.
When running the testsuite this means that these
files do not end up in the Output directory. The
best solution I could find is to change directory
into Output before running tests.
llvm-svn: 40437
llvm_gcc_supports function that takes the language as an argument. Base that
function on the new LLVMGCC_LANGS configured variable so that we don't have
to execute feature checks during the test run.
llvm-svn: 36322
1. Don't bother truncating reading of the file. It doesn't save that much
time and we should support putting RUN lines anywhere in the file. For
example, someone might want to put the grep match before each function
in the test file which would sprinkle the RUN: lines throughout the file.
2. Fix a bug with llvmgcc version match .. global var wasn't declared as such
llvm-svn: 36085
1. Only read the first 1024 bytes of the file. The RUN: lines should all be
within that amount of space. This keeps I/O costs down when reading
very large files.
2. Print PR numbers with a PR prefix so it is clear what they are.
llvm-svn: 36071
More improvements:
1. Using ::errorInfo wasn't such a hot idea. Go back to just printing the
offending line of code and the stderr output. This is sufficient and
not entangled with Tcl goop.
2. Capture the problem report numbers and report them whether pass or fail.
This helps quickly get some context when a test fails, if it has an
associated PR number.
llvm-svn: 36010
that want to use LLVM's notion of compiling and linking programs. This
includes all the -I -L and optimization switches that LLVM would using to
compile or link any of this files.
llvm-svn: 35920
global variables that needed to be passed in. This makes it possible to
add new global variables with only a couple changes (Makefile and llvm-dg.exp)
instead of touching every single dg.exp file.
llvm-svn: 35918
1. Make sure bytecode/assembly inputs are always redirected stdin so that
the module name is <stdin>. This helps not get false negatives when the
diff is done.
2. Scan the test file to determine if llvm-upgrade needs to be run.
3. Avoid running testings that are XFAIL'd because they'll cause a failure
when run for llvm2cpp.
4. Get some better error message output.
llvm-svn: 35914
is the default and handled by the makefile system and runtest
2. Redirect stderr of llvm-as and llvm2cpp so that warning messages about
instrinsics don't cause Tcl to report the run as failed.
llvm-svn: 28576
committed). This infrastructure is only activated when RUNLLVM2CPP=1 is
specified on the make command line. Currently it is only supported in the
Feature test suite.
llvm-svn: 28525
capture the error output from the exec option. This generally will capture
the stderr messages generated by the tools. This information is then
printed if the test fails. This helps to recognize more quickly what the
error was. Otherwise, this information is lost.
llvm-svn: 28385
Tanya Lattner