similar to: [LLVMdev] UnitTests/2003-05-31-CastToBool.c

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

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

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 Thu, 2004-07-08 at 07:07, Vladimir Prus wrote: > 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

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'

Alkis Evlogimenos wrote: > > But the test still has a problem ;-) > > > > printf("%ld\n", Arg / (1LL << 4)); > > > > Again, the passed value is long long, and format specifier is '%ld'. What > > about the attached patch? > > I think testL has another problem. It takes a long argument which in C I > think is a 4-byte int,

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

Hi, I've sent one of these before, but i wasn't subscribed, and i'm unsure if it went out. I'm subscribed now and i've written another (i believe) nifty wrapper for oggz-tools. oggz-comments - allows a user to pass the plain text file with each tag on their own line theoracomment - works like 'vorbiscomment' from VorbisTools package, but sets comments for the

On May 24, 2008, at 11:43 AM, Marcel Moolenaar wrote: > All, > > So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD > and aside for ia64, things look pretty good for a first try. There > are 2 unexpected failures for PowerPC, which appear to be caused by > uninitialized memory. I'm still working on a fix for that (need to > brush up on my C++

All, So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD and aside for ia64, things look pretty good for a first try. There are 2 unexpected failures for PowerPC, which appear to be caused by uninitialized memory. I'm still working on a fix for that (need to brush up on my C++ skills). [sidenote: In FreeBSD -current, the memory allocator initializes memory with 0xa5

Reid Spencer wrote: > Volodya, > > I think you may need to update your CFE and rebuild. I compiled the test > using my local build and I didn't get the results you see below. I'm > also very surprised to see this output. The first %tmp.11 should have > been %tmp.1 .. not sure how it got corrupted. In any event, the > attachment is obviously generated by code that runs

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

Volodya, I think you may need to update your CFE and rebuild. I compiled the test using my local build and I didn't get the results you see below. I'm also very surprised to see this output. The first %tmp.11 should have been %tmp.1 .. not sure how it got corrupted. In any event, the attachment is obviously generated by code that runs quite differently because the virtual register names

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

Folks, With some MacOS help from Nate, I've begun the conversion of LLVM to use lib/System, the operating system independence layer. Currently, the library has implementations for three abstractions: Path, Program, and Signals. These provide some basic utilities for manipulating file system paths, finding and executing programs, and cleaning up after Signals. The implementations should work

Hi, Does anyone know of any projects that would allow you to use Redis in place of AstDB? By in place of I don't mean for what Asterisk needs but to store values. For instance for CNAM currently we need to use an AGI to connect to redis to pull CNAM. So in place of: Set(CALLERID(name)=${DB(CNAM/${CALLERID(num)})} it would be done with redis for example:

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, the insertBefore parameter, present in all constructors, is declared like this: Instruction *InsertBefore=0 any reason there's no "const" before "Instruction" ? - Volodya