similar to: [LLVMdev] C++ Interpreter

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

Hi, what would be needed to make a C/C++ interpreter using the LLVM libraries. We have in our project (http://root.cern.ch) a C/C++ interpreter (http://root.cern.ch/twiki/bin/view/ROOT/CINT), but it has some limitations (the biggest being maintenance). I see there is a libLLVMInterpreter that can interpret the LLVM IR. Could this be used to interpret, or a starting point, to an real

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

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

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

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

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

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?

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 am asking this question to see if it is possible or desirable to build a compilation/runtime system for C/C++ that can support the following: 1. allow bc to call native (in dynamically loaded *.so) 2. allow native to call bc (through JIT or interpreter) 3. can compile/interpret C/C++ sources _BASED_ on type info in precompiled bc Motivation: The class files produced by the java compiler

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? Cheers, Axel.

2009/8/31 Douglas Gregor <dgregor at apple.com>: > 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 this happen, e.g., by providing clean APIs for an interpreter to call > into Clang's parser to parse a new expression/statement/function. Ok, my bad, language barrier.

Motivation === Over the last decade we have developed an interactive, interpretative C++ (aka REPL) as part of the high-energy physics (HEP) data analysis project -- ROOT [1-2]. We invested a significant  effort to replace the CINT C++ interpreter with a newly implemented REPL based on llvm -- cling [3]. The cling infrastructure is a core component of the data analysis framework of ROOT and

On 7/10/20 1:57 PM, Vassil Vassilev wrote: > On 7/10/20 6:43 AM, JF Bastien wrote: >> I like cling, and having it integrated with the rest of the project >> would be neat. I agree with Hal’s suggestion to explain the design of >> what remains. It sounds like a pretty small amount of code. > > >   JF, Hal, did you mean you want a design document of how cling in >

I like cling, and having it integrated with the rest of the project would be neat. I agree with Hal’s suggestion to explain the design of what remains. It sounds like a pretty small amount of code. > On Jul 9, 2020, at 7:25 PM, Hal Finkel via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > I think that it would be great to have infrastructure for incremental C++ compilation,

Hi Chris, Chris Lattner wrote on 10/15/2009 05:45 PM: > On Oct 15, 2009, at 8:29 AM, Anton Korobeynikov wrote: >> >> I'm a bit curious: is there any reason why are other slides / videos >> not available (it seems that the ones missing are from Apple folks)? > > Unfortunately, we found out at the last minute that Apple has a rule > which prevents its engineers