similar to: [LLVMdev] bugpoint / cbe Problems

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 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 run into an issue specifying intrinsics for AVX. Right now one can use GCCBuiltin to get automatic CBE (and other) support for emitting intrinsics as gcc builtins. It looks like this: def int_x86_sse3_hadd_pd : GCCBuiltin<"__builtin_ia32_haddpd">, Intrinsic<[llvm_v2f64_ty], [llvm_v2f64_ty, llvm_v2f64_ty], [IntrNoMem]>; AVX

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

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

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 -

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

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

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

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

Hello, Jeffrey > Here are the relevant lines from main.cbe.c. Notice that > "pthread_cancel" is declared as a weak external symbol, but > "_ZL22__gthrw_pthread_cancelm" is never declared (even though it is > used). This is bug in CBE. Please fill problem report in LLVM bugzilla. -- With best regards, Anton Korobeynikov. Faculty of Mathematics &

On Nov 8, 2008, at 10:12 AM, Anton Korobeynikov wrote: >> Here are the relevant lines from main.cbe.c. Notice that >> "pthread_cancel" is declared as a weak external symbol, but >> "_ZL22__gthrw_pthread_cancelm" is never declared (even though it is >> used). > This is bug in CBE. Please fill problem report in LLVM bugzilla. I submitted a request for

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

On Thu, Dec 06, 2012 at 10:05:03AM +0800, Mingliang LIU wrote: > Hi Arnold, > > Thank you. I googled but missed the release notes. > > Regards. Someone else out there tried to bring cbe back. You can search the ML archieve and reach them out. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.)