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

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

[bardeau at iram dot fr]

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

             Bug #: 51268
           Summary: [Regression] A subroutine can not know anymore its own
                    interface
    Classification: Unclassified
           Product: gcc
           Version: fortran-dev
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: bardeau@iram.fr


Created attachment 25881
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25881
Declare a subroutine interface and use this interface in the subroutine

This a regression which appeared in the last months: problem is in 4.7.0
20111119 but not in 4.7.0 20110507

In the latest version, a subroutine can not know its own interface and an error
is raised about duplicate symbols (see example attached):

test.f90:15.6:

  use myinterfaces
      1
Error: 'mysub' of module 'myinterfaces', imported at (1), is also the name of
the current program unit

>From our developer point of view, this is a very annoying regression, since we
are in charge of several libraries, with hundreds of subroutines in each. We
made the choice to provide all the interfaces of all the subroutines to all of
them, in order to ensure a correct use of the subroutines everywhere. For each
library we thus have a dedicated interface module which is used everywhere.
Forbidding a subroutine to know its own interface would imply to use the
statement "use only", which is definitely not well suited for large programs.

Thanks for your help.

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

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-22 16:09:19 UTC ---
Well, that one now gets a diagnostic and didn't get one before is a change, but
the question is whether it is a progression or a regression.

NAG prints:
  Error: line 15: USE MYINTERFACES in program-unit MYSUB imports symbol MYSUB

g95 prints:
  Module 'myinterfaces' at (1) redefines the current program unit 'mysub'

pathf95 prints:
  "MYSUB" is the name of this program unit, therefore it must not be use 
  associated from module "MYINTERFACES".

openf95 prints:
  "MYSUB" is the name of this program unit, therefore it must not be use 
  associated from module "MYINTERFACES".

crayftn prints:
  "MYSUB" is the name of this program unit, therefore it must not be use 
  associated from module "MYINTERFACES".

While ifort prints (only with -stand f95/f03):
  warning #7925: An interface-block in a subprogram shall not contain an
  interface-body for a procedure defined by that subprogram.   [MYSUB]

And "pgf90 -Minfo=all" and "sunf95 -w0" simply silently accept the program.


I think the program is indeed invalid - but if needed, I can check the
standard. One could consider allowing it with a warning (as ifort does), but I
am not sure one should.

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

[bardeau at iram dot fr]

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

--- Comment #2 from Sebastien Bardeau <bardeau at iram dot fr> 2011-11-23 09:22:12 UTC ---
Well, we are definitely interested in what the standard says exactly. 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 just hope the official
recommendation is different from defining all the subroutines as module
procedures in a single 100000-lines long module...

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

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-23 10:22:12 UTC ---
(In reply to comment #2)
> Well, we are definitely interested in what the standard says exactly.

For links to the standards see:
  http://gcc.gnu.org/wiki/GFortranStandards

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, other than generic interfaces or defined
operators, may have the same local identifier only if the identifier is not
used. Generic interfaces and defined operators are handled as described in
12.4.3.4. Except for these cases, 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."


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

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.

With submodules you can create a master module:

module master
  interface
    MODULE SUBROUTINE sub (a,b)
      integer, intent(in) a, b
    end subroutine
  end interface
end module master

SUBMODULE (master) implementation
contains
  MODULE SUBROUTINE sub (a,b)
    integer, intent(in) a, b
    ! < implementation >
  end subroutine
end module implementation

Variant which saves typing by leaving out the repeated variable declaration:

SUBMODULE (master) implementation
contains
  MODULE SUBROUTINE sub
    ! < implementation >
  end subroutine
end module implementation

 * * *

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

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

[bardeau at iram dot fr]

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?

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

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-23 16:51:39 UTC ---
(In reply to comment #4)
> 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?

Yes. It gets more obvious if you consider a function:
  function f()
    integer :: f
thus, the "f" needs to be part of the body of the function.

It should be buried in "16 Scope, association, and definition", but I need some
time to extract it. You could also ask at the comp.lang.fortran newsgroup where
(among others) the editor of the Fortran 2003 standard answers such questions.


> From my view, a subroutine and an interface are not just orthogonal objects
> which should conflict because they have the same name.

Instead of an interface, consider:
  module m
    external sub
  end module m

  recursive subroutine sub()
    use m
    call sub()
  end subroutine sub

This is equivalent to:

  recursive subroutine sub()
    external sub
    call sub()
  end subroutine sub

Thus, you specify that some external subroutine "sub" exists ("external sub")
but at the same time you are in the subroutine. Thus, you have somehow either
specified the same subroutine twice or two different ones, which have the same
name. It looks odd, it looks wrong - and the committee has decided that it is
invalid.

That it is invalid does not mean that one cannot implement it, it also does not
mean that there is no usage case for it; it just means that either they did not
come up with the usage case - or thought that it is the wrong solution to the
problem. In this case, I think it is the latter.


> 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...

In an ideal world there is no need to use an INTERFACE block at all as the
interface is automatically available if the procedure is in a module or an
internal procedure. As written, the committee has realized that the previous
concept is insufficient and added around 2003 (ISO publication: 2005) a
technical report to solve this problem: submodules.


[Submodules]
> 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...

Well, as I wrote that's the idea of the committee. Many expected that it would
be quickly implemented - much earlier than the rest of Fortran 2003. However,
it seems to be one of the features which gets implemented very late - one of
the last Fortran 2008 features! Given that currently only crayftn supports it,
I also do not recommend its use.


> > (In reply to comment #2)
> > 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
> 
> I am not sure to understand what you suggest to put in the modules m1, m2 etc:
> the interfaces only or the subroutines themselves?

The subroutines themselves. That avoids having the whole library in a single
file; it also avoid to write an interface for all the procedures. There is a
down side: If you need the library available without "USE module" in a Fortran
77 like fashion or if you do not want to release the source code, it won't
work. (For the former case, one should consider C bindings.) Whether this
proposal is a good solution for your problem, I don't know, but it is a Fortran
95 solution for (part of) your problem.

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

[bardeau at iram dot fr]

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

--- Comment #6 from Sebastien Bardeau <bardeau at iram dot fr> 2011-11-24 13:23:18 UTC ---
(In reply to comment #5)

> It should be buried in "16 Scope, association, and definition", but I need some
> time to extract it.

Ok, so did I. Here is what I can read section 16.2, p.406 (shortened):

"Within a scoping unit, identifiers of entities in the following classes:
(1) ..., abstract interfaces, generic interfaces, ...
are local identifiers in that scoping unit.
Within a scoping unit, a local identifier of an entity of class (1) shall not
be the same as a global identifier used in that scoping unit."

There is no explicit rule regarding the "specific interfaces" which we are
interested in since the beginning.

Furthermore, section 12.3.2.1, p.260 + corrigendum 5:
"A procedure shall not have more than one explicit specific interface in a
given scoping unit, except that if the interface is accessed by use
association, there may be more than one local name for the procedure".
As far as I understand, specific interface names accessed by use-association do
not conflict with the procedure name itself. Isn't it a key point in our
discussion?


> You could also ask at the comp.lang.fortran newsgroup where
> (among others) the editor of the Fortran 2003 standard answers such questions.
Yes it will be interesting to have their point of view depending on how we
finally agree on the standard interpretation.

Thanks for your other explanations and examples, I keep them in mind for
further discussions, here or on the comp.lang.fortran newsgroup .

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

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-24 14:04:20 UTC ---
(In reply to comment #6)

> "Within a scoping unit, identifiers of entities in the following classes:
> (1) ..., abstract interfaces, generic interfaces, ...
> are local identifiers in that scoping unit.
> Within a scoping unit, a local identifier of an entity of class (1) shall not
> be the same as a global identifier used in that scoping unit."
> 
> There is no explicit rule regarding the "specific interfaces" which we are
> interested in since the beginning.

Well, there is:
 "external procedures accessed via USE,"
which should apply as "1.3.112.2 external procedure -- procedure defined [...]
by means other than Fortran (12.6.3)", namely (12.6.3): "The interface of a
procedure defined by means other than Fortran may be specified by an interface
body or procedure declaration statement."


> "A procedure shall not have more than one explicit specific interface in a
> given scoping unit, except that if the interface is accessed by use
> association, there may be more than one local name for the procedure".
> As far as I understand, specific interface names accessed by use-association
> do not conflict with the procedure name itself. Isn't it a key point in our
> discussion?

Well, it is the key point of the discussion. However, the quote is about:
  USE m, func1 => f, func2 => f
where func1 and func2 both are different local names for the same procedure and
where the USE statement does not make "f" a class-1 identifier. And there is
also:
  use m1, only: f
  use m2, only: f
which is OK if "m2" use-associates "f" from m1 (or vice versa).

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

[bardeau at iram dot fr]

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

--- Comment #8 from Sebastien Bardeau <bardeau at iram dot fr> 2011-11-24 15:58:31 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> 
> > "Within a scoping unit, identifiers of entities in the following classes:
> > (1) ..., abstract interfaces, generic interfaces, ...
> > are local identifiers in that scoping unit.
> > Within a scoping unit, a local identifier of an entity of class (1) shall not
> > be the same as a global identifier used in that scoping unit."
> > 
> > There is no explicit rule regarding the "specific interfaces" which we are
> > interested in since the beginning.
> 
> Well, there is:
>  "external procedures accessed via USE,"
> which should apply as "1.3.112.2 external procedure -- procedure defined [...]
> by means other than Fortran (12.6.3)", namely (12.6.3): "The interface of a
> procedure defined by means other than Fortran may be specified by an interface
> body or procedure declaration statement."

So I think at this stage we disagree on the standard interpretation. External
procedures are just external procedures declared with the EXTERNAL statement.
If their interface is provided thanks to a specific interface, then the rules
regarding the specific interfaces must apply, if such rules exist.
Furthermore in our case we are discussing Fortran-based subroutines and their
interfaces, so there are no "external procedures defined by other means than
Fortran" to be considered here.


> > "A procedure shall not have more than one explicit specific interface in a
> > given scoping unit, except that if the interface is accessed by use
> > association, there may be more than one local name for the procedure".
> > As far as I understand, specific interface names accessed by use-association
> > do not conflict with the procedure name itself. Isn't it a key point in our
> > discussion?
> 
> Well, it is the key point of the discussion. However, the quote is about:
>   USE m, func1 => f, func2 => f
> where func1 and func2 both are different local names for the same procedure and
> where the USE statement does not make "f" a class-1 identifier. And there is
> also:
>   use m1, only: f
>   use m2, only: f
> which is OK if "m2" use-associates "f" from m1 (or vice versa).

Well, by reading again and again the corrigendum added here, I would have said
that it corrects on purpose the problem we are facing. We must not be the only
ones trying to write and share among files the specific interfaces to
Fortran77-based procedures...

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

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-29 13:10:26 UTC ---
Sebastien has now ask at c.l.f, cf.
 
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ef3900ab261c5cd9

Suggested workaround/solution:

  subroutine mysub()
    use MYINTERFACES, ignore_me => mysub

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

[bardeau at iram dot fr]

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

--- Comment #10 from Sebastien Bardeau <bardeau at iram dot fr> 2011-11-29 14:33:08 UTC ---
Indeed this is a workaround that we will probably adopt.

I would say that although I partially disagree the choices made in the Fortran
Standards in this context, gfortran is not to blame here. So I think this "bug"
can be closed.

Thanks for the comments Tobias.

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

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-29 14:44:05 UTC ---
(In reply to comment #10)
> I would say that although I partially disagree the choices made in the Fortran
> Standards in this context, gfortran is not to blame here. So I think this "bug"
> can be closed.

Well, it (and the other compilers) could still be blamed for not implementing
submodules earlier. (For instance, the authors of "Fortran 95/2003 explained"
assumed that it would get implemented before most of the Fortran 2003 features.
As it turned out, it gets implemented as one of the later Fortran 2008 (!)
features.)

CLOSED bug.