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

Possible Fortran Standards Violation in ifx 2025.3

Matt_Thompson
Novice
944 Views

This is an odd one. I have a code that ifx compiles when as far as I (and NAG Fortran and Flang) can tell, it should not. Here is a reproducer:

module Recon1d_PCM
   type PCM
      real :: a
   end type PCM
end module Recon1d_PCM

module MOM_remapping2

#ifdef DECLARE_IN_MODULE
use Recon1d_PCM, only : PCM
#endif
implicit none ; private

public remapping_unit_tests

contains

logical function remapping_unit_tests()
#ifndef DECLARE_IN_MODULE
   use Recon1d_PCM, only : PCM
#endif
   type(PCM) :: PCM
end function remapping_unit_tests

end module MOM_remapping2

In the end this code is doing:

type(PCM) :: PCM

which should not be allowed in Fortran. And most small reproducers you can make would fail. But ifx (and gfortran) allow this if the PCM use is done at the module level as seen above.

For example, if you save the above code as "repro_typeconflict.F90":

> ifx --version
ifx (IFX) 2025.3.0 20251010
Copyright (C) 1985-2025 Intel Corporation. All rights reserved.

> ifx repro_typeconflict.F90
repro_typeconflict.F90(22): error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [PCM]
   type(PCM) :: PCM
----------------^
repro_typeconflict.F90(18): warning #6178: The return value of this FUNCTION has not been defined.   [REMAPPING_UNIT_TESTS]
logical function remapping_unit_tests()
-----------------^
compilation aborted for repro_typeconflict.F90 (code 1)

> ifx -DDECLARE_IN_MODULE repro_typeconflict.F90
repro_typeconflict.F90(18): warning #6178: The return value of this FUNCTION has not been defined.   [REMAPPING_UNIT_TESTS]
logical function remapping_unit_tests()
-----------------^
/ford1/share/gmao_SIteam/intel/oneapi/2025/compiler/2025.3/lib/for_main.o: In function `main':
for_main.c:(.text+0x19): undefined reference to `MAIN__'

 As you can see, without the "-DDECLARE_IN_MODULE" ifx is not happy. With it, it is fine. gcc 15.2 is the same.

NAG Fortran is not happy either way:

> nagfor -fpp -DDECLARE_IN_MODULE repro_typeconflict.F90
NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7236
Error: repro_typeconflict.F90, line 22: Redeclaration of symbol PCM from USEd module RECON1D_PCM
       detected at PCM@<end-of-statement>
Error: repro_typeconflict.F90, line 22: Data type given to inappropriate symbol PCM
       detected at PCM@<end-of-statement>
Warning: repro_typeconflict.F90, line 23: Function REMAPPING_UNIT_TESTS has not been assigned a value
[NAG Fortran Compiler pass 1 error termination, 2 errors, 1 warning]

> nagfor -fpp repro_typeconflict.F90
NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7236
Error: repro_typeconflict.F90, line 22: Redeclaration of symbol PCM from USEd module RECON1D_PCM
       detected at PCM@<end-of-statement>
Error: repro_typeconflict.F90, line 22: Data type given to inappropriate symbol PCM
       detected at PCM@<end-of-statement>
Warning: repro_typeconflict.F90, line 23: Function REMAPPING_UNIT_TESTS has not been assigned a value
[NAG Fortran Compiler pass 1 error termination, 2 errors, 1 warning]

And neither is flang:

> flang --version
flang version 22.1.0-rc3 (git@github.com:GEOS-ESM/build-llvm-flang.git 4b7685b9b8f0da358165f3a32d0c486fbed137ea)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /ford1/share/gmao_SIteam/llvm-flang/22.1.0-rc3/bin

> flang  repro_typeconflict.F90
error: Semantic errors in repro_typeconflict.F90
./repro_typeconflict.F90:22:17: error: 'pcm' is use-associated from module 'recon1d_pcm' and cannot be re-declared
     type(PCM) :: PCM
                  ^^^
> flang -DDECLARE_IN_MODULE repro_typeconflict.F90
error: Semantic errors in repro_typeconflict.F90
./repro_typeconflict.F90:22:9: error: 'pcm' from host is not accessible
     type(PCM) :: PCM
          ^^^
./repro_typeconflict.F90:22:17: because: 'pcm' is hidden by this entity
     type(PCM) :: PCM
                  ^^^

though it is unhappy in slightly different ways.

0 Kudos
5 Replies
Matt_Thompson
Novice
943 Views

Also, here is the "simple" test:

type :: PCM
   integer :: a
end type PCM

type(PCM) :: PCM

end

and ifx does not like it:

> ifx test.F90
test.F90(5): error #6406: Conflicting attributes or multiple declaration of name.   [PCM]
type(PCM) :: PCM
-------------^
compilation aborted for test.F90 (code 1)
0 Kudos
Steve_Lionel
Honored Contributor III
878 Views

The "simple" test is too simple. In order to show the issue, the type PCM must be host-associated. For example:

type :: PCM
   integer :: a
end type PCM
contains
subroutine test
type(PCM) :: PCM
end subroutine test
end

F2023 19.3.1 (Classes of local identifiers) provides four classes of local identifiers, with named variables and nonintrinsic types both being class 1. Paragraph 3 then says:

Within its scope, a local identifier of one class shall not be the same as another local identifier of the same class, except that a generic name may be the same as the name of a procedure as explained in 15.4.3.4 or the same as the name of a derived type (7.5.10). A local identifier of one class may be the same as a local identifier of another class.

In your original example with the define, and my reduced example, "PCM" is both a named variable and a nonintrinsic type, so it's not allowed for these to share a name. Host association and use association are somewhat different in effect, but here the compiler should be looking for any accessible definition of "PCM" to detect a conflict.

0 Kudos
Matt_Thompson
Novice
721 Views

@Steve_Lionel  Thanks for the clarification. (And sorry for the late reply, Outlook decided recently all Intel Forum posts are junk...along with some other email replies I'd been waiting for. :/)

Your reproducer code seems to "work" for me as in I assume it should fail and does not.

0 Kudos
Steve_Lionel
Honored Contributor III
714 Views
0 Kudos
Igor_V_Intel
Moderator
411 Views

Escalated to Intel Fortran developers (CMPLRLLVM-74140). Thank you for brining it to our attention.


0 Kudos
Reply