lli -force-interpreter=true crash at APInt::operator==

[llvmbot]

Bugzilla Link	1293
Resolution	FIXED
Resolved on	Feb 22, 2010 12:52
Version	trunk
OS	Linux
Attachments	bytecode crashing the interpreter
Reporter	LLVM Bugzilla Contributor

Extended Description

$ lli -force-interpreter=true ./apint.bc
lli: lib/Support/APInt.cpp:491: bool llvm::APInt::operator==(const
llvm::APInt&) const: Assertion `BitWidth == RHS.BitWidth && "Comparison
requires equal bit widths"' failed.

I couldn't get bugpoint to reduce the testcase, so I'm attaching
the compressed bytecode in all its massiveness.

[llvmbot]

The issue here is this code:

%tmp15.i.i.i = call i32 @​malloc( i32 10256 ) ; [#uses=3]
icmp eq i32 %tmp15.i.i.i, 0 ; :0 [#uses=1]

LLI doesn't know how to coerce the result of malloc to a 32-bit integer from a
pointer. Previously (before APIntification) this would (accidentally) be okay
because the i32 and the pointer value shared the same memory. However, after
APIntification, they don't any more so these kinds of implicit conversions don't
happen any more.

One solution is to just fix the code (define it as returning a void* and then
compare void* instead of i32.

Its not clear how to fix LLI except to make it check for "weird" prototypes of
well known functions. I think that's not worth it.

[llvmbot]

Perhaps lli should issue a warning that the function its calling is not
returning the correct type.

[llvmbot]

I have modified LLI to generate this kind of assert:

lli: ExternalFunctions.cpp:157: llvm::GenericValue
lle_X_malloc(llvm::FunctionType*, const std::vector<llvm::GenericValue,
std::allocatorllvm::GenericValue >&): Assertion
`isa(FT->getReturnType()) && "malloc must return pointer"' failed.

It will now do this for all functions that should return pointer values (things
like strcat, strdup, fopen, freopen, etc.).

I think this is about as far as we can go with this.

[llvmbot]

Fixed with this patch:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070326/046510.html