Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Generic procedures with submodules

Simon_Geard
New Contributor I
588 Views

I've been trying to do this but can't figure out the correct syntax (It works when everything is in one module).

parent.f90:

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

child.f90

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

modprob.f90:

program modprob
    use parent

        call wri(3)

end program modprob

Then

ifort /nologo parent.f90 child.f90 modprob.f90 /Femodprob.exe

gives

child.f90(7): error #6285: There is no matching specific subroutine for this generic subroutine call.   [PRIN]
           call prin(c)
----------------^
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.

 

0 Kudos
10 Replies
Simon_Geard
New Contributor I
588 Views

I've just tried this with gfortran 6.1 and it works, so I guess it's a compiler bug.

0 Kudos
Kevin_D_Intel
Employee
588 Views

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.

0 Kudos
Kevin_D_Intel
Employee
588 Views

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

    NOTE 2.4
    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)

0 Kudos
Simon_Geard
New Contributor I
588 Views

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.

0 Kudos
Kevin_D_Intel
Employee
588 Views

Yes, you're right. Not a viable work around then. I'll let you know what Development finds.

0 Kudos
Andrew_Smith
New Contributor III
588 Views

I hit this issue too while converting to submodules. Is there a targeted release for a fix please.

0 Kudos
Kevin_D_Intel
Employee
588 Views

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.

0 Kudos
OP1
New Contributor II
588 Views

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.

0 Kudos
Andrew_Smith
New Contributor III
588 Views

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?

0 Kudos
Kevin_D_Intel
Employee
588 Views

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.

0 Kudos
Reply