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
Tanya Lattner