Skip to content

Ignore forward declarations of ccall functions in C backend #1096

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

czgdp1807
Copy link
Collaborator

@czgdp1807 czgdp1807 commented Sep 7, 2022

Closes #1094

@czgdp1807 czgdp1807 marked this pull request as ready for review September 7, 2022 14:04
@czgdp1807 czgdp1807 requested a review from certik September 7, 2022 14:24
@certik
Copy link
Contributor

certik commented Sep 7, 2022

It's fine as a quick fix.

What is the logic / use case how this will be used?

It seems this should be made configurable using some compiler option. Even better: why do we need them in the first place? Well, they are needed because gcc will not compile it if we call a function that is declared after it is called. It seems that is the way in C, you have to forward declare them. However, it also seems some C compilers do not support forward declarations, in which case, what is the proper way to support those C compilers?

@czgdp1807
Copy link
Collaborator Author

@certik So should we merge this?

@czgdp1807
Copy link
Collaborator Author

@certik Can we merge this?

@certik
Copy link
Contributor

certik commented Oct 3, 2022

I would like to know the answers to my question above (#1096 (comment)).

One way to give an answer is to test this by actually compiling some code with some special (?) gcc options that require it.

@czgdp1807
Copy link
Collaborator Author

Even better: why do we need them in the first place? Well, they are needed because gcc will not compile it if we call a function that is declared after it is called.

AFAICT, it is needed because some C compilers raise error when we forward declare a function which is already present in an included header.

One way to give an answer is to test this by actually compiling some code with some special (?) gcc options that require it.

GCC by default doesn't raise any error on re-declaring the same function which is already present in an included header. It is that some specific compiler raise error when we re-declare a function. which is already present in an included header.

@certik
Copy link
Contributor

certik commented Oct 3, 2022

I am mainly concerned about ensuring that this stays working, otherwise it is almost guaranteed that it will break in the future. The only test is the cpp textual test, but it's very easy to forget that this was needed there.

Let's figure out a way to test it, possibly with some scripts.

@czgdp1807
Copy link
Collaborator Author

So I and @certik figured that instead of the current workaround in this PR we should go ahead with emitting the functions in the right order. See lfortran/lfortran#802 (comment) for more details.

@czgdp1807 czgdp1807 marked this pull request as draft October 5, 2022 09:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Declare @ccall only when asked by the user
2 participants