Bug with IMPORT and SELECT TYPE

[OP1]

It's starting to feel like there is a substantial issue lurking under the surface with IMPORT statements... Building on top of my previous post (IMPORT and ASSOCIATE), here is another bug report, this time when using IMPORT and SELECT TYPE.

This bug will be triggered by uncommenting the IMPORT, ALL statement on line 53 (the code compiles fine when that line is commented out). Both the latest ifort and ifx compilers will produce error messages that are nonsensical.

MODULE M
IMPLICIT NONE (TYPE, EXTERNAL)
TYPE F
    INTEGER :: VALUE
    CONTAINS
        PROCEDURE :: GET_VALUE => F_GET_VALUE
END TYPE F
TYPE W
    CLASS(F), ALLOCATABLE :: F
END TYPE W
TYPE T
    TYPE(W), ALLOCATABLE :: W(:)
    CONTAINS
        PROCEDURE :: F_GET_VALUE => T_F_GET_VALUE
END TYPE T
INTERFACE
    MODULE SUBROUTINE F_GET_VALUE(SELF, VALUE)
    IMPORT, ALL
    IMPLICIT NONE (TYPE, EXTERNAL)
    CLASS(F), INTENT(IN) :: SELF
    INTEGER, INTENT(OUT) :: VALUE
    END SUBROUTINE F_GET_VALUE
    MODULE SUBROUTINE T_F_GET_VALUE(SELF, I, VALUE)
    IMPORT, ALL
    IMPLICIT NONE (TYPE, EXTERNAL)
    CLASS(T), INTENT(IN) :: SELF
    INTEGER, INTENT(IN)  :: I
    INTEGER, INTENT(OUT) :: VALUE
    END SUBROUTINE T_F_GET_VALUE
END INTERFACE
END MODULE M


SUBMODULE (M) F_GET_VALUE
IMPORT, ALL
IMPLICIT NONE (TYPE, EXTERNAL)
CONTAINS
    MODULE SUBROUTINE F_GET_VALUE(SELF, VALUE)
    IMPORT, ALL
    IMPLICIT NONE (TYPE, EXTERNAL)
    CLASS(F), INTENT(IN) :: SELF
    INTEGER, INTENT(OUT) :: VALUE
    VALUE = SELF%VALUE
    END SUBROUTINE F_GET_VALUE
END SUBMODULE F_GET_VALUE


SUBMODULE (M) T_F_GET_VALUE
IMPORT, ALL
IMPLICIT NONE (TYPE, EXTERNAL)
CONTAINS
    MODULE SUBROUTINE T_F_GET_VALUE(SELF, I, VALUE)
    !IMPORT, ALL
    IMPLICIT NONE (TYPE, EXTERNAL)
    CLASS(T), INTENT(IN) :: SELF
    INTEGER, INTENT(IN)  :: I
    INTEGER, INTENT(OUT) :: VALUE
    SELECT TYPE (THIS => SELF%W(I)%F)
        CLASS IS (F)
            CALL THIS%GET_VALUE(VALUE)
    END SELECT
    END SUBROUTINE T_F_GET_VALUE
END SUBMODULE T_F_GET_VALUE

[jdelia]

The same answer here (as my reply for your post "Bug with IMPORT and ASSOCIATE"), i.e.

$ gfortran --version
GNU Fortran (GCC) 12.3.1 20230508 (Red Hat 12.3.1-1)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gfortran -march=native -mtune=native -m64 -fall-intrinsics -fcheck=all -fimplicit-none -fmax-errors=4 -fno-finite-math-only -fPIC -pthread -std=f2018 -Wall -Waliasing -Warray-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 -flto -O2 -c test192.f90
test192.f90:22:13:

22 | import, all
| 1
Error: F2008: C1210 IMPORT statement at (1) is not permitted in a module procedure interface body
test192.f90:29:13:

29 | import, all
| 1
Error: F2008: C1210 IMPORT statement at (1) is not permitted in a module procedure interface body
f951: Fatal Error: Module file ‘m.smod’ has not been generated, either because the module does not contain a MODULE PROCEDURE or there is an error in the module.
compilation terminated.

Maybe, is there another way to do it such that it is F2008 standard compliant?

Regards.

[OP1]

Well, it appears that gfortran also gets it wrong... the use of an IMPORT statement is not limited to interfaces. See this paragraph from the Intel documentation:

An IMPORT statement can appear in a submodule, module procedure, a contained procedure, the specification part of a BLOCK construct, or in an interface body. It can not appear in the specification part of a main program, external procedure, module, or block data except in an interface body.

[Paul_Thomas]

nagfor gives a rather more verbose version of the same error.

Further to my remark about nagfor in the previous topic, on rereading the F2018 standard it does seem to me that all three compilers have it wrong post-F2003, where we find:

C1210 (R1209) The IMPORT statement is allowed only in an interface-body.

Regards

Paul

[andrew_4619]

[Paul_Thomas]

Existing gcc Bugzilla PRs 108650/106035 apply

Paul

[Steve_Lionel]

IMPORT in a contained subroutine was new in F2018. Intel Fortran claims to support all of F2018, thus Intel's documentation is correct. The only other compiler I know of to support all of F2018 is Cray.

[Barbara_P_Intel]

@OP1, what compiler options are you using? Your reproducer is compiling without error for me.

$ ifx --version
ifx (IFX) 2023.1.0 20230320
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

$ ifx -c select.f90
$

Never mind... I see you commented out the offending line!

ifx -c select.f90
select.f90(60): error #6404: This name does not have a type, and must have an explicit type.   [VALUE]
            CALL THIS%GET_VALUE(VALUE)
--------------------------------^
select.f90(52): warning #6843: A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value.   [VALUE]
    MODULE SUBROUTINE T_F_GET_VALUE(SELF, I, VALUE)
---------------------------------------------^
compilation aborted for select.f90 (code 1)

[Barbara_P_Intel]

Another bug filed for you, @OP1! It's CMPLRLLVM-48315. I'll let you know about the fix.

[Barbara_P_Intel]

This bug is fixed in an early version of ifx, 2024.2.1. Look for it to be released mid-2024, just a few months from now.