search for: arrayref

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

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, though (if we could easily gather the number of >> instances of this - I'm not sure of the easiest way to do that, given >> the build system li...

...> >> Nope - since the temporary is a subexpression - not the thing being declared. >> > > >>>>>>> We could move this ctor into a factory function (and/or just make the >>>>>>> CTor >>>>>>> private and friend the makeArrayRef helper for this case) to make it >>>>>>> more >>>>>>> obvious/easier to find bad call sites. But it would be helpful to >>>>>>> have >>>>>>> the >>>>>>> context of the prior discussion to contin...

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

...e? 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 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!) &gt...

...used. > Have you tried applying your suggested patch? I assume you meant to suggest > replacing/modifying the existing ctor (to take non-const ref) rather than > adding another? > > I'd assume that causes a lot of build failures as we probably rely on binding > temporaries to ArrayRef's in many places correctly (most ArrayRef's are > temporaries, not local variables). > > I think in the previous discussion I suggested we might just want to make a > practice of treating named/local (not parameter) ArrayRef's with greater > suspicion, the same way we do...

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

It is suggested in the documentation that if you would have declared a function parameter as SmallVector<Foo,N>&, it is better to instead declare it as SmallVectorImpl<Foo>&. This makes sense, but it seems to me that it is better still to declare it as ArrayRef<Foo>; a quick test suggests it compiles to the same (highly efficient) code, and adds a bit more flexibility in case e.g. you someday want to pass a std::vector. By that logic, there is never any reason to take a SmallVectorImpl, because ArrayRef is strictly better. Am I missing anything? --...

...uot;hello world!\n"); } And here's the error: g++ e.cpp /Developer/Platforms/iPhoneOS.platform/Developer/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin10/4.2.1/libllvmgcc.dylib Undefined symbols for architecture x86_64: "llvm::ConstantExpr::getGetElementPtr(llvm::Constant*, llvm::ArrayRef<llvm::Value*>, bool)", referenced from: llvm::ConstantExpr::getInBoundsGetElementPtr(llvm::Constant*, llvm::ArrayRef<llvm::Value*>)in ccFB7xjg.o "llvm::GetElementPtrInst::getIndexedType(llvm::Type*, llvm::ArrayRef<llvm::Value*>)", referenced from: llvm...

Hi all- I am mostly doing work in Clang (and am new there), so I apologize if this isn't the proper place to mention this. I appreciate guidance in advance. I was looking into some of the unit tests, and noticed that the ArrayRefTest.InitializerList, and thus the InitializerList constructor of ArrayRef (under normal use-case) hit undefined behavior. The test does the following: ArrayRef<int> A = { 0, 1, 2, 3, 4 }; for (int i = 0; i < 5; ++i) EXPECT_EQ(i, A[i]); For those unfamiliar, ArrayRef is a T* Data/...

Does anybody else have an opinion on this issue? I'm planning to submit a patch which would add a new get method for ConstantDataVector taking an ArrayRef<Constant*> and use that in the few places in constant propagation where convertToFloat is used. Let me know if you think there is a more obvious way to do it. Right now the only way to create a ConstantDataVector are those method: /// get() constructors - Return a constant with vector t...

+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: &g...

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 give a compile time error. something like: ArrayRef<int> Foo(Something); std::sort(Foo.begin(), Foo.end()); Will wo...

I agree that the ArrayRef is likely the issue. I've debugged a crash caused by a temporary ArrayRef like that a couple times. Either do what David suggested or use a normal array: Metadata *mdArray[] = {ConstantInt::get(Int64Ty, 0), newMD}; ~Craig On Thu, Apr 30, 2020 at 9:56 AM David Blaikie via llvm-dev < llv...

...efully this is clear enough. -----Original Message----- From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Wednesday, August 24, 2016 10:55 AM To: Keane, Erich <erich.keane at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Pointer to temporary issue in ArrayRefTest.InitializerList > On Aug 24, 2016, at 10:48 AM, Keane, Erich via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all- > I am mostly doing work in Clang (and am new there), so I apologize if this isn't the proper place to mention this. I appreciate guidance in advan...

...; And here's the error: > > g++ e.cpp > /Developer/Platforms/iPhoneOS.platform/Developer/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin10/4.2.1/libllvmgcc.dylib > Undefined symbols for architecture x86_64: > "llvm::ConstantExpr::getGetElementPtr(llvm::Constant*, > llvm::ArrayRef<llvm::Value*>, bool)", referenced from: > llvm::ConstantExpr::getInBoundsGetElementPtr(llvm::Constant*, > llvm::ArrayRef<llvm::Value*>)in ccFB7xjg.o > "llvm::GetElementPtrInst::getIndexedType(llvm::Type*, > llvm::ArrayRef<llvm::Value*>)", referen...

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>

Hello, I am editing the LowerTypeTests pass in LLVM, and part of my additions include the following 3 lines of code: // newTypeName is a std::string MDString* newMD = MDString::get(M.getContext(), newTypeName); ArrayRef<Metadata*> mdArray {ConstantInt::get(Int64Ty, 0), newMD}; auto* node = MDTuple::get(M.getContext(), mdArray); Thus far, I have been developing on a version of Clang with debugging symbols enabled, and this code has worked. However, on the Release+Asserts version, the third line results in a...

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

...om downstream fork of LLD: https://github.com/zig-lang/zig/commit/41da9fdb69065082f57c604b12eb02ca166cb18d diff --git a/lld/COFF/Driver.cpp b/lld/COFF/Driver.cpp index 854c3e69098..8b17f039870 100644 --- a/lld/COFF/Driver.cpp +++ b/lld/COFF/Driver.cpp @@ -1030,7 +1030,7 @@ void LinkerDriver::link(ArrayRef<const char *> ArgsArr) { if (!Args.hasArgNoClaim(OPT_INPUT)) { fixupExports(); createImportLibrary(/*AsLib=*/true); - exit(0); + return; } // Handle /delayload @@ -1122,7 +1122,7 @@ void LinkerDriver::link(ArrayRef<const char *> ArgsArr) { // This is useful...