similar to: [LLVMdev] Some love for bugpoint.

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

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

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

Hi all, I've been running into what appears to be an optimization bug in llvm, while compiling the latest ruby 1.9.3 with the latest llvm/clang 2.9 version. From hands on experimentation I do know that the gvn pass for the "vm.c" compilation is the culprit of the miscompilation (clang -O2/-O3 options produce the miscompilation, however -O1 is fine!). I've also tried to

On Jul 8, 2009, at 12:42 AM, Viktor Kutuzov wrote: > Hello Evan, > > Thanks for looking at the patch. > >> This should use std::cerr and make sure it is wrapped inside the >> DEBUG >> macro. > > Will do. > >> Also, we don't want RemoteRunSafely.sh to be under utils/bugpoint. >> Can you move it to test-suite? Are you planning to change the

Hi, I am trying to use bugpoint to reduce testcase. And bugpoint try to reduce the number of operands for metadata, and this generate corrupted metadata: *** Attempting to remove named metadata: Checking for crash with only these named metadata nodes: llvm.dbg.cu llvm.module.flags llvm.ident: <crash> Checking for crash with only these named metadata nodes: llvm.module.flags llvm.ident:

----- Original Message ----- > From: "Reed Kotler" <rkotler at mips.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: LLVMdev at cs.uiuc.edu > Sent: Friday, November 22, 2013 11:18:53 PM > Subject: Re: bugpoint question > > In that case it tries to do something but fails. > > rkotler at ubuntu-rkotler:~/testmips16$ >

Hi,all I ran my generated whole-program bitcode file which performs as a bodytrack tool, it can give me the right result but with a stack dump before it exsits Update Error : Model observation failed for time : 1 Error loading observation data terminate called after throwing an instance of 'std::bad_cast' what(): std::bad_cast 0 lli 0x08b713d2 1 lli 0x08b71247

> I will investigate. I'm in the middle of it as well. Best regards, Viktor ----- Original Message ----- From: "David Goodwin" <david_goodwin at apple.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Friday, July 10, 2009 2:43 PM Subject: Re: [LLVMdev] Heads up! Working on bugpoint >I just checked in my changes to bugpoint and

On Tue, May 23, 2017 at 2:40 PM Reid Kleckner <rnk at google.com> wrote: > We have the LLVM_DISABLE_CRASH_REPORT environment variable, but that's > more about whether we should do crash reporting or not. > > It would be pretty reasonable to have another one to disable all this > stuff. It would also be reasonable to have a cmake option that compiles > this stuff away,

I would like to use bugpoint to debug some of my passes. I have read the documentation, but I don't completely understand it. I have a bitcode file X.bc that I transform using the following commands: opt -mypass1 -f -o X.1.bc X.bc // transform with mypass1 llvm-link -f -o X.2.bc X.1.bc support.bc // link with support.bc opt -mypass2 -f -o X.3.bc X.2.bc // transform with mypass2 After

"Finkel, Hal J. via llvm-dev" <llvm-dev at lists.llvm.org> writes: > One concern that I have is that, from personal experience, the ability > for bugpoint to reduce the set of optimization passes applied in order > to reproduce a bug is extremely helpful. I understand your desire to > decouple the logic somewhat, and maybe there's some way to generalize > that

Thank you so much for this info. That's exactly what I want. But, I'm still not sure about using -g. Let me imagine I am modifying x86 assembly instructions and trying to test it with 'hello.c' to check out the assembly is properly emitted. I should type "$ llvm-gcc hello.c -o hello" to have the bytecode of 'hello.c'. And then I can have an x86 assembly mnemonics

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