Standards interpretation: interface and intent?

Hi experts, the following code snippet is a boiled down version of code that appears to compile without warning with several Fortran compilers that I have tested (including Intel's ifort8 with option -stand=f95), but that refuses to compile with Intel's ifc 7.1 (Build 20040713Z). Before reporting a bug with either version, I would like get some feedback about the correct interpretation of the standard. Assume that 'extsub' is a subroutine of legacy code that takes as argument another subroutine (auxsub), which returns some calculated value via the first parameter. In the interface the parameters have no intent attributes, so they would normally be interpreted as 'intent(inout)'. The actual subroutine (myfunc) defines the first parameter as 'intent(out)'. -------------8<---------------> cut here <--------------8<-------------- module ifc7_if_bug implicit none interface subroutine extsub (auxsub) interface subroutine auxsub (y, x) real :: y, x end subroutine auxsub end interface end subroutine extsub end interface contains subroutine myfunc (y, x) ! ifc barfs when the first argument has intent(out) ! instead of intent(inout) or no 'intent' real, intent(out) :: y ! real :: y real, intent(in) :: x y = x end subroutine myfunc subroutine sub () call extsub (myfunc) end subroutine sub end module ifc7_if_bug -------------8<---------------> cut here <--------------8<-------------- ifc version 7 refuses to compile this with the message: % ifc -c ifc7-if-bug.f90 module IFC7_IF_BUG module subroutine MYFUNC module subroutine SUB call extsub (myfunc) ^ Error 260 at (27:ifc7-if-bug.f90) : This subroutine has the wrong number of arguments or arguments with the wrong name, type or rank 1 Error compilation aborted for ifc7-if-bug.f90 (code 1) unless I redeclare the first parameter (y) as 'intent(inout)'. What has the Fortran 95 standard to say about this? -- Cheers, -ha

Harald Anlauf <anlauf@hep.tu-darmstadt.de> writes: > In the interface the parameters have > no intent attributes, so they would normally be interpreted as > 'intent(inout)'. Let's start by correcting that. No. Unspecified intent is not the same as intent(inout). It is similar, but not identical. In particular, in context where the intent is required to agree, unspecified and intent(inout) would not count as agreeing. The differences are fairly subtle. For intent(inout), the actual argument must be something that is definable - period. For unspecified intent, the actual argument only has to be definable if the subroutine actually tries to define it. After all, prior to f77, all arguments had unspecified intent, and many actual arguments were not definable. Also note that there are dummy arguments for which you are not allowed to specify an intent (dummy procedures, pointers until f2003, alternate returns); thus intent(inout) or any other intent except for unspecified is not allowed for those. > unless I redeclare the first parameter (y) as 'intent(inout)'. > What has the Fortran 95 standard to say about this? From the f2003 draft (because I have a copy handily next to me; f95 says basically the same thing on this) In 12.2, Characteristics of procedures "The characteristics of a procedure are the classification of the procedure as a function or subroutine, ..., the characteristics of its dummy arguments..." In 12.2.1.2, Characteristics of dummy procedures... "The characteristics of a dummy procedure are the explicitness of its interface (12.3.1), its characteristics as a procedure if the interface is explicit..." Then in 12.4.1.3, Actual arguments associated with dummy procedure entities "If the interface of the dummy argument is explicit, the characteristics listed in 12.2 shall be the same for the associated actual argument and the corresponding dummy argument, except... [the exceptions don't include anything related to this]" In your case, the interface of the dummy argument is explicit, so the characteristics are required to agree. But intent of the dummy arguments is a characteristic. Unspecified intent does not agree with intent(out) (or inout either), so the code you show has a disagreement. Thus the code is nonstandard. This is not an error that a compiler is required to be able to diagnose. (But it is one that I'd expect a quality compiler to do anyway). The NAG compiler also diagnoses the error with Error: clf.f90, line 27: Dummy proc AUXSUB arg 1 has different INTENT from actual proc MYFUNC arg Error: clf.f90, line 27: Incompatible procedure argument for AUXSUB (no. 1) of EXTSUB -- Richard Maine | Good judgment comes from experience; email: my first.last at org.domain | experience comes from bad judgment. org: nasa, domain: gov | -- Mark Twain

On 20 Jul 2004 22:45:03 +0200, Harald Anlauf <anlauf@hep.tu-darmstadt.de> wrote: > Hi experts, > > the following code snippet is a boiled down version of code that > appears to compile without warning with several Fortran compilers that > I have tested (including Intel's ifort8 with option -stand=f95), but > that refuses to compile with Intel's ifc 7.1 (Build 20040713Z). > Before reporting a bug with either version, I would like get some > feedback about the correct interpretation of the standard. > > Assume that 'extsub' is a subroutine of legacy code that takes as > argument another subroutine (auxsub), which returns some calculated > value via the first parameter. In the interface the parameters have > no intent attributes, so they would normally be interpreted as > 'intent(inout)'. The actual subroutine (myfunc) defines the first > parameter as 'intent(out)'. > > -------------8<---------------> cut here <--------------8<-------------- > module ifc7_if_bug > implicit none > > interface > subroutine extsub (auxsub) > interface > subroutine auxsub (y, x) > real :: y, x > end subroutine auxsub > end interface > end subroutine extsub > end interface > > contains > > subroutine myfunc (y, x) > ! ifc barfs when the first argument has intent(out) > ! instead of intent(inout) or no 'intent' > real, intent(out) :: y > ! real :: y > > real, intent(in) :: x > y = x > end subroutine myfunc > > subroutine sub () > call extsub (myfunc) > end subroutine sub > > end module ifc7_if_bug > -------------8<---------------> cut here <--------------8<-------------- > > ifc version 7 refuses to compile this with the message: > > % ifc -c ifc7-if-bug.f90 > module IFC7_IF_BUG > module subroutine MYFUNC > module subroutine SUB > call extsub (myfunc) > ^ > Error 260 at (27:ifc7-if-bug.f90) : This subroutine has the wrong number of arguments or arguments with the wrong name, type or rank > > 1 Error > compilation aborted for ifc7-if-bug.f90 (code 1) > > > unless I redeclare the first parameter (y) as 'intent(inout)'. > What has the Fortran 95 standard to say about this? I can't say much about the Fortran 95 standard, but here is my interpretation. Only inside the F90/F95 worlds does intent(out), as opposed to intent(inout) have any meaning. Here is my heuristic explanation; If you pass a function "over the wall" to a potentially F77-semantics routine, then it has to have an interface which is morally F77 compatible, not using fancy F95 features. In particular, I ran into this using a standard F77 numerical integration package from NETLIB. There is obviously a callback, but it was crashing oddly and sometimes returning bad results. The fix was to make the called vector field subroutine read like this: subroutine F(n,x,y) integer n real x(*), y(*) ! do NOT use x(:), y(:), as this will be called by F77. I would presume the intent(out) is the same sort of problem.

Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> writes: > There is obviously a callback, but it was crashing oddly and sometimes > returning bad results. The fix was to make the called vector field subroutine > read like this: > > subroutine F(n,x,y) > integer n > real x(*), y(*) > ! do NOT use x(:), y(:), as this will be called by F77. > > > I would presume the intent(out) is the same sort of problem. No, I don't think so. I once mixed up "assumed size" and "assumed shape" arrays in a similar case, and in turn learned the difference between them the hard way !-( With "assumed shape" arrays, a certain amount of meta-information is automatically passed to the subroutine, which is not the case for "assumed size" arrays. I cannot imagine that this is necessary for scalars. The only case I can conceive is a certain protection of the passed variable (with intent(in)) and additional optimization opportunities (with intent(out)). AFAIK there is not even a "call by value" for parameters with intent(in). -- Cheers, -ha

On 27 Jul 2004 11:10:01 +0200 Harald Anlauf <anlauf@hep.tu-darmstadt.de> wrote: > Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> writes: > > > There is obviously a callback, but it was crashing oddly and > > sometimes returning bad results. The fix was to make the called > > vector field subroutine read like this: > > > > subroutine F(n,x,y) > > integer n > > real x(*), y(*) > > ! do NOT use x(:), y(:), as this will be called by F77. > > > > > > I would presume the intent(out) is the same sort of problem. > > No, I don't think so. I once mixed up "assumed size" and "assumed > shape" arrays in a similar case, and in turn learned the difference > between them the hard way !-( > > With "assumed shape" arrays, a certain amount of meta-information is > automatically passed to the subroutine, which is not the case for > "assumed size" arrays. I cannot imagine that this is necessary for > scalars. The only case I can conceive is a certain protection of the > passed variable (with intent(in)) and additional optimization > opportunities (with intent(out)). AFAIK there is not even a "call by > value" for parameters with intent(in). There isn't an explicit rule preventing a compiler doing call by value for any argument. In many cases it might be difficult to comply with some of the other rules for arguments if call by value is used (which is probably where the "Fortran is call by reference" myth comes from) but an intent(in) argument sounds like an occasion where call by value might be a sensible thing to do. Compilers also sometimes do copy in/copy out for arguments and intent can indicate to a compiler that one of the directions can be skipped. David

Harald Anlauf wrote: > > Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> writes: > > > There is obviously a callback, but it was crashing oddly and sometimes > > returning bad results. The fix was to make the called vector field subroutine > > read like this: > > > > subroutine F(n,x,y) > > integer n > > real x(*), y(*) > > ! do NOT use x(:), y(:), as this will be called by F77. > > > > > > I would presume the intent(out) is the same sort of problem. > > No, I don't think so. I once mixed up "assumed size" and "assumed > shape" arrays in a similar case, and in turn learned the difference > between them the hard way !-( > > With "assumed shape" arrays, a certain amount of meta-information is > automatically passed to the subroutine, which is not the case for > "assumed size" arrays. This is one thing about the terminology that confuses me a little. If it is "assumed", then there should be no additional information passed since the shape or size is "assumed"??? > I cannot imagine that this is necessary for > scalars. The only case I can conceive is a certain protection of the > passed variable (with intent(in)) and additional optimization > opportunities (with intent(out)). AFAIK there is not even a "call by > value" for parameters with intent(in). > > -- > Cheers, > -ha -- Gary Scott mailto:garyscott@ev1.net Fortran Library: http://www.fortranlib.com Support the Original G95 Project: http://www.g95.org -OR- Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html Why are there two? God only knows. Democracy is two wolves and a sheep, voting on what to eat for dinner... Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

> This is one thing about the terminology that confuses me a little. If > it is "assumed", then there should be no additional information passed > since the shape or size is "assumed"??? Well, you're the native speaker here (I assume), but I've always taken it to mean "assumed from information supplied by the callee". The other thing that's confusing is that all those adjectives start with an "a", which makes it difficult to distinguish all those variants... Jan

Jan Vorbr=FCggen wrote: > = > > This is one thing about the terminology that confuses me a little. = If > > it is "assumed", then there should be no additional information passe= d > > since the shape or size is "assumed"??? > = > Well, you're the native speaker here (I assume), but I've always taken = it > to mean "assumed from information supplied by the callee". Usually though if something is passed, that makes it explicit. The application programmer didn't provide it, but the compiler did. Doesn't make it any less explicit. "Assumed" would me that there is no explicit information provided, it's just "assumed". Oh well. Something to memorize. > = > The other thing that's confusing is that all those adjectives start wit= h > an "a", which makes it difficult to distinguish all those variants... > = > Jan -- = Gary Scott mailto:garyscott@ev1.net Fortran Library: http://www.fortranlib.com Support the Original G95 Project: http://www.g95.org -OR- Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html Why are there two? God only knows. Democracy is two wolves and a sheep, voting on what to eat for dinner... Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

On Tue, 27 Jul 2004 06:44:51 -0500, Gary L. Scott <garyscott@ev1.net> wrote: > Jan Vorbr�ggen wrote: >> >> > This is one thing about the terminology that confuses me a little. If >> > it is "assumed", then there should be no additional information passed >> > since the shape or size is "assumed"??? >> >> Well, you're the native speaker here (I assume), but I've always taken it >> to mean "assumed from information supplied by the callee". > > Usually though if something is passed, that makes it explicit. The > application programmer didn't provide it, but the compiler did. Doesn't > make it any less explicit. yes it does, because most humans don't know exactly what any given compiler is doing, and neither should they. Since humans read the words defining the meaning of a programming language, the terminology ought to be in words meaningful to them. I believe that something "explicit" ought to mean "something that the human intentionally supplies by writing software statements saying so". like "explicit typing" integer :: i real :: a i = 42 a = 3.14159 "implicit typing" ! ! with ! implicit real (a-h,o-z) ! implicit integer (i-n) ! in effect ! i = 42 a = 3.14159

Dr Chaos wrote: > = > On Tue, 27 Jul 2004 06:44:51 -0500, Gary L. Scott <garyscott@ev1.net> w= rote: > > Jan Vorbr=FCggen wrote: > >> > >> > This is one thing about the terminology that confuses me a littl= e. If > >> > it is "assumed", then there should be no additional information pa= ssed > >> > since the shape or size is "assumed"??? > >> > >> Well, you're the native speaker here (I assume), but I've always tak= en it > >> to mean "assumed from information supplied by the callee". > > > > Usually though if something is passed, that makes it explicit. The > > application programmer didn't provide it, but the compiler did. Does= n't > > make it any less explicit. It's explicit to the compiler. That's what matters. If the compiler has the exact dimensions or shape, then it is "explicitly known" what the dimensions or shape is. If not, then it may have to make assumptions (which may be wrong). But I understand the usage. I was just feeling argumentative again. > = > yes it does, because most humans don't know exactly what any given comp= iler > is doing, and neither should they. > = > Since humans read the words defining the meaning of a programming langu= age, > the terminology ought to be in words meaningful to them. > = > I believe that something "explicit" ought to mean "something that the h= uman > intentionally supplies by writing software statements saying so". > = > like "explicit typing" > = > integer :: i > real :: a > = > i =3D 42 > a =3D 3.14159 > = > "implicit typing" > = > ! > ! with > ! implicit real (a-h,o-z) > ! implicit integer (i-n) > ! in effect > ! > i =3D 42 > a =3D 3.14159 -- = Gary Scott mailto:garyscott@ev1.net Fortran Library: http://www.fortranlib.com Support the Original G95 Project: http://www.g95.org -OR- Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html Why are there two? God only knows. Democracy is two wolves and a sheep, voting on what to eat for dinner... Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

Dr Chaos wrote: (snip) > yes it does, because most humans don't know exactly what any given compiler > is doing, and neither should they. I disagree, somewhat. While they shouldn't need to know exactly what the compiler is doing, they should have some idea what it is doing. It is hard to write good code if you really have no idea what it is doing. > Since humans read the words defining the meaning of a programming language, > the terminology ought to be in words meaningful to them. How many actually read the standard? -- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > Dr Chaos wrote: > > (snip) > >> yes it does, because most humans don't know exactly what any given compiler >> is doing, and neither should they. > > I disagree, somewhat. While they shouldn't need to know exactly > what the compiler is doing, they should have some idea what it > is doing. It is hard to write good code if you really have no > idea what it is doing. Some idea, yes. If they have to start thinking in compiler words which induce ideas entirely the opposite of what humans care about, such as calling something "explicit" when quite clearly in any sense useful to the programmer it was definitely not supplied "explicitly" and when this is in fact distinct from cases when the humans do supply bounds explicitly (in the normal human sense of natural language), then that's definitely too much. >> Since humans read the words defining the meaning of a programming language, >> the terminology ought to be in words meaningful to them. > > How many actually read the standard? I don't know, but when people try to explain things in a way using standardese which is profoundly misleading to expectations of human usage, maybe the answer is "too many" 1/2 :) > -- glen