Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
The Intel sign-in experience is changing in February to support enhanced security controls. If you sign in, click here for more information.

Bug with user defined assignment

OP1
New Contributor II
220 Views

Unless there is some obscure part of the standard that escapes me, I believe that this is a bug:

In the code below, compiled with the latest ifort classic 2021.5.0 compiler, the PRIVATE statement in the module M is not honored in the USE statement of the main program. The whole thing compiles just fine when a compile-time error should be issued.

Note: I observed that this problem does not exist with user-defined operators; only with user defined assignment.

MODULE M
IMPLICIT NONE (TYPE, EXTERNAL)
PRIVATE
INTERFACE ASSIGNMENT(=)
    MODULE SUBROUTINE F(S, I)
    IMPLICIT NONE (TYPE, EXTERNAL)
    INTEGER, INTENT(IN) :: I
    CHARACTER(LEN = 15), INTENT(OUT) :: S
    END SUBROUTINE F
END INTERFACE
END MODULE M

SUBMODULE (M) F
IMPLICIT NONE (TYPE, EXTERNAL)
CONTAINS
    MODULE SUBROUTINE F(S, I)
    IMPLICIT NONE (TYPE, EXTERNAL)
    INTEGER, INTENT(IN) :: I
    CHARACTER(LEN = 15), INTENT(OUT) :: S
    WRITE(S, '(I15)') I
    END SUBROUTINE F
END SUBMODULE F

PROGRAM P
USE M, ONLY : ASSIGNMENT(=)
CHARACTER(LEN = 15) :: S
S = 1
END PROGRAM P
0 Kudos
4 Replies
FortranFan
Honored Contributor II
205 Views

For whatever it's worth, I agree the issue with PRIVATE in relation to ASSIGNMENT is a bug in Intel Fortran.

 

Intel staff: please note there is another issue in Intel Fortran as well that will be worth your Fortran team's attention: the use of `F` as submodule identifier that is global in relation to the module subprogram identifier too as `F'.  That does not conform to the standard, if I am not mistaken.  Here it will be good if Intel Fortran can diagnose this even if the standard may not require it (I'll need to check) i.e., Intel Fortran users will benefit greatly from an error/warning here.

OP1
New Contributor II
181 Views

I vaguely remember asking here if having the same name for a submodule and a contained procedure in that submodule was an issue and was told that it was acceptable. I actually like this 'feature'. When following a one-procedure-per-submodule coding style it helps avoid the problem of figuring out a new name for the submodule (a nice thing when you have 1000s upon 1000s of procedures).

IanH
Black Belt
162 Views

@FortranFan wrote:

Intel staff: please note there is another issue in Intel Fortran as well that will be worth your Fortran team's attention: the use of `F` as submodule identifier that is global in relation to the module subprogram identifier too as `F'.  That does not conform to the standard, if I am not mistaken.  Here it will be good if Intel Fortran can diagnose this even if the standard may not require it (I'll need to check) i.e., Intel Fortran users will benefit greatly from an error/warning here.


This practice conforms to the standard.  See F2018 14.2.3p2.  The identifier for a submodule is the combination of the ancestor module and the submodule name, a submodule name on its own is not a global or local identifier.

Ron_Green
Moderator
152 Views

Thank you for bringing this to the Forum.

Bug ID is CMPLRLLVM-36847


Reply