similar to: [LLVMdev] using bugpoint

Hi all, I wrote 2 passes and I want to make run llvm run the passes in this order: -mem2reg -load=…/mypass1.dylib -mypass1 -load=…/mypass2.dylib -mypass2 -O1 -O2 -O3 I know I can do this by manually passing them as an argument to opt. Is there any way to force this sequence directly from clang? I am asking this because I am trying to compile a program and I can specify in the ./configure

On Dec 6, 2010, at 2:18 AM, Ryan M. Lefever wrote: > > llc X.3.bc arg1 arg2 > > That llc command is currently seg faulting because of a bug in one of my > passes or in support.bc. Can I use bugpoint to find a smaller version of > X.bc that produces the same problem? Specifically how would I call > bugpoint to do that? bugpoint X.3.bc -run-llc -tool-args arg1 arg2 /jakob

On Oct 5, 2013, at 9:17 PM, Niko Zarzani <koni10 at hotmail.it> wrote: > Hi all, > > I wrote 2 passes and I want to make run llvm run the passes in this order: > -mem2reg -load=…/mypass1.dylib -mypass1 -load=…/mypass2.dylib -mypass2 -O1 -O2 -O3 > > I know I can do this by manually passing them as an argument to opt. > > Is there any way to force this sequence

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

Chris, I'm a little confused. I am experiencing a crash when compiling the llvm-gcc frontend. According to the bugpoint documentation, bugpoint is used to debug "optimizer crashes, miscompilations by optimizers, or bad native code generation," which seems like it implies that the frontend compiles. Also, the http://llvm.org/docs/HowToSubmitABug.html documentation seems to

On Wed, 22 Aug 2007, Ryan M. Lefever wrote: > I checked llvm-gcc 4.0 out from svn yesterday and am compiling it on 3 > different machines. I was able to compile it on 2 of the machines, but > the compilation failed on the third machine with the errors below. The > machine that the compilation failed on is running Fedora Core 4. The > processor is a AMD Athlon(tm) 64 Processor

Is a PR a bug report on the bugzilla database? I am also running bugpoint to see if that yields anything. Reid Spencer wrote: > Hi Ryan, > > On Fri, 2007-04-06 at 13:34 -0500, Ryan M. Lefever wrote: > >>I am running the following llvm-ld command to produce native code: >> >>llvm-ld -native -o code.exe code.bc -lm >> >>However, I am getting the

On Fri, 2007-04-06 at 14:27 -0500, Ryan M. Lefever wrote: > Is a PR a bug report on the bugzilla database? Yes, so named because of the URL translation. I.e. http://llvm.org/PR123 takes you to bugzilla bug 123. PR == Problem Report. > I am also running > bugpoint to see if that yields anything. Okay, good. That might turn up something useful. If you suspect its a bug, please file

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

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

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 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':

On Sun, 3 Dec 2006, Ryan M. Lefever wrote: > I am working on a transform that uses an scc_iterator on a program's > CallGraph. However, I am running into a problem in which not all > callees are being processed before callers, leading me to believe there > might be a bug. In particular, this is happening in a case where a > callee is a function pointer. I ran bugpoint and

I am working on a transform that uses an scc_iterator on a program's CallGraph. However, I am running into a problem in which not all callees are being processed before callers, leading me to believe there might be a bug. In particular, this is happening in a case where a callee is a function pointer. I ran bugpoint and have included the bugpoint-reduced-simplified.ll below. If

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

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

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

I printed the call graph as you suggested. The bugpoint bytecode that I sent below prints the following call graph: Indirect call node / | | \ / | | \ V | V V execute | prog_char clear_func | | V V push_constant | V Node0x8d7b370 i.e., Indirect call node -> execute

--- tools/bugpoint/bugpoint.cpp | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) I came across this while running bugpoint --help, hope you don't mind the git patch output :) diff --git a/tools/bugpoint/bugpoint.cpp b/tools/bugpoint/bugpoint.cpp index 2364675..587077e 100644 --- a/tools/bugpoint/bugpoint.cpp +++ b/tools/bugpoint/bugpoint.cpp @@ -67,7 +67,7 @@ int main(int argc,

I have a failing test and bugpoint would be the perfect tool to help narrow it down. llc is the failing tool. It fails with one set of options and passes with another. I was hoping to use bugpoint like this: bugpoint -safe-llc -run-llc <testcase> -tool-args <failing args> -safe-tool-args <passing args> Unfortunately, this doesn't seem to be possible. According to the