Incorrect warning with /stand option

[Andrey_V_]

I have module with interfaces of all routines of program. This module compile with other compilers(CVF for example) with standart checking without
warnings. Following example shows the problem

Compile it with /stand:f95

Code:

program foo
real(8):: ttt(3)
integer:: k

k=3
call sss(ttt,k)
end

module intrf
interface
subroutine SSS(a,i)
integer:: i
real(8):: a(i)
end
end interface
end module

subroutine SSS(a,i)
use intrf
integer:: i
real(8):: a(i)

a(1)=1.d0
end

PS I submitted issue 363820about this problem about 2 months ago, but it don't have progress father then "investigating".

[Steven_L_Intel1]

I'm sorry that the support request did not receive a proper answer. I'll have that investigated.

The warning is correct by Fortran 95 and Fortran 2003

"Two or more accessible entities, other than generic interfaces, may have the same name only if the name is not used to refer to an entity in the scoping unit. Generic interfaces are handled as described in section 14.1.2.3. Except for these cases, the local name of any entity given accessibility by a USE statement shall differ from the local names of all other entities accessible to the scoping unit through USE statements and otherwise."

I'll agree that it is an annoying restriction, which is why we allow it as an extension.

[Andrey_V_]

Thanks for explanation. This information is new for me. You say that this correct by F95 and F2003. What's about F90 (for /stand:f90 warning also occur)?

In any case I'm not satisfied :), please make small change in example:

Code:

...
subroutine SSS(a,i)
use intrf, MyName=>SSS
...

Now this example satisfied to standart, but warning still occur.

[Steven_L_Intel1]

It's not standard in F90 either. What you want is known as "interface to self", which certainly makes life easier when writing and using modules, but sadly it is not allowed in the standard language. I think there may be a proposal for Fortran 2008 to lift this restriction, but I am not sure of that.

The recommended way of dealing with this is to not use interface blocks at all - put all your routines in a module. This can get messy when you have module A calling something in module B, and module B calls something in module A. In your case, I would move routine SSS into a module and then anyone who wants to call it uses the module. There are some who consider interface blocks to be a bad programming practice when used for Fortran code - module procedures are preferred.

The approach that IMSL takes is to have each class of routines have its own module, so in your case, there would be a module SSS_INT or something like that, containing SSS. Anyone who wants to call SSS would have to USE SSS_INT.

[Andrey_V_]

Thanks for you propose. Of couse including routines into modules is very good idea, but it is not acceptable for me. My program have a lots of different routines that compiles into the library. Then execution code is linked some programs may be replaced with specific versions. I am not sure that using of modules accept this scheme on different platforms (for example this scheme not work for CVF)

Some words about modules. Of couse modules is great feature of Fortran 90 that solves a lots of problems, but all implementation that I use have some problems. One of problem you describe. In my opinion, modules is a best choice for independent class of routines (In this case you get access to this class through one "use"). Problems arise if you can't group you routines to independent classes. In my case almost each routine may be replaced, because of that I must put each routine in single file (then linking you may replace object file, not routine). If I create module for each routine, then I have one library-file and few hundred of modules. This lead to very large count of addition files. This is not great. This is first lack of modules that it's not included in library.

The second point is that programmer must remember not only name of subroutine but also name of module (it's not problem if you have a lots of routines in one module, but if almost each routines included in single module it's appends some problems). Of couse you may create name of modules based on name of routine plus fixed suffix or someone like that, but if you have few modules with lots of subroutines and lots of modules with one routine you may don't remembered that this subroutine is part of class or it's independent.

The third point is that you must add use operator at the head of subroutine. In my case if I call a few tens of routines, I must append the same count of use operators. Header of subroutine significant increase in this case. Also, how do you think, if I remove call of someone routine, will I remove corresponding use operator? I think not. Header will increase throwgh development.

Also if you create makefile, then you must range all modules in the compilation order. This is not trivial task for large project. Now think about supporting of makefile then you change/add/remove calls in source files adding/removing routines...

This problems solves by creating single module with interfaces of everyone routine. Of couse it's not completly solves all problems, but significantly decrease it (much easier support one interface module than few hundred). Also this approach have them one lacks. In any case I think that allowing of "interface to self" in F2008 will be very usefull. This feature adds waranty that everyone routine (that use intrerface module) use the same interface call as original routine.

PS I don't understand, renaming of subroutine name in use operator must remove warning or not (in other words: problem exist or not :) )?

[Steven_L_Intel1]

I am not sure why the compiler still complains with the rename. I will have to research that some more.

[Steven_L_Intel1]

Ok, now I understand the issue more.

First, I did not quote the most relevant part of the standard to justify the compiler warning. What I should have quoted was this:

Constraint: An interface-block in a subprogram shall not contain an interface-body for a procedure
defined by that subprogram.

Now, let's look at the rename. A rename creates a "local name" for the entity in the module, but it does not change the entity. Even if you rename the interface to SSS, it is still an interface to SSS, which is a global name, and thus it is still not legal to make that interface visible inside SSS. If you called the renamed routine, it would call SSS and not what you renamed it as.

One way you can work around this is to use ONLY and select the names you want specifically imported into SSS from the module. As long as that list does not include SSS, you're ok.

[Andrey_V_]

Thanks for you explanation. Now I understand that this warning message is correct.

Using of ONLY is simple solve. But ithave one restriction:IfI forgot to add subroutine name in ONLY list, then code compiles and links correctly, but under runtime programmay work incorrectly (if called subroutine have arguments of not usual types, for example, user types). For me more useful EXCEPT :), but this feature not exist in Fortran.

PS Where I can ask some another questionsabout Fortran standart?

[Steven_L_Intel1]

Yes, you are correct regarding what happens when you leave out the name from an ONLY when the external routine otherwise has a normal interface. For functions, you could solve this by always using IMPLICIT NONE, but that does not help for subroutines.

You might find it helpful to use the compiler options /gen_interfaces /warn:interface. This causes the compiler to automatically generate interface blocks for procedures that aren't part of modules, and then to look for these generated interfaces and check calls to the routines.

You can ask standards questions in this forum - I'll be glad to answer what I can. The comp.lang.fortran newsgroup is another place to ask questions about the standard itself rather than how a particular compiler supports the standard.

[Andrey_V_]

I know about /gen_interfaces /warn:interface command line switches. I think, that this is a great feature of the IVF, but currently /gen_interfaces is too bugy (I have opened a few issues in premier support). Currently I use /gen_interfaces only inone project of3.

Another problem with /gen_interfaces /warn:interface is that it not only check interfaces, but use generated interfaces for real calls (I open issue on this too)

[Steven_L_Intel1]

I understand. We're fixing those issues as we learn about them.