search for: ejones

I am currently trying to build the CVS version of LLVM, and no matter what I do, ./configure always reports that llvm-gcc cannot be found or is not working. I currently have the LLVM 1.4 llvm-gcc binaries. My path is set correctly: rn-spra1c07:~/llvm/llvm ejones$ which llvm-gcc /Users/ejones/llvm/cfrontend/ppc/llvm-gcc/bin/llvm-gcc rn-spra1c07:~/llvm/llvm ejones$ which llvm-g++ /Users/ejones/llvm/cfrontend/ppc/llvm-gcc/bin/llvm-g++ So LLVM is on my path, and I ran configure with: ./configure --with-llvmgccdir=/Users/ejones/llvm/cfrontend/ppc/llvm-gcc/b...

...ures are those? Are they dated tests for the C/C++ > front-end whose date is later than the CFE build you are using? Ah ha! Of course. That makes perfect sense. 12 of the failures are in "CFrontend" and are dated 2005-01-02 through 2005-03-11. The remaining three are: FAIL: /home/ejones/llvm/llvm/test/Regression/Archive/ranlib_GNU.ll: FAIL: /home/ejones/llvm/llvm/test/Regression/Archive/ranlib_SVR4.ll: FAIL: /home/ejones/llvm/llvm/test/Regression/Archive/ranlib_xpg4.ll: Which I am guessing are also related, since the linker I am using is also old. Thanks, Evan Jones

...EquivalenceClasses.h" needs to include <stdint.h> in order to get the typedef for "intptr_t." If anyone wants me to make a patch for this, let me know. The build error that this solves is: llvm[3]: Compiling DataStructure.cpp for Debug build In file included from /home/ejones/llvm/llvm3/include/llvm/Analysis/DataStructure/DSGraph.h: 20, from /home/ejones/llvm/llvm3/include/llvm/Analysis/DataStructure/ DSGraphTraits.h:19, from DataStructure.cpp:14: /home/ejones/llvm/llvm3/include/llvm/ADT/EquivalenceClasses.h: In constructor...

...es wrote: > I am currently trying to build the CVS version of LLVM, and no matter > what I do, ./configure always reports that llvm-gcc cannot be found or > is not working. I currently have the LLVM 1.4 llvm-gcc binaries. My > path is set correctly: > > rn-spra1c07:~/llvm/llvm ejones$ which llvm-gcc > /Users/ejones/llvm/cfrontend/ppc/llvm-gcc/bin/llvm-gcc > rn-spra1c07:~/llvm/llvm ejones$ which llvm-g++ > /Users/ejones/llvm/cfrontend/ppc/llvm-gcc/bin/llvm-g++ > > > So LLVM is on my path, and I ran configure with: > > ./configure > --with-llvmgccdi...

