similar to: [LLVMdev] Weird memory bug

This was indeed a memory issue - the hard datasize limit on my freebsd box was 512 mb and this opt went over. Increasing hard limit fixed the problem. However, most unices have a 512mb limit - maybe insanely huge functions as this one should be automagically split somewhere? On Dec 24, Alexander Friedman wrote: > > After running through bugpoint, I get this reduced function > >

On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer wrote: > Misha Brukman wrote: > >On Tue, Apr 19, 2005 at 07:01:40AM +0200, Markus F.X.J. Oberhumer > >wrote: Have you considered using bugpoint for your codegen debugging > >needs? http://llvm.cs.uiuc.edu/docs/Bugpoint.html#codegendebug > > Well, the (critical) bug in question was >

void MetaSplit::handleProgramUses(Value *V){ if(!isa<BasicBlock>(V)) programValues.insert(V); if(User *U = dyn_cast<User>(V)){ User::op_iterator OB = U->op_begin(), OE = U->op_end(); for(; OB != OE; ++OB){ if(CallInst *CI = dyn_cast<CallInst>(*OB)){ Function *F = CI->getCalledFunction(); if(F == ii || F == fi || F == vi || F == di || F == ci

All, As of last night's commits, the analyze tool's functionality has been moved to the opt tool. This was requested in PR872. The change reduces LLVM's Debug footprint by 36MB without any loss of functionality. To obtain analyze's old functionality, pass the -analyze switch to the opt tool. If you previously did this: analyze $FNAME -domset -disable-verify you would now do

I'm having some trouble using bugpoint with newer version of gcc (bugpoint debug output below). I looked into the "conflicting type for malloc" problem and it doesn't seem easy to solve due to the unknown size of size_t (see LowerAllocations.cpp). The "void main()" problem is probably a result of this test being converted from Fortran. I'll have to dig into

While running the llvm tests, I get several error messages like these: [1/1] Running the LLVM regression tests FAILED: cd /home/steve/llvm-build/test && /usr/local/bin/python /home/steve/llvm/utils/lit/lit.py --param build_config=. --param build_mode=Release -sv --param llvm_site_config=/home/steve/llvm-build/test/lit.site.cfg --param

On Mar 26, 2014, at 6:56 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 3/26/2014 11:39 AM, İsmail Dönmez wrote: >> >> make check-all but yes make check would suffice. Thanks! > > I see two reported failures: > > > FAIL: LLVM :: BugPoint/compile-custom.ll (459 of 9992) > ******************** TEST 'LLVM ::

Hi, I am trying to reduce what I believe to be a miscompilation bug. Running lli on my bitcode file causes a segmentation fault. However, running bugpoint as bugpoint file.bc gives me the following errors, /tmp/ccAdmNqH.o: In function `_ZL17bus_error_handleriP7siginfoPv': bugpoint-test-program.bc-Vega5s.cbe.c:(.text+0x1b4e1): undefined reference to `std::cerr' /tmp/ccAdmNqH.o: In

What's different about code that's been mem2reg'd from straight front end code, or anything that mem2reg hasn't been run on? PHINODES! It appears to be crashing when I try to cast a Value* that's really a BB* (from the PHInode operands) to a User*, insteresting since I am dyn_casting. I just caught this on cerr though (printing out what the Value* was each time). Let me

Hi, I didn't get a clear idea what to do whit this problem: OptimizerDriver.cpp seems to be unix platform specific. However, I'm compiling this on MinGW. Shouldn't this be moved to lib/System/<platform>? Any suggestions? -------------------------- c:/Projects/src/llvm/tools/bugpoint/OptimizerDriver.cpp:28:22: sys/wait.h: No such file or directory

On Wed, Oct 31, 2012 at 04:43:42PM -0700, Eli Friedman wrote: > On Wed, Oct 31, 2012 at 4:33 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: > > On Wed, Oct 31, 2012 at 03:53:50PM -0700, Eli Friedman wrote: > >> On Wed, Oct 31, 2012 at 8:43 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: > >> > While testing llvm/polly svn on

On Wed, Jun 23, 2004 at 03:50:09PM -0500, Patrick Meredith wrote: > MetaSplit is an anlysis I just finished writing. It doesn't alter > anything, all it does is build a set of "program instructions". For > some reason even though if I run it with any other combination of > passes I've found, anytime I run it with mem2reg I get a seg fault in > dyn_cast!

On Wednesday 16 July 2008 10:12, David Greene wrote: > I'm having some trouble using bugpoint with newer version of gcc (bugpoint > debug output below). I was using gcc 4.1.2. When I try 3.2.3 I get: bugpoint-test-program.bc.cbe.c:237: warning: conflicting types for built-in function `memcpy' bugpoint-test-program.bc.cbe.c: In function `main':

Thank you for this information. If so, is there any way to grasp which kinda data throw in and out in LLVM as shown in such a way in gdb? Thanks, Seung Jae Lee ---- Original message ---- >Date: Tue, 20 Feb 2007 23:54:04 -0600 >From: "John T. Criswell" <criswell at cs.uiuc.edu> >Subject: Re: [LLVMdev] bugpoint usage >To: LLVM Developers Mailing List <llvmdev at

On Jul 8, 2009, at 1:52 PM, Viktor Kutuzov wrote: >> bugpoint should be a standalone tool. It should not require a >> separate >> script to handle remote execution. Why is the script needed? > > Bugpoint is a standalone too and does not require any separate script. > The script is a helper for using ssh as a remote client. Ok. > > Bugpoint should not be aware

On Wed, Oct 31, 2012 at 5:01 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: > On Wed, Oct 31, 2012 at 04:43:42PM -0700, Eli Friedman wrote: >> On Wed, Oct 31, 2012 at 4:33 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: >> > On Wed, Oct 31, 2012 at 03:53:50PM -0700, Eli Friedman wrote: >> >> On Wed, Oct 31, 2012 at 8:43 AM, Jack Howarth

I've made quite a bit of progress getting bugpoint to work with our (non-gcc) tools. In fact I caught the alignment bug I recently posted about using it. But it's not there yet. In particular, I am seeing this scenario a lot (comments in brackets): *** Found miscompiling pass: -instcombine Emitted bitcode to 'bugpoint-passinput.bc' [ Good! This is progress! ] *** You can

Hi everyone, I want to test the passes in llvm, and I got some passes sequences that caused the crash of opt. Although I can use bugpoint to narrow down the source of problems, I can only get some reduced and simplified IR and passes to reproduce the problem. My question is how to get the reduced IR of the original IR file to reproduce the problem. For example, "opt a.bc -a -b -c -d (where

> bugpoint should be a standalone tool. It should not require a separate > script to handle remote execution. Why is the script needed? Bugpoint is a standalone too and does not require any separate script. The script is a helper for using ssh as a remote client. Bugpoint should not be aware of any details how the test program will be delivered to a remote target, get executed there, and

On Wednesday 16 July 2008 10:31, David Greene wrote: > On Wednesday 16 July 2008 10:12, David Greene wrote: > > I'm having some trouble using bugpoint with newer version of gcc > > (bugpoint debug output below). > > I was using gcc 4.1.2. When I try 3.2.3 I get: > > bugpoint-test-program.bc.cbe.c:237: warning: conflicting types for built-in > function