search for: giterator

Displaying 5 results from an estimated 5 matches for "giterator".

Did you mean: iterator
2004 Oct 19
1
[LLVMdev] Re:question about Insert callInst to call a function in library
...ant *randKey; }; RegisterOpt<DecodeStr> X("DecodeStr", "Decode to visible string"); } bool DecodeStr::runOnFunction(Function &F){ get_randKey(F.getParent()); DecodeString(F.getParent()); return true; } void DecodeStr::get_randKey(Module *M){ for(Module::giterator gI=M->gbegin(),gE=M->gend();gI!=gE;++gI){ std::string GVname = gI->getName(); if(strcmp(GVname.c_str(),"Gvkey")==0){ randKey =(gI->getInitializer()); } } } void DecodeStr::DecodeString(Module *M){ std::cerr<<"filename "<<M->getMo...
2004 Apr 02
1
[LLVMdev] Verifier & abort()
...ing all of the external function's linkage now... for (Module::iterator I = M.begin(), E = M.end(); I != E; ++I) visitGlobalValue(*I); for (Module::giterator I = M.gbegin(), E = M.gend(); I != E; ++I) visitGlobalValue(*I); // If the module is broken, abort at this time. abortIfBroken(); return false;...
2005 Mar 15
0
[LLVMdev] Consistency patches to Module and Function
Dear llvm-devs, we discussed a consistency issue with the naming of iterators in the #llvm IRC channel and I came up with a patch to Module.h and Function.h. The patch renames the aiterator family of typedefs to arg_iterator in Function and correspondingly giterator and friends to global_iterator. The accessor functions also change accordingly. Right now the old spellings are preserved, but will go away after some time. So this is a heads-up to do a global replace in your non-LLVM-CVS codes from the old names to the new ones. The change is blessed by Chris L...
2004 Apr 01
0
[LLVMdev] Verifier & abort()
On Thu, 1 Apr 2004, Reid Spencer wrote: > On Thu, 2004-04-01 at 18:04, Misha Brukman wrote: > > > Perhaps another solution would be to throw an exception with the error > > message? > > Perhaps, but that would violate the programming contract already in > place. Right now LLVM and its users expect failed verifications to cause > an abort(). I wouldn't want to
2004 Apr 01
4
[LLVMdev] Verifier & abort()
On Thu, 2004-04-01 at 18:04, Misha Brukman wrote: > Perhaps another solution would be to throw an exception with the error > message? Perhaps, but that would violate the programming contract already in place. Right now LLVM and its users expect failed verifications to cause an abort(). I wouldn't want to unleash on LLVM the new semantics of now handling exceptions in every place the