[Bug fortran/51268] [Regression] A subroutine can not know anymore its own interface

["bardeau at iram dot fr" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268

--- Comment #4 from Sebastien Bardeau <bardeau at iram dot fr> 2011-11-23 13:56:19 UTC ---
(In reply to comment #3)
> For links to the standards see:
>   http://gcc.gnu.org/wiki/GFortranStandards

Ok thank you for this link, very useful.


> I think the following of "11.2.2 The USE statement and use association" of
> Fortran 2008 should capture this:
> 
> "Two or more accessible entities may have the same local identifier only if
> the identifier is not used. The local identifier of any entity given
> accessibility by a USE statement shall differ from the local identifiers of
> all other entities accessible to the scoping unit."

So basically you mean that in the gfortran implementation the subroutine name
is part of the scope this subroutine defines (which forbids any other entity
declared with the same identifier). Is this standard? (Sorry I am not yet used
to parse by myself all the Fortran specs...)

>From my view, a subroutine and an interface are not just orthogonal objects
which should conflict because they have the same name. In an ideal world, the
compiler would assume the interface "foo" refers to the subroutine "foo", and
the compiler will have by the way the possibility to check if they are
consistent...


> > Because if this is explicitly forbidden, we are wondering what the Fortran
> > committee had in mind for programs using thousands of subroutines and where
> > the programmers want to provide the interfaces for each.
> 
> I think your idea is to "hide" the implementation (the subroutines) from the
> interfaces (i.e. the module itself).

We just have (herited from a Fortran 77 implementation) several libraries,
divided in several files each, defining several subroutines each. In addition
we wrote (i.e. duplicated the interface code) all the subroutine interfaces in
a few modules, and used these modules everywhere. This gave satisfying results
until now.


> Well, until Fortran 2003, they had no real solution but then they created the
> Technical Report (TR) 19767:2005 "Enhanced Module Facilities". This TR is now
> part of Fortran 2008 and informally known as "submodules":
> 
> There is only one important downside: So far, almost no compiler supports
> submodules; http://fortranwiki.org/fortran/show/Fortran+2008+status lists only
> Cray.

We support a large range of systems and we can not yet consider this solution
as long as it is not widely supported by the compilers...


> (In reply to comment #2)
> > I just hope the official recommendation is different from defining all
> > the subroutines as module procedures in a single 100000-lines long module...
> 
> Well, you could use multiple modules for the actual implementation and then
> collect all of them in
> 
>   module master
>     use m1
>     use m2
>     ...
>   end module master
> 
> This will automatically export all (public) procedures from the used modules
> such that
>   "use master"
> will work.
> 
> This is not as flexible as submodules but it valid and works since Fortran 90.

I am not sure to understand what you suggest to put in the modules m1, m2 etc:
the interfaces only or the subroutines themselves?