Opaque types in function parameters

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,


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.)

Ok, this explains my issue :slight_smile:

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!