similar to: [LLVMdev] SmallPtrSet Iterator Behavior

On Tue, 4 Dec 2007, David Greene wrote: > What are the rules regarding iterator stability for SmallPtrSet? > I'm running into a problem where erasing an element seems > to invalidate iterators that are not pointing at the erased element. Interesting question. > Specifically, the set is in small mode, I advance an iterator to the last > element in the set (not end(), but one

On Tuesday 04 December 2007 13:28, Chris Lattner wrote: > > Specifically, the set is in small mode, I advance an iterator to the last > > element in the set (not end(), but one before) and then erase the > > second-to-last element. I understand that the last element will replace > > Right, deleting an element will invalidate any iterators past it, just > like a vector.

I'm using the various LLVM set containers (SmallPtrSet and the like), and something I need to do fairly often is iterate over a set, removing all elements that don't pass a test. Now, doing this on lists is fairly straightforward using the "it = container.erase(it)" idiom so as to keep the iterator valid during the delete. However, the set classes don't have a means to both

On Jul 9, 2011, at 11:30 AM, Talin wrote: > I'm using the various LLVM set containers (SmallPtrSet and the like), and something I need to do fairly often is iterate over a set, removing all elements that don't pass a test. Now, doing this on lists is fairly straightforward using the "it = container.erase(it)" idiom so as to keep the iterator valid during the delete. However,

On May 27, 2008, at 2:01 PM, Dale Johannesen wrote: > On May 27, 2008, at 1:40 PM, Mike Stump wrote: >> >> From n2461: >> >>> 8 The insert members shall not affect the validity of iterators and >>> references to the container, and the erase members shall invalidate >>> only iterators and references to the erased elements. >> >> Pretty

On May 23, 2008, at 10:19 AM, Dale Johannesen wrote: > On May 23, 2008, at 4:10 AM, Nicolas Capens wrote: > >> I updated from 2.2 to the latest SVN head and I now get a debug >> assert in BranchFolder::RemoveBlocksWithHash: “vector iterators >> incompatible”. I’m using Visual C++ 2005. I think this is the >> culprit code: >> >>

On May 27, 2008, at 1:40 PM, Mike Stump wrote: > On May 23, 2008, at 10:19 AM, Dale Johannesen wrote: >> On May 23, 2008, at 4:10 AM, Nicolas Capens wrote: >> I also am not a STL guru; the standard says erase >> "Invalidates all the iterators and references after the point of the >> erase" >> which is not wonderfully worded, but I take it to mean an

On May 23, 2008, at 4:10 AM, Nicolas Capens wrote: > Hi all, > > I updated from 2.2 to the latest SVN head and I now get a debug > assert in BranchFolder::RemoveBlocksWithHash: “vector iterators > incompatible”. I’m using Visual C++ 2005. I think this is the > culprit code: > > MergePotentials.erase(CurMPIter); > if (CurMPIter==B) > break; >

hi, On Sat, Mar 17, 2012 at 2:11 AM, Andrew Trick <atrick at apple.com> wrote: > Yep. I normally do that. I was under some strange impression last night that SmallPtrSetImpl wasn't a template. The patch is incorrect because the SmallPtrSetImpl is neither a template nor has an "insert" function... After a detailed look at the header of SmallPtrSet, I found that the

Hi all, I updated from 2.2 to the latest SVN head and I now get a debug assert in BranchFolder::RemoveBlocksWithHash: "vector iterators incompatible". I'm using Visual C++ 2005. I think this is the culprit code: MergePotentials.erase(CurMPIter); if (CurMPIter==B) break; The erase clears the _Mycont field (i.e. the iterator's container), while the ==

On May 7, 2011, at 1:00 PM, llvmdev-request at cs.uiuc.edu wrote: > > Hi Justin, > >> I have a call to ReplaceInstWithInst(Instruction *From, Instruction *To) inside of a for loop iterating through a BasicBlock::iterator. On the very next pass after I replace the instruction, the iterator appears to be invalidated. Is this supposed to happen or am I doing something silly? Is

for (BasicBlock::reverse_iterator I = BB.rbegin(), E = BB.rend(); I != E; ) { Instruction& inst = *I; ++I; <-- iterator should be advanced to the previous instruction // Happens to be an Instruction::SExt. // Works fine if I iterate forwards if (isInstructionTriviallyDead(&inst, TLI)) inst.eraseFromParent(); } Sorry for the inexperienced question, but

Thank you for the idea! Could you please explain it? If I’m not mistaken, you advise to insert the unknown insts of an every AS from AliasSetTracker::add(const AliasSetTracker &AST) into a smallptrset and consequently append it to merged alias sets from AliasSetTracker::findAliasSetForUnknownInst. I think that Philip proposed something similar to your approach in

Nice idea. Please also try using SmallPtrSet (with a sufficiently large size) instead of std::set for traversal after everything is working. Using std::set can really hurt compile time in case of large basic block numbers. Is there a way to dynamically adjust "SmallSize" based on number of basic blocks in the function? Evan On Jun 21, 2007, at 10:20 PM, Fernando Magno Quintao

tl;dr: I think we have too many different set classes. They have incompatible APIs and surprising behavior. I think we can reduce their number substantially. Dear all, The following is a subset of the set classes we have in ADT: * DenseSet * SmallDenseSet (https://reviews.llvm.org/D25628) * SetVector * SmallSetVector * SmallSet * SmallPtrSet * StringSet * FoldingSet *

Dear llvm contributors, Could you please advise me how to skip checks, which are performed in AliasSet::aliasesUnknownInst, of unknown instructions from different alias sets of an alias set tracker that is a parameter of ‘AliasSetTracker::add(const AliasSetTracker &AST)’? If this wasn’t available at the moment and someone could review me, I would try to implement it. A temporary patch can be

My code to create an ExecutionEngine is segfaulting: std::string errStr; llvm::ExecutionEngine * ee = llvm::EngineBuilder( unique_ptr<llvm::Module>(module) ) .setErrorStr( &errStr ) //line 1618 .setEngineKind( llvm::EngineKind::JIT ) Where module is a `llvm::Module*`. This is code I'm migrating from 3.3 to 3.8. Since the deletion error is happening during

UniqueVector is an stl map coupled with an stl vector[1], which seems very undesirable for you. As far as SmallVector + slow search, I believe that is precisely what the implementation of SmallSet does until it has to grow, after which it uses an stl set[2]. If you're always staying within your small number, SmallSetVector would be wasteful as the SmallSet would itself also have a SmallVector.

I recently upgraded from llvm 3.7.1 to a pre release of llvm (3.8.0rc2) in order to test some issues regarding bug 24233. After upgrading I starting to see heap corruption messages in vs 2015 sp1 when my program exits. "HEAP[ConsoleEngine.exe]: Invalid address specified to RtlValidateHeap( 0000000000290000, 0000000000318698 )" Initially I only got it in Release build. Debug build seems

Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time. The real culprit here is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn't? >From what I can gather, Tablegen currently depends on these headers and all of their transitive dependencies. #include