On Feb 19, 2005, at 20:26, Reid Spencer wrote: > You need to tell configure where the install directory for all of > llvm-gcc is located. Ah ha. That was my problem. I forgot that I ran into this with LLVM 1.4 as well. Basically, I specified: --with-llvmgccdir=/Users/ejones/llvm/cfrontend/ppc/llvm-gcc/bin instead of: --with-llvmgccdir=/Users/ejones/llvm/cfrontend/ppc/llvm-gcc Which does make sense now. For me, the issue was that the directions (http://llvm.cs.uiuc.edu/docs/GettingStarted.html) were slightly misleading. They say: > ◦ --with-llvmgccdir=direct...

Maybe I'm screwing something up, but with the current CVS build on x86 Linux, I get the following output when I execute "make" in the test directory: === Summary === # of expected passes 978 # of unexpected failures 15 # of expected failures 32 Are these 15 failures known failures, or am I doing something wrong? I have a clean CVS

On Wed, 16 Mar 2005, Evan Jones wrote: > Maybe I'm screwing something up, but with the current CVS build on x86 Linux, > I get the following output when I execute "make" in the test directory: > > === Summary === > > # of expected passes 978 > # of unexpected failures 15 > # of expected failures 32 > > >

...ase. The program mmaps a file called 'data,' prints the last byte, truncates the file, then tries to read the last byte again. It causes a Bus Error on both the RedHat system and my Mac OS X workstation. Hence, this appears to be valid (or at least common) mmap behaviour. rn-spra1c07:~ ejones$ dd if=/dev/zero of=data bs=1 count=4096 4096+0 records in 4096+0 records out 4096 bytes transferred in 0.067263 secs (60895 bytes/sec) rn-spra1c07:~ ejones$ ./mmaptest last byte = 0x00 Bus error I can also reproduce it with a minimal LLVM example, also attached. That program needs the "GNU....

...behavior for mmap in such a situation. The mapped file, when it is truncated, invalidates the memory corresponding to truncated portion of the file. The memory is taken out of the virtual memory table so that any attempt to access generates a, you guessed it, bus error. > > rn-spra1c07:~ ejones$ dd if=/dev/zero of=data bs=1 count=4096 > 4096+0 records in > 4096+0 records out > 4096 bytes transferred in 0.067263 secs (60895 bytes/sec) > rn-spra1c07:~ ejones$ ./mmaptest > last byte = 0x00 > Bus error > > I can also reproduce it with a minimal LLVM example, also atta...

Evan, Your patch uses an operating system call that is not portable. All non-portable code needs to be located in the lib/System library. I'm not sure why this problem appears on an old Red Hat system. Perhaps the C++ io library is not up to snuff on that platform? What compiler are you using? Reid. Evan Jones wrote: > I ran the LLVM regression tests today (via make check) and

...cute simple C programs compiled with llvm-gcc. I couldn't see anything that looked like a bug report for this issue in Bugzilla. I can't quite figure out this bug. The backtrace looks like: #0 0x900429ac in kill () #1 0x9009eb1c in abort () #2 0x00120ec8 in __eprintf () at /Users/ejones/llvm/llvm/include/llvm/ADT/ilist:440 #3 0x00011ae8 in llvm::JIT::runJITOnFunction(llvm::Function*) (this=0x51015c0, F=0x5101010) at JIT.cpp:217 #4 0x00011da4 in llvm::JIT::getPointerToFunction(llvm::Function*) (this=0x51015c0, F=0x5101010) at JIT.cpp:261 #5 0x000123e4 in (anonymous namespa...

I ran the LLVM regression tests today (via make check) and noticed that llvm-ranlib crashes with a Bus Error on my test system (a fairly old RedHat 9 system), using the latest CVS version. I did some digging and I think I know what the problem is, and I have attached a quick and dirty patch that fixes the problem for me, but I need a suggestion about how it should be integrated properly. Here

On Thu, 2005-21-04 at 09:31 -0400, Vyacheslav Akhmechet wrote: > At this point I cannot know the type of 'i' at compile time. At > runtime 'i' is a structure that contains a type and a function > pointer. What I can't figure out is how to cast my llvm function > pointer to an appropriate function type. I cannot know until runtime > what the type will be.

I recently ran into the following problem. I'm prototyping a compiler for a dynamically typed language in which functions are first class objects. Assuming I have something like this: if(rand() > 5) i = define(x, y, z) { return x + y + z; } else i = define(x, y) { return x + y; } At this point I cannot know the type of 'i' at compile time. At runtime 'i' is a

...The problem is that I do not know the type of a target function at compile time. If you consider my code example, I don't know the type of 'i' until runtime (in fact, I can't even know a possible range of types 'i' may assume). Thanks, - Slava. On 4/21/05, Evan Jones <ejones at uwaterloo.ca> wrote: > On Thu, 2005-21-04 at 09:31 -0400, Vyacheslav Akhmechet wrote: > > At this point I cannot know the type of 'i' at compile time. At > > runtime 'i' is a structure that contains a type and a function > > pointer. What I can't figur...

Hello, I have been thinking about efficient implementation of dynamically typed languages in my spare time. Specifically, I'm working on a toy implementation of a tiny piece of Python using LLVM as a native code generating JIT. I've run into a bit of an issue, involving how Python deals with method calls. I'm not sure how/if I can implement this in LLVM. In Python, the following

On Feb 8, 2005, at 23:52, Chris Lattner wrote: > That would be great. As a first implementation, I would suggest > adding a lock to the ExecutionEngine class in > include/llvm/ExecutionEngine/ExecutionEngine.h, locking it when > particular state is accessed. Note that the JIT subclasses this in > lib/ExecutionEngine/JIT/JIT.h, so its accesses should be synchronized > as

This is what I was trying to do when I ran into the HowToUseJIT problem. I've made a first attempt at adding locking to the JIT. Unfortunately, since I do not really understand the structure of LLVM, I could have very easily screwed something up. I touched two classes, the JIT and the ExecutionEngine. I need some help from someone who is more familiar with the code to make sure that I

On Feb 28, 2005, at 19:16, Curt Cox wrote: > I'm interested in using LLVM to run source languages supported by GCC > (mostly just C and Fortran, actually) on a JVM. There seem to be two > general ways this could be accomplished. Here is a better way to do this. At least, I think it is better, mostly because someone else has already done all the work: http://www.xwt.org/mips2java/

On Apr 20, 2005, at 0:01, Misha Brukman wrote: > Sure. Patches are accepted, but please separate formatting changes > from > functionality changes into different patches. Speaking of random formatting changes, I've noticed in a few pages that the doxygen documentation comments incorrectly only have two '//' characters on the line. Hence, no doxygen documentation gets