Type mismatch when unconditionally specializing function pointer-typed parameter

[tshiUCSB]

Hi, I just posted this in the LLPE Google Group but just reposting here as well.

I have been trying to use LLPE's feature to unconditionally specialize a function pointer-typed parameter. However, I would keep getting the following error:

clang func_ptr.c -c -emit-llvm func_ptr.bc
$LLPE_OPT func_ptr.bc -o func_ptr_spec.bc -llpe-root f -spec-param 0,void_func
Type mismatch: constant 
; Function Attrs: noinline nounwind optnone uwtable
define dso_local void @void_func() #0 {
  %1 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([6 x i8], [6 x i8]* @.str.1, i64 0, i64 0))
  ret void
}
 supplied for parameter of type void (...)*

My program looks like the following:

void void_func() {
	printf("hello");
}

void f(void (*func_ptr)()) {
	func_ptr();
}

int main() {
	f(&void_func);
}

Is it a usage problem where I'm issuing the command incorrectly? Or am I potentially encountering a bug?
Thanks for any help!

[smowton]

The cause is that the type void (*func_ptr)() is different from the type void (*func_ptr)(void) in C -- the former means that we don't state any information about the parameter list, while the latter explicitly has an empty parameter list. By contrast because void void_func() { occurs in definition context, the empty parameter list has the same meaning as an explicit (void). C++ also cleans up this trap.

So the quick fix is to use an explicit type void (*func_ptr)(void). It may also be feasible to do something sensible with an apparently-type-incompatible function pointer, but on that front considering my time currently available to work on LLPE, I'll have to just say "patches welcome" :)