similar to: [LLVMdev] Bug in Support/Allocator.h

Hi all (No idea if I have the correct audience. Please CC more people as needed). I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. The problem is that lld requests that we StringRef::copy an empty string. This passes a length of 0 to a BumpPtrAllocator. The BumpPtrAllocator happened to not have anything allocated yet so the CurPtr is nullptr, but given that we need 0 space we think

> On Mar 22, 2016, at 5:35 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in

Ok, here is the patch again... I also included fixes for the bits that originally gave my mailer fits... Two votes for orange, so I went with orange... Doing diffs in .: --- ./lib/AsmParser/LLLexer.cpp.~1~ 2007-12-14 22:09:06.000000000 -0800 +++ ./lib/AsmParser/LLLexer.cpp 2007-12-15 13:02:47.000000000 -0800 @@ -54,7 +54,7 @@ static uint64_t HexIntToVal(const char * Result +=

Newer g++ compilers can emit: /Volumes/mrs5/net/llvm/llvm/llvm/lib/AsmParser/LLLexer.cpp: In member function 'int llvm::LLLexer::LexAt()': /Volumes/mrs5/net/llvm/llvm/llvm/lib/AsmParser/LLLexer.cpp:287: warning: suggest a space before ';' or explicit braces around empty body in 'for' statement /Volumes/mrs5/net/llvm/llvm/llvm/lib/AsmParser/LLLexer.cpp: In member

On Dec 15, 2007, at 2:13 AM, Duncan Sands wrote: > Hi, > >> - for (++CurPtr; isdigit(CurPtr[0]); ++CurPtr); >> + for (++CurPtr; isdigit(CurPtr[0]); ++CurPtr) ; > > personally I like > > for (++CurPtr; isdigit(CurPtr[0]); ++CurPtr) {} > > better since it is more explicit. I think the bikeshed should be orange: for (++CurPtr; isdigit(CurPtr[0]);

Am 28.08.2011 20:02, schrieb geovanisouza92 at gmail.com: > Hi, Jo! > > I'm trying create a new programming language, and I want that it have > Unicode support (support for read and manipulate rightly the source-code and > string literals). > > But, in addition, my programming language supports "string interpolation" > string, and in these interpolations, tiny

Hi, > - for (++CurPtr; isdigit(CurPtr[0]); ++CurPtr); > + for (++CurPtr; isdigit(CurPtr[0]); ++CurPtr) ; personally I like for (++CurPtr; isdigit(CurPtr[0]); ++CurPtr) {} better since it is more explicit. Ciao, Duncan.

On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. > > The problem is that lld requests that we StringRef::copy an empty string. > This passes a length of 0 to a BumpPtrAllocator. The

On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. > > The problem is that lld requests that we StringRef::copy an empty string. > This passes a length of 0 to a

FWIW, I agree with Mehdi that we should just assert that our types don't get called with size zero. That said, I don't think we can be terribly cavalier with what we expect from standard allocator types, operator new, or malloc. And so I would expect LLVM_ATTRIBUTE_RETURNS_NOALIAS to not imply NONNULL, and while it seems reasonable to put NONNULL on *our* allocate function because of the

Hi, all Recently I'm trying to use LLVM PGO and autoFDO. However I have some problems in the process. LLVM source code is updated on April 9th. Operating system is SUSE x86_64 1. Problems in instrumentation based PGO: clang -O2 -fprofile-instr-generate test.c -o a.out ./a.out (then default.profraw is generated) clang -O2 -fprofile-instr-use=default.profraw test.c -o a.out

> On Mar 22, 2016, at 5:39 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Mar 22, 2016, at 5:35 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> >> >> On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at

On Sat, Oct 15, 2011 at 9:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > >> I recently updated my version of LLVM from revision 140108 to 142082, and >> several things broke, most of which were easily fixed. However, I'm now >> getting a "pure virtual method called"

> On Mar 28, 2016, at 6:02 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Mar 28, 2016, at 3:12 PM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote: >> >> FWIW, I agree with Mehdi that we should just assert that our types don't get called with size zero. > Yeah, I agree. I’ve

Interestingly, I also get a similar error in a different executable (my unittest): pure virtual method called terminate called without an active exception 0 tartc 0x00000001010a8265 PrintStackTrace(void*) + 53 1 tartc 0x00000001010a88cc SignalHandler(int) + 364 2 libSystem.B.dylib 0x00007fff831341ba _sigtramp + 26 3 libSystem.B.dylib 0x7261742e65637365 _sigtramp +

> On Mar 28, 2016, at 3:12 PM, Chandler Carruth <chandlerc at google.com> wrote: > > FWIW, I agree with Mehdi that we should just assert that our types don't get called with size zero. Yeah, I agree. I’ve tried running the tests with the assert in place and there’s about 1000 failures across llvm/clang. I’ll see what I can fix as I would like to get these to behave. There

On 03/29/2016 01:59 PM, Pete Cooper via llvm-dev wrote: > >> On Mar 28, 2016, at 6:02 PM, Pete Cooper via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >>> >>> On Mar 28, 2016, at 3:12 PM, Chandler Carruth <chandlerc at google.com >>> <mailto:chandlerc at google.com>> wrote:

> On Mar 29, 2016, at 4:45 PM, Philip Reames <listmail at philipreames.com> wrote: > > > > On 03/29/2016 01:59 PM, Pete Cooper via llvm-dev wrote: >> >>> On Mar 28, 2016, at 6:02 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>>> >>>> On Mar 28, 2016, at

Hi Djordje, On Wed, Sep 9, 2020 at 7:52 AM Djordje Todorovic <Djordje.Todorovic at syrmia.com> wrote: > Using entry-values ('callee' side of the feature) is not enough in any case. It is always connected to the call-site-param (function arguments but we call it call-site-params; 'caller' side of the feature) debug info. I believe that there are call-site-params that could

Hi Djordje, [Late reply as I was away, alas], For the example in https://reviews.llvm.org/D85012 , I'm not sure that just using an entry value is correct. The reason why the dbg.values for arguments are set to undef is not because the value can't be described, it's because deadargelim changes all the call sites to pass in 'undef', which I believe makes the value unrecoverable