search for: llvmpowerpc

...build/llvm-2/Debug/ lib/LLVMSparcV8.o /usr/build/llvm-2/Debug/lib/LLVMSparcV9.o /usr/build/llvm-2/De bug/lib/LLVMSparcV9RegAlloc.o /usr/build/llvm-2/Debug/lib/LLVMSparcV9InstrSched. o /usr/build/llvm-2/Debug/lib/LLVMSparcV9LiveVar.o /usr/build/llvm-2/Debug/lib/L LVMX86.o /usr/build/llvm-2/Debug/lib/LLVMPowerPC.o /usr/build/llvm-2/Debug/lib/L LVMAlpha.o /usr/build/llvm-2/Debug/lib/LLVMIA64.o /usr/build/llvm-2/Debug/lib/LL VMSelectionDAG.o /usr/build/llvm-2/Debug/lib/LLVMCodeGen.o /usr/build/llvm-2/Deb ug/lib/LLVMScalarOpts.o /usr/build/llvm-2/Debug/lib/LLVMBCReader.o /usr/build/ll vm-2/Debug/lib/LLVMBCWri...

Simon Burton <simon at arrowtheory.com> writes: >> There are several possibilities here: either add1 is assigned a NULL >> pointer, or LLVM was unable to use the JIT and generates bytecode >> instead of native code, or invalid native code was generated >> (unlikely). > > Well, it's not NULL: > > (gdb) print add1 > $1 = (int (*)(int)) 0x83e43b8 >

...provided by "llvm-config --libs" it works fine (yay!). Except it's a huge executable: 168Mb. And the linker warns about some symbols: /usr/bin/ld: `.gnu.linkonce.t._ZNK4llvm14TargetLowering12getValueTypeEPKNS_4TypeE' referenced in section `.rodata' of /home//users//simonb//lib/LLVMPowerPC.o: defined in discarded section `.gnu.linkonce.t._ZNK4llvm14TargetLowering12getValueTypeEPKNS_4TypeE' of /home//users//simonb//lib/LLVMPowerPC.o etc. If instead I use "llvm config --libs jit asmparser" it compiles but segfaults in the usual place. Here are the libs it uses in this c...

...build/llvm-2/Debug/lib/LLVMSparcV8.o /usr/build/ llvm-2/Debug/lib/LLVMSparcV9.o /usr/build/llvm-2/Debug/lib/LLVMSparcV9RegAlloc.o /usr/build/llvm-2/Debug/lib/LLVMSparcV9InstrSched.o /usr/build/llvm-2/Debug/lib /LLVMSparcV9LiveVar.o /usr/build/llvm-2/Debug/lib/LLVMX86.o /usr/build/llvm-2/De bug/lib/LLVMPowerPC.o /usr/build/llvm-2/Debug/lib/LLVMAlpha.o /usr/build/llvm-2/ Debug/lib/LLVMIA64.o /usr/build/llvm-2/Debug/lib/LLVMSelectionDAG.o /usr/build/l lvm-2/Debug/lib/LLVMCodeGen.o /usr/build/llvm-2/Debug/lib/LLVMScalarOpts.o /usr/ build/llvm-2/Debug/lib/LLVMBCReader.o /usr/build/llvm-2/Debug/lib/LLVMBCWrit...

On Fri, 14 Apr 2006 03:25:39 +0200 Oscar Fuentes <oscarfv at telefonica.net> wrote: ... > Simon, > > With a fresh CVS checkout, I've tried your test case on Windows/VC++ > and it works ok. Too bad that I have not access to a Linux machine > right now. I'll like to see what's wrong with your test case. > > What you get from running the test case under gdb

...fail on OS X, too. I have attached the whole .cpp file containing the complete code. It's adapted from the JIT example in the LLVM source distribution. I compile it using g++ -c codegen1.cpp -o codegen1.o -D__STDC_LIMIT_MACROS g++ -o codegen1 -L${LLVM_LIB_DIR} codegen1.o ${LLVM_LIB_DIR}/ LLVMPowerPC.o -lLLVMSelectionDAG ${LLVM_LIB_DIR}/LLVMInterpreter.o $ {LLVM_LIB_DIR}/LLVMJIT.o -lLLVMCodeGen -lLLVMScalarOpts - lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis ${LLVM_LIB_DIR}/ LLVMExecutionEngine.o -lLLVMTarget -lLLVMCore -lLLVMSupport - lLLVMbzip2 -lLLVMSystem -lpthread -ldl greetings, Jan R...

...-install/lib/LLVMMSIL.o /home/rich/llvm-install/lib/LLVMCBackend.o /home/rich/llvm-install/lib/LLVMCellSPU.o /home/rich/llvm-install/lib/LLVMMips.o /home/rich/llvm-install/lib/LLVMARM.o /home/rich/llvm-install/lib/LLVMIA64.o /home/rich/llvm-install/lib/LLVMAlpha.o /home/rich/llvm-install/lib/LLVMPowerPC.o /home/rich/llvm-install/lib/LLVMSparc.o /home/rich/llvm-install/lib/LLVMX86.o -lLLVMSelectionDAG -lLLVMCodeGen -lLLVMScalarOpts -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMSupport -lLLVMSystem Does this sort of thing ring a bell with anyone? -Rich

On Fri, Oct 21, 2005 at 12:10:12AM +0100, Aaron Gray wrote: > I thought I should warn you the Cygwin Release (ENABLE_OPTIMIZED=1) build > fails due to 'ld/collect2' assertion failure. > > This is really a Cygwin problem that I thought would be fixed with time by > now but is still present with GCC 3.4.4 and binutils 2.16.91. Is there a version of Cygwin that _does_ build

Hello Anton Thu, 3 Aug 2006 15:06:56 +0400 you wrote: > here it is in the attachment :) Ok. Could you also send LibDeps.txt file? It should be in /obj/tools/llvm-config directory -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hi, > If I recall correctly, in Linux you get the message: > > PPCJITInfo.cpp:382: failed assertion `ResultPtr >= -(1 << 23) && > ResultPtr < (1 << 23) && "Relocation out of range!"' > > > Right? But on OS X you don't have this messsage? Not exactly. There seem to be two problems. Your patch fixes one of them: in OS X I

...not using the correct link flags? That is large. I'd suggest using the output of the llvm-config tool to pass the right options to the linker: $ llvm-config --libs --ldflags jit native -L/Volumes/ProjectsDisk/cvs/llvm/Debug/lib -lpthread -lltdl -lm /Volumes/ProjectsDisk/cvs/llvm/Debug/lib/LLVMPowerPC.o -lLLVMSelectionDAG -lLLVMCodeGen -lLLVMScalarOpts -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis /Volumes/ProjectsDisk/cvs/llvm/Debug/lib/LLVMJIT.o /Volumes/ProjectsDisk/cvs/llvm/Debug/lib/LLVMExecutionEngine.o -lLLVMTarget -lLLVMCore -lLLVMSupport -lLLVMSystem (this is on a ppc/darwin system...

...tached the whole .cpp file containing > the complete code. It's adapted from the JIT example in the LLVM > source distribution. I compile it using > > g++ -c codegen1.cpp -o codegen1.o -D__STDC_LIMIT_MACROS > g++ -o codegen1 -L${LLVM_LIB_DIR} codegen1.o ${LLVM_LIB_DIR}/ > LLVMPowerPC.o -lLLVMSelectionDAG ${LLVM_LIB_DIR}/LLVMInterpreter.o $ > {LLVM_LIB_DIR}/LLVMJIT.o -lLLVMCodeGen -lLLVMScalarOpts - > lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis ${LLVM_LIB_DIR}/ > LLVMExecutionEngine.o -lLLVMTarget -lLLVMCore -lLLVMSupport - > lLLVMbzip2 -lLLVMSystem -lpthread -l...

Hello Anton Fri, 4 Aug 2006 21:45:19 +0400 you wrote: > Written by Mike Haertel and Paul Eggert. > I've updated llvm and llvm-gcc4 ant trying to build it again after > PR845 was resolved. According to Reid's letter this PR coud be the > reason of my problem. Anyway, "sort" call can cause large problems depending, where in your PATH cygwin directory is (before

I did not report this first error earlier as I thought it trivial. Basically it looks like something odd is happening with the configuration and 'include/llvm/config/config.h' Getting this error on building the tools on a fresh Cygwin install and update :- $ make tools-only make[1]: Entering directory `/usr/build/llvm/lib/System' llvm[1]: Compiling Path.cpp for Debug build In file

...s by somehow building the bindings against an installed llvm-config. LLVMers, what's the advantage to building .o files instead of .a's for these libs? LLVMARM.o LLVMAlpha.o LLVMCBackend.o LLVMCellSPU.o LLVMExecutionEngine.o LLVMIA64.o LLVMInterpreter.o LLVMJIT.o LLVMMSIL.o LLVMMips.o LLVMPowerPC.o LLVMSparc.o LLVMX86.o This wouldn't be a problem if these components used .a's instead, since ld's search paths are set up correctly. The options I see are: Use archive libraries instead of objects for the above. Link the above .o files into .a's just for the ocaml bindings....

...Pick the right LLVM backend based on the target triple. LLVMTARGETOBJCMD := case $(target) in \ alpha-*-*) echo LLVMAlpha.o;; \ ia64-*-*) echo LLVMIA64.o;; \ i[34567]86-*-*) echo LLVMX86.o;; \ powerpc*-*-*) echo LLVMPowerPC.o;; \ sparc-*-*) echo LLVMSparc.o;; \ sparcv9-*-*) echo LLVMSparc.o;; \ esac LLVMTARGETOBJ := $(shell $(LLVMTARGETOBJCMD)) ifeq ($(LLVMTARGETOBJ),) $(error Unsuported LLVM Target $(target)) endif LLVMLIBS = -L$(LLVMLIBPATH) $(LLVMLI...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What is the expected footprint of a tool using the LLVM JIT? I have created a simple project that uses the LLVM C++ API to JIT calls to XPCOM method signature... it works well, but the component DLL is very large (Linux x86-74, 5.8MB optimized and stripped). Is this normal? Am I linking to "too much" or not using the correct link flags?

I've run into a problem with the ocaml bindings and the jit. It builds fine without the jit, but when I try to include it it tries to use the c object files from the build location, instead of the install location: > llvm-config --libdir --libfiles engine /opt/local/lib /opt/local/lib/LLVMX86.o /opt/local/lib/libLLVMSelectionDAG.a /opt/local/lib/libLLVMCodeGen.a

On Mar 10, 2006, at 2:57 PM, Martin Pärtel wrote: > I'm currently using the "make install"-ed version of LLVM in an > autoconf/automake project. Setting it up wasn't that bad really. > The .a > libraries can be statically linked with the -l flag and .o > libraries are > simply linked in as normal object files (without -l). All the > libraries got >

> > If you're building llvm-gcc4, you don't need the runtime libraries, so > I'd just stick with the "tools-only" build and declare success. If > you're building llvm-gcc3, I'd suggest you switch to llvm-gcc4 :) I switched to llvm-gcc4 but when I run make from obj folder i run into folowing errors: Can't find a library with no dependencies at