search for: make_shar

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 <boost/shared_ptr.hpp> #include <boost/make_shared.hpp> #include <boost/enable_shared_from_this.hpp> #ifndef prefix #define prefix std #endif class foo: prefix::enable_shared_from_this<foo> { public: prefix::shared_ptr<foo> get_sptr() { return shared_from_this(); } }; int main() { auto a =...

...IT.h index 47a2acc4d7e..41a7c99413b 100644 --- a/tools/lli/OrcLazyJIT.h +++ b/tools/lli/OrcLazyJIT.h @@ -62,7 +62,11 @@ public:               bool InlineStubs)        : TM(std::move(TM)), DL(this->TM->createDataLayout()),         CCMgr(std::move(CCMgr)), -       ObjectLayer([]() { return std::make_shared<SectionMemoryManager>(); }), +       ObjectLayer([]() { return std::make_shared<SectionMemoryManager>(); }, +              [this](llvm::orc::RTDyldObjectLinkingLayerBase::ObjHandleT, +                     const llvm::orc::RTDyldObjectLinkingLayerBase::ObjectPtr &obj, +            ...

...gt; >> 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 <boost/shared_ptr.hpp> >> #include <boost/make_shared.hpp> >> #include <boost/enable_shared_from_this.hpp> >> >> #ifndef prefix >> #define prefix std >> #endif >> >> class foo: >> prefix::enable_shared_from_this<foo> >> { >> public: >> prefix::shared_ptr<...

On Tue, Apr 4, 2017 at 12:36 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > On 2017-Apr-04, at 12:12, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>

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 traffi...

...be easily adopted by std::shared_ptr or > std::unique_ptr as needed, They'd actually only ever need to return std::unique_ptr. std::shared_ptrs can be constructed from xvalue std::unique_ptrs without any overhead: std::unique_ptr<T> create(); std::shared_ptr<T> x = create(); (make_shared has a small allocation (and destruction) benefit that might sometimes be useful to exploit, of course, but you don't benefit from that with raw new either, so unique_ptr is no /worse/ off than a raw implicitly-owning pointer in that regard) > so there's no benefit in enforcing smart p...

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

Variadic templates themselves don't avoid the copy, but combined with perfect forwarding you should be doing well (see, for example, make_shared) From: Jordy Rose Sent: 8/21/2011 10:34 AM To: Carlo Alberto Ferraris Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Accessing arguments in a caller What I can think of: 1. Anonymous struct, to avoid a copy. 2. Use stdarg.h...dangerous but accomplishes what you're looking for. 3. Split up...

...o create the query, but it always has Segmentation fault (core dumped). It looks like some pointers are double freed. This is the function that we use to create xapian-query. std::shared_ptr<Xapian::Query> constructQuery() { Xapian::Query black_list("BLt1"); return std::make_shared<Xapian::Query>(Xapian::Query::OP_AND_NOT, Xapian::Query::MatchAll, black_list); } I have wrote a demo to reproduce our problems, you can click this link for the detail. https://github.com/xiangqianzsh/xapian_leaning/tree/master/matchall_coredump How we solve this problems?

...ype(DumpObjectsLayer), SimpleCompiler> CompileLayer; > > public: >   using ModuleHandle = decltype(CompileLayer)::ModuleHandleT; > >   KaleidoscopeJIT() >       : TM(EngineBuilder().selectTarget()), DL(TM->createDataLayout()), >         ObjectLayer([]() { return > std::make_shared<SectionMemoryManager>(); }), >         DumpObjectsLayer(ObjectLayer, &KaleidoscopeJIT::dumpObject), >         CompileLayer(DumpObjectsLayer, SimpleCompiler(*TM)) { >     llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr); >   } > > Hope this helps! > > Ch...

...TM;constDataLayoutDL;RTDyldObjectLinkingLayerObjectLayer;IRCompileLayer<decltype(ObjectLayer),SimpleCompiler>CompileLayer;public:usingModuleHandle=decltype(CompileLayer)::ModuleSetHandleT;GenericJIT():TM(EngineBuilder().selectTarget()),DL(TM->createDataLayout()),ObjectLayer([](){returnstd::make_shared<SectionMemoryManager>();}),CompileLayer(ObjectLayer){llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr);}TargetMachine&getTargetMachine(){return*TM;}ModuleHandleaddModule(std::unique_ptr<Module>M){// Build our symbol resolver:// Lambda 1: Look back into the JIT itself to...

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

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 Christian Your use case seems to have similar requirements as remote JITing in ORC. So far I haven't used that part myself and I am sure Lang can tell you much more about it. However, this comment on the RemoteObjectClientLayer class sounds promising for your questions (1) and (2): /// Sending relocatable objects to the server (rather than fully relocated /// bits) allows JIT'd code

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