-
Notifications
You must be signed in to change notification settings - Fork 171
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
base: main
Are you sure you want to change the base?
Conversation
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? |
@certik So should we merge this? |
@certik Can we merge this? |
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. |
AFAICT, it is needed because some C compilers raise error when we forward declare a function which is already present in an included header.
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. |
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. |
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. |
Closes #1094