I've been trying to do this but can't figure out the correct syntax (It works when everything is in one module).
module parent interface prin module procedure prin_i module procedure prin_r end interface prin interface module subroutine wri(c) integer, intent(in) :: c end subroutine wri module subroutine prin_i(i) integer, intent(in) :: i end subroutine prin_i module subroutine prin_r(r) real, intent(in) :: r end subroutine prin_r end interface end module parent
submodule (parent) child contains module subroutine wri(c) integer, intent(in) :: c call prin(c) end subroutine wri module subroutine prin_i(i) integer, intent(in) :: i write(*,'(i0)') i end subroutine prin_i module subroutine prin_r(r) real, intent(in) :: r write(*,'(g0.6)') r end subroutine prin_r end submodule child
program modprob use parent call wri(3) end program modprob
ifort /nologo parent.f90 child.f90 modprob.f90 /Femodprob.exe
child.f90(7): error #6285: There is no matching specific subroutine for this generic subroutine call. [PRIN]
compilation aborted for child.f90 (code 1)
I've tried lots of syntax variations but can't figure this one out. Any ideas will be greatly appreciated, thanks.
When the interface declaration for prin also appears in the submodule and not the parent module, then the example compiles and runs successfully with ifort. At this moment, I'm not certain whether that's required.
I think your original example should compile based section 2.2.5 from the F2008 Working Document (J3/10-007r1, Nov. 24th, 2010).
6 2.2.5 Submodule
7 1 A submodule extends a module or another submodule.
8 2 It may provide definitions (12.6) for procedures whose interfaces are declared (22.214.171.124) in an ancestor module
9 or submodule. It may also contain declarations and definitions of other entities, which are accessible in its
10 descendants. An entity declared in a submodule is not accessible by use association unless it is a module procedure
11 whose interface is declared in the ancestor module. Submodules are further described in Clause 11.
A submodule has access to entities in its parent module or submodule by host association.
I will report this to Development.
(Internal tracking id: DPD200413153)
The change you suggest doesn't really work because you still can't make a call to prin in the main program (which you should be able to do) and you can't have the generic interface in both the module and submodule.
This was just recently fixed in our internal sources and is targeted for the first update of our upcoming newest PSXE 2017 release. That update is planned for the early-Q4 timeframe.
The workaround is to have each of the prin_r, prin_i and wri procedures in their own submodules. In general, I like to adhere to a strict one submodule/one procedure policy - just a personal preference though.
Thanks for that workaround OP, it works! I would not have imagined the implementers of the procedures would have affected ability of the compiler to resolve the correct specific since the interfaces should be all that is neeeded.
However it does mean a whole load of cludgy code changes for me.
To take advantage of submodules, we had planned to upgrade to XE2016 as it is now stable(ish) after several updates, rather than going for XE2017 as soon as its out. As submodules were a main feature of XE2016 will there be a fix for this version?
The fix was not applied to the 16.0 compiler branch from what I see in our internal tracking system and it came about after the code cutoff for the final planned PSXE 2016 update 4 in the coming months. I inquired w/Development about whether the fix can be added to the 16.0 branch in the event we turnout an additional unplanned PSXE 2016 update next year. Unfortunately, at this time, the fix will only be available beginning with the PSXE 2017 update 1 release. I’m sorry I do not have better news on this.