similar to: [LLVMdev] CBE errors

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

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

Hi All, I am creating an instrumentation pass using LLVM libraries. I am using clang++ (version 2.9) to compile cpp code into LLVM bit code. When I generate the llvm bit code using clang++ using -O3, I get many instances of instructions that look like the following. br i1 icmp ne (i8* bitcast (i32 (i32)* @pthread_cancel to i8*), i8* null), label %bb23, label %bb25 Here three LLVM instructions

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

Hello, I get the following error when I kill icecast. I am running icecast2 from source on a debian unstable box. I have looked around google and tried a couple of suggestions like moving and linking the libgcc library around, without any luck. "libgcc_s.so.1 must be installed for pthread_cancel to work?" Anyone have any suggestions? Thanks, Alex Martin shorewall@rettc.com

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

I will definately look into this tonight and see if it is a problem with my recent patch. On Wednesday 02 March 2005 3:39 am, Markus F.X.J. Oberhumer wrote: > Reid Spencer wrote: > > On Tue, 2005-03-01 at 22:07, Markus F.X.J. Oberhumer wrote: > >>Follow up: After removing the dangling symlink the problem now looks: > >> > >>-march=c((anonymous

On 10/10/12 18:57, Nadav Rotem wrote: > Hi Roel! > > > On Oct 10, 2012, at 5:29 AM, Roel Jordans <r.jordans at tue.nl> wrote: > >> 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

On Tue, 2005-03-01 at 22:07, Markus F.X.J. Oberhumer wrote: > Follow up: After removing the dangling symlink the problem now looks: > > -march=c((anonymous namespace)::PrintStackTrace()+0x1e)[0x847a17e] > -fno-strict-aliasing: example.out.cbe.c: No such file or directory > gccld: example.out.cbe.c: Can't destroy file: > make: *** [example.out] Error 1 > At a minimum that

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

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,

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

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

Adam, Looks like you have your first issue with the gccld patch. Could you please look into this for us? Markus seems to have detected a situation where -native-cbe is acting like -native ... On Wed, 2005-03-02 at 00:39, Markus F.X.J. Oberhumer wrote: > Short update: -native-cbe is currently broken as gccld/llc seems to generate > assembler code instead of C. To easy debugging of such

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 -

Hey, I try to run a postlogin script with: service pop3 { executable = pop3 postlogin } service postlogin { executable = script-login /etc/dovecot/popafter.sh user = $default_internal_user unix_listener postlogin { } } In my popafter.sh I call a php script, and that result in: dovecot: postlogin: Error: libgcc_s.so.1 must be installed for pthread_cancel to work dovecot:

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