Actually, the following problem appeared when I tried to compile a huge fortran code with pgfortran 12.8-1 64-bit. For simplicity I created the code given below (a.f90) that reproduces the same problem. When I try to compile it (using pgfortran a.f90) I get the following error message
PGF90-S-0165-c appeared more than once as a subprogram (a.f90)
0 inform, 0 warnings, 1 severes, 0 fatal for c
I understand that something goes wrong with the names of subroutines during linking and how the compiler combines the names of the modules with the names of the subroutines. In the case that I rename subroutine “c” to “c1” everything works. Of course in such a small code I could just rename the subroutines but this work around can not be applied to the real code. Why this strange behavior and how someone could overcome it?
module a
contains
subroutine b_c
print*,'Hello from b_c'
end subroutine b_c
end module a
module a_b
contains
subroutine c
print*,'Hello from c'
end subroutine c
end module a_b
program aaa
use a
use a_b
call b_c
call c
end program aaa
Hi fanourg,
This is an odd one but it does look like a compiler issue. I’ve sent a report to our compiler engineers (TPR#19231) for further investigation.
The problem appears to be that the compiler isn’t clearing it’s name list between the compilation of modules a and a_b. Since module names are appended to the beginning of routine names, module a’s routine “b_c” gets the name “a_b_c” and module a_b’s routine “c” gets the name “a_b_c”, hence the collision.
The work around is to change names or put the modules into their own source files, and compile them separately.
Thanks for the report,
Mat
Hi Mat,
Thank you for your reply
I am afraid that putting the modules into separate files (e.g. in the a_mod.f90 and a_b_mod.f90) does not help. It this case I can compile each one separately but during linking I get a similar error message.
a_b_mod.o: In function a_b_c_': (.text+0x10): multiple definition of a_b_c_’
a_mod.o:(.text+0x10): first defined here
I am afraid that for the moment the only solution is to rename the modules or the subroutines, but this requires quite a lot of work in the real application I work with.
Anyway, thanks again
–George
The problem is not just a failure to clear module name tables as matcolg guessed, but is inherent to the way that entry names are emitted into object files by concatenating module names with procedure names, with a connecting underscore. Thus, Procedure b_c in Module a and Procedure c in Module a_b both lead to the text symbol a_b_c in the object file.
This problem is present in the 13.2 compiler (Windows) as well. It cannot be resolved by compiling each module with a separate invocation of the compiler.
Until the bug is fixed, the only workaround that I can think of is to use module names that, when concatenated with procedure names, do not result in the clash described above. Had the compiler used a character other than the underscore, preferably a character that is not allowed in Fortran names, to connect the module name to the procedure name, the problem would not have arisen.
I think you are right. So, there is no other work around but to choose module names that combined with the subroutine names will not lead to this conflict.
Hi fanourg and mecej4,
I discussed this with our compiler architect. This was a design decision made long ago made necessary by High Performance Fortran (HPF). The name convention was keep and this problem does come up occasionally (the last time he remembers was five years ago).
There are probably ways in which we could fix it, but doing it in a way that retains backward compatibility, uses symbols that are accepted by the assembler, and would not simply reformulate the problem, would be difficult. He’ll see if he can come up with an elegant solution, but otherwise, it’s probably not something we’ll fix any time soon.