similar to: [LLVMdev] LLVM Usage Question: Generating objects and executables from an LLVM client

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] LLVM Usage Question: Generating objects and executables from an LLVM client"

2012 Jun 05
0
[LLVMdev] vmkit: Requires JAVA_HOME
While building i got this error Error: JAVA_HOME is not defined correctly. I wonder why vmkit requires JAVA_HOME, i would expect it to be independent of any java staff except the classspath. Am i missing something? Thank you Foivos
2012 Jun 05
1
[LLVMdev] vmkit: Requires JAVA_HOME
While building i got this error Error: JAVA_HOME is not defined correctly. I wonder why vmkit requires JAVA_HOME, i would expect it to be independent of any java staff except the classspath. Am i missing something? Thank you Foivos
2012 Jun 07
4
[LLVMdev] VMKIT: Assertion at build
Hi Nicolas, it looks like there are missing things $ more lib/j3/LLVMRuntime/LLVMRuntime.inc // Generated by llvm2cpp - DO NOT MODIFY! Module* makeLLVMModuleContents(Module *mod) { mod->setModuleIdentifier("<stdin>"); // Type Definitions // Function Declarations // Global Variable Declarations // Constant Definitions // Global Variable Definitions // Function
2012 Jun 07
2
[LLVMdev] VMKIT: Assertion at build
Still the same. Is there any chance that the placement of my directories are causing this? Also the exact command that fails is /home1/public/zakkak/java/vmkit/Release+Asserts/bin/vmjc -std-compile-opts -load=/home1/public/zakkak/java/vmkit/Release+Asserts/lib/MMTKRuntime.so -load=/home1/public/zakkak/java/vmkit/Release+Asserts/lib/MMTKMagic.so -LowerMagic
2012 Jun 10
0
[LLVMdev] VMKIT: Assertion at build
Hi Nicolas, I finally found the root of the problem. Build was unable to locate llvm-build because it was looking for it in path/to/vmkit_src/utils/llvm-build while it was located in path/to/llvm_src/utils/llvm-build Actually llvm-build's path is defined by the path/to/llvm_src/Makefile.rules and looks like this LLVMBuildTool := $(PROJ_SRC_ROOT)/utils/llvm-build/llvm-build however in
2012 Jun 07
0
[LLVMdev] VMKIT: Assertion at build
Hi Fovios, Do you have a ./lib/j3/LLVMRuntime/LLVMRuntime.inc file being generated? What does it contain? Nicolas On Thu, Jun 7, 2012 at 5:47 PM, Foivos S. Zakkak <foivos at zakkak.net> wrote: > Still the same. > > Is there any chance that the placement of my directories are causing this? > > Also the exact command that fails is > >
2012 Jun 07
2
[LLVMdev] VMKIT: Assertion at build
Hi Nicolas, I thought MMTk is written in java and it is compiled by javac. retried a clean build with JIT enabled llvm configuration ../../llvm/configure --enable-doxygen --enable-optimized --enable-jit vmkit configuration ../../llvm/vmkit/configure --with-llvmsrc=/home1/public/zakkak/llvm/ --with-llvmobj=/home1/public/zakkak/java/llvm/
2012 Jun 07
0
[LLVMdev] VMKIT: Assertion at build
On Thu, Jun 7, 2012 at 4:27 PM, Foivos S. Zakkak <foivos at zakkak.net> wrote: > Hi Nicolas, > > I thought MMTk is written in java and it is compiled by javac. > It is compiled by javac to produce Java bytecode. Then vmkit runs the initialization code of MMTk (through the JIT) and generates the binary code through llvm. > retried a clean build with JIT enabled > >
2012 Jun 07
2
[LLVMdev] VMKIT: Assertion at build
Hi, My machine is running Ubuntu server 64-bit And the revision from the trunk is 158095 for llvm, clang and vmkit llvm configuration ../../llvm/configure --enable-doxygen --enable-optimized --disable-jit vmkit configuration ../../llvm/vmkit/configure --with-llvmsrc=/home1/public/zakkak/llvm/ --with-llvmobj=/home1/public/zakkak/java/llvm/
2012 Jun 06
0
[LLVMdev] VMKIT: Assertion at build
Hi Fivos, I cannot reproduce on my machine (ubuntu 64bit, clang/llvm/vmkit on svn trunk). What's your configuration? Cheers, Nicolas On Tue, Jun 5, 2012 at 3:08 PM, Fivos <fivosz at gmail.com> wrote: > Hello, > > after completing the build i get > > ... > BUILD SUCCESSFUL > Total time: 5 seconds > llvm[2]: Building Release+Asserts mmtk-vmkit.jar all > vmjc:
2012 Jun 07
0
[LLVMdev] VMKIT: Assertion at build
Hi Fovios, On Thu, Jun 7, 2012 at 3:51 PM, Foivos <fivosz at gmail.com> wrote: > Hi, > > My machine is running Ubuntu server 64-bit > And the revision from the trunk is 158095 for llvm, clang and vmkit > > llvm configuration > ../../llvm/configure --enable-doxygen --enable-optimized --disable-jit > Why do you disable the JIT? VMKit needs it to compile MMTk.
2012 Jun 11
2
[LLVMdev] VMKIT: Assertion at build
Thanks Favios for finding the problem! I have applied a patch to Makefile.rules, hopefully it now works without you editing some files. About VMKIT_SRC_ROOT and PROJ_SRC_ROOT, it is fine to have both in the code. I find it clearer to use VMKIT_SRC_ROOT. Nicolas On Sun, Jun 10, 2012 at 10:09 PM, Foivos S. Zakkak <foivos at zakkak.net>wrote: > Hi Nicolas, > > I finally found the
2012 Jun 11
0
[LLVMdev] VMKIT: Assertion at build
Hi Nicolas, thanks, it works fine :) Is there any manual/documentation available for vmkit? Do you know if there is an easy way to completely disable JIT and interpret the code instead? Foivos On 06/11/2012 04:51 PM, Nicolas Geoffray wrote: > Thanks Favios for finding the problem! I have applied a patch to > Makefile.rules, hopefully it now works without you editing some files. >
2012 May 28
1
[LLVMdev] VMKIT: Error while producing LLVMruntime.inc (using llvm-as and llc)
vmkit fails to build because llvm-as with llc -march=cpp generate wrong code for AttrListPtr AttrListPtr::get(ArrayRef< AttributeWithIndex >Attrs) http://llvm.org/doxygen/classllvm_1_1AttrListPtr.html#a3a19622d131e9f0d981398f54cf6acfc bellow you can see the faulty generated code llvm-as ./vmkit/lib/vmkit/Compiler/LLVMRuntime.ll -o - | llc -march=cpp -cppgen=contents -o - | grep
2012 Jun 05
3
[LLVMdev] VMKIT: Assertion at build
Hello, after completing the build i get ... BUILD SUCCESSFUL Total time: 5 seconds llvm[2]: Building Release+Asserts mmtk-vmkit.jar all vmjc: /home1/public/zakkak/llvm/lib/VMCore/Type.cpp:747: static llvm::PointerType *llvm::PointerType::get(llvm::Type *, unsigned int): Assertion `EltTy && "Can't get a pointer to <null> type!"' failed. 0 vmjc
2012 Jun 09
0
[LLVMdev] VMKIT: Assertion at build
On Jun 7, 2012, at 4:32 PM, Foivos S. Zakkak wrote: > Hi Nicolas, > > it looks like there are missing things > > $ more lib/j3/LLVMRuntime/LLVMRuntime.inc > // Generated by llvm2cpp - DO NOT MODIFY! > > > Module* makeLLVMModuleContents(Module *mod) { > > mod->setModuleIdentifier("<stdin>"); > > // Type Definitions > > //
2012 Jun 13
1
[LLVMdev] [REQUEST] VMKIT: cross compilation
Hello, As i understand vmkit's Makefiles are not written to support cross compilation. It looks like they ignore the --target flag from the configuration. Please correct if i am wrong. I would like to make a request to add cross compilation support to the project. I am willing to contribute if needed Thank you Foivos
2012 Jul 09
1
[LLVMdev] Error generating a executable using llcj
I installed vmkit-0.29 and tried to generate a executable using llcj I generated the libvmjc and updated the library path export LD_LIBRARY_PATH=$(VMKIT_OBJ)/Release/lib llcj --main=hello hello.class -o hello but i am getting the following error /home/shyam/classpath-0.97.2/lib/vmkit/Release+Debug/lib/libvmjc.a(glibj.zip.o): In function
2012 Jun 27
1
[LLVMdev] How to make a cross compiler for xilinx microblaze
conmfigure does not accept mblaze nor mblaze-elf as target. checking target system type... Invalid configuration `mblaze': machine `mblaze' not recognized configure: error: /bin/bash ../../spare/llvm/autoconf/config.sub mblaze failed However with microblaze it proceeds fine. But when i try to use clang i get: clang: error: 'microblaze-unknown-none': unable to pass LLVM bit-code
2014 Jan 21
4
[LLVMdev] MCJIT versus getLazyBitcodeModule?
Thanks for the pointers. Am I correct in assuming that putting the precompiled bitcode into a second module and linking (or using the object caches) would result in ordinary function calls, but would not be able to inline the functions? -- lg On Jan 21, 2014, at 11:55 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I would say that the incompatibility is by design. Not