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

[everythingfunctional]

I'm getting this error where I believe it is incorrect. I'm having a hard time determining why or how to create a simpler reproducer though. The code can be found here for anyone who would be interested in helping investigate: https://gitlab.com/everythingfunctional/rojff/-/tree/try-with-intel?ref_type=heads

Trying to compile with the latest version of ifx I get:

$ fpm test --compiler ifx
...
././src/rojff/fallible/string_s.f90: error #6405: The same named entity from different modules and/or program units cannot be referenced.   [ERROR_LIST_T]
././src/rojff/fallible/string_s.f90(140): catastrophic error: Too many errors, exiting
compilation aborted for ././src/rojff/fallible/string_s.f90 (code 1)

To explain what I believe to be relevant points:

error_list_t is a derived type defined in an external dependency, erloff. It is defined in a module named erloff_error_list_m. It's structure constructor is overloaded, so references the function error_list_t, do not refer to the intrinsic one (not entirely sure this is relevant). It is not intended erloff modules to be used directly, but rather a module named erloff is provided which uses all the relevant modules to re-export what is intended to be part of the public API.

The file referenced in the error message contains a submodule named rojff_fallible_json_string_s, which is a child of the module rojff_fallible_json_string_m. The module contains a use statement from erloff which brings error_list_t into scope. The submodule contains another use from erloff, which brings some other things into scope.

I understand that's a complicated scenario, but I've tried creating a minimal reproducer with those aspects and it doesn't elicit the error message. If anybody could provide other ideas or possible workarounds I'd appreciate it.

FYI, gfortran and nagfor can both compile and execute this code successfully, so I'm pretty confident this is a bug in ifx.

[FortranFan]

Attention: Intel Support team

@everythingfunctional ,

At first glance, your codebase appears very extensive with many dependencies to look through and thus prohibitive to me time-wise unfortunately.

But here's a simple example which you can review that, to me, is clearly a bug in Intel Fortran and which raises the same exception with IFORT and IFX.  Does your codebase involve the same pattern involving a type-bound procedure `USE`d directly and with a rename?  If yes, that might explain the issue and which then falls in Intel's court.  By the way, my view is any variant of the scenario I show around SUBMOULEs involving USE or IMPORT of type-bound procedures with possible renaming might raise the same exception.

module m
   type :: t
   contains
      procedure :: f
   end type 
contains
   function f( this ) result(r)
      class(t), intent(in) :: this
      integer :: r
      r = 0
   end function
end module
   use m, only : t, func => f, f
end

C:\temp>ifort /c /free /standard-semantics p.f
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.10.0 Build 20230609_000000
Copyright (C) 1985-2023 Intel Corporation.  All rights reserved.

p.f: error #6405: The same named entity from different modules and/or program units cannot be referenced.   [FUNC]
p.f(13): error #6581: Unresolved rename.   [FUNC]
   use m, only : t, func => f, f
--------------------^
compilation aborted for p.f (code 1)

C:\temp>ifx /c /free /standard-semantics p.f
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2023.2.0 Build 20230627
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

p.f: error #6405: The same named entity from different modules and/or program units cannot be referenced.   [FUNC]
p.f(13): error #6581: Unresolved rename.   [FUNC]
   use m, only : t, func => f, f
--------------------^
compilation aborted for p.f (code 1)

[everythingfunctional]

I do not have the pattern shown in your example, but it is an interesting guess. Perhaps it will help point the way towards the real culprit. Thanks for the thought.

[everythingfunctional]

As a second data point, the inference-engine project produces the same error.

https://github.com/everythingfunctional/inference-engine/tree/try-compiling-with-ifx

$ fpm build --compiler ifx --profile debug --flag "-coarray=single" --verbose
...
././src/inference_engine/inference_engine_s.f90(453): catastrophic error: Too many errors, exiting
compilation aborted for ././src/inference_engine/inference_engine_s.f90 (code 1)
././src/inference_engine/layer_s.f90: error #6405: The same named entity from different modules and/or program units cannot be referenced.   [STRING_T]
././src/inference_engine/layer_s.f90(179): catastrophic error: Too many errors, exiting
...

[Barbara_P_Intel]

@FortranFan, thank you for the simple reproducer. I filed a bug, CMPLRLLVM-52315. There will be a post here when it's fixed.

[gzengm]

@Barbara_P_Intel Any updates? I'm also experiencing this issue while compiling a large project with several thousand modules and submodules. I am using numerous generic names like "this," "res," and "value" for dummy arguments in type-bound procedures, and my code follows an object-oriented approach.

My current workaround is to rename the dummy arguments that trigger the "same named entity" error. However, this often leads to a cascade of module recompilations, which can take several hours to complete. Even more frustratingly, as I continue to expand the project, these naming conflicts reoccur in submodules, including ones that had previously compiled successfully. This issue is becoming increasingly disruptive and significantly slows down my development process.

[Ron_Green]

We are working on this error.  We have missed code freeze for the 2024.2 Update which will release in July.  So assuming we get this fixed in the next week or 2 we should be able to get this into the next release after that.  That release is the 2025.0 release that is due to release in November.