search for: verifyfunction

...lobalValue::CommonLinkage, "f", module); // Entry block auto entry = BasicBlock::Create(context, "entry", f); builder.SetInsertPoint(entry); // return 0 auto val = ConstantInt::getSigned(rty, 0); builder.CreateRet(val); // Check f->dump(); outs() << verifyFunction(*f) << '\n'; return 0; } Output: define common i32 @f() { entry: ret i32 0 } 1 So the verifier says there is a problem, but I don't see anywhere the problem could be. What am I missing? -------------- next part -------------- An HTML attachment was scrubbed... URL: <htt...

Hello everyone: I have a little question about the second argument *action* of verifyFunction. In docs: *Enumerator: * *AbortProcessAction* verifyModule will print to stderr and abort() *PrintMessageAction* verifyModule will print to stderr and return true *ReturnStatusAction* verifyModule will just return true But it still abort when I pass PrintMessageAction/ReturnS...

...106, lib/VMCore/Verifier.cpp) Perhaps you should file a bug against this, to allow you to not abort if you so wish. Joey On 11 June 2012 09:41, Guowei Xu <myesis at gmail.com> wrote: > Hello everyone: > > I have a little question about the second argument *action* of > verifyFunction. > > In docs: > > *Enumerator: * *AbortProcessAction* > > verifyModule will print to stderr and abort() > *PrintMessageAction* > > verifyModule will print to stderr and return true > *ReturnStatusAction* > > verifyModule will just return true > >...

I also tried iterating through the functions of the module and calling verifyFunction(), which also returns false, but does not cause an abort or report anything to stderr about what caused the verification to fail. From the doxygen for verifyFunction() and verifyModule(), it seems like they both should print information to stderr if the verification fails and should abort opt...

...each function > 4. dofinalization for mypass > 5. dofinalization for verify > > Because you'd doing your xform in #4, but verifier checks the code at #3, > you lose :( > > However, there is hope! Just call "llvm/Analysis/Verifier.h" -> > verifyModule or verifyFunction explicitly in your pass. > > -Chris > >> opt: Reader.cpp:1978: llvm::Value* >> llvm::BytecodeReader::ParseConstantPoolValue(unsigned int): Assertion >> `(!isa<Constant>(Result) || !cast<Constant>(Result)->isNullValue()) || >> !hasImplicitNull(TypeID...

...should file a bug against this, to allow you to not abort if > you so wish. > > Joey > > On 11 June 2012 09:41, Guowei Xu <myesis at gmail.com> wrote: > >> Hello everyone: >> >> I have a little question about the second argument *action* of >> verifyFunction. >> >> In docs: >> >> *Enumerator: * *AbortProcessAction* >> >> verifyModule will print to stderr and abort() >> *PrintMessageAction* >> >> verifyModule will print to stderr and return true >> *ReturnStatusAction* >> >&g...

On Tue, Jun 12, 2012 at 10:11:01AM +0800, Michael.Kang wrote: > > > On Mon, Jun 11, 2012 at 5:44 PM, Joey Gouly <joel.gouly at gmail.com> wrote: > > Hi Xiu, > > The Verifier pass runs a PreVerifier pass, which does not honour the action > argument, > and will always abort on a broken module, (Line 106, lib/VMCore/ > Verifier.cpp) >

I think I misread the doxygen. verifyFunction & verifyModule return false if no errors are detected. However, my question now becomes why does the code produced by my transform pass verification, but it causes an assertion failure in the byte reader when it (the code produced by my transform) is passed to another invocation of opt? R...

...asicBlock::Create(context, "entry", aFun); /// @brief builder llvm::IRBuilder<> builder(block); builder.SetInsertPoint(block); llvm::CallInst *cCall = builder.CreateCall(cFun, {}, "c"); llvm::Value *res = cCall; builder.CreateRet(res); llvm::verifyFunction(*aFun); } // Body of the `b` function { /// @brief Set entry label llvm::BasicBlock *block = llvm::BasicBlock::Create(context, "entry", bFun); /// @brief builder llvm::IRBuilder<> builder(block); builder.SetInsertPoint(block); llvm::CallInst *aCall = build...

