similar to: ArrayRef vs SmallVectorImpl

+1, totally a bug. That’s the domain of MutableArrayRef. -Chris > On Oct 1, 2017, at 6:52 AM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > +1 seems like a bug > > On Sun, Oct 1, 2017 at 12:35 AM Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > It wraps a constant T* and a size_t, so

It wraps a constant T* and a size_t, so I'm surprised std::sort works. It shouldn't. On Sep 30, 2017 5:22 PM, "Daniel Berlin via llvm-dev" < llvm-dev at lists.llvm.org> wrote: It seems like ArrayRefs are supposed to be immutable ( However, as far as i can tell, the iterators are defined wrong to make this true. While ArrayRef<int> Foo(Something); Foo[0] = 5; will

Some background: A while back while working on code to read / write PDB files, I came up with Yet Another Stream Abstraction. Note that LLVM already has a few. Off the top of my head, theres: 1) `MemoryBuffer` and its associated class hierarchy 2) `raw_ostream` and it's associated classes. 3) `DataExtractor` which is used for reading from a StringRef. There's probably more, and

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: >>

On Mon, Nov 16, 2020 at 12:55 PM David Blaikie <dblaikie at gmail.com> wrote: > I will say I'm not a huge fan of adding even more names for things in > this fairly core/common use case (now we'll have even more vector > names to pick from) - can we use default template arguments so we can > write SmallVector<T> instead of SmallVector<T, N> and would that >

I've had the same thought but never got around to trying to implement it. Does everything compile for you if it's protected? If so, then a patch would probably be happily accepted ------------------------------ From: Vane, Edwin Sent: 1/20/2012 7:13 AM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Public SmallVectorImpl constructor? Hi all, Just finished debugging a memory

On Fri, Aug 22, 2014 at 11:22 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2014-Aug-22, at 10:43, David Blaikie <dblaikie at gmail.com> wrote: >> >> Yep - the convenience of one-element->ArrayRef is "cute" at best, I >> think. Having to wrap it doesn't seem detrimental. Would have to look >> at some numbers,

Hi, I think I ran into a rather subtle bug inside llvm/ADT/ArrayRef.h which only shows up when compiling the code with GCC-4.8 with switched-off optimizations. (Both clang and GCC-4.7 don't trigger the bug.) I already filed a bug against GCC-4.8 which was rejected by the GCC-folks as being invalid, because the code (basically ArrayRef.h) "is doing something bad - it's retaining a

On Mon, Nov 16, 2020 at 2:12 PM David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Nov 16, 2020 at 1:55 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > > On Mon, Nov 16, 2020 at 12:55 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> > >> I will say I'm not a huge fan of adding even more names for things in > >> this fairly

On Fri, Aug 22, 2014 at 10:16 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> On 2014-Aug-21, at 10:39, David Blaikie <dblaikie at gmail.com> wrote: >> >> On Thu, Aug 21, 2014 at 10:34 AM, Reid Kleckner <rnk at google.com> wrote: >>> Is there some way we can get lifetime extension of temporaries to kick in >>> here? >>

Analyzing why GCC failed to build LLVM recently, one root cause lies in definition of ArrayRef: // ArrayRef.h: ArrayRef(const T &OneElt) : Data(&OneElt), Length(1) {} Here address of const reference is taken and stored to an object. It is believed that live range of const reference is only at the function call site, escaping of its address to an object with a longer live range is invalid.

It seems like ArrayRefs are supposed to be immutable ( However, as far as i can tell, the iterators are defined wrong to make this true. While ArrayRef<int> Foo(Something); Foo[0] = 5; will give a compile time error. something like: ArrayRef<int> Foo(Something); std::sort(Foo.begin(), Foo.end()); Will work fine. Is this expected? (FWIW: I expected this to only work with a

Hi, Why is StringRef not an ArrayRef<char> extension? That might simplify some interfaces. Cheers, Paweł -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151105/ef56dcdc/attachment.html>

On Thu, Aug 21, 2014 at 10:34 AM, Reid Kleckner <rnk at google.com> wrote: > Is there some way we can get lifetime extension of temporaries to kick in > here? Nope - since the temporary is a subexpression - not the thing being declared. > > > On Thu, Aug 21, 2014 at 8:05 AM, David Blaikie <dblaikie at gmail.com> wrote: >> >> Yeah - I suspect there are just

David Blaikie <dblaikie at gmail.com> writes: > I seem to recall discussing this before - is there an existing llvm > bug filed, another email thread or something (or perhaps it was just > an IRC conversation)? It would be good to keep all the discussion > together or at least reference the prior (llvm community) discussion. I'm not sure if it's been discussed before,

Yeah - I suspect there are just too many cases where we use this ctor correctly: where the ArrayRef is only a temporary to a function call. Perhaps this is a problem for which the best solution is a clang-tidy checker - though I'm not sure if we have good integration there yet. (& yes, Andreas, that looks like the previous thread - thanks!) On Thu, Aug 21, 2014 at 5:09 AM, Andreas Weber

On Mon, Nov 16, 2020 at 4:10 PM David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Nov 16, 2020 at 2:44 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > > > > > On Mon, Nov 16, 2020 at 2:12 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> > >> On Mon, Nov 16, 2020 at 1:55 PM Mehdi AMINI <joker.eph at

While debugging a bootstrap problem, I noticed that SmallVector stores one element in SmallVectorImpl and N - 1 in SmallVector. It also assumes that all elements are continuous in memory. Does C++ makes any guaranties about the relative memory position of a base and parent classes? I haven't studied it a lot, maybe we can keep N elements in SmallVector and pass the pointer to SmallVectorImpl

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

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