PGI User Forum

[fanourg]

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

[mkcolg]

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

[fanourg]

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.

[mecej4]

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.

[fanourg]

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.