...ype = Type::getInt32Ty(getGlobalContext()); // Constant *zerov = Constant::getNullValue(type); Constant *zerov = Constant::getIntegerValue(type, APInt(32, 0)); V = new GlobalVariable(getGlobalContext(), type, 0, GlobalValue::PrivateLinkage, zerov, name); And these are the error messages given by verifyFunction: Function return type does not match operand type of return inst! ret i32* @x i32Referencing global in another module! ret i32* @xBroken module found, compilation aborted! Any idea of what I might be doing wrong? Is this the right way to be going about it in the first place?

What does this error mean? I'm getting it from an ExecutionEngine::runFunction() call. The function I'm passing it was run through verifyFunction() right before the runFunction() call. I can't seem to find anything that tells me what causes this, only specific (but seemingly unrelated to my problem) cases of it happening. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/l...

Hi, I want to run the Mem2Reg pass on a function without using the the LLVM opt utility. I wrote some code, which I am not sure is correct: TS_ASSERT(!verifyFunction(*function)); // find the dominance frontier of the CFG DominanceFrontier DF; DF.runOnFunction(*function); // try to promote stack allocated variables PromoteMemToReg(function->getRegAllocas(), DF, *tgt_data); function->print(std::cout); TS_ASSERT(!verifyFunction(*function)); Is this suppo...

Ah! I didn't know about verifyFunction; it does indeed catch it, thanks! I'll leave that call in my code for all cases for the moment, should help identify problems like that. Is there a recommended way to avoid this problem when compiling a language that has an explicit and optional return statement? On Fri, Feb 5, 2010 at 5:25 P...

The title says it all. verifyFunction checks it (Verifier.cpp, line 728). Why can't BasicBlocks that serve as a function's entry point also have predecessors? What keeps a function from looping back to its beginning? Félix -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.or...

Did your test include running llvm::verifyFunction(...) on the function in question? I guess I should test this, but I would have thought this would catch the issue. Garrison On Feb 5, 2010, at 12:13, Russell Wallace wrote: > Fair enough. In that case, is there an elegant way to test whether a > basic block already has a terminator instruc...

Fair enough. In that case, is there an elegant way to test whether a basic block already has a terminator instruction? (I can think of several ways to do it in the front-end, but all of them are fairly inelegant. The problem I'm trying to solve is things like 'a return instruction needs to be added to the end of a function, if and only if the programmer didn't already end the function

On Aug 15, 2010, at 1:06 PM, Alec Benzer wrote: > What does this error mean? I'm getting it from an ExecutionEngine::runFunction() call. The function I'm passing it was run through verifyFunction() right before the runFunction() call. I can't seem to find anything that tells me what causes this, only specific (but seemingly unrelated to my problem) cases of it happening. Which unreachable was it? The basic idea is that whichever section of code gives that assertion shouldn't be e...

...t; // Constant *zerov = Constant::getNullValue(type); > Constant *zerov = Constant::getIntegerValue(type, APInt(32, 0)); > V = new GlobalVariable(getGlobalContext(), type, 0, > GlobalValue::PrivateLinkage, zerov, name); > > And these are the error messages given by verifyFunction: > > Function return type does not match operand type of return inst! > ret i32* @x i32Referencing global in another module! > ret i32* @xBroken module found, compilation aborted! > > Any idea of what I might be doing wrong? Is this the right way to be > going about it in the...

Oh! Okay, thanks, I'll fix it up to do that then. Any chance verifyFunction could be tightened up to catch this case? I'm currently running all my generated code through it, and it passes the i32 conditional without complaint. On Mon, Feb 8, 2010 at 10:07 PM, John McCall <rjmccall at apple.com> wrote: > On Feb 8, 2010, at 1:53 PM, Russell Wallace wrote: >&...

On Fri, Feb 5, 2010 at 11:30 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > Ah! I didn't know about verifyFunction; it does indeed catch it, > thanks! I'll leave that call in my code for all cases for the moment, > should help identify problems like that. > > Is there a recommended way to avoid this problem when compiling a > language that has an explicit and optional return statement? > &...