similar to: [LLVMdev] More on backend testing

I've finally managed to bring my backend to a minimally working form. I can compile three small examples with arithmetic operations, branches and phi operations. However, there surely is a lot of omissions and bugs. How do I test a backend. For obvious reasons, I'd prefer a number of really small tests, to make debugging easier. I see some number of such small tests in

Vladimir Prus wrote: > Ok, I'm slowly making my backend understand stuff in > test/Programs/SingleSource/UnitTests. I can convert the first test to > assembler, compile it and run. > > The only thing I don't see if the expected outputs from the tests -- so that I > don't need to look at each test and figure out what it should output. Is it > true such

Vladimir, The makefile for the feature tests is in the directory above. Simply: cd ~/llvm/test make Feature.t This works for the regression tests to: make Regression.t The tests are run QMTest which just "knows" what to do with the test file. In many cases there is a RUN: line which instructs the test harness how to run the test. On Wed, 2004-06-09 at 05:18, Vladimir Prus wrote:

hi, when i change the OBJ_ROOT and recompile the llvm, it's successful. but run following test, then the error occues: ----------------------------------------------------- [yue at RH9 obj]$ make -C ./test/Programs make: Entering directory `/home/yue/llvm/obj/test/Programs' make[1]: Entering directory `/home/yue/llvm/obj/test/Programs/SingleSource' make[2]: Entering directory

Reid Spencer wrote: > Vladimir, > > The makefile for the feature tests is in the directory above. Simply: > > cd ~/llvm/test > make Feature.t > > This works for the regression tests to: > > make Regression.t > > The tests are run QMTest which just "knows" what to do with the test > file. In many cases there is a RUN: line which instructs the

hi, when I run "make -C ./llvm/test/Programs", it show following error: ------------------------------------------------------------------------------------------- [root at RH9 llvm]# make -C ./llvm/test/Programs make: Entering directory `/usr/local/llvm/llvm/test/Programs' make[1]: Entering directory `/usr/local/llvm/llvm/test/Programs/SingleSource' make[2]: Entering directory

I think test/Programs/SingleSource/UnitTests/2003-05-31-CastToBool.c has a problem. Consider: void testLong(long long X) { printf("%ld ", X); testBool(X != 0); } This passes 'long long' value to 'ld' format specifier -- but for that specifier the parameter should be 'long'. So, the behaviour of the above is undefined and in fact it

Hello, when I'm compiling test/Programs/SingleSource/UnitTests/2003-05-26-Shorts.c I get LLVM assembler which looks like: int %main(int %argc, sbyte** %argv) { entry: call void %__main( ) %tmp.11 = call ulong %getL( ) ; <ulong> [#uses=16] %tmp.3 = cast ulong %tmp.11 to long ; <long> [#uses= %tmp.5 = cast ulong %tmp.11 to

Volodya, This program is in error. Either the format specifier needs to be %lld or the argument value X needs to be casted to type long. This will compile fine but it probably won't work at runtime because printf is expecting a long, not a long long. I think your backend producing "wrong results" is actually correct :) Most modern C/C++ compilers will detect this for you at

The above-mentioned test contains this: long B53 = - (1LL << 53); strictly speaking, this is not correct code. The C standard says about shift: "if the value of the first operator is ... or greater than ... the width of the promoted left operand, the behaviour is underfined". Thouhts? - Volodya

Vladimir Prus wrote: > Vladimir Prus wrote: > > The above-mentioned test contains this: > > > > long B53 = - (1LL << 53); > > > > strictly speaking, this is not correct code. The C standard says about > > shift: "if the value of the first operator is ... or greater than ... the > > width of the promoted left operand, the behaviour is

On Wednesday 20 October 2004 12:01, Reid Spencer wrote: > I'm re-thinking my penchant for automake. automake is great for many > standard applications that just need to get portable makefiles up and > running quickly. However, it turns out that LLVM is "different enough" > from a standard application that automake might not be the best choice. I might just here to

Vladimir Prus wrote: > The above-mentioned test contains this: > > long B53 = - (1LL << 53); > > strictly speaking, this is not correct code. The C standard says about > shift: "if the value of the first operator is ... or greater than ... the > width of the promoted left operand, the behaviour is underfined". Forget this, I've missed the 'LL'

The SingleSource/Regression/C/callargs.c test uses the %lf format specifier for printf. However, "man printf" does not specify what this means. Shouldn't the following patch be applied? - Volodya -------------- next part -------------- A non-text attachment was scrubbed... Name: callargs.diff Type: text/x-diff Size: 1463 bytes Desc: not available URL:

On Mon, Feb 23, 2009 at 6:32 PM, John Criswell <criswell at cs.uiuc.edu> wrote: > Aaron Gray wrote: > > I am trying to build llvm-test in a separate directory to the main llvm > tree. > > > > I have put llvm and llvm-gcc's bin directories on the path but think I am > missing a switch on the configure command. > > > You need to use --with-llvmsrc and

Hello, I've just tries make && make install on a fresh CVS tree, and get: llvm[0]: Installing include files /bin/sh: line 1: pax: command not found Two questions. 1. Why install process requires some nonstandard tool? Is it possible to get away without it. 2. autoconf/configure.ac has this: AC_PATH_PROG(PAX, [pax], [pax]) but Makefile.rules uses plain 'pax',

Reid Spencer wrote: > This program is in error. Either the format specifier needs to be %lld > or the argument value X needs to be casted to type long. This will > compile fine but it probably won't work at runtime because printf is > expecting a long, not a long long. I think your backend producing "wrong > results" is actually correct :) Yea, that's what

On Thursday 21 October 2004 01:54, Vladimir Prus wrote: > On Wednesday 20 October 2004 12:01, Reid Spencer wrote: > > I'm re-thinking my penchant for automake. automake is great for many > > standard applications that just need to get portable makefiles up and > > running quickly. However, it turns out that LLVM is "different enough" > > from a standard

Dear LLVM Developers, The LLVM website, CVS repository, and SAFECode website should now be back online. Should you encounter any problems with the LLVM services, please send email to llvmdev at cs.uiuc.edu so that we may fix it. Regards, John T. Criswell ********************************************************************* * John T. Criswell Email: criswell at uiuc.edu

Dear Devang Patel, In response to your comment on bug 1868, how do I get BottomPass to requires Pass2 before Pass1? Is it by reversing the order of the calls to AU.addRequired()? -- John T. -- John T. Criswell jcriswel at bigw.org "It's today!" said Piglet. "My favorite day," said Pooh.