[LLVMdev] Incompatible types at call site

Duncan Sands baldrick at free.fr
Tue Apr 5 11:44:32 PDT 2011

Hi Arushi,

>   %tmp63 = call %struct.TypHeader* (...)* bitcast (%struct.TypHeader*
> (%struct.TypHeader*, i64, i64)* @Cyclotomic to %struct.TypHeader*
> (...)*)(%struct.TypHeader* %tmp62, i64 %tmp24, i32 1) nounwind, !dbg !907 ;
> <%struct.TypHeader*> [#uses=1]
> the 3rd parameter is now used in an srem statement. How do we know what value is
> used? Does this use decide whether the value is sign extended or zero extended?

inside the called function the 3rd value will contain rubbish.  That's because
the function takes an i64 parameter but via the bitcast you pretend it takes an
i32 parameter, which is wrong.  This is not the correct way to pass an i32 to a
function that takes an i64.  Where did you get this IR from?

Ciao, Duncan.

PS: It may not contain rubbish in practice, in particular probably the lower 32
bits will have the "right" value, but nothing guarantees that.

> Arushi
> On Tue, Apr 5, 2011 at 1:35 AM, Duncan Sands <baldrick at free.fr
> <mailto:baldrick at free.fr>> wrote:
>     Hi Arushi,
>      > For a call like this,
>      >
>      > %tmp6 = call i32 (...)* bitcast (i32 (i8*, i8, i8**)* @ssplit to i32
>     (...)*)(i8*
>      > %tmp599, i32 46, i8** %domainv3) nounwind ; <i32>
>      >
>      > does the 2nd argument get zero extended or sign extended?
>     neither since it does not have the zext or sext attribute.
>     Ciao, Duncan.
>     _______________________________________________
>     LLVM Developers mailing list
>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list