similar to: [LLVMdev] Problems Cross Compiling for x86 and ia64

OK, I noticed a few problems with my previous email, so I will boil the question down: What I want to do is compile for x86 and ia64 from darwin. I also want to load my own passes into opt and llc. Should I be using llvmc at all here, or should I be doing something like llvmgcc -> gccas -> opt -> llc ? I've given up on the filetype=obj argument, so now the problem is that llc is

I'm having troubles running the test suite on OS X 10.4. Inside my objdir, 'make check' gives this: % make check llvm[0]: Running test suite

On Tue, 21 Mar 2006, Michael McCracken wrote: > opt: /home/mmccrack/lens/obj-llvm-darcslocal/../llvm-darcslocal/llvm/lib/VMCore/PassManagerT.h:426: > void llvm::PassManagerT<UnitType>::markPassUsed(const llvm::PassInfo*, > llvm::Pass*) [with UnitType = llvm::Module]: Assertion > `getAnalysisOrNullUp(P) && > dynamic_cast<ImmutablePass*>(getAnalysisOrNullUp(P))

A On 3/21/06, Michael McCracken <michael.mccracken at gmail.com> wrote: > On 3/21/06, Chris Lattner <sabre at nondot.org> wrote: > > On Mon, 20 Mar 2006, Michael McCracken wrote: > > > > > Hi, I'm trying to access an analysis pass from the Inliner pass, and > > > I'm having a lot of trouble getting that to work - I can verify that > >

On 3/21/06, Chris Lattner <sabre at nondot.org> wrote: > On Mon, 20 Mar 2006, Michael McCracken wrote: > > > Hi, I'm trying to access an analysis pass from the Inliner pass, and > > I'm having a lot of trouble getting that to work - I can verify that > > my pass is loaded and run (it is a dynamically loaded pass that is > > part of an analysisgroup),

Hi, just a quick question about the intent of the ApproximateLoopSize() function in LoopUnroll.cpp: If a loop contains debug stoppoint intrinsics, does it make sense to count them? My understanding is that they are removed when not running under llvm-db anyway, so we probably shouldn't make size judgements based on them. Is that right, or am I missing something? Anyway, if I'm right,

Here's what's left on Linux (GCC 4.1.0), after all updates that went into the branch: Running /proj/llvm/build/../llvm/test/Regression/CFrontend/dg.exp ... FAIL: /proj/llvm/build/../llvm/test/Regression/CFrontend/2004-02-12- LargeAggregateCopy.c.tr: gccas: /proj/llvm/build/../llvm/lib/VMCore/Function.cpp:266: unsigned int llvm::Function::getIntrinsicID() const: Assertion `0 &&

>> Is attached patch acceptable? > > Looks great, applied, thanks! > http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050131/023931.html Thanks! >> Also I have in Makefile.rules (but not include in patch) some >> modification for simplify used common Makefile.rules in LLVM projects and >> non-LLVM project (guarding some LLVM specific parts by ifdef

On Mon, 7 Feb 2005, Tanu Sharma wrote: > I have been trying to randomize blocks in a program and modified > "BasicBlockPlacement.cpp" for the purpose but getting segmentation > fault.I am not able to determine the problem.Can anyone please decrypt > these error messages or suggest what might be the possible cause of > failure? I'd be happy to fix this, but I need

Hi, I have been trying to randomize blocks in a program and modified "BasicBlockPlacement.cpp" for the purpose but getting segmentation fault.I am not able to determine the problem.Can anyone please decrypt these error messages or suggest what might be the possible cause of failure? -----------------------------------------------------------------------------------------------------

The various intrinsic assert/crashes should all be fixed on mainline CVS (they are PR733, which I just fixed). The only ones that I'm wary of are: XPASS: /proj/llvm/build/../llvm/test/Regression/CFrontend/2004-02-20- StaticRedeclare.c.tr FAIL: /proj/llvm/build/../llvm/test/Regression/CFrontend/2005-12-04- DeclarationLineNumbers.c: In the former case, I would guess that the test isn't

Branches have been created. You are free to checkin to cvs head again. I'll send mail once I have the prerelease tar balls up. Please continue to review and revise the documentation. I can fold this into the release later. Thanks, Tanya On Thu, 13 Apr 2006, Tanya Lattner wrote: > > I will be creating the release branch at 1:00pm PDT. Please refrain from > checking in from

I will be creating the release branch at 1:00pm PDT. Please refrain from checking in from 1:00-1:30pm. I will send email once I am done. Thanks, Tanya

I just updated again (both llvm and llvm-gcc). The only thing that changed was: P test/Regression/CFrontend/2005-12-04-DeclarationLineNumbers.c The regression test below was done *with* your llvm-gcc changes to llvm- expand.c. I don't know what the failures are all about, but I will try it again. If its the same, I'll let you know. Reid. On Thu, 2006-04-13 at 16:20 -0500, Chris Lattner

1. If we run a few passes in a sequence ..is the bytecode file transformed after each pass in sequence i.e if we have a) opt -pass1 -pass2 -pass3 < in.bc > out.bc b)opt -pass1 -pass2 < in.bc > tmp.bc opt -pass3 < tmp.bc > out.bc are the above two equivalent ? what I basically want is to run my pass on an optimised bytecode , so should i optimize it and get a new bytecode

Thanks a lot for replying Chris, I m trying to randomize the blocks in a program.I generate a random number( between the current "InsertPos" and the last block), and then iterate through the list of basicblocks , picking up block with position equal to that of the random number and place it into the current InsertPos and increment InsertPos. Running it like this:

I got the following error in 1.5 release. As far as installation is concerned, everything went fine. llc hello.bc -o hello.bs llc((anonymous namespace)::PrintStackTrace()+0x17)[0xd435f1] llc((anonymous namespace)::SignalHandler(int)+0xbd)[0xd437ff] /lib64/tls/libc.so.6[0x3ff522e410] llc(llvm::Type::isFirstClassType() const+0x13)[0x8fc38d] llc(llvm::FunctionType::FunctionType(llvm::Type const*,

Cyrille Mescam wrote: > On Mon, Jun 13, 2005 at 11:02:10AM -0500, John Criswell wrote: > >>Cyrille Mescam wrote: >> [snip] > > In fact, i am using the CFE build procedures. I am on instructions 5. > > cyrille > Okay, I took a closer look at your output. I was correct in that gccas is attempting to assemble a native PPC assembly language file. However,

On Mon, Jun 13, 2005 at 11:02:10AM -0500, John Criswell wrote: > Cyrille Mescam wrote: > >Hi, > > > > > >When compiling the cfrontend for Linux/PPC architecture on a powermac > >G5, i got > >the following error : > > I hate to ask a silly question, but are you using "make bootstrap" to > build the cfrontend? Your output looks like gccas

Hi, I've got the cfe debug info to the point where it outputs correct function info, stoppoints for statements (but not for declarations anymore) and region ends at the beginning of the return block. So this is about as far as I wanted to go with it. However, there's one last big problem that I need some advice on. Running : gcc -g -S -o foo.ll llvmas foo.ll produces bytecode that works