similar to: [LLVMdev] New C Frontend available

yue wrote: > hi, > about [LLVMdev] another question > > thanks > > yueqiang One other thing you might want to try is to put your object tree in a directory that is *not* inside of your source tree. Currently, we don't support using separate object trees that are subdirectories of the source tree. In other words: Will work: ========== SRC_ROOT=/home/yue/llvm

On Thu, 24 Jun 2004, Vladimir Merzliakov wrote: > At this moment I use > "gmake TEST=nightly" command line to run night tester > > What I must specific and where to disable SPEC run (i don't have it) I think that it's currently a bug that this does not automatically happen. > I known about new NightlyTest.pl option: -noexternals > But what I must do for

> On Thu, 24 Jun 2004, Vladimir Merzliakov wrote: > > > At this moment I use > > "gmake TEST=nightly" command line to run night tester > > > > What I must specific and where to disable SPEC run (i don't have it) > > I think that it's currently a bug that this does not automatically happen. > > > I known about new NightlyTest.pl option:

On Thu, 24 Jun 2004, Vladimir Merzliakov wrote: > > Are you using the NightlyTest.pl file? To run the tester I don't use > > gmake directly at all. Instead, I have this in my crontab: > > > > 5 3 * * * > LLVM_LIB_SEARCH_PATH=/home/vadve/lattner/local/x86/llvm-gcc/bytecode-libs > $HOME/llvm/utils/NightlyTest.pl -parallel -enable-linscan >

> Are you using the NightlyTest.pl file? To run the tester I don't use > gmake directly at all. Instead, I have this in my crontab: > > 5 3 * * * LLVM_LIB_SEARCH_PATH=/home/vadve/lattner/local/x86/llvm-gcc/bytecode-libs $HOME/llvm/utils/NightlyTest.pl -parallel -enable-linscan /home/vadve/shared/PublicCVS $HOME/buildtest-X86 $HOME/cvs/testresults-X86 > > When run like this,

Vladimir, Did the checkout fail? Its trying to do a chdir("llvm") in the build directory (second argument to the script) but that directory doesn't exist or isn't executable. Can you verify that you have an $HOME/pkg/build/llvm/night/build/llvm dir? Reid. On Thu, 2004-06-24 at 10:42, Vladimir Merzliakov wrote: > > Are you using the NightlyTest.pl file? To run the

On Nov 19, 2004, at 9:25 PM, Mohd-Hanafiah Abdullah wrote: > Dear Dr Vikram: > > I need to know how to invoke llvmg++ so that it generates C code. Here's how you can do a single file (i.e., an unlinked executable): llvmg++ -c infile.cpp -o - | llc -march=c -o infile.cbe.c Reid might be able to tell you how to do it with a single command using the llvmc tool. In future, please

This is a note to let everyone know that I just changed the LLVM build scripts to use the new C front-end for everything (on X86). If you are doing development on X86, you *must* make the following changes to your setup: 1. Change your llvm-gcc symlink (or alias, or whatever you use) to point to ~lattner/local/x86/llvm-gcc/bin/gcc 2. Add the following environment variable to your startup

Just like we did for X86: http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-May/000382.html We're now switching over to the new C frontend on solaris. If you are doing development on solaris, you *must* make the following changes to your setup: 1. Change your llvm-gcc symlink (or alias, or whatever you use) to point to ~lattner/local/sparc/llvm-gcc/bin/gcc 2. Add the following environment

As I have been threatening: (http://mail.cs.uiuc.edu/pipermail/llvmdev/2002-October/000141.html) to do (http://mail.cs.uiuc.edu/pipermail/llvmdev/2002-September/000092.html) for some time now, I have regenerated the X86 and Sparc C frontends. They are now in-sync again and both emit the 'external' keyword instead of 'uninitialized' as appropriate (plus other changes). If you are

gccld would barf if you tried to specify the full pathname of an archive on the command line to gcc, (e.g., instead of gcc ... -L/full/path/to -lFOO you say gcc ... /full/path/to/libFOO.a) which many GNU Makefiles try to do. This patch fixes that. Ok to commit? -- gaeke at uiuc.edu gccld.cpp: Fix typo in header. Add IsArchive static method. Roll LoadLibraryFromDirectory() into

Hi, I'm mainly insterested on the x86 JIT compiler. /lib/Target/X86/README.txt talks about 'Jello', the JIT compiler, which should be on /tools/jello. I think that changed to /tools/lli and now comprises a bytecode interpreter as well. Is that right? -- Oscar

Hi All, Do to popular request, I just set up a new mailing list to capture the nightly tester output from the various testers running 'round the world. The new list is available here: http://mail.cs.uiuc.edu/mailman/listinfo/llvm-testresults If you're running a nightly tester, please update your crontab to send mail to the llvm-testresults at cs.uiuc.edu list (potentially in addition

Hey all, In case anyone is interested in using the X86 JIT for stuff, here's a rundown on where it stands. The X86 JIT can currently be used like this: lli -force-interpreter=false foo.bc <args> Until the remaining issues, described below, are fixed, the -force-interpreter switch will default to true. Once things are finished, it will default to false, so lli will automatically

On Sun, 12 Dec 2004, Reid Spencer wrote: > Hello, > > I need to solicit your opinion about something. > > I'm toying with the idea of getting rid of LLVM_LIB_SEARCH_PATH. Right > now the linkers will use this environment variable if it specifies a > single directory. It will look in that directory to find libraries when > things like -lc or -lcrtend are specified on

Chris Lattner wrote: > On Sun, 12 Dec 2004, Reid Spencer wrote: > >> Hello, >> >> I need to solicit your opinion about something. >> >> I'm toying with the idea of getting rid of LLVM_LIB_SEARCH_PATH. Right >> now the linkers will use this environment variable if it specifies a >> single directory. It will look in that directory to find

Hello, I need to solicit your opinion about something. I'm toying with the idea of getting rid of LLVM_LIB_SEARCH_PATH. Right now the linkers will use this environment variable if it specifies a single directory. It will look in that directory to find libraries when things like -lc or -lcrtend are specified on the command line. Right now, the only known place this is useful to set to is the

> That's weird. What is your default shell that Perl invokes with the > "system" command. This works fine with bash-2.05b. In reality :) i use this script in crontab (and run it manually with added verbose flag): ---8X-------------- #!/bin/sh - # if !([ -d /home/wanderer/pkg/build/llvm/night/testresults-X86-FreeBSD ]) then mkdir

The LLVM 1.5 is out! Get it here: http://llvm.cs.uiuc.edu/releases/ or read about it here: http://llvm.cs.uiuc.edu/releases/1.5/docs/ReleaseNotes.html#whatsnew This release adds several new major features to the LLVM compiler, allows it to be used in domains where it couldn't before (e.g. for functional languages), supports new targets, generates faster code, and is much easier to port

Chris Lattner wrote: > On Tue, 1 Mar 2005, Jakob Praher wrote: > >> thanks for the pointer. Yes I've done that, but in the new shell >> session I apparently forgot to set the LLVM_LIB_SEARCH_PATH. >> >> now gccld isn't complaining anymore but the interpreter doesn't seem >> to like it still: > > > It looks like the jit doesn't find