search for: curptr

...&Str) { if (Str.empty()) return; - + char *Buffer = &Str[0], *EndBuffer = Buffer+Str.size(); char *BOut = Buffer; for (char *BIn = Buffer; BIn != EndBuffer; ) { @@ -168,9 +168,9 @@ int LLLexer::getNextChar() { // a random nul in the file. Disambiguate that here. if (CurPtr-1 != CurBuf->getBufferEnd()) return 0; // Just whitespace. - + // Otherwise, return end of file. - --CurPtr; // Another call to lex will return EOF again. + --CurPtr; // Another call to lex will return EOF again. return EOF; case '\n': case '...

...it goes with the for. Thoughts? Index: lib/AsmParser/LLLexer.cpp =================================================================== --- lib/AsmParser/LLLexer.cpp (revision 45058) +++ lib/AsmParser/LLLexer.cpp (working copy) @@ -284,7 +284,7 @@ // Handle GlobalVarID: @[0-9]+ if (isdigit(CurPtr[0])) { - for (++CurPtr; isdigit(CurPtr[0]); ++CurPtr); + for (++CurPtr; isdigit(CurPtr[0]); ++CurPtr) ; uint64_t Val = atoull(TokStart+1, CurPtr); if ((unsigned)Val != Val) @@ -335,7 +335,7 @@ // Handle LocalVarID: %[0-9]+ if (isdigit(CurPtr[0])) { - for (++CurPtr; is...

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])...

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.

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

...ofraw test.c -o a.out error: pgo data file has malformed function entry I found that the run-time function "writeFile" in InstrProfilingFile.cpp didn't write '\n'. But when parsing the profile data, in CodeGenPGO.cpp line 56, it tried to find '\n' like below: CurPtr = strchr(CurPtr, '\n'); if (!CurPtr) { ReportBadPGOData(CGM, "pgo data file has malformed function entry"); return; } 2. Problems in autoFDO: Actually the problem happened in using create_llvm_prof, transformation is failed. clang -O2 -g test.c -o a.out per...

Hi, llvm::BumpPtrAllocatorImpl::Reset() looks like it has a bug. There is this check at the top: if (Slabs.empty()) return; But what if you don't have any normal Slabs allocated but only CustomSizedSlabs. I think this should be: if (Slabs.empty() && CustomSizedSlabs.empty()) return;

...dience. 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 we have enough space and return an allocation of size 0 at address nullptr. This therefore returns nullptr from Allocate, but that method is marked with LLVM_ATTRIBUTE_RETURNS_NONNULL and LLVM_ATTRIBUTE_RETURNS_NOALIAS, both of which aren’t true...

...locator clobbering things, and I feel the below is a more general solution. I'd like to use this (contrived) code as an illustrative example: void ext(long); void foo(long *ptr, long bar, long baz) { for (long i = 0; i < bar; ++i) { long index = baz + i; long *curptr = &ptr[index]; ext(*curptr); } } All it does is iterate over a loop, loading values from an offset into a pointer. I've compiled this at -O2, and then given it an additional run of -loop-reduce with opt [0]. During optimisation, LLVM rightly identifies that the 'baz...

...ore 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 we have enough space and return an allocation of size 0 at address nullptr. This therefore returns nullptr from Allocate, but that method is marked with LLVM_ATTRIBUTE_RETURNS_NONNULL and LLVM_ATTRIBUTE_RETURNS_NOALIAS, both of which aren’t true...

...ple 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 we have enough space and return an > allocation of size 0 at address nullptr. This therefore returns nullptr > from Allocate, but that method is marked > with LLVM_ATTRIBUTE_RETURNS_NONNULL and LLVM_ATTRIBUTE_RETURNS_NOALIAS, > b...

...ple 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 we have enough space and return an > allocation of size 0 at address nullptr. This therefore returns nullptr > from Allocate, but that method is marked with LLVM_ATTRIBUTE_RETURNS_NONNULL > and LLVM_ATTRIBUTE_RETURNS_NOALIAS, both o...

...eded). >> >> 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 we have enough space and return an allocation of size 0 at address nullptr. This therefore returns nullptr from Allocate, but that method is marked with LLVM_ATTRIBUTE_RETURNS_NONNULL and LLVM_ATTRIBUTE_RETURNS_NOALIAS, both of which aren’t true...

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

...>> 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 we have enough space >> and return an allocation of size 0 at address nullptr. This therefore >> returns nullptr from Allocate, but that method is marked >> with LLVM_ATTRIBUTE_RETURNS_NONNULL and LLVM_ATTRIBUTE_RETURNS...

...gt; >>> 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 we have enough space and return an allocation of size 0 at address nullptr. This therefore returns nullptr from Allocate, but that method is marked with LLVM_ATTRIBUTE_RETURNS_NONNULL and LLVM_ATTRIBUTE_RETURNS_NOALIAS, both of which aren’t true...

...;>> 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 we have enough space and return an allocation of size 0 at address nullptr. This therefore returns nullptr from Allocate, but that method is marked with LLVM_ATTRIBUTE_RETURNS_NONNULL and LLVM_ATTRIBUTE_RETURNS_NOALIAS, both of which aren’t true...

...>> 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 we have enough space and return an >> allocation of size 0 at address nullptr. This therefore returns nullptr >> from Allocate, but that method is marked with LLVM_ATTRIBUTE_RETURNS_NONNULL >> and LLVM_ATTRIBUTE_RETURNS...

...gt;> 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 we have enough space >>>>> and return an allocation of size 0 at address nullptr. >>>>> This therefore returns nullptr from Allocate, but that >>>>>...

...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 we have enough space and return an allocation of size 0 at address nullptr. This therefore returns nullptr from Allocate, but that method is marked with LLVM_ATTRIBUTE_RETURNS_NONNULL and LLVM_ATTRIBUTE...