similar to: [LLVMdev] IMPORTANT: Switch-over to new C front-end on X86

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

The following should work: % cd llvm/test/Programs/MultiSource % gmake DISABLE_CBE=1 DISABLE_LLC=1 --Vikram http://www.cs.uiuc.edu/~vadve > -----Original Message----- > From: llvmdev-admin at cs.uiuc.edu > [mailto:llvmdev-admin at cs.uiuc.edu] On Behalf Of Juan Nicolas Ruiz > Sent: Sunday, December 08, 2002 2:20 PM > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] Olden BM

A new and improved C frontend is now available for experimentation. This is a C frontend that is based on the GCC AST representation as opposed to the old frontend which came from the RTL representation (which lost a lot of type information and caused other problems). I am still working on the new front-end, but it is remarkably stable for being so new. If you are interested in playing with it,

Here are a few bits of news about the C frontend: 1. I have ported it to compile and run under linux. On our research machines, it is available here: /home/vadve/lattner/cvs/gcc_install_x86 Note that this C compiler will still generate "64-bit" LLVM files, thus the code will probably not work right if run through the C backend, then compiled on x86. For middle-end

On Tue, May 5, 2009 at 12:26 PM, Duncan Sands <baldrick at free.fr> wrote: > this is indeed a miscompilation by your system compiler.  However so many > compilers miscompiled this that a workaround was committed to svn.  So you > may want to check out llvm and llvm-gcc from svn.  Alternatively, maybe > the patch applies to llvm 2.5 too.  I've attached it. I will try the

Hi Scott, > On Tue, May 5, 2009 at 12:26 PM, Duncan Sands <baldrick at free.fr> wrote: > > this is indeed a miscompilation by your system compiler. However so many > > compilers miscompiled this that a workaround was committed to svn. So you > > may want to check out llvm and llvm-gcc from svn. Alternatively, maybe > > the patch applies to llvm 2.5 too.

Hi, > cc1: /pkg/build/llvm/llvm-2.5/include/llvm/Transforms/Utils/InlineCost.h:44: > llvm::InlineCost::InlineCost(int, int): Assertion `Cost == C && "Cost > exceeds InlineCost precision"' failed. > ../../llvm-gcc4.2-2.5.source/gcc/libgcov.c:644: internal compiler error: Aborted this is indeed a miscompilation by your system compiler. However so many compilers

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

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:

On Sun, 4 Sep 2005, Tanu Sharma wrote: > > I have a doubt. > > This is an excerpt of the raw report I get after running Spec benchmarks > through llvm-test.I am trying to calculate the program execution > time.Does the output result in bold corresponds to "lli time" in > Makefile.spec ? I am not interested in llc, jit or cbe.I simply need the > normal

On Tue, May 5, 2009 at 11:33 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Scott, > >> On Tue, May 5, 2009 at 12:26 PM, Duncan Sands <baldrick at free.fr> wrote: >> > this is indeed a miscompilation by your system compiler.  However so many >> > compilers miscompiled this that a workaround was committed to svn.  So you >> > may want to check

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

This nightly tester is now using an llvm-g++ that produces the new ODR linkage types. This means that many more functions are being considered by the inter-procedural optimization passes (for example, "linkonce" functions defined in a header). The result seems to be pretty huge swings (both good and bad) in the C++ tests in the testsuite, see below. Note that this tester is often

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

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 >

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

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

On Tue, Aug 25, 2009 at 3:01 PM, Vikram S. Adve<vadve at cs.uiuc.edu> wrote: > For my introductory Compiler Construction class, I have been giving > the students a project to write a simple compiler for a toy, single- > inheritance object-oriented language.  We give them a set of classes > implementing an AST for the language and a type checker as well.  The > students write

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