similar to: [LLVMdev] pthread?

I try to run lli with "--load=/lib/libpthread.so", but it shows: --------------------------------------------------- [yue at RH9 test]$ ./pthread.ll Error opening '/lib/libpthread.so.0': /lib/libpthread.so.0: symbol _errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference -load request ignored. Creating thread 0 WARNING: Cannot resolve fn

On Wed, 24 Dec 2003, yue wrote: > I try to run lli with "--load=/lib/libpthread.so", but it shows: > --------------------------------------------------- > [yue at RH9 test]$ ./pthread.ll > Error opening '/lib/libpthread.so.0': /lib/libpthread.so.0: symbol > _errno, version GLIBC_2.0 not defined in file libc.so.6 with link time > reference > -load request

Try llvmgcc pthread.c -o pthread.ll -pthread You have to link in the pthreads library, and I believe -pthread is all you need on a redhat 9 box. Kevin > -----Original Message----- > From: llvmdev-admin at cs.uiuc.edu [mailto:llvmdev-admin at cs.uiuc.edu] On > Behalf Of yue > Sent: Tuesday, December 23, 2003 11:43 PM > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] pthread?

Does LLVM called the pthread directly? and what time do you plan to release Java front end? I'll try this. ----- Original Message ----- From: "Chris Lattner" <sabre at nondot.org> To: "yue" <qiangyue at ict.ac.cn> Cc: <llvmdev at cs.uiuc.edu> Sent: Wednesday, December 24, 2003 12:47 PM Subject: Re: [LLVMdev] GCC3.5 tree-ssa > On Wed, 24 Dec 2003,

hi, when build test echo.cpp using "llvmg++ echo.cpp -o echo" it create an echo file, contain: ------------------------------------- [yue at RH9 Shootout-C++]$ cat echo #!/bin/sh lli \ -load=/usr/lib/libm.so \ $0.bc $* --------------------------------------- and using "llvmgcc echo.cpp -o echo-c", it creates an echo-c file, contain:

hi, I try to build hello.cpp using both llvmg++ and GNU g++, the generate llvm bytecode's size is about 960K, and the size of binary code generated by g++ is only 13K. Could anyone explain the difference between the two result? BWT: I rebuild the cfrontend in RH linux9.0, but when I build the hello.cpp the llvmG++ reports warnings too, it shows: ----------------------------- [yue at RH9

hi, when I run "make -C ./llvm/test/Programs", it show following error: ------------------------------------------------------------------------------------------- [root at RH9 llvm]# make -C ./llvm/test/Programs make: Entering directory `/usr/local/llvm/llvm/test/Programs' make[1]: Entering directory `/usr/local/llvm/llvm/test/Programs/SingleSource' make[2]: Entering directory

hi, when i change the OBJ_ROOT and recompile the llvm, it's successful. but run following test, then the error occues: ----------------------------------------------------- [yue at RH9 obj]$ make -C ./test/Programs make: Entering directory `/home/yue/llvm/obj/test/Programs' make[1]: Entering directory `/home/yue/llvm/obj/test/Programs/SingleSource' make[2]: Entering directory

On Wed, 24 Dec 2003, yue wrote: > what difference is between gcc3.5 tree-ssa and llvm? They are completely different projects. The short version is that LLVM is more mature and stable than tree-ssa is, LLVM supports interprocedural and runtime optimization, and LLVM has a well defined intermediate representation with a textual format. On the other hand tree-ssa may be a part of GCC 3.5

Dear yueqiang, I tracked this down this morning, and it is a bug with our Python code that runs the tests. Essentially what is happening is that the code is finding the temporary directory it created the first time it ran the tests and believes that there are tests inside of it which it needs to run. It then gets confused and quits. This bug only shows up when the source tree and the

hi, what difference is between gcc3.5 tree-ssa and llvm? yueqiang 2003/12/24

why doesn't llvm transfer bytecode to RTL form? I mean the cross-platform compile in GCC. Could LLVM do that? maybe tree-ssa also create the representation with a testual format if needed. is it very difficalt? I want to know. BWT: if we port pthread library to llvm, what do we consider at first? yueqiang Chris Lattner wrote: >On Wed, 24 Dec 2003, yue wrote: > > >>what

hi, when i build hello.cpp, it show following conflict: ----------------------------------------------------------- [yue at RH9 Shootout-C++]$ llvmg++ hello.cpp -o hello WARNING: Type conflict between types named 'struct._Unwind_Exception'. Src='{ ulong, void (uint, \4 *) *, uint, uint }'. Dest='{ ulong, void (ubyte, \4 *) *, uint, uint }' gccld: error linking in

Hi, the terminating part of nut-scanner can crash in pthread code, because some threads won't exist. For example snmp part: ============================== if( allow_snmp && nutscan_avail_snmp ) { if( start_ip == NULL ) { printq(quiet,"No start IP, skipping SNMP\n"); } else { printq(quiet,"Scanning SNMP bus.\n"); #ifdef HAVE_PTHREAD if(

On Wed, 24 Dec 2003, yue wrote: > we work on distribute software development, most programs are wroten in > java. > but the running speed of that is slowly, it requires thread library to > support, you know. I'm not sure exactly what you mean here. LLVM does not currently have a Java front-end, though there is one in development. Thread support should not be a problem, you can

we work on distribute software development, most programs are wroten in java. but the running speed of that is slowly, it requires thread library to support, you know. Chris Lattner wrote: >On Wed, 24 Dec 2003, yue wrote: > > > >>why doesn't llvm transfer bytecode to RTL form? I mean the >>cross-platform compile in GCC. Could LLVM do that? >> >>

Hi Nick: Thanks for pointing me to libffi. Recompile LLVM with libffi does solve the problem of printf. But it still has other problems: 1) sinf() returns 0 in the interpreter, but returns correct value in JIT (see hellosin.c) 2) calling pthread_create cause lli to crash in the interpreter mode, but no problem in JIT (see phello.c). My questions are: i) can I call any arbitrary external function

Xu Yang wrote: > Hi Nick: > > The first problem have been solved by calling llvm-ld: > > $ llvm-ld -o hellosin.llvm hellosin.bc -lm > $ lli -force-interpreter=true -load=/usr/lib/libm.so hellosin.llvm.bc > hello sin: 0.50 Only because the optimizer saw sin(constant) and folded it away. The entire program became 'print constant string'. There is certainly a bug

Hi Nick, On 9/20/2013 5:59 PM, Nick Kledzik wrote: > On Sep 20, 2013, at 3:42 PM, Shankar Easwaran > <shankare at codeaurora.org> wrote: >> nextFile could pass the current resolver state at the time when its called, the linkingcontext can return the next file to be processed as below :- >> >> nextFile(currentResolverState) :- >> >> a) Returns the next

Hi Nick: The first problem have been solved by calling llvm-ld: $ llvm-ld -o hellosin.llvm hellosin.bc -lm $ lli -force-interpreter=true -load=/usr/lib/libm.so hellosin.llvm.bc hello sin: 0.50 The pthread problem remains after llvm-ld: $ lli -force-interpreter=true -load=/lib/libpthread.so.0 phello.llvm.bc 0 lli 0x08796bf8 Segmentation fault For those who are getting "invalid