similar to: [LLVMdev] New bugpoint feature

I believe I can use bugpoint to help you folks track down an LLVM bug using the bugpoint mode where it runs the program and looks at its output. However there is a slight complication: to distinguish between correct and incorrect runs I need to run the program under test in our hacked valgrind. After reading all the bugpoint docs I can't figure out how I would do that. What I would like

> -----Original Message----- > From: Nick Lewycky [mailto:nicholas at mxc.ca] > Sent: Saturday, July 30, 2011 2:36 PM > To: Gregory Junker > Cc: 'Rotem, Nadav'; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] "Cannot select" error in 2.9 > > Gregory Junker wrote: > >>> -----Original Message----- > >>> From: Rotem, Nadav

Hey everyone. It sounds like 426 people are in for a fun weekend. It's possible that some of you may even have bugs in your code (I know, I know, not YOU... :) If this is you, read on... You might be interested in trying out the 'bugpoint' tool. It can help you when your pass crashes on a testcase. Merely tell it the input testcase and the name of your pass, and it will try to

"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

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

Hi, I have a program that runs when statically compiled using llc and gcc but crashes with a segmentation fault when run with lli. I am trying to debug it with bugpoint and the initial part of bugpoint seems to be suggesting that I am somehow missing the linking with the libraries having dlsym/dlopen although I am passing it to lli : *$ bugpoint -run-jit

Ketan Pundlik Umare wrote: > Hi Guys, > I am an absolute newbie to the compiler community. I am experimenting a little bit with llvm. > I have a few small questions, i would be really great if someone could help me. It sounds like what you want is valgrind --tool=cachegrind (or --tool=callgrind). See http://valgrind.org/ > 1. Can i find out (is there something already built), if the

It seems that bugpoint (and llvmc2, etc.) is hard-wired to use gcc to do assembling and linking. I want to bugpoint-reduce a testcase that came from Fortran and so I need to invoke our compiler to do at least the linking step to get our Fortran libraries. Is there a way to do this via bugpoint's command-line interface or do I have to hack bugpoint's source? I can see how I might make

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, 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 Dave, > It seems that bugpoint (and llvmc2, etc.) is hard-wired to use gcc to do > assembling and linking. I want to bugpoint-reduce a testcase that came > from Fortran and so I need to invoke our compiler to do at least the linking > step to get our Fortran libraries. you can always cheat and have gcc be a symlink to your compiler. Ciao, Duncan.

Gregory Junker wrote: >>> -----Original Message----- >>> From: Rotem, Nadav [mailto:nadav.rotem at intel.com] >>> Sent: Saturday, July 30, 2011 6:51 AM >>> To: Gregory Junker >>> Subject: RE: [LLVMdev] "Cannot select" error in 2.9 >>> >>> Can you reduce the test with bug-point ? Does it work on ToT ? >> >> Hi

In that case it tries to do something but fails. rkotler at ubuntu-rkotler:~/testmips16$ /home/rkotler/llvmw/install/bin/bugpoint casts.bc -llc-safe --safe-tool-args -target=mips-linux-gnu -mcpu=mips16 -mips16-constant-islands Read input file : 'casts.bc' *** All input ok Initializing execution environment: Found llc: /home/rkotler/llvmw/install/bin/llc Running the code

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

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

This is what works for me, when I want to reduce an llc failure triggering a failure with a "foo bar baz" in the assert message (the grep for the error message avoids reducing to an unrelated failure): $ cat run_llc.sh #!/bin/sh if ! $HOME/dev/llvm/build/bin/llc "$@" 2>&1 | grep "foo bar baz"; then exit 0 else exit $? fi $

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

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