similar to: [LLVMdev] bugpoint / cbe Problems

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 -

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

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

Hello, Dave > So I'm in a bit of a pickle. Does anyone know which versions of gcc > understand the cbe output? At least 3.4.6 and 4.2.x were ok. For semicolon problem - please file a PR. -- WBR, Anton Korobeynikov

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

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

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

Hello, Andrew > That's right.  If you want to be able to call any code produced by gcc, > you have to preserve 16-alignment.  gcc-generated code does not realign > the stack pointer. This was for gcc < 4.4, where stack alignment handling was really messy. stack-realignment branch was merged afair into gcc 4.4 and allows automatic realignment of stack, when necessary. -- With

Hi, I'm running into some strange errors with the CBE. I've narrowed the problem down to a very simple CPP program: main.cpp: -------------------------------------------------------------------------------- #include <string> static std::string hello("Hello world!"); int main() { return 0; }

Hello all, As some of you may remember, I am trying to get the C back-end back in working condition. I have the old version up and running (including most of it's pre-existing bugs), email me if you want a patch to the current trunk. === Question 1: new design feedback === I am currently looking into moving the CBE to run after the initial lowering and type legalization phases so that

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

Hi all, I met an error when I run the llc command to transform a bitcode file to C code (source to source): $ llc -march=c -o foo.c foo.ll However, it said "*llc: error: invalid target 'c'.*" I checked the 'llc --version' only to find that there is no *c* as target. The *cpp* was there, which makes calls against the LLVM C++ API. But that's not what I want. I

The C Backend was remove in 3.1 (http://llvm.org/releases/3.1/docs/ReleaseNotes.html): "Major Changes and Removed Features ... The C backend has been removed. It had numerous problems, to the point of not being able to compile any nontrivial program." On Wed, Dec 5, 2012 at 10:00 AM, Mingliang LIU <liuml07 at gmail.com> wrote: > Hi all, > > I met an error when I run the

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 Arnold, Thank you. I googled but missed the release notes. Regards. On Thu, Dec 6, 2012 at 12:13 AM, Arnold Schwaighofer < arnold.schwaighofer at gmail.com> wrote: > The C Backend was remove in 3.1 > (http://llvm.org/releases/3.1/docs/ReleaseNotes.html): > > "Major Changes and Removed Features > ... > The C backend has been removed. It had numerous problems,