Closed hikari-no-yume closed 3 years ago
Probably the same issue as https://github.com/JuliaComputing/llvm-cbe/issues/66
Ah, indeed, it must be the same issue. Sorry, I should have remembered it.
No worries. I just cross-linked so both can be closed together.
And if you’re interested in being a collaborator here with commit rights, let me know and I’ll see if I can give you that access.
Thank you for the kind offer. I would be interested. I expect I would still use pull requests for most things, but being able to merge small fixes myself would be useful.
Yep, that's exactly right. While I don't commit here, when I do, I would also typically use PRs. Currently it is mostly just myself doing reviews and merging things for others. And while I have been mostly able to keep on top of it, being able to expand that will be helpful. And someday we may even finish getting CI setup, making the PR process even more useful for everyone. It took a couple days to work out the details, so you may see the repository team name has changed now, as that turned out to be necessary to add you here. But also welcome!
Consider the following C program:
It has a function pointer type used in a struct type, but it's never actually touched in a function. Clang will generate LLVM IR for it that looks something like this:
If this LLVM IR is compiled with LLVM-CBE, this function pointer type gets mentioned in the resulting C code within the struct definition, but never actually gets defined:
(There should be some
typedef void l_fptr_1(void);
line under “Function definitions”, but there isn't.)C compilers obviously don't like this very much.
The real-world case where I encountered this was when trying to compile a Rust “hello world” program (though it wasn't the only problem). This C program is a contrived reproducer. If you un-comment the statement
foo_ptr_object.foo_ptr = foo;
, the bug doesn't happen. This suggests that the bug is specific to function pointer types that aren't directly referenced within functions.Some printf debugging suggests that this problem is occurring because
printFunctionName
(which assigns the ID to the function type) is being called after all the function types have been printed.There's already some logic in
printModuleTypes
for handling function types that depend on other function types, so maybe this can be fixed by just doing the same for structs. If so, I will probably have a fix for this very soon. :)