Someone please look into the case. These USE statements in MODULE scope (Tip 1) were correctly compiled but those in SUBMODULE scope(Tip 2) were not. The error for those in SUBMODULE scope is:
error #6580: Name in only-list does not exist or is not accessible. [FUNC]
Compiler version: 2018 initial.
BTW, only one scope of USE statements were used when testing. Appreciate any replies.
Is this legal to have multiple definitions in the use.... only statement?
module test use test1, only: func ! <---1 use test2, only: func ! <---1 use test3, only: func ! <---1 use test4, only: func ! <---1 implicit none interface module subroutine sub() end subroutine sub end interface end module test
and the same for the submodule
submodule(test) testsubmodule use test1, only: func ! <---2 use test2, only: func ! <---2 use test3, only: func ! <---2 use test4, only: func ! <---2 implicit none contains module procedure sub end procedure sub end submodule testsubmodule
PSXE 18 update one delivers the same error:
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R ) 64, Version 126.96.36.199 Build 20171018 Copyright (C) 1985-2017 Intel Corporation. All rights reserved. test.f90(102): error #6580: Name in only-list does not exist or is not accessibl e. [FUNC] use test1, only: func ! <---2 ---------------------^ compilation aborted for test.f90 (code 1)
If you comment out the multiple definition of 'use... only: func' in the submodule, there is no error. The multiple definition in the module seems be be accepted.
This is a known bug in that version (also 18.0.1). I would have expected 18.0.2 to be out by now, not sure what the delay is.
Hi Steve, do you refer to the submodule bug introduced with 18.0.1 (e.g. https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/755658) or is this a different issue?
ps: got it, func is generic, defined with different integer kinds in each module. Never saw it distributed over different modules. Nice feature.
All I know is that the symptom is similar to what has been reported before. Someone from Intel will want to check on it.