similar to: [LLVMdev] Supported JIT targets

On Jan 20, 2009, at 5:56 AM, Axel Naumann wrote: > Hi, > > I've been trying to find a list of the current JIT-supported > targets. Not easy > :-) The sources seem to say that the architectures are X86, PowerPC, > ARM, > Alpha. And then their obvious combination with Linux, FreeBSD / > MacOSX, Win32 - > is that it? X86-64 and PPC64 also. I don't know how

Hi Keno, The part that scares me a bit is > and then adjust the other methods to not > bail out two quickly when encountering a weak symbol. I would very much appreciate if you could implement this; I don't have enough knowledge of the MCJIT nor llvm CodeGen internals... I will happily try it out and provide you with feedback, though! :-) Thank you *so* much for your fast reaction!

2009/8/31 Axel Naumann <Axel.Naumann at cern.ch>: > we want to implement a C++ interpreter using LLVM and clang Isn't clang going on that direction anyway? cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm

Hi, we want to implement a C++ interpreter using LLVM and clang, to replace our existing one <http://root.cern.ch/drupal/content/cint> that is used as part of a data handling and analysis environment <http://root.cern.ch>. We plan to keep the set of features that our current interpreter offers, e.g. calls into and out of libraries, dynamic scoping, unloading of code, and a prompt. I

Hi, This is a question on how to resolve weak symbols from the binary for symbols that are also llvm::Module-local. Currently, the JIT seems to favor resolving to module-local symbols over existing symbols: $ cat symbols.cxx extern "C" int printf(const char*,...); template <class T> struct StaticStuff { static T s_data; }; template <class T> T

Hi, is there an option to build LLVM's libs (and maybe clangs, but that's for later :-) as shared libraries? It's not --enable-shared :-) If it doesn't exist: is there any interest to have it? It would reduce my build time considerably... Cheers, Axel.

Hi Óscar, On 2009-10-08 00:49, Óscar Fuentes wrote: > Axel Naumann <Axel.Naumann at cern.ch> writes: >> is there an option to build LLVM's libs (and maybe clangs, but that's >> for later :-) as shared libraries? > > With cmake it is BUILD_SHARED_LIBS > > http://www.llvm.org/docs/CMake.html Great! So I must use CMake instead of configure / make to get

Axel Naumann <Axel.Naumann at cern.ch> writes: > is there an option to build LLVM's libs (and maybe clangs, but that's > for later :-) as shared libraries? It's not --enable-shared :-) If it > doesn't exist: is there any interest to have it? It would reduce my > build time considerably... With cmake it is BUILD_SHARED_LIBS http://www.llvm.org/docs/CMake.html

Hi, I'm finally moving cling to MCJIT - and MCJIT is wonderful! So far I only ran into this issue: $ cat linkonceodr.cxx extern "C" int printf(const char*,...); template <class T> struct StaticStuff { static T s_data; }; template <class T> T StaticStuff<T>::s_data = 42; int compareAddr(int* mcjit); #ifdef BUILD_SHARED int compareAddr(int* mcjit) { if (mcjit

Hi, I ran into a problem migrating cling (finally!) to MCJIT: When an ("outer") MCJIT's finalization / llvm::RuntimeDyldImpl::resolveExternalSymbols() is called and a symbol is not known, cling can help by loading the suitable library and providing the symbol. It compiles the relevant C++ header as part of loading the library. This compilation emits symbols through the MCJIT. That

On Mon, Oct 5, 2009 at 8:27 PM, Axel Naumann <Axel.Naumann at cern.ch> wrote: > Hi, > > #include "JIT.h" will do. Thanks. That was exactly what I needed to progress to the next error ("Unable to find target for this triple (no targets are registered)") As soon as I get this front-end working with the trunk, I'll start submitting patches that add calls to

Hi, #include "JIT.h" will do. Cheers, Axel. On 2009-10-06 03:09, Kenneth Uildriks wrote: > I've gotten my front-end to compile with the 2.6 branch and with trunk > (not with both; I have to fiddle with a few things when switching), > and it refuses to give me an execution engine. > > My link flags include everything coming from "llvm-config --libs". >

I've gotten my front-end to compile with the 2.6 branch and with trunk (not with both; I have to fiddle with a few things when switching), and it refuses to give me an execution engine. My link flags include everything coming from "llvm-config --libs". Nevertheless, the error string coming back from ExecutionEngine::create is: JIT has not been linked in Is this a known problem?

On Fri, 2012-07-20 at 08:36 +0200, Duncan Sands wrote: > Hi Adhemerval Zanella, the old JIT infrastructure is going away, to be replaced > by "MC-JIT" (try passing -use-mcjit to lli). It sounds like you are working on > the old JIT, so I suggest you work instead on getting MC-JIT working on powerpc. Hi Duncan, Thanks for the pointers. We hadn't stumbled across the

On 07/20/2012 10:35 AM, Will Schmidt wrote: > On Fri, 2012-07-20 at 08:36 +0200, Duncan Sands wrote: >> Hi Adhemerval Zanella, the old JIT infrastructure is going away, to be replaced >> by "MC-JIT" (try passing -use-mcjit to lli). It sounds like you are working on >> the old JIT, so I suggest you work instead on getting MC-JIT working on powerpc. > Hi Duncan,

On Aug 31, 2009, at 1:19 PM, Renato Golin wrote: > 2009/8/31 Axel Naumann <Axel.Naumann at cern.ch>: >> we want to implement a C++ interpreter using LLVM and clang > > Isn't clang going on that direction anyway? Clang is meant to be flexible enough to be used as the basis for a C++ interpreter. However, there will probably be a bit of work to do in Clang to make

Dear R users, I am trying to get data from the clipboard into R on MacOSX. I tried the following, but got an error message: read.delim("clipboard") Error in file(file, "r") : unable to open connection In addition: Warning message: unable to contact X11 display Obviously, I'm not running R using X11. I'm wondering, can I import data from the clipboard on MacosX?

On 07/31/2012 11:26 AM, Adhemerval Zanella wrote: > On 07/20/2012 10:35 AM, Will Schmidt wrote: >> On Fri, 2012-07-20 at 08:36 +0200, Duncan Sands wrote: >>> Hi Adhemerval Zanella, the old JIT infrastructure is going away, to be replaced >>> by "MC-JIT" (try passing -use-mcjit to lli). It sounds like you are working on >>> the old JIT, so I suggest

Hi all, I have been experiencing the failure of the address sanitizer regression tests for a PPC64 target (Power7 machine). My understanding is that most of the failures are related with the fact the stack is not being dumped. I tried to understand what might be wrong and started by looking into the null_deref.cc test as it hangs during the test run. I observe that after the detection of the

Hello, I am currently working with PPC64 JIT support for LLVM. So far I could make function calls work by adding function descriptors in 'lib/Target/PowerPC/PPCJITInfo.h' and adding a virtual method at 'LLVM::TargetJITInfo' that is called within 'JITEmitter::finishFunction' just after 'sys::Memory::InvalidateInstructionCache' to update the Global Mapping with