There's a bug with ocamlc that uses "char*" instead of "const char*" for
global string variables. This causes g++ to be very noisy when linking
ocamlc programs. That's why the ocaml test used to cat to /dev/null.
ocamlopt doesn't have this problem, so we can get rid of the >/dev/null,
which may obscure some problems.
llvm-svn: 80968
Before there were two problems: (1) configure
turned "obj-c++" into "obj" in the langs line;
(2) the dejagnu library called it objc++ not
obj-c++.
Now the problem is that some of these tests don't
pass!
llvm-svn: 57167
tests. This breaks 80 tests in the tree.
The interesting part here is that this no longer ignores syntax errors
in RUN command lines. Some tests have not been working all the time because of
this.
The tricky part is that it now also views any stderr output as an error. This
can be suppressed in tcl 8.5, but let's not add this dependency. Instead, all
testcases should be changed to redirect stderr if they expect stderr output.
This holds in particular for lines like:
; RUN: not llvm-as < %s
where an error is expected (but I think I can solve this by modifying the not
script). Also, compilations resulting in warnings will now also fail (so
the warnings should be fixed, disabled or redirected...).
I'll continue with fixing the testcases that are broken now.
llvm-svn: 52172
(on solaris10, which are:
CodeGen/PowerPC/frounds.ll
Transforms/InstCombine/2008-02-23-MulSub.ll)
I needed a tool to figure out which one is the guilty.
To this end I have added a verbosity
option to the test/Makefile.
It can be invoked thus:
gmake check TESTSUITE=CodeGen/PowerPC VERBOSE="-v -v"
(The number of "-v"s specifies the verbosity level.
Instead of "-v" other aliases can be specified,
please consult the dejagnu docs for info.)
At level >= 2 following line is logged for each
test, before running it:
ABOUT TO RUN: <test>.ll
llvm-svn: 47602
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
