Bug with IMPORT and ASSOCIATE

[OP1]

This code (as is) triggers a compile-time error. This is incorrect since the code is valid.

Note that commenting out line 5 (the IMPORT statement) results in a code that compiles. So, there is some weird interaction between the ASSOCIATE and IMPORT statements here.

This issue occurs with both the latest ifx and ifort (2023.1.0).

MODULE M
IMPLICIT NONE (TYPE, EXTERNAL)
CONTAINS
    SUBROUTINE S(I)
    IMPORT, ALL
    IMPLICIT NONE (TYPE, EXTERNAL)
    INTEGER, INTENT(IN) :: I
    ASSOCIATE (I_LOC => I)
    END ASSOCIATE
    END SUBROUTINE S
END MODULE M

[jdelia]

Dear OP1,

Well, at least with:

$ 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 -o test191.exe test191.f90

test191.f90:5:11:

5 | import, all
   |             1
Error: IMPORT statement at (1) only permitted in an INTERFACE body
f951: all warnings being treated as errors

so that, is that line standar conforming?

Regards.

[OP1]

See my reply in the other post - gfortran does not get it right either.

[Paul_Thomas]

For what it's worth:

nagfor ../import1.f90 -O3
rm: cannot remove '*.original': No such file or directory
NAG Fortran Compiler Release 7.1(Hanzomon) Build 7115
Error: ../import1.f90, line 2: Syntax error
detected at NONE@(
Error: ../import1.f90, line 5: The IMPORT statement is only allowed in an INTERFACE body
detected at IMPORT@,
Error: ../import1.f90, line 5: Syntax error
detected at IMPORT@,
Error: ../import1.f90, line 6: Syntax error
detected at NONE@(
[NAG Fortran Compiler pass 1 error termination, 4 errors]

In my experience, nagfor does not often get such things wrong.

Regards

Paul

[andrew_4619]

The normal use of IMPORT is within interfaces. The standard excludes IMPORT form various places, my understanding is the you can have it in a contained subroutine of a subroutine but not a contained subroutine of a module. But reading  the f18 standard is is not 100% clear.

C896 (R867) An IMPORT statement shall not appear in the scoping unit of a main-program, external subprogram,
module, or block-data. 

Either which way "IMPORT, ALL" in the context of the original post has no meaning as all the module variables are already in scope.

[Steve_Lionel]

This use of IMPORT is new in F2018, which neither gfortran nor NAG Fortran support. "The IMPORT statement can appear in a contained subprogram or BLOCK construct, and can restrict access via host association; diagnosis of violation of the IMPORT restrictions is required." As best as I can tell, the example is valid F2018 (but not F2008 or earlier.)

[OP1]

Thanks Steve for confirming this, and yes, access restriction is exactly why we use IMPORT statements for our projects - this is a very convenient and nifty way to detect any name collision between local entities and host-associated entities.

It's also great in BLOCK statements, for the same purpose.

[andrew_4619]

Interesting point I had not considered. Yes that could be useful to prevent those hard to find bugs where a local trumps a module variable. 

[OP1]

It's really valuable to us indeed! Those programming mistakes are easy to make on really large projects (say, by new developers being onboarded, or by experienced developers with a failing memory) and they are really hard to track!

Our policy is thus to use IMPORT statements (any of the various forms those statements can take) everywhere they can be used.

For instance, we have a unit testing framework that relies extensively on BLOCK constructs, and having the guarantee that any potential conflict (between a local block entity and an entity of the host procedure) will be flagged by the compiler (when using an IMPORT statement in each block construct) is a godsend.

[Barbara_P_Intel]

@OP1, just want to confirm, is this the error message you get? I used the compiler that will be available mid-2023.

$ ifx -what m.f90
 Intel(R) Fortran 23.0-1769.01
m.f90(8): error #6404: This name does not have a type, and must have an explicit type.   [I]
    ASSOCIATE (I_LOC => I)
------------------------^
compilation aborted for m.f90 (code 1)

[jdelia]

Dear Barbara,

$ cat /proc/version
Linux version 6.3.4-101.fc37.x86_64 (mockbuild@bkernel02.iad2.fedoraproject.org) (gcc (GCC) 12.3.1 20230508 (Red Hat 12.3.1-1), GNU ld version 2.38-27.fc37) #1 SMP PREEMPT_DYNAMIC Sat May 27 15:09:40 UTC 2023

$ ifort --version
ifort (IFORT) 2021.9.0 20230302
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

$ ifort -warn all -O2 -o test191-ifort.exe -L${MKLROOT}/lib/intel64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -ldl test191.f90
test191.f90(8): error #6404: This name does not have a type, and must have an explicit type. [II]
associate (i_loc => ii)
------------------------^
test191.f90(8): remark #7712: This variable has not been used. [II]
associate (i_loc => ii)
------------------------^
test191.f90(4): remark #7712: This variable has not been used. [II]
subroutine ss (ii)
-----------------^
compilation aborted for test191.f90 (code 1)

$ ifx --version

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

$ ifx -warn all -O2 -o test191-ifx.exe -L${MKLROOT}/lib/intel64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -ldl test191.f90
test191.f90(8): error #6404: This name does not have a type, and must have an explicit type. [II]
associate (i_loc => ii)
------------------------^
test191.f90(8): remark #7712: This variable has not been used. [II]
associate (i_loc => ii)
------------------------^
test191.f90(4): remark #7712: This variable has not been used. [II]
subroutine ss (ii)
-----------------^
compilation aborted for test191.f90 (code 1)

[OP1]

@Barbara_P_Intel Yes it is! As I mentioned, there is probably a bigger problem lurking under the surface with IMPORT statements, so it's probably worth for your team to take a look into the implementation of this F2018 feature, otherwise it's going to be a game of whack-a-mole I am afraid.

[Barbara_P_Intel]

Whack-a-mole is great for venting frustations! 

[Barbara_P_Intel]

@jdelia, please upload your reproducer. The compiler team can take advantage of additional reproducers to ensure the fix.

[jdelia]

module m_modulo
implicit none (type, external)
contains
  subroutine ss (ii)
    import, all
    implicit none (type, external)
    integer, intent (in) :: ii
    associate (i_loc => ii)
    end associate
  end subroutine ss
end module m_modulo

[Barbara_P_Intel]

That was quick. Thanks!  

[Barbara_P_Intel]

I filed a bug for this, CMPLRLLVM-48313. Stay tuned for the fix.

[Barbara_P_Intel]

I just tried these reproducers with an early version of the 2024.0 compilers. I do not get an error message.

Look for these compilers in mid-2024.