similar to: [LLVMdev] top of tree broken?

See attached build (gmake -k) log. -- gaeke at uiuc.edu -------------- next part -------------- gmake[1]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/utils/Burg' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/scratch/scratch0/gaeke/llvm-497cz/utils/Burg' gmake[1]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/lib' gmake[2]: Entering

Hello, In preparation for the LLVM public release, I've moved the reoptimizer out of the main cvs module "llvm" and into the cvs module "reopt". You can go ahead and delete the lib/Reoptimizer directory from your tree, about which cvs will undoubtedly be complaining to you. If you want to build the reoptimizer, cd into your SPARC tree's "projects"

Brian Gaeke wrote: > > A typo in test/Makefile was the trigger for this problem: > > http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041101/ > 020216.html > > John, can you please look into this bug some more and add some error > checking to the llvm-specific qmtest python modules to make this error > less severe? Does the fork bomb occur in the

On Sat, 21 Aug 2004 18:36:08 -0500 Misha Brukman <brukman at uiuc.edu> wrote: > On Sat, Aug 21, 2004 at 04:15:49PM -0700, Jeff Cohen wrote: > > I don't know if it's under cvs. It's the "getting started" page > > (http://llvm.cs.uiuc.edu/docs/GettingStarted.html) in section > > "Getting Started Quickly (A Summary)". But careful reading

On Sat, Aug 21, 2004 at 04:15:49PM -0700, Jeff Cohen wrote: > I don't know if it's under cvs. It's the "getting started" page > (http://llvm.cs.uiuc.edu/docs/GettingStarted.html) in section "Getting > Started Quickly (A Summary)". But careful reading of the remainder of > the page does give the correct path. http://llvm.cs.uiuc.edu/docs/* is a copy of

Hi Jeff, On Fri, 2004-08-20 at 08:07, Jeff Cohen wrote: > OK. I've built the front end without any heartaches, but I did > encountered the following glitches: > > The documentation of --with-llvmgccdir is a bit ambiguous. I had to try > several paths before I got the right one. It should state that the > directory is <path>/cfrontend/<platform>/llvm-gcc.

A typo in test/Makefile was the trigger for this problem: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041101/ 020216.html John, can you please look into this bug some more and add some error checking to the llvm-specific qmtest python modules to make this error less severe? Thanks! -Brian On Nov 3, 2004, at 10:35 AM, Brian Gaeke wrote: > > I think there is a very

Hi Brian Here's the config.log (I'm not posting it on the dev-list). The automatic gcc macro for Interix is __INTERIX if this is to any help. /Henrik >From: "Brian R. Gaeke" <gaeke at uiuc.edu> >Reply-To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >Subject: Re: [LLVMdev]

> Ok that works but why on earth would I get a runtime error of: > > Type.cpp:132: const llvm::Type* llvm::Type::getForwardedTypeInternal() > const: Assertion `ForwardType && "This type is not being forwarded to > another type!"' failed. > Aborted > > For the line of code: > > MyModule = new Module( std::string("IDontWork")); I was

On Fri, 20 Aug 2004 08:52:28 -0700 Reid Spencer <reid at x10sys.com> wrote: > Hi Jeff, > > On Fri, 2004-08-20 at 08:07, Jeff Cohen wrote: > > OK. I've built the front end without any heartaches, but I did > > encountered the following glitches: > > > > The documentation of --with-llvmgccdir is a bit ambiguous. I had to > > try several paths

ISSUE: The constant "3791650815" is too large to fit in a 32-bit signed integer. ACTION: Use the unsigned 32-bit integer constant "3791650815U" instead. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL:

I have checked in 3 new analyses: 1. IPModRef (analyze -ipmodref): This is a Module pass that computes flow-insensitive context-sensitive interprocedural Mod/Ref information for a program. It uses DS Graphs to track mod/ref info for distinct data structures. 2. MemoryDepAnalysis (analyze -memdep): This is a Module pass (but will eventually be a Function pass) that computes a

I want to use PgmDependenceGraph pass , but my pass cannot work with PgmDependenceGraph. I tried again in Hello2 pass, and it could not work also. The following is I did with llvm/lib/Transforms/Hello.cpp: 1.insert #include "llvm/Analysis/PgmDependenceGraph.h" in Hello.cpp. 2.insert AU.addRequired<PgmDependenceGraph>() in the getAnalysisUsage(AnalysisUsage &AU) of Hello2.

Hello everybody, I would like to know more about runtime & idle time reoptimizer mentioned in the powerpoint presentations about LLVM. Which tool in the LLVM toolchain is responsible for this? Where I can find more details on how reoptimizer is implemented? If someone can let me know any doc or specific source code file to look at, it would be helpful. I have also seen a similar post by

Whoops, I forgot to cc the list. Sorry. ----- Forwarded message from "Brian R. Gaeke" <gaeke at uiuc.edu> ----- Date: Thu, 13 Nov 2003 15:35:34 -0600 From: "Brian R. Gaeke" <gaeke at uiuc.edu> To: Reid Spencer <reid at x10sys.com> Subject: Re: [LLVMdev] Headers & Libraries Hi Reid, Sorry I can't go into as much detail as your question did right

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

I think there is a very similar situation with the PowerPC/Mac OS X nightly tests. Over each of the past few nights, something has been filling up the process table, causing me to be unable to log in. The nightly tester wrote out regression test and feature test logs featuring hundreds of "Resource temporarily unavailable" errors from fork(), so I assume it's the qmtest

On Thu, 19 Aug 2004 08:45:23 -0700 Reid Spencer <reid at x10sys.com> wrote: > > Also, as a general note, make sure you follow precisely the steps for > building the c front end. If you discover any BSDisms that aren't > documented, we'd love to hear about them. > > Thanks, > > Reid. > OK. I've built the front end without any heartaches, but I did

Hi, Thanks for the replies in the mailing list. I made some progress in building LLVM, but I still have a problem about ELF class. I am working with LLVM on a sparcv9 machine, while the gcc is configured to emit 32-bit binary by default. After executing "configure --with-llvmgccdir=... --enable-jit", I modified Makefile.config so it contains CXX = g++ -mcpu=v9 -m64 CC := gcc -mcpu=v9

> I'm trying to get the demo script to run llvm2cpp so that people can get > familiar with the LLVM C++ API through the online demo. However, it > seems that the path used doesn't include llvm2cpp (not updated in a > while?). The demo script currently uses these paths on Zion: I can look into this, but I would strongly suggest not messing with the demo script until 2-3