 |
forums.silverfrost.com
Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
davidb
Joined: 17 Jul 2009
Posts: 560
Location: UK
|
 Posted: Tue Nov 20, 2012 12:08 pm Post subject: Same signature procedures in interface |
 |
|
In the following code, the two subroutines aaa1 and aaa2 have the same signature and the compiler should detect this and generate an error message but it doesn't.
| Code: |
module xxx
interface aaa
module procedure aaa1
module procedure aaa2
end interface
contains
subroutine aaa1(a, b, c)
real :: a, b(2), c
c = a + b(1)
end subroutine aaa1
subroutine aaa2(b, a, c)
real :: b(2), a, c
c = a + b(1)
end subroutine aaa2
end module xxx
|
Both NAG and gfortran compilers correctly report the error in the above.
FTN95 should generate this error:
error 435 - Specific procedure AAA2 of type SUBROUTINE is too similar to AAA1 of type SUBROUTINE for overload AAA in module XXX. The arguments are too similar.
I know they look like they have different signatures, but they don't. I can demonstrate the signatures are the same, since the following code works:
| Code: |
program main
use xxx
real :: s, w(4)
w = 0.0
call aaa1(w(1), w(3), s)
call aaa2(w(1), w(3), s)
end program main
|
The compiler seems to know something is wrong though, because the following doesn't compile, but the error message is misleading.
error 418 - No matching specific procedure for generic overloaded name AAA
| Code: |
program main2
use xxx
real :: s, w(4)
w = 0.0
call aaa(w(1), w(3), s)
end program main2
|
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
| Back to top |
|
 |
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Tue Nov 20, 2012 1:11 pm Post subject: |
|
|
| I will make a note of this. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Tue Apr 02, 2013 3:53 pm Post subject: |
|
|
I have had a look at this but I am reluctant to change FTN95 at this point.
FTN95 and Lahey do behave differently from gFortran and NAG. FTN95 and Lahey report an error when you compile a subprogram that uses the generic rather than when you compile the module.
However both FTN95 and Lahey allow you to use the generic when you call it in a certain way (when you pass the array by its name).
Although this behaviour should strictly be regarded as an extension to the Standard, if I add the constraint now it might unwittingly break someone's code. |
|
| Back to top |
|
|
davidb
Joined: 17 Jul 2009
Posts: 560
Location: UK
|
| Posted: Tue Apr 02, 2013 5:07 pm Post subject: Re: |
|
|
| PaulLaidler wrote: |
FTN95 and Lahey do behave differently from gFortran and NAG. FTN95 and Lahey report an error when you compile a subprogram that uses the generic rather than when you compile the module.
|
As long as there is an error generated there is no problem with this approach.
| PaulLaidler wrote: |
However both FTN95 and Lahey allow you to use the generic when you call it in a certain way (when you pass the array by its name).
|
Hmmm... If I had used different names for the dummy arguments in the subroutines, there wouldn't be an error since one could use the NAME of the argument to distinguish between the two cases.
However, in the example, I deliberately chose the same names so that it should be impossibe to ever make a valid call using the generic interface.
Could you post a calling sequence to show what you mean?
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Wed Apr 03, 2013 7:54 am Post subject: |
|
|
Using your module, the following code produces self-consistent results that are the same for FTN95 and Lahey.
| Code: | program main
use xxx
integer :: s, w(4)
call aaa(w(1), w, s)
call aaa(w, w(4), s)
end program main |
Given that one normally gets an error condition, I am happy for now to treat this usage as an extension to the Standard. |
|
| Back to top |
|
|
davidb
Joined: 17 Jul 2009
Posts: 560
Location: UK
|
| Posted: Wed Apr 03, 2013 2:16 pm Post subject: |
|
|
Well I'm confused. 
When I try your code with my module, I get the following Error messages (one for each call):
D:\xxx\anon.F90(25) : error 418 - No matching specific procedure for generic overloaded name AAA
D:\xxx\anon.F90(26) : error 418 - No matching specific procedure for generic overloaded name AAA
If I then "correct" the declarations in your code to match those in the interface (changing Integer to Real), the program seems to compile OK.
It calls aaa1 for the first call and aaa2 for the second call. I can't see why though!
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
| Back to top |
|
|
davidb
Joined: 17 Jul 2009
Posts: 560
Location: UK
|
| Posted: Wed Apr 03, 2013 2:34 pm Post subject: |
|
|
I can see what you're doing now. Since F90 you shouldn't distinguish between an actual argument W(1) and W when matching to a dummy array argument. (I think this requirement comes from a desire to be compatible with F77 codes).
So I would expect a compile error here.
No problem though. Just keep this as an extension to what is in the Fortran standard.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
