search for: unique_ptrs

Michael, In lld, we have places that used nested a ErrorOr<std::unique_ptr<xx>> and I often hit compiler errors that require breaking up expressions to work around. Do you have suggestions on how to code the following simple examples to not error? Can some of these be fixed in ErrorOr.h? Or am I totally not getting something? -Nick struct Foo { void doit(); };

On Nov 21, 2013, at 4:07 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Nov 21, 2013 at 3:57 PM, Nick Kledzik <kledzik at apple.com> wrote: > Michael, > > In lld, we have places that used nested a ErrorOr<std::unique_ptr<xx>> and I often hit compiler errors that require breaking up expressions to work around. Do you have

Anyone have opinions on whether the cast machinery should be taught to handle unique_ptr? Presumably that'd involve cast, etc, returning raw pointers when it was passed references to unique_ptr, which might be surprising/error-prone? But the only errors would be: 1) double delete - if the result of the cast was used to take ownership because the caller didn't realize there was a

On Thu, Nov 21, 2013 at 3:57 PM, Nick Kledzik <kledzik at apple.com> wrote: > Michael, > > In lld, we have places that used nested a ErrorOr<std::unique_ptr<xx>> and > I often hit compiler errors that require breaking up expressions to work > around. Do you have suggestions on how to code the following simple > examples to not error? Can some of these be

On Thu, Nov 21, 2013 at 4:33 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Nov 21, 2013, at 4:07 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > > On Thu, Nov 21, 2013 at 3:57 PM, Nick Kledzik <kledzik at apple.com> wrote: > >> Michael, >> >> In lld, we have places that used nested a

...ctStreamer() { delete &Assembler->getBackend(); delete &Assembler->getEmitter(); delete &Assembler->getWriter(); delete Assembler; } In the depths of a fever from a head-cold, I snapped. I've been hacking MC to convert these raw pointers (and worse: references!) to unique_ptrs (apologies to people whose backbends I've broken), but I hit a big blocker when I get to Target in "llvm/Support/TargetRegistry.h". Target vends MC objects by calling registered ctor functions. E.g.: MCAsmBackend *createMCAsmBackend(const MCRegisterInfo &MRI,...

Hello, I am trying to run this basic C++ hello-world code in my iOS app that has LLVM libraries linked in (the app runs on the actual device - iPad Pro, iOS 13.4.1). #include <iostream> int main (int argh, char *argv[]) { std::cout << "Hello World!" << std::endl; return 0; } So below is the break down of the steps that I do: First I compile this code to an

Hi, I have been using LLVM+Clang in my project for some time and it has been working just fine up to now (I am currently using version 3.5.1). However, with version 3.6 having just been released, I thought I would give it a try and update my code to use MCJIT rather than the now discontinued JIT. Well, this proved to be a relatively smooth process, and everything is now working fine on

In lld we have a Reader class which is a factory that takes .o file(s) and produces an in memory lld::File object(s). But in doing so, there could be I/O errors (file not readable) or file may be malformed. We are also using C++11 in lld, so we use std::unique_ptr for managing object ownership. The Reader class currently has an interface that can be simplified down to: virtual error_code

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

On Wed, Jun 20, 2012 at 12:36 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Jun 20, 2012, at 12:28 AM, Chandler Carruth wrote: >> On Tue, Jun 19, 2012 at 11:18 AM, Jeffrey Yasskin <jyasskin at google.com> wrote: >> On Jun 18, 2012 1:24 PM, "Nick Kledzik" <kledzik at apple.com> wrote: >> > >> > On Jun 16, 2012, at 3:51 PM, Chris

Sorry, I am using CMake+JOM or CMake+Ninja, if Ninja is available on the developer’s machine. Either way, it fails in both cases with a message similar to the one I included below (which was obtained using CMake+Ninja). Just in case, my (current) CMakeLists.txt file can be found at here

On Tue, Jun 19, 2012 at 11:18 AM, Jeffrey Yasskin <jyasskin at google.com>wrote: > On Jun 18, 2012 1:24 PM, "Nick Kledzik" <kledzik at apple.com> wrote: > > > > On Jun 16, 2012, at 3:51 PM, Chris Lattner wrote: > > > On Jun 15, 2012, at 3:48 PM, Nick Kledzik wrote: > > > > > >> In lld we have a Reader class which is a factory that

Hi Lang, Please see below is the trace. -- Thanks, Igor *2020-06-06 12:05:21.016705-0400 CppDevProCompiler[6613:3000073] Running...* *jitLink_MachO: magic = 0xfeedfacf, identifier = "llvm-link.submodule-jitted-objectbuffer"* *jitLink_MachO: cputype = 0x0100000c, cpusubtype = 0x00000000* *Creating normalized sections...* * __text: 0x0000000000000000 -- 0x0000000000000064, align:

On Jun 20, 2012, at 12:28 AM, Chandler Carruth wrote: > On Tue, Jun 19, 2012 at 11:18 AM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Jun 18, 2012 1:24 PM, "Nick Kledzik" <kledzik at apple.com> wrote: > > > > On Jun 16, 2012, at 3:51 PM, Chris Lattner wrote: > > > On Jun 15, 2012, at 3:48 PM, Nick Kledzik wrote: > > > > >

On Fri, Jul 18, 2014 at 12:06 PM, Jordan Rose <jordan_rose at apple.com> wrote: > I don't have much to add here besides +1. I think using std::unique_ptr > even for create* functions/methods is the right way to go. +1 smart pointers here are a win in terms of safety and self-documentation. I don't see why create* factories should be treated differently. Eli >

Hi Dave, Yep. This is JITLink specific, so we could only have observed it on MachO x86-64 or arm64 until recently. It takes a little bit of poking to get IR to produce a zero-lengh section on MachO, but not much. Jared Wyles recently contributed an initial JITLink ELF implementation, so the fix seems timely -- we might have been about to see more of it. -- Lang. On Fri, Jun 19, 2020 at 4:02 PM

On Jun 15, 2012, at 3:48 PM, Nick Kledzik wrote: > In lld we have a Reader class which is a factory that takes .o file(s) and produces an in memory lld::File object(s). But in doing so, there could be I/O errors (file not readable) or file may be malformed. We are also using C++11 in lld, so we use std::unique_ptr for managing object ownership. > > The Reader class currently has an

Hi On Windows 10 when using a debug build of LLVM 10, I get this assertion failure: Assertion failed: (KV.second.getFlags() & ~WeakFlags) == (I->second & ~WeakFlags) && "Resolving symbol with incorrect flags", file C:\work\github\llvm-10.0.0.src\lib\ExecutionEngine\Orc\Core.cpp, line 450 The same failure occurred in LLVM 9 too: Assertion failed: I->second ==

Ok. I can make a copy of the unique_ptr before moving it into the builder's constructor and use the copy later on. It is confusing to require a unique_ptr. Frank On 09/14/2016 12:11 PM, Frank Winter via llvm-dev wrote: > I am constructing the engine builder in the following way: > > llvm::SMDiagnostic Err; > unique_ptr<Module> Mod = getLazyIRFileModule("f.ll",