[LLVMdev] Opaque types in function parameters

[Carlos Sánchez de La Lama]

Ok, this explains my issue :)

Also, I was actually using a pointer-to-opaque at the first place,  
obtaining exact same results. I tested with integers and saw it was  
ok, and then with plain opaques ang get same error as with pointer-to- 
opaques, so when writting to the list I said plain opaques in a try  
to simplify the explanation.

Thanks Kenneth!

Carlos

El 15/09/2009, a las 20:05, Kenneth Uildriks escribió:

> 2009/9/15 Carlos Sánchez de La Lama <carlos.delalama at urjc.es>:
>> Hi all,
>>
>> I am creating a function and trying to call it using the LLVM API. It
>> seems that whenever the function type includes an opaque-typed
>> parameter, the CallInst::Create call causes an assert:
>>
>> Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i)
>> == Params[i]->getType()) && "Calling a function with a bad
>> signature!"), function init, file /usr/home/csanchez/shared/prj/tce/
>> src/llvm-2.5/lib/VMCore/Instructions.cpp, line 294.
>>
>> If I change the code so the function type has only non-opaque types,
>> everything is correct. Of course, the parameters passed to the
>> function are correct (I call with either an opaque parameter or an
>> integer parameter, to match function type). According to the assert,
>> I would say an opaque type always compares to false (even with
>> another opaque), but this does not make much sense I do not see such
>> in the source. I am using llvm-2.5
>>
>> Does anybody find an explanation for this?
>>
>> Thanks a lot,
>>
>> Carlos
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> Every time you call OpaqueType::get, you get a distinct opaque type...
> they compare unequal.  If you call OpaqueType::get once and store the
> result, and use that same instance in declaring your function and in
> calling it, it'll match and the assert will go away.
>
> In other words, while there is only one i32 type, and using the API to
> fetch it any number of times will always fetch the same one, there can
> be an unlimited number of different opaque types... it's up to you to
> make sure you're using the same opaque type in situations where you
> need them to match, and to make sure you're using different opaque
> types in situations where you don't want them to match.
>
> Also, when writing stuff using a single opaque type out to IR, those
> uses will come back as using different opaque types unless you gave
> your opaque type a name in the module's type symbol table.
>
> (Also, you can't have a parameter or a value of type opaque... it must
> be of type pointer-to-opaque.  Opaque is not a first-class type.)