similar to: [LLVMdev] %lf specifier

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

At the LLVM Developers' Meeting in November, I promised to work on isolating a subset of the current test suite that is useful for benchmarking. Having looked at this in more detail, most of the applications and benchmarks in the test suite are useful for benchmarking, and so I think that a better way of phrasing it is that we should construct a list of programs in the test suite that are not

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 expected outputs are not available? I not, I'll probably do

Hi, I'm trying to replace function call with call to wrapper(function_name, num_args, ...), where varargs hold args of original call. Function* launch = Function::Create( TypeBuilder<int(const char*, int, ...), false>::get(context), GlobalValue::ExternalLinkage, "kernelgen_launch_", m2); { CallInst* call = dyn_cast<CallInst>(cast<Value>(I)); if

Hi Dimitry, This makes sense if you think about it from the perspective that the string you want passing must be passed at runtime, and so can't use a const char * from compile time. You need to make the string visible in the compiled image, and use that as the argument. A string is an array of 8-bit integers, so you need to create a ConstantArray. Value *v = ConstantArray::get(Context,

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

Hello; I was able to build and install llvm(3.0) under Ubuntu 11.10 (using the ./configure script found under llvm source, and then make and make install). While configuring, I gave --prefix as a directory where I would like llvm to be installed. I did not give --with-llvmgccdir and the --enable-optimized argument to configure. Because 3.0 doesn't come with llvmgcc source/binaries and I

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

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

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:

G'Day Tanya, Is it too late to bring in the following patches to fix some major brokenness in the AuroraUX tool chain for 2.6? http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?r1=84468&r2=84469&view=diff&pathrev=84469 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?r1=84265&r2=84266&view=diff&pathrev=84266

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

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

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: > 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'

Hi! When I go to http://llvm.cs.uiuc.edu/doxygen/annotated.html and click on link for, say, "llvm::Module", I've told that the target page does not exist. Same happens for llvm::Value, and in fact everything under "llvm" namespace. Any idea what's wrong? - Volodya

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',

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

I've another problem. There's one register, gr6, which is used to return high part of return value for functions returning 64-bit values. For such functions, the register should not be saved, naturally. But when function does not return 64-bit value, then the register must be saved. How can I express this in .td file? - Volodya

Hello, after some time I'm trying to build my code with the current CVS of LLVM, and have a problem. The mentioned file, around line 184, contains: if (FixedSlot == FixedSpillSlots+NumFixedSpillSlots) { // Nope, just spill it anywhere convenient. FrameIdx = FFI->CreateStackObject(RegInfo->getSpillSize(Reg)/8,