Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28455 Discussions

error #6405: The same named entity from different modules and/or program units cannot be referenced.

Todor_K_
Novice
2,842 Views

Hi,

I am getting the error message from the title when compiling the code in which there are many modules having the initialisation procedures with the same name, init. Normally, when the various modules use each other, I mask those init procedures with use somemodule, forgetme => init. However, intel fortran compiler 13.1.3 20130607 fails to compile it and, what is worse, it is not easy to say where exactly the error originates from, since it is issued from some temporary .i90 file the compiler made as it went about its business.

Both ifort 15.0.0 and gfortran 4.9.1 are able to compile the code without issues. However, I would like to be able to use 13.1.3 compiler too. Is there any way to do this, without modifying the code itself?

1 Solution
Steven_L_Intel1
Employee
2,842 Views

Probably not. It's not as if there's some compiler switch that says "make all the bugs go away". In particular, there is no control over the processing of modules.

The .i90 is from the use of preprocessing, but I agree that this message could be more helpful in identifying the modules from which the allegedly conflicting definitions occur.

View solution in original post

0 Kudos
6 Replies
Steven_L_Intel1
Employee
2,843 Views

Probably not. It's not as if there's some compiler switch that says "make all the bugs go away". In particular, there is no control over the processing of modules.

The .i90 is from the use of preprocessing, but I agree that this message could be more helpful in identifying the modules from which the allegedly conflicting definitions occur.

0 Kudos
Todor_K_
Novice
2,842 Views

Steve Lionel (Intel) wrote:

Probably not. It's not as if there's some compiler switch that says "make all the bugs go away". In particular, there is no control over the processing of modules.

I would be happy with a magical circumvention procedure for just this one bug. :)

 

Thanks for the answer, though.

0 Kudos
FortranFan
Honored Contributor II
2,842 Views

Steve,

With respect to the background situation presented by the OP where

Tudor K. wrote:
 there are many modules having the initialisation procedures with the same name, init. Normally, when the various modules use each other, I mask those init procedures with use somemodule, forgetme => init.

will it be possible for you to comment on the idea in this thread at comp,lang.fortran where I'm wondering about the concept of a fully qualified name for module entities as an additional way of avoid name conflicts: https://groups.google.com/forum/#!topic/comp.lang.fortran/sNNnQaoqC9I.  The question is whether something like the case below can be supported?

module m1
contains
   subroutine init()
   end subroutine init 
end module 

module m2
contains
   subroutine init()
   end subroutine init 
end module
 
program p
   
   use m1 !.. or use m1, only : init
   use m2 !.. or use m2, only : init

   call m1%init()  !.. currently not supported in the standard, 
   call m2%init()  !   but can it be?

end program 

How do you think Intel Fortran compiler team would view the introduction of such syntax into the standard?  Note the % delimiter is arbitrary such as call m1%init().  It can be something else; the idea is to be able to use <module name>[delimiter]<module entity> syntax for disambiguation as an alternative to the current renaming method which is ok but which can be unwieldy.

Also, in large "inherited" codes with poor documentation, coding practices, etc., it becomes tedious to keep track of module entities.  With the editors these days, it is rather easy to change a reference to foo (assuming it is use'd from m) to m%foo globally which can then greatly increase code clarity; I think this will be true even when ONLY keyword is applied in USE stataments (which, by the way, is one of the first changes I make to code that doe 

Thanks, 

0 Kudos
Steven_L_Intel1
Employee
2,842 Views

Whether or not it could be supported, our position is that this is a matter best left up to the Fortran standard. An extension of this nature, supported by a single vendor, is not in the best interests of the language. I'll note that many of our customers tell me that they won't use a language feature unless it is supported by a minimum of three or even four different compilers.

There has been some discussion on the committee of a "namespace qualifier", but I haven't seen a formal proposal. I doubt the syntax you propose would be accepted as it looks too much like a type-bound procedure reference. There's also a general conflict with the rules governing global and local identifiers. Maybe this is something that will come up for the standard after F2015.

0 Kudos
Todor_K_
Novice
2,842 Views

Guile Scheme,at least (not sure about R6RS), introduces renaming by prefix. That would spare us of the need to rename each conflicting function by hand, while retaining the great flexibility that is a major advantage of Fortran modules system over various other languages.

I was thinking of something like: use m1, prefix : m1_ ; then call m1's init with m1_init.

This way, if you're a fan of Java/C++-esque approach to stuffing extra red tape into procedure calls, you would be free to implement it with a minimum of fuss.

0 Kudos
FortranFan
Honored Contributor II
2,842 Views

Thanks Steve.  No, I did not mean intend to imply any Intel-specific extension along these lines.  I was simply trying to get a sense whether my primary Fortran compiler vendor would have any compiler-specific reason for opposition to such a change in the standard.  (Besides a few exceptions related to OS-specific needs (via !DIR$ ATTRIBUTE), I insist on standard Fortran in the code we support.)

A "namespace qualifier" will be a good thing.  Hope there will be progress on this front in the standard.

0 Kudos
Reply