Skip to content
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

Subroutine name mismatch between caller and callee #2

Open
ppenzin opened this issue Dec 14, 2017 · 1 comment
Open

Subroutine name mismatch between caller and callee #2

ppenzin opened this issue Dec 14, 2017 · 1 comment

Comments

@ppenzin
Copy link
Contributor

ppenzin commented Dec 14, 2017

Migrated from llvm-flang/flang#2
To reproduce:

$ cat bug_name.f90 
subroutine mysub(x,y)
  character :: x, y

  y = x
end

program p
  external mysub
  character c,d

  c = 'a'
  call mysub(c,d)

  print *, d
end
$ fort bug_name.f90 
bug_name.o: In function `main':
bug_name.f90:(.text+0x7b): undefined reference to `mysub_.1'
collect2: error: ld returned 1 exit status

If you use -S -emit-llvm you can see that callee is produced as mysub_ and caller is tying to invoke mysub_.1.

@ppenzin
Copy link
Contributor Author

ppenzin commented Mar 12, 2020

A call to an procedure declared external triggers codegen to produce a function declaration matching the call (there might be some set up on AST level too, but nonetheless). That makes backend perfectly content with the generated code in simple cases, but is not correct in general. It also directly leads to this bug.

Before modules external was used to call procedures defined outside of current program unit scope. The only part of procedure signature such declarations can describe is the return type (or lack of it), parameters are taken from the call and don't have to match between different calls to the same external. The gotcha is that it is OK to define the target procedure in the same source file and calling mismatch between declaration and the call would only lead to a warning (at least in GNU Fortran).

What happens in this bug is that the second definition produced by the call site is treated as a local redefinition and that's why it gets a .1 name. To fix this the compiler need to check if a function with the same name is already defined in this file and ditch the definition in this case.

@ppenzin ppenzin added this to the Next release milestone Mar 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant