[LLVMdev] Expected behavior of calling bitcasted functions?

[Pete Couperus]

Hello,

Using a type incompatible pointer to call a function has undefined behavior
(6.3.2.3).
As for the tests, I don't know...maybe we want specific behavior within
LLVM for these cases?

Pete




On Thu, May 30, 2013 at 11:41 AM, Matt Arsenault
<Matthew.Arsenault at amd.com>wrote:

>  On 05/30/2013 06:12 AM, Pete Couperus wrote:
>
>   Hello,
>
>  This is an interesting example.  Whenever I see strange things like this,
> I use opt's -lint.
>  In this case, opt -lint reports:
> Undefined behavior: Call return type mismatches callee return type
>   %call = call float @alias_f32(float %tmp2) #1
>
>  You'll get a similar report when the parameter types mismatch.
>
>  Pete
>
>
> Is it really supposed to be undefined? The tests are checking for specific
> behavior in these "undefined" cases.
>
> opt -lint < test/Transforms/InstCombine/call.ll
>
> Undefined behavior: Call argument type mismatches callee parameter type
>   call  void bitcast (void (i8*)* @test1a to void (i32*)*)(i32* %A)
> Undefined behavior: Call argument type mismatches callee parameter type
>   call  void bitcast (void (i8)* @test2a to void (i32)*)(i32 %A)
>
> Undefined behavior: Call return type mismatches callee return type
>   %X = call  i32 bitcast (i8 ()* @test4a to i32 ()*)()
> Undefined behavior: Call argument count mismatches callee argument count
>   %X = call  i32 bitcast (i32 (i32)* @test6a to i32 ()*)()
> Undefined behavior: Call argument count mismatches callee argument count
>   call  void bitcast (void ()* @test7a to void (i32)*)(i32 5)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130531/f7a1c630/attachment.html>