similar to: Feasibility of cling/llvm interpreter for JIT replacement

Hi Richard, On 7/10/20 11:10 PM, Richard Smith wrote: > Hi Vassil, > > This is a very exciting proposal that I can imagine bringing important > benefits to the existing cling users and also to the clang user and > developer community. Thank you for all the work you and your team have > done on cling so far and for offering to bring that work under the > LLVM umbrella!

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,

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

Dear LLVM-Developers and Vinod Grover, we are trying to extend the cling C++ interpreter (https://github.com/root-project/cling) with CUDA functionality for Nvidia GPUs. I already developed a prototype based on OrcJIT and am seeking for feedback. I am currently a stuck with a runtime issue, on which my interpreter prototype fails to execute kernels with a CUDA runtime error. === How to use the

Hi Lang, thank You very much. I've used Your code and the creating of the object file works. I think the problem is after creating the object file. When I link the object file with ld I get an executable, which is working right. After changing the clang and llvm libraries from the package control version (.deb) to a own compiled version with debug options, I get an assert() fault. In void

I do not know enough about cling, but I like what you describe very much, am particularly intrigued about how your approach could also be appropriated to do ahead-of-time constexpr metaprogramming as well, which also involves incrementally adding declarations to the translation unit. Dave > On Jul 9, 2020, at 11:43 PM, JF Bastien via cfe-dev <cfe-dev at lists.llvm.org> wrote: > >

Jun 14 07:35:20 cling imap-login: Login: tallison [192.168.1.10] Jun 14 07:35:21 cling dovecot: child 17755 (imap) killed with signal 11 --- I run into this when I try to enter one folder. The rest are fine.

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 Thu, Jun 12, 2014 at 10:57:46AM +0200, Armin Steinhoff wrote: > > Hi, > > first problem was: > > >FileManager.cpp:311:21: error: range-based ‘for’ loops are not allowed > >in C++98 mode > >for (auto & fe: SeenFileEntries) { > >^ > >FileManager.cpp:312:14: error: request for member ‘getValue’ in ‘fe’, > >which is of non-class type ‘int’

On Jul 8, 2008, at 4:57 AM, Chris Lattner wrote: > On Mon, 7 Jul 2008, David Greene wrote: >>> Since I think it really is a part of the LLVM internals, I don't >>> think >>> that mangling it with a prefix is the right way to go. This would >>> significantly increase verbosity in the code and would be generally >>> detrimental. >>

Indeed ld does link it. The reason I am using llvm-ld, is for its unique functionality. I intend to link to object files together (created by cling), and link them with llvm-ld. The main feature that I am currently interested in is the ability to have "inline functions" between two object files. This was basically impossible with gcc. Is there any way to make the raw binary with llvm?

Hi I have been assigned the task of porting the ARM code generator to the ipad. I would like to know if there are any available documents about the instruction set/code format of the A64 chip of Apple. Also, if at all possible, documents that describe executable formats, etc are welcome. Any pointers? Thanks in advance.

Hello: I am told that compile cling, from CERN, I need revision 165095. HOW do I check out that version? When going through the /tags directory, all version are 17xxxx. I tried svn checkout -r 165095 http://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx llvm but it will not work with either /truck or /tags I tried svn checkout http://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx at 165095, but that also doen't work

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 Jun 14, 2017, at 1:53 PM, Rolf Turner <r.turner at auckland.ac.nz> wrote: > > On 15/06/17 05:29, David Winsemius wrote: >>> On Jun 14, 2017, at 10:18 AM, David Winsemius <dwinsemius at comcast.net> wrote: >>> >>> >>>> On Jun 14, 2017, at 9:46 AM, Jeff Newmiller <jdnewmil at dcn.davis.ca.us> wrote: >>>>

Hi On Mon Jul 27 11:29:44 CDT 2015 I posted a question here about the way llvm implements exceptions in Apple's OS X. Since then I have received ZERO answers. I have solved the problem myself by "disassembling" the messy source code available. I thank everyone for proving me (yet another time) that THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.

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!

Le 25/08/2015 20:39, Renato Golin a écrit : > I'm also interested in knowing what you did. I think most people here > would be glad to know your peril and how you solved it. Stack layout: C++ code calls | | JITted C code, compiled and linked on the fly tha calls | | C++ code that throws The throw must pass through the JITted code to arrive at the catch at the top.

Sigh. I never load packages in .Rprofile to avoid the irreproducibility trap. Might seem drastic to some, but I don't feel much pain because I almost always edit my code in a file rather than on the fly at the console, and re-run it frequently from a fresh R process to check my progress. -- Sent from my phone. Please excuse my brevity. On June 14, 2017 3:27:15 PM PDT, David Winsemius