similar to: enable_shared_from_this fails at runtime when inherited privately

Am 29.08.19 um 12:07 schrieb Jonathan Wakely: > On Thu, 29 Aug 2019 at 10:15, Christian Schneider > <cschneider at radiodata.biz> wrote: >> >> Hello, >> I just discovered, that, when using enable_shared_from_this and >> inheriting it privately, this fails at runtime. >> I made a small example: >> >> #include <memory> >> #include

Oooh. Neat. Thanks Dave. Please go ahead and commit that. Arnaud - I have no idea whether Dave's patch will help with this bug, but it's certainly worth testing. - Lang. On Wed, Sep 10, 2014 at 4:10 PM, David Blaikie <dblaikie at gmail.com> wrote: > While I'm not sure where the leak is, using some pre-canned memory > management might help... > > Attached is a

On Thu, Jul 17, 2014 at 4:45 PM, Alp Toker <alp at nuanti.com> wrote: > > On 18/07/2014 02:21, David Blaikie wrote: >> >> Are people OK with/prefer the use of owning smart pointers in APIs? > > > I think smart pointers are great to use for storage, or as struct members > where there's actually a clear need for ownership. Just by virtue of getting > rid of

Hi Lang, In PBQPBuilderWithCoalescing::build, around line 360, we have code looking like: … PBQP::Vector newCosts(g.getNodeCosts(node)); addPhysRegCoalesce(newCosts, pregOpt, cBenefit); g.setNodeCosts(node, newCosts); … I suspect the leak occurs around the setNodeCosts method, and I have trouble understanding how it handles the case where the node already has costs. It seems to

On Wed, Oct 19, 2016 at 6:24 PM, Benjamin Kramer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > In terms of performance shared_ptr has a number of disadvantages. One > is that it always uses atomics even though most IntrusiveRefCntPtrs > are used in single-threaded contexts. Another is weak_ptr adding a lot > of complexity to the implementation, IntrusiveRefCntPtr

why llvm contains IntrusiveRefCntPtr instead of using only std::shared_ptr? IntrusiveRefCntPtr widely used in llvm and clang source code. Due to better performance? for example in main func of clang frontend: int cc1_main(ArrayRef<const char *> Argv, const char *Argv0, void *MainAddr) { ensureSufficientStack(); std::unique_ptr<CompilerInstance> Clang(new CompilerInstance());

In the most basic case, I'd imagine something like this: auto C = std::make_shared<LLVMContext>(); struct ModuleAndSharedContextDeleter { std::shared_ptr<LLVMContext> C; operator()(Module *M) { delete M; } /* ctor to init C */}; std::unique_ptr<Module, ModuleAndSharedDeleter> M(new Module(C.get()), ModuleAndSharedContextDeleter(C)); (or invert this and traffic in structs

My experience with LLVM is limited, but I am trying to figure out how to add optimizations for automatic reference counting. The GC documentation mentions that patch-points could be useful, but it does not state how they would be useful. If this is a FAQ, please let me know... So this is my idea at this point: The context is a C++ like language with an aggregate type that is always reference

On Wed, Oct 19, 2016 at 9:31 PM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On Oct 19, 2016, at 11:14 AM, Bruce Hoult via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On Wed, Oct 19, 2016 at 6:24 PM, Benjamin Kramer via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> In terms of performance shared_ptr has a number of

There seems to be some uncertainty about the use of smart pointers (previously OwningPtr, now std::unique_ptr and std::shared_ptr predominantly) in the LLVM project as a whole, so here's a thread to discuss/clarify/etc the project preferences/direction with regard to smart pointer usage. For some context, see discussions in LLVM r212403 and Clang r213307. The basic question here seems to be

Hi, I have read the concurrency webpage from the Xapian documentation: http://getting-started-with-xapian.readthedocs.io/en/latest/concepts/concurrency.html But it is still not clear to me how to ensure thread-safety when using libxapian (C++ API). Usually when doing multi-threading many threads can read the same variable concurrently without locking provided none of the threads modifies the

On 18 Nov 2020, at 7:39, Florian Hahn wrote: >> On Nov 18, 2020, at 12:08, Ola Fosheim Grøstad via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> >> My experience with LLVM is limited, but I am trying to figure out how >> to add optimizations for automatic reference counting. The GC >> documentation mentions that patch-points could be useful, but it

Agreed, the existing ownership seems sub-optimal. I wouldn't say broken, but subtle at least - looks like you get the choice to either manage the ownership of the Module object yourself, or let the context handle it (eg: currently it'd be valid to just do "{ LLVMContext C; new Module(C); new Module(C); }" - Modules end up owned by the context and cleaned up there). Might be hard

I am getting all these messages when run `passenger-status''. Do I need to worry about this? I am using passenger 2.2.2 with puppet 0.24.8 and apache2 on ubuntu 9.04. I installed it using the wiki http://reductivelabs.com/trac/puppet/wiki/UsingPassenger Thread ''Main thread'': in ''int Server::start()'' (ApplicationPoolServerExecutable.cpp:553)

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

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 all, hi Lang It's a little late to report issues for release_50, but I just found that thing while porting my JitFromScratch examples to 5.0. This is a really nifty detail, but (if I'm not mistaken) the function signature of RTDyldObjectLinkingLayer::NotifyLoadedFtor is incorrect: $ grep -h -r -A 1 "using NotifyLoadedFtor"

Hi, I would like to use std::shared_ptr in my pass. However I'm facing a problem wrt RTTI. If I have a code like: std::shared_ptr<BaseClass> x(new DerivedClass()); ... std::shared_ptr<DerivedClass> p = std::dynamic_pointer_cast<DerivedClass>(x); It does not compile since the default RTTI infrastructure is not used by LLVM. Also, it's not clear to me if the

Hello everyone, I bring to discussion the necessity/design of a new type of smart pointer. r215176 and r217791 rise the problem, D5443 <http://reviews.llvm.org/D5443> is devoted to the solution. r215176 applies several temporary ugly fixes of memory leaks in TGParser.cpp which would be great to be refactored using smart pointers. D5443 <http://reviews.llvm.org/D5443> demonstrates

hi. Is there interest in enhancing the objc++ compiler to make objc mechanisms friendly to the newer features of c++? For instance... 1) making blocks movable so that they can capture things like unique_ptr<> and still be moved off the stack 2) making @property declarations work with move-only types like unique_ptr<> 3) enabling std::weak_ptr<> to weakly store an objc pointer