Bug with user defined assignment

[OP1]

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

[FortranFan]

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]

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]

---

@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]

Thank you for bringing this to the Forum.

Bug ID is CMPLRLLVM-36847