Displaying 20 results from an estimated 69 matches for "clinge".
Did you mean:
cline
2020 Jul 10
3
[cfe-dev] [RFC] Moving (parts of) the Cling REPL in Clang
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!
2020 Jul 09
5
[RFC] Moving (parts of) the Cling REPL in Clang
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
2020 Jul 10
4
[cfe-dev] [RFC] Moving (parts of) the Cling REPL in Clang
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,
2020 Jul 10
3
[cfe-dev] [RFC] Moving (parts of) the Cling REPL in Clang
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
>
2020 Jul 10
0
[cfe-dev] [RFC] Moving (parts of) the Cling REPL in Clang
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:
>
>
2019 Apr 10
4
Feasibility of cling/llvm interpreter for JIT replacement
Dear Sir/Madam
Our company, 4Js software, has developed an SQL data base software that
runs under different operating systems: Windows, Linux, Mac OS X. This
software compiles each SQL statement into a C program that is compiled
"on the fly" and executed by our JIT, Just In Time compiler.
We wanted to port it to Apple's iOS, and spent a lot of time
retargetting the JIT for
2004 Jun 14
2
disconnected errors
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.
2017 Sep 27
2
OrcJIT + CUDA Prototype for Cling
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
2014 Jun 12
2
[LLVMdev] problems to recompile LLVM version 3.4.1 with gcc48 / SuSE 13.1
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
2017 Nov 14
1
OrcJIT + CUDA Prototype for Cling
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
2015 Jan 22
2
[LLVMdev] MCJIT and recursive finalization
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
2008 Jul 08
3
[LLVMdev] DEBUG
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.
>>
2009 Dec 17
3
[LLVMdev] Compiling a raw binary with llvm/clang
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?
2012 Dec 01
0
[LLVMdev] Minimum Python Version
On 2012-12-01 21:57, Gregory Szorc wrote:
> I'd like to continue the discussion about minimum Python versions from the "Use multiprocessing instead of threading" thread in its own thread because I feel it warrants additional discussion.
...
> For these reasons, I urge LLVM to drop support for Python older than 2.6. I would encourage requiring 2.7 (preferably the latest
2012 Oct 10
0
[LLVMdev] Solicit code review (change to CodeGen)
LGTM.
I will commit.
On Oct 10, 2012, at 1:20 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:
> Hi,
>
> The attached is the fix to radar://11663049. The optimization can be outlined by following rules:
>
> (select (x != c), e, c) -> select (x != c), e, x),
> (select (x == c), c, e) -> select (x == c), x, e)
> where the <c> is an integer
2012 Dec 01
2
[LLVMdev] Minimum Python Version
On Sat, Dec 1, 2012 at 2:08 PM, Dimitry Andric <dimitry at andric.com> wrote:
> On 2012-12-01 21:57, Gregory Szorc wrote:
>>
>> I'd like to continue the discussion about minimum Python versions from the
>> "Use multiprocessing instead of threading" thread in its own thread because
>> I feel it warrants additional discussion.
>
> ...
>
2013 Feb 18
1
[LLVMdev] how to check out revision 165095
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
2015 Mar 12
2
Expunge (?)
Hi,
I don't know if this is the correct term. Let me elaborate. From time to
time, I want to expunge (?) the mail folder so that users' Trash'd mails
don't occupy space. So, here are my questions:
1. Is this the correct term?
2. Is it a Good Idea? to do it?
Thanks,
--
mto
2015 Jan 12
2
[LLVMdev] MCJIT handling of linkonce_odr
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
2012 Dec 01
11
[LLVMdev] Minimum Python Version
I'd like to continue the discussion about minimum Python versions from the
"Use multiprocessing instead of threading" thread in its own thread because
I feel it warrants additional discussion.
In that thread, we were discussing maintaining support for Python 2.4 and
2.5. The latest response is:
On Fri, Nov 30, 2012 at 1:40 PM, Daniel Dunbar <daniel at zuster.org> wrote:
>