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

Entity name collision

OP1
New Contributor II
442 Views

Could the experts on this forum chime in on the following example, where it seems that the variable I (obtained in the submodule SM2 by USE association) takes precedence over the variable I declared in the parent module of SM2? The IMPORT, ALL statement does not detect the name collision here either, is this expected?

If those two facts are normal behavior, can somebody point me at the correct location in the fortran standard? I couldn't find an answer to those questions there.

 

 

 

MODULE M1
IMPLICIT NONE (TYPE, EXTERNAL)
INTEGER :: I = 1
END MODULE M1

MODULE M2
IMPLICIT NONE (TYPE, EXTERNAL)
INTEGER :: I = 2
INTERFACE
    MODULE SUBROUTINE S
    IMPLICIT NONE (TYPE, EXTERNAL)
    END SUBROUTINE S
END INTERFACE
END MODULE M2

SUBMODULE (M2) SM2
USE M1
IMPORT, ALL
IMPLICIT NONE (TYPE, EXTERNAL)
CONTAINS
    MODULE SUBROUTINE S
    IMPLICIT NONE (TYPE, EXTERNAL)
    WRITE(*, *) I
    END SUBROUTINE S
END SUBMODULE SM2

PROGRAM P
USE M2
IMPLICIT NONE (TYPE, EXTERNAL)
CALL S
END PROGRAM P

 

 

6 Replies
IanH
Honored Contributor II
414 Views

The body of subroutine `S` accesses `I` via host association from submodule `SM2` of module `M2`.

Without the IMPORT, ALL statement, submodule `SM2` would access `I` via use association from module M1.  The use association would make the `I` from the host of the submodule, module `M2`, inaccessible per F2018 19.5.1.4 - "If an entity that is accessed by use association has the same nongeneric name as a host entity, the host entity is inaccessible by that name".

With the presence of IMPORT, ALL, I think F2018 constraint C8012 should come into play "An entity whose name appears as an import-name or which is made accessible by an IMPORT, ALL statement shall not appear in any context described in 19.5.1.4 that would cause the host entity of that name to be inaccessible.".  That constraint isn't being diagnosed, so I consider this a compiler bug.

 

(I say "I think" because the "appear in any context" thing is a bit marginal - the identifier `I` doesn't actually *appear* in one of the contexts listed in that section - what appears is the name of a module that happens to define an entity with the name `I`.  Probably worth getting this language clarified - "shall not meet the conditions described in 19.5.1.4" or similar.

I note that non-generic name clashes via USE are ok as long as the clashing non-generic identifier "is not used".  Rules for IMPORT, ALL appear to be different - the potential for a clash would appear to trigger the constraint, even if the identifier subsequently is not used.  I wonder whether this inconsistency was the intent of the language designers.)

0 Kudos
OP1
New Contributor II
394 Views

@IanH thanks! I also think this is a bug: the presence of the IMPORT, ALL statement on line 18 should lead to an error message, which currently is not issued (ifort and ifx exhibit the same behavior).

@Barbara_P_Intel here is another one for your team!

0 Kudos
jdelia
New Contributor I
389 Views

Also agree, the presence of the IMPORT, ALL in statement on line 18 should lead to an error message, e.g. gfortran gives the following one:

$ gfortran -march=native -mtune=native -fall-intrinsics -fassociative-math -fautomatic -fcx-fortran-rules -fcheck=all -fcoarray=lib -fimplicit-none -fmax-errors=4 -fPIC -std=f2018 -Wall -Waliasing -Wno-array-temporaries -Wcharacter-truncation -Werror -Wextra -Wimplicit-interface -Wimplicit-procedure -Wintrinsic-shadow -Wline-truncation -Wrealloc-lhs-all -Wsurprising -Wtabs -Wunused-parameter -Wno-unused-function -Wno-unused-value -Wno-compare-reals -O2 -c test198.f90

18 | import, all
      |             1
Error: IMPORT statement at (1) only permitted in an INTERFACE body

0 Kudos
OP1
New Contributor II
388 Views

This is a different issue here - what you are observing is the inability of gfortran to comply with the F2018 feature that DOES allow IMPORT statements in submodules, module procedures, contained procedures, block constructs, and interfaces (not just interfaces as was the case for fortran standards older than F2018). See my other recent posts on the topic!

0 Kudos
jdelia
New Contributor I
384 Views

Yes, yes: I saw your recent posts on the topic. You're right! Regards.

0 Kudos
Barbara_P_Intel
Moderator
341 Views

You all convinced me! I filed CMPLRLLVM-48432.

Thanks, @OP1, for the concise reproducer.


0 Kudos
Reply