Displaying 20 results from an estimated 22 matches for "assert1".
Did you mean:
assert
2015 Jan 19
2
[LLVMdev] [INCOMPLETE] [GC] Support wrapping vararg functions in statepoint
...639,8 +2639,6 @@ void Verifier::visitIntrinsicFunctionCall(Intrinsic::ID ID, CallInst &CI) {
"gc.statepoint callee must be of function pointer type",
&CI, Target);
FunctionType *TargetFuncType = cast<FunctionType>(PT->getElementType());
- Assert1(!TargetFuncType->isVarArg(),
- "gc.statepoint support for var arg functions not implemented", &CI);
const Value *NumCallArgsV = CI.getArgOperand(1);
Assert1(isa<ConstantInt>(NumCallArgsV),
@@ -2650,8 +2648,13 @@ void Verifier::visitIntrinsicFunctionCall...
2014 Mar 10
2
[LLVMdev] GlobalValues appear in their own use lists?
...pp (revision 203468)
+++ lib/IR/Verifier.cpp (working copy)
@@ -360,6 +360,11 @@
"Global is external, but doesn't have external or weak linkage!",
&GV);
+ for (Value::const_use_iterator UI = GV.use_begin(), UE = GV.use_end();
+ UI != UE; ++UI) {
+ Assert1(*UI != &GV, "Global values cannot be their own uses!", &GV);
+ }
+
Assert1(!GV.hasAppendingLinkage() || isa<GlobalVariable>(GV),
"Only global variables can have appending linkage!", &GV);
–
Is it ever reasonable for a global value to be its own u...
2010 Jun 25
1
[LLVMdev] redundant checking of terminator in Verifier?
...when
visiting each instruction, the checking at visitTerminatorInst seems
redundant to me. Did I miss any case?
void Verifier::visitInstruction(Instruction &I) {
...
line 1356:
// Verify that if this is a terminator that it is at the end of the block.
if (isa<TerminatorInst>(I))
Assert1(BB->getTerminator() == &I, "Terminator not at end of block!", &I);
...
}
void Verifier::visitTerminatorInst(TerminatorInst &I) {
// Ensure that terminators only exist at the end of the basic block.
Assert1(&I == I.getParent()->getTerminator(),
"Te...
2014 Mar 11
3
[LLVMdev] GlobalValues appear in their own use lists?
...pp (revision 203523)
+++ lib/IR/Verifier.cpp (working copy)
@@ -360,6 +360,11 @@
"Global is external, but doesn't have external or weak linkage!",
&GV);
+ for (Value::const_use_iterator UI = GV.use_begin(), UE = GV.use_end();
+ UI != UE; ++UI) {
+ Assert1(*UI != &GV, "Global values cannot be their own uses!", &GV);
+ }
+
Assert1(!GV.hasAppendingLinkage() || isa<GlobalVariable>(GV),
"Only global variables can have appending linkage!", &GV);
$ cat whatever.ll
define i8 @foo() #0 {
entry:
%call0 =...
2009 Sep 22
5
[LLVMdev] Verifier should not make any assumptions about calls to "malloc"
...-end build:
const Module* M = CI.getParent()->getParent()->getParent();
Constant *MallocFunc = M->getFunction("malloc");
if (CI.getOperand(0) == MallocFunc) {
const PointerType *PTy =
PointerType::getUnqual(Type::getInt8Ty(CI.getParent()->getContext()));
Assert1(CI.getType() == PTy, "Malloc call must return i8*", &CI);
}
I think it is completely wrong for the verifier to be checking anything
about calls to functions that happen to be called "malloc". What if I
have my own runtime in which "malloc" is completely differ...
2010 Mar 17
1
[LLVMdev] is structtyp a firstclass typ?
Hi LLVM,
In lib/VMCare/Verifier.cpp::visitInstruction, we have such code
1287 // Check that the return value of the instruction is either
void or a legal
1288 // value type.
1289 Assert1(I.getType() == Type::getVoidTy(I.getContext()) ||
1290 I.getType()->isFirstClassType()
1291 || ((isa<CallInst>(I) || isa<InvokeInst>(I))
1292 && isa<StructType>(I.getType())),
1293 "Instruction returns a non-scalar type!&...
2004 Mar 28
0
[LLVMdev] Re: Can't Figure Out My Error :(
...check for
this. The only place where basic blocks can appear is in PHI nodes and
terminators.
I just checked this patch into the Verifier. Maybe it will help?
--- Verifier.cpp 14 Mar 2004 03:23:54 -0000 1.88
+++ Verifier.cpp 29 Mar 2004 00:27:29 -0000
@@ -493,6 +493,11 @@
Assert1(I.getType() != Type::VoidTy || !I.hasName(),
"Instruction has a name, but provides a void value!", &I);
+ // Check that the return value of the instruction is either void or a legal
+ // value type.
+ Assert1(I.getType() == Type::VoidTy || I.getType()->isFirstClassTy...
2008 Apr 27
1
[LLVMdev] Can't invoke an intrinsic?
In line 1157 of Verifier.cpp, there is this code:
Assert1(!F->isIntrinsic() || (i == 0 && isa<CallInst>(I)),
"Cannot take the address of an intrinsic!", &I);
This check appears to have a problem with this line:
invoke void @llvm.memcpy.i32( i8* %._items.i.i, i8*
%._items2.i.i, i32 ptrtoint (i32* gete...
2012 Apr 16
2
[LLVMdev] Representing -ffast-math at the IR level
...ill catch any goofs.
+ // If it's not a floating point number then it must be 'fast'.
+ return !isa<ConstantFP>(MD->getOperand(0));
Here as well.
+ if (ConstantFP *CFP0 = dyn_cast_or_null<ConstantFP>(Op0)) {
+ APFloat Accuracy = CFP0->getValueAPF();
+ Assert1(Accuracy.isNormal() && !Accuracy.isNegative(),
+ "fpmath accuracy not a positive number!", &I);
To be pedantic for a moment, zero is not a positive number. What about
asserting these individually to give us more clear asserts if they fire?
That also makes the str...
2004 Mar 28
2
[LLVMdev] Can't Figure Out My Error :(
The XPL compiler produced the attached OneOfEach.bc file without error
or warning from either LLVM or XPLC. However when I llvm-dis the file, I
get:
llvm-dis: Failed value look-up for name 'entry'
The Bytecode Reader prints this out when it can't find the associated
value for the name. Obviously I botched something in the XPL compiler
but I would have thought the verified would
2009 Sep 22
0
[LLVMdev] Verifier should not make any assumptions about calls to "malloc"
...st Module* M = CI.getParent()->getParent()->getParent();
> Constant *MallocFunc = M->getFunction("malloc");
>
> if (CI.getOperand(0) == MallocFunc) {
> const PointerType *PTy =
> PointerType::getUnqual(Type::getInt8Ty(CI.getParent()->getContext()));
> Assert1(CI.getType() == PTy, "Malloc call must return i8*", &CI);
> }
>
> I think it is completely wrong for the verifier to be checking
> anything
> about calls to functions that happen to be called "malloc". What if I
> have my own runtime in which "mall...
2015 Jun 04
2
[LLVMdev] Assert in BlockFrequency pass
> On 2015-Jun-04, at 12:45, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>
>> On 2015-Jun-04, at 12:28, Ivan Baev <ibaev at codeaurora.org> wrote:
>>
>> Hi, we got the following assert:
>>
>> assert(!Working[0].isLoopHeader() && "entry block is a loop header");
>>
>> [in
2009 Sep 22
1
[LLVMdev] Verifier should not make any assumptions about calls to "malloc"
...gt;getParent()->getParent();
>> Constant *MallocFunc = M->getFunction("malloc");
>>
>> if (CI.getOperand(0) == MallocFunc) {
>> const PointerType *PTy =
>> PointerType::getUnqual(Type::getInt8Ty(CI.getParent()->getContext
>> ()));
>> Assert1(CI.getType() == PTy, "Malloc call must return i8*", &CI);
>> }
>>
>> I think it is completely wrong for the verifier to be checking
>> anything
>> about calls to functions that happen to be called "malloc". What
>> if I
>> have my...
2009 Sep 22
0
[LLVMdev] Verifier should not make any assumptions about calls to "malloc"
...* M = CI.getParent()->getParent()->getParent();
> Constant *MallocFunc = M->getFunction("malloc");
>
> if (CI.getOperand(0) == MallocFunc) {
> const PointerType *PTy =
>
> PointerType::getUnqual(Type::getInt8Ty(CI.getParent()->getContext()));
> Assert1(CI.getType() == PTy, "Malloc call must return i8*", &CI);
> }
Yes, I agree, the verifier shouldn't worry about malloc calls.
> Actually isMalloc also seems bogus. In a freestanding environment
> there is no reason that a function that happens to be called "mallo...
2012 Apr 16
0
[LLVMdev] Representing -ffast-math at the IR level
...'s not a floating point number then it must be 'fast'.
> + return !isa<ConstantFP>(MD->getOperand(0));
>
> Here as well.
>
> + if (ConstantFP *CFP0 = dyn_cast_or_null<ConstantFP>(Op0)) {
> + APFloat Accuracy = CFP0->getValueAPF();
> + Assert1(Accuracy.isNormal() && !Accuracy.isNegative(),
> + "fpmath accuracy not a positive number!", &I);
>
> To be pedantic for a moment, zero is not a positive number.
Zero is not allowed. The isNormal call will return false for zero.
What about asserting
> these in...
2008 Mar 10
0
[LLVMdev] Verifier Error
...(this=0xbfaeecf8, M=@0x8773d10) at
PassManager.cpp:1345
#16 0x0836680d in main (argc=13, argv=0xbfaeeee4) at
opt.cpp:426
When I tried debugging stepwise
Error:
Breakpoint 1, (anonymous
namespace)::Verifier::visitBinaryOperator
(this=0x8794f08, B=@0x87996a8) at Verifier.cpp:905
905 Assert1(B.getOperand(0)->getType() ==
B.getOperand(1)->getType(),
1: B.getName () = {static npos = 4294967295,
_M_dataplus =
{<std::allocator<char>> =
{<__gnu_cxx::new_allocator<char>> = {<No data
fields>}, <No data fields>}, _M_p = 0x879bfdc
"indvar.next4&...
2012 Apr 16
0
[LLVMdev] Representing -ffast-math at the IR level
Here's a revised patch, plus patches showing how fpmath metadata could be
turned on in clang and dragonegg (it seemed safest for the moment to
condition on -ffast-math rather than on one of the flags implied by
-ffast-math).
Major changes:
- The FPMathOperator class can no longer be used to change math settings,
only to read them. Currently it can be queried for accuracy info. I split
the
2014 Mar 07
3
[LLVMdev] [RFC] Add second "failure" AtomicOrdering to cmpxchg instruction
...sult;
}
diff --git a/lib/IR/Verifier.cpp b/lib/IR/Verifier.cpp
index deb708d..4e1ad30 100644
--- a/lib/IR/Verifier.cpp
+++ b/lib/IR/Verifier.cpp
@@ -1829,10 +1829,23 @@ void Verifier::visitAllocaInst(AllocaInst &AI) {
}
void Verifier::visitAtomicCmpXchgInst(AtomicCmpXchgInst &CXI) {
- Assert1(CXI.getOrdering() != NotAtomic,
+
+ // FIXME: more conditions???
+ Assert1(CXI.getSuccessOrdering() != NotAtomic,
+ "cmpxchg instructions must be atomic.", &CXI);
+ Assert1(CXI.getFailureOrdering() != NotAtomic,
"cmpxchg instructions must be atomic.",...
2012 Jul 31
0
[LLVMdev] rotate
Oh, no. I should have been more clear. The patch was not rejected, just
lost in the daily shuffle.
I already have my employer's approval to send this upstream, so I will
prepare a patch against trunk this morning.
> I proposed a similar patch to LLVM (left circular shift) around 10/2011.
> > Parts of my patch did make it into trunk about a year after, but others
> > did not.
2012 Jul 31
4
[LLVMdev] rotate
On Monday, July 30, 2012 12:16 AM, Cameron McInally wrote:
> Hey Andy,
>
> I proposed a similar patch to LLVM (left circular shift) around 10/2011.
> Parts of my patch did make it into trunk about a year after, but others
> did not.
>
> At that time, my solution was to add a binary operator to the IRBuilder,
> since LCS fits in nicely with the other shift operators. But,