similar to: [LLVMdev] using bugpoint in a complex ruby code build case

> Due to the lack of bugpoint examples in the documentation, I have no > idea how to use bugpoint > in this complex case, where vm.o firstly needs to be linked with lots > of other compiled modules > and libraries, then the resulting program needs to be executed with > some parameters! It should be possible. I did something like that for debugging a clang bootstrap. What I did

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

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

On Tue, Oct 28, 2008 at 12:17 PM, Prakash Prabhu <prakash.prabhu at gmail.com> wrote: > Generating reference output from raw program: <cbe><gcc> > Error running tool: [snip] > /tmp/cc08IpX8.o: In function `SyLoadModule': > bugpoint-test-program.bc.cbe.c:(.text+0x25705): undefined reference to > `dlopen' [snip] This is saying that compilation with CBE is

Hi Eli, Thanks for the reply. I tried with -Xlinker="-ldl ". However it does not seem to make a difference. It seems that when bugpoint is run with --run-jit, the linker args are not passed to gcc (from tools/bugpoint/ExecutionDriver.cpp) : if (InterpreterSel == RunLLC || InterpreterSel == RunCBE || InterpreterSel == CBE_bug || InterpreterSel == LLC_Safe) RetVal =

Hi Prakash, Unfortunately it looks like you need to do quite a bit of investigation into this. However, I hope I can provide some useful tips. 1. In general, lli and llc generate exact the same code except lli default to static codegen while llc defaults to dynamic-no-pic codegen. So try passing -relocation-model=dynamic-no-pic to lli. If this works, that means there are issues with

Sorry to ask about a documented use of bugpoint, but I am having trouble understanding what to do. I would like to be able to use bugpoint to simplify test cases, when the symptom is a run time difference in the testprogram behavior. That looks like what is described in the documentation as "miscompilation or perhaps code generation problems". There are examples in the LLVM doc showing

Hi Evan, Thanks for the pointers. We found a simple test case that causes the problem (thanks to Tom in my group): #include<stdio.h> #include<stdlib.h> void test(); void (*funcPtr)(); int main(int argc, char **argv) { funcPtr = test; test(); } void test() { if(funcPtr == test) { printf("OK!\n"); } else { fprintf(stderr, "Bad!\n"); exit(1);

I've filed PR3043 for this. Evan On Nov 3, 2008, at 4:00 PM, Prakash Prabhu wrote: > Hi Evan, > > Thanks for the pointers. We found a simple test case that causes the > problem (thanks to Tom in my group): > > #include<stdio.h> > #include<stdlib.h> > > void test(); > void (*funcPtr)(); > > int main(int argc, char **argv) { > funcPtr =

Hi David, It looks like you added the PWD= magic to Makefile.spec. It is preventing me from running bugpoint on the desktop, with errors like this: /Users/sabre/llvm/projects/llvm-test/External/SPEC/Sandbox.sh bugpoint- train Output/176.gcc.bugpoint-opt /Users/sabre/cvs/benchmarks/ speccpu2000/benchspec/CINT2000/176.gcc/data/train/input/ \

Yes, its what I want, but I can't figure out how to get bugpoint to accomplish this. -David ________________________________ From: Duncan Sands [mailto:baldrick at free.fr] Sent: Thu 2/18/2010 6:06 AM To: David Dunkle Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] using bugpoint to find miscompilation/code generation problems? Hi David, > It then iterates until a simplified test

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

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