On Thu, Mar 02, 2017 at 02:33:09PM +0000, Dibyendu Majumdar wrote: > This occurs in calc_memop_addr() function when it tries to do following: > > as = LLVMGetPointerAddressSpace(LLVMTypeOf(src)); > > If I dump insn, insn->src, and the LLVM value and type before this line, I get: > > 1) insn load.64 %r18 <- 8[%r2] > 2) pseudo %r2 > 3) store %struct.buffer_type_st* %R2, %struct.buffer_type_st** %26 > 4) void > > The type of the LLVM store instruction is 'void'. > > My guess is that something is going horribly wrong in the way member > access is handled. > > If you are able to reproduce this and have any suggestions then please > let me know. Why I try your code (without LLVM assertions), I got indeed several problems: Call parameter type does not match function signature! i0 16 i64 %1 = call i8* @malloc(i0 16) Invalid bitcast %27 = bitcast void <badref> to i8** Both operands to a binary operator are not of the same type! %R31 = add void <badref>, i64 %R30 Stored value type does not match pointer operand type! store void %R31, i8** %46 The first one is really weird but I think you don't see it. The next two I have no idea. The fourth have something obviously wrong with the type of its 'target'. None of these seems to correspond to the problem you're seeing. However, while running sparse-llvm on some code sample I use to test the linearization, I see that most errors are type errors and are related to pointer arithmetic, exactly where LLVM's getelemptr is used. Most offending instructions are OP_ADD (but since I have tests for bitfields I see also errors for OP_AND, OP_OR & OP_LSR). I guess that if you test OP_ADD instruction with pointer on one side and integer on tne other side and issue an appropriate LLVMBuildGEP(), things will already be much better. Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
