topic Re: Bug with user defined assignment in Intel® Fortran Compiler

Bug with user defined assignment

OP1 — Tue, 12 Apr 2022 18:59:29 GMT

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

Re: Bug with user defined assignment

FortranFan — Tue, 12 Apr 2022 19:26:59 GMT

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.

Re: Bug with user defined assignment

OP1 — Tue, 12 Apr 2022 20:42:54 GMT

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).

Re: Bug with user defined assignment

IanH — Tue, 12 Apr 2022 22:25:04 GMT

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

Re:Bug with user defined assignment

Ron_Green — Wed, 13 Apr 2022 00:48:27 GMT

Thank you for bringing this to the Forum.

Bug ID is CMPLRLLVM-36847

Re: Bug with user defined assignment

Devorah_H_Intel — Thu, 03 Oct 2024 22:46:30 GMT

This issue was fixed and the fix will be available in the 2025.1 ifx release.