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

Conflict between module name and variable name

OP1
New Contributor II
778 Views

Shouldn't the compiler (XE 17) issue an error due to the duplicate use of name S in this example?

MODULE S
IMPLICIT NONE
INTERFACE
    MODULE FUNCTION F(S)
        IMPLICIT NONE
        INTEGER  :: S,F
    END FUNCTION F
END INTERFACE
END MODULE S

 

0 Kudos
7 Replies
andrew_4619
Honored Contributor II
778 Views

There is no conflict with S

0 Kudos
OP1
New Contributor II
778 Views

Hmmm. Something fishy is going on here. I have a set of modules and module functions that lead to a "error LNK2019: unresolved external symbol...". These module functions take a dummy argument that has the same name as the module name. The problem disappear if I rename either the module or the dummy argument.

I am going to try to create a small reproducer.

0 Kudos
OP1
New Contributor II
778 Views

ok, here is the bug - there may be more than one actually (unless my understanding of what happens here is incorrect).

The code (as is) will not build (a LNK2019 error is issued).

1. If MODULE S on line 1 is changed to something else, say, MODULE S1 (and the rest of the code is changed to accommodate this new name) then the code compiles, builds and runs.

2. If MODULE S stays the same, but the name of the variable S on line 4 is changed to S1, then the code compiles, builds and runs.

3. If the (empty) submodule SI is entirely eliminated (and line 19 is changed accordingly), then the code compiles, builds and runs.

So, there is definitely some strangeness occurring here.

 

MODULE S
IMPLICIT NONE
INTERFACE
    MODULE FUNCTION F(S)
        IMPLICIT NONE
        CHARACTER(LEN=*),INTENT(IN)  :: S
        CHARACTER(LEN=:),ALLOCATABLE :: F
    END FUNCTION F
END INTERFACE
END MODULE S


SUBMODULE (S) SI
IMPLICIT NONE
INTEGER :: I
END SUBMODULE SI


SUBMODULE (S:SI) SF
IMPLICIT NONE
CONTAINS
    MODULE FUNCTION F(S)
        IMPLICIT NONE
        CHARACTER(LEN=*),INTENT(IN)  :: S
        CHARACTER(LEN=:),ALLOCATABLE :: F
        F = S
    END FUNCTION F
END SUBMODULE SF


MODULE M
IMPLICIT NONE
TYPE T
    CHARACTER(LEN=:),ALLOCATABLE :: S
    CONTAINS
    PROCEDURE,PASS :: P
END TYPE T
PRIVATE :: P
INTERFACE
    MODULE SUBROUTINE P(V,ST)
        IMPLICIT NONE
        CHARACTER(LEN=*),INTENT(IN) :: ST
        CLASS(T),INTENT(INOUT) :: V
    END SUBROUTINE P
END INTERFACE
END MODULE M


SUBMODULE (M) SM
IMPLICIT NONE
CONTAINS
    MODULE SUBROUTINE P(V,ST)
        USE S
        IMPLICIT NONE
        CHARACTER(LEN=*),INTENT(IN) :: ST
        CLASS(T),INTENT(INOUT) :: V
        V%S = F(ST)
    END SUBROUTINE P
END SUBMODULE SM


PROGRAM MAIN
USE M
IMPLICIT NONE
TYPE(T) :: TT
CALL TT%P('test')
WRITE(*,*) TT%S
END PROGRAM MAIN

 

0 Kudos
Steven_L_Intel1
Employee
778 Views

Yes, that's a bug. I'll report it. Thanks. Issue ID DPD200414371.

0 Kudos
andrew_4619
Honored Contributor II
778 Views

Does that work if all the SUBMODULEs are in separate files BTW?

0 Kudos
OP1
New Contributor II
778 Views

Yes, the behavior is the same (that is, buggy) whether the source is spread over multiple source files or not.
 

0 Kudos
Steven_L_Intel1
Employee
778 Views

I expect this bug to be fixed in Update 2 to Parallel Studio XE 2017.

0 Kudos
Reply