similar to: [LLVMdev] make bugpoint-jit

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

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

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

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

Hi Nan Zhu, > I use Bugpoint to check it , Bugpoint gives me the following information: > > > Read input file : 'bodytrack.bc' > *** All input ok > Initializing execution environment: Found gcc: /usr/lib/ccache/gcc > Running the code generator to test for a crash: <cbe>*** Debugging code > generator crash! > > Error running tool: >

On Wed, Jul 16, 2008 at 9:00 AM, David Greene <dag at cray.com> wrote: > What's the proper incantation to get bugpoint to run things through opt > but use llc to generate asm? As noted, CBE has issues generating > correct code so using it isn't an option right now. It should be something like bugpoint x.bc -llc-safe -pass1 -pass2 -pass3. The -llc-safe forces it to never

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

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

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

On Sat, 2007-03-31 at 15:34 +0200, Ferad Zyulkyarov wrote: > Hi, > > I want to implement a new intrinsic in llvm that will denote a > parallel section within a function. I followed the documentation for > extending llvm (http://llvm.org/docs/ExtendingLLVM.html) but there is > something about the working mechanism that is not clear for me. > > 1. Why do we have to add

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

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

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

Hello, David. > After hacking around in the CBE output I managed to compile it with > gcc, only to discover that gcc 4.1.2 has the SAME bug LLVM does with > respect to alignment. Automatic stack realignment was atted to X86 backend ~3 months ago. Everything should work with LLVM. If not - please fill out a PR. AFAIR, automatic stack realignment still does not land into gcc mainline

On Wednesday 16 July 2008 13:28, Anton Korobeynikov wrote: > Hello, David. > > > After hacking around in the CBE output I managed to compile it with > > gcc, only to discover that gcc 4.1.2 has the SAME bug LLVM does with > > respect to alignment. > > Automatic stack realignment was atted to X86 backend ~3 months ago. > Everything should work with LLVM. If not -

Ping? Still looking for advice in figuring out how and why my generated code is causing lli to crash... Talin wrote: > I've been using lli to do most of my unit tests for the compiler that > I'm writing. However, when I get a test that crashes, its difficult to > find which instruction it was that caused the crash. I tried running > bugpoint, but it didn't seem to work

On Fri, Apr 22, 2005 at 01:46:53AM +0200, Markus F.X.J. Oberhumer wrote: > Debugging code generator problem! > <cbe><gcc><program>Warning: While generating reference output, program > exited with > non-zero exit code. This will NOT be treated as a failure. > > *** The C backend cannot match the reference diff, but it is used as the > 'known good'