[cfe-dev] Function pointer type becomes empty struct

Christian Dehnert via cfe-dev cfe-dev at lists.llvm.org
Sun Nov 13 03:49:17 PST 2016


Hi cfe-dev,
I am using clang to compile C programs to LLVM IR. I have the following program:
struct A {
   int (*f)(int, struct A*);
   int (*g)(char, struct A*);
};

int h(int a, struct A* b) {
	return 0;
}

int i(char a, struct A* b) {
	return 1;
}

int main() {
	struct A a;
	a.f = h;
	a.g = 0;
	a.f(0, &a);
	return 0;
}
Now, if I compile this to LLVM IR, the struct A becomes:

%struct.A = type { {}*, i32 (i8, %struct.A*)* }

So the type of function pointer f in A is {}* and the type of g (in A) is (just as I would expect of type i32 (i8, %struct.A*)*. Now, why is the type for f abbreviated like this? If I change the order of the functions in the C program by swapping the order of the definitions of h(...) and i(…), the type of the struct A becomes:

%struct.A = type { i32 (i32, %struct.A*)*, {}* }

Now the type of f is spelt out completely as I would expect, but g’s type is given by {}*. If I slightly change the type of the function pointers whose type becomes {}* (e.g. changing “int” to “long” or something like this), I get their full types back again.

From what I can see, the function pointer types within struct A become {}* if they coincide with the type of the first function following the structure definition that involves the struct itself. In other words, if I put a function 

int j() {
	return 0;
}

between struct A and h, then everything stays as it is (i.e. one of the types is going to be {}*), but if I make it

int j(struct A* a) {
	return 0;
}

the IR for %struct.A changes (and I suddenly get the full types for both function pointers).

How is the type {}* supposed to be interpreted here? Why is it, that depending on what follows, the type is “abbreviated” as {}* and sometimes not?

I am using AppleClang on Mac OS 10.12, but I get the same behavior with pre-built clang 3.9 downloaded from the LLVM website.

Best wishes,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161113/b3ce7bd8/attachment.html>


More information about the cfe-dev mailing list