| August 30, 2009 10:00 PM PDT | |
This error is reported when an entity (procedure, variable, type, named constant, etc.) is declared in two different modules and is referenced. For example:
module MODA
integer I_GLOBAL
end module MODA
module MODB
integer I_GLOBAL
end module MODB
program CONFLICT
use MODA
use MODB
I_GLOBAL = 0
end program CONFLICT
In this example, the variable I_GLOBAL is defined in MODA and MODB, both modules are USEd and the variable is referenced. This last item is important: if the entity is not referenced in the program unit, then it is ok to have multiple entities of the same name visible. But, once you reference it, it is required that the name have a single definition point.
Note that if you have two modules which both USE the same definition, that is allowed, as there is only one original definition. For example:
module MODA
integer I_GLOBAL
end module MODA
module MODB
use MODA
end module MODB
module MODC
use MODA
end module MODB
program NO_CONFLICT
use MODB
use MODC
I_GLOBAL = 0
end program NO_CONFLICT
There are two typical approaches to resolving the issue. First, use an ONLY clause to specify only the desired names from each module. For example:
use MODA, only: SYMBOL1, SYMBOL2
use MODB, only: SYMBOL3, SYMBOL4
An alternative is to use a renaming clause to change the "local name" of the symbol you don't want to use to something that will not be referenced. For example:
use MODA, DUMMY1 => I_GLOBAL
Note that it is not sufficient to declare a local version of the entity that comes from the modules - this does not hide the module definitions and will result in a different error: Diagnostic 6401: The attributes of this name conflict with those made accessible by a USE statement.
The following known product defects cause this diagnostic to be improperly issued:
This article applies to: Intel® Fortran Compiler for Linux* Knowledge Base, Intel® Fortran Compiler for Mac OS X* Knowledge Base, Intel® Visual Fortran Compiler for Windows* Knowledge Base
For more complete information about compiler optimizations, see our Optimization Notice.
Comments (5) 
| January 7, 2010 11:21 PM PST
brchrisman
|
From 11.3 in f95, "The module name is global to the program, and shall not be the same as the name of any other program unit, external procedure, or common block in the program, nor be the same as any local name in the module." In my example, the 'use one' would make type 'two' a local name in the 'two' module, which causes the conflict when the derived type is referenced? |
| January 8, 2010 7:02 AM PST
Steve Lionel (Intel)
| Yes, that's the rule that makes this code invalid. |
| June 15, 2010 7:11 AM PDT
Joe Zuntz | Are there any ifort 11.1 compiler flags that would help track down exactly which modules define the symbol? If you have a bit of a web of modules this can take a while. |
| June 16, 2010 12:41 PM PDT
Steve Lionel (Intel)
| Sorry, no, we don't. I agree that would be nice. |
Trackbacks (0)
Leave a comment 
Steve Lionel (Intel)
|


brchrisman
40
The spec doesn't seem to help here (I'm looking at an f95 'final draft', if there's a free f90 spec pdf around somewhere, please let me know, I couldn't find it). The section 14.1.2 identifies three classes of entities which aren't allowed to conflict, but module name/identifier doesn't seem to be listed in any of them?
This throws an error under gfortran and ifort, but pgf accepts it. I'm compiling code that originally compiled on pgf, which is how I noticed it. Am I interpreting this correctly?
-Brian
module one
type two
integer :: aaa
end type
end module
module two
use one
contains
integer function test()
type (two) :: my_two
end function
end module
program main
end program
[bc@anubis sample]$ ifort test.f90
test.f90(11): error #6405: The same named entity from different modules and/or program units cannot be referenced. [TWO]
type (two) :: my_two
------------^