In a statement function, only the type and kind are determined from the host. gfortran fails to compile troutmask:kargl[205] cat n.f SUBROUTINE PHTOD(E,N,I,H) DIMENSION E(N) HSTAR(E,B)=B**.4*((1.25*FUN(-E/40)+.18)) ! Doesn't work. C HSTAR(X,Y)=Y**.4*((1.25*FUN(-X/40)+.18)) ! Works. A = 1. H = HSTAR(E(I-1), A) END troutmask:kargl[207] ftnchek n.f FTNCHEK Version 3.3 November 2004 File n.f: 0 syntax errors detected in file n.f No main program found Warning: Subprogram FUN never defined Invoked in module PHTOD line 3 file n.f (possibly it is an array which was not declared) troutmask:kargl[208] gfc -c n.f n.f:1.24: SUBROUTINE PHTOD(E,N,I,H) 1 Error: Argument 'e' of statement function at (1) must be scalar If the reference to FUN in statement function is changed to an elemental function, then one gets an additional error. Changing FUN to SIN yields troutmask:kargl[210] gfc -c n.f n.f:1.24: SUBROUTINE PHTOD(E,N,I,H) 1 Error: Argument 'e' of statement function at (1) must be scalar n.f:3.11: HSTAR(E,B)=B**.4*((1.25*SIN(-E/40)+.18)) ! Doesn't work. 1 Error: Incompatible ranks 0 and 1 in assignment at (1) Because statement functions are obselscent in Fortran 95, this should be considered a very low priority bug.
Confirmed.
I disagree. In Fortran 2003 12.5.4, C1263/R1238 says "The function-name and each dummy-arg-name shall be specified, explicitly or implicitly, to be scalar.". Intel accepts it, but IBM, g95 and (most importantly) Lahey think it's invalid. However, the error message should point to the statement function. The patch below gives, in my opinion, a better error message: HSTAR(E,B)=B**.4*((1.25*FUN(-E/40)+.18)) ! Doesn't work. 1 Error: Argument 'e' of statement function 'hstar' at (1) must be scalar Index: resolve.c =================================================================== --- resolve.c (revision 132578) +++ resolve.c (working copy) @@ -240,8 +240,9 @@ { if (sym->as != NULL) { - gfc_error ("Argument '%s' of statement function at %L must " - "be scalar", sym->name, &sym->declared_at); + gfc_error ("Argument '%s' of statement function '%s' at %L " + "must be scalar", sym->name, proc->name, + &proc->declared_at); continue; }
Subject: Re: scope of variables in statement function do not acquire rank from host On Fri, Feb 29, 2008 at 05:53:40PM -0000, fxcoudert at gcc dot gnu dot org wrote: > I disagree. In Fortran 2003 12.5.4, C1263/R1238 says "The function-name and > each dummy-arg-name shall be specified, explicitly or implicitly, to be > scalar.". Intel accepts it, but IBM, g95 and (most importantly) Lahey think > it's invalid. > > > However, the error message should point to the statement function. The patch > below gives, in my opinion, a better error message: > > HSTAR(E,B)=B**.4*((1.25*FUN(-E/40)+.18)) ! Doesn't work. > 1 > Error: Argument 'e' of statement function 'hstar' at (1) must be scalar > I disagree with your disagreement. :-) Gordon Sande and Richard Maine also disagrees with you (see c.l.f threads "I've never seen this before in 30 years - what is this?" and "What is this"). From Fortran 95, Sec. 12.5.4, lines 38 and 39: The dummy arguments have a scope of the statement function. Each dummy argument has the same type and type parameters as the entity of the same name in the scoping unit containing the statement function. Note, this passage does not include rank.
(In reply to comment #3) > The dummy arguments have a scope of the statement function. Each > dummy argument has the same type and type parameters as the > entity of the same name in the scoping unit containing the statement > function. > > Note, this passage does not include rank. No, but it does not say that they are scalar either. It does not say "Each dummy argument is a scalar of the same type and type parameters...". If we follow this interpretation, then what does "The function-name and each dummy-arg-name shall be specified, explicitly or implicitly, to be scalar" mean? In your (and Richard Maine's and ...) reading, the dummy arguments are by definition scalar, and so how can they be "specified, explicitly or implicitly, to be scalar". Or, to say it the other way around, let's say that I want to break this particular constraint, how do I explicitly specify one of my dummy arguments not to be a scalar? I'm thoroughly confused.
Subject: Re: scope of variables in statement function do not acquire rank from host On Fri, Feb 29, 2008 at 08:23:16PM -0000, fxcoudert at gcc dot gnu dot org wrote: > (In reply to comment #3) > > The dummy arguments have a scope of the statement function. Each > > dummy argument has the same type and type parameters as the > > entity of the same name in the scoping unit containing the statement > > function. > > > > Note, this passage does not include rank. > > No, but it does not say that they are scalar either. It does not say "Each > dummy argument is a scalar of the same type and type parameters...". > > If we follow this interpretation, then what does "The function-name > and each dummy-arg-name shall be specified, explicitly or implicitly, > to be scalar" mean? In your (and Richard Maine's and ...) reading, > the dummy arguments are by definition scalar, and so how can they be > "specified, explicitly or implicitly, > to be scalar". Or, to say it the other way around, let's say that I want to > break this particular constraint, how do I explicitly specify one of my dummy > arguments not to be a scalar? > > I'm thoroughly confused. > Don't worry, I share your confusion (when I read the standard). :) I think the passage you quote applies to the following code: program z real :: y = 2. real :: x(5) = 1. f(x(2:4)) = 2 * sum(x) ! dummy arg is an array. g(y) = y * x ! function g is an array because of x. end program z I just found the definition of type parameters in 2.4.1.1. "The type parameters are KIND and LEN." All other attributes are irrelevant. PS: I see you just found the c.l.f threads.
I've thought about it more, and it's probably going to be tricky to solve: after we have matched the formal arglist, we need to fill the namespace with replacement symbols for all the dummy args (stripping them from their attributes other than type and kind), then match the body of the statement function, then remove these symbols and go on with our life. I don't know the resolution code well enough to do that :(
Subject: Re: scope of variables in statement function do not acquire rank from host On Fri, Feb 29, 2008 at 10:55:31PM -0000, fxcoudert at gcc dot gnu dot org wrote: >--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-02-29 22:55 ------- > I've thought about it more, and it's probably going to be tricky to solve: > after we have matched the formal arglist, we need to fill the namespace with > replacement symbols for all the dummy args (stripping them from their > attributes other than type and kind), then match the body of the statement > function, then remove these symbols and go on with our life. I don't know the > resolution code well enough to do that :( This bug pre-dates gfortran (at least it is also in g95). gfortran has compiled a ton of F77 code, and this is the first instance that I've seen. I think this bug is way down the priority list.
Subject: Re: scope of variables in statement function do not acquire rank from host > > Don't worry, I share your confusion (when I read the standard). :) > > I think the passage you quote applies to the following code: > > program z > real :: y = 2. > real :: x(5) = 1. > f(x(2:4)) = 2 * sum(x) ! dummy arg is an array. > g(y) = y * x ! function g is an array because of x. > end program z > Well, Richard Maine shot these down from other considerations. The x(2:4) isn't a dummy-arg-name, so that one's out. In 'g(y) = y * x', the RHS is not a scal-expr, so that one's out. BTW, I don't use statement function, and I've come to dislike them even more after thinking about this issue.
what is the 'rejects-valid' testcase here? apart from ifort, all compilers I can access right now reject the program in the initial comment.
Subject: Re: scope of variables in statement function do not acquire rank from host On Fri, Aug 08, 2008 at 09:06:37PM -0000, jv244 at cam dot ac dot uk wrote: > > ------- Comment #9 from jv244 at cam dot ac dot uk 2008-08-08 21:06 ------- > what is the 'rejects-valid' testcase here? apart from ifort, all compilers I > can access right now reject the program in the initial comment. > -- > Well, to start with, the code in comment #1 is valid Fortran 95. See comment #3. In checking, F2003 the exact same text appears. I suppose you need to file bug reports with the other compiler vendors.
Author: kargl Date: Sun Feb 11 18:55:31 2018 New Revision: 257566 URL: https://gcc.gnu.org/viewcvs?rev=257566&root=gcc&view=rev Log: 2018-02-11 Francois-Xavier Coudert <fxcoudert@gcc.gnu.org> PR fortran/35299 * gfortran.dg/statement_function_3.f: New test. 2018-02-11 Francois-Xavier Coudert <fxcoudert@gcc.gnu.org> PR fortran/35299 * resolve.c (resolve_formal_arglist): Update error message. Added: trunk/gcc/testsuite/gfortran.dg/statement_function_3.f Modified: trunk/gcc/fortran/resolve.c
Author: kargl Date: Sun Feb 11 19:07:55 2018 New Revision: 257568 URL: https://gcc.gnu.org/viewcvs?rev=257568&root=gcc&view=rev Log: Commit ChangeLog entries forgotten in r257566. 2018-02-11 Francois-Xavier Coudert <fxcoudert@gcc.gnu.org> PR fortran/35299 ChangeLog for r257566 * gfortran.dg/statement_function_3.f: New test. 2018-02-11 Francois-Xavier Coudert <fxcoudert@gcc.gnu.org> PR fortran/35299 ChangeLog for r257566 * resolve.c (resolve_formal_arglist): Update error message. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog
Author: kargl Date: Mon Feb 12 18:08:02 2018 New Revision: 257594 URL: https://gcc.gnu.org/viewcvs?rev=257594&root=gcc&view=rev Log: 2018-02-12 Francois-Xavier Coudert <fxcoudert@gcc.gnu.org> PR fortran/35299 ChangeLog for r257566 * gfortran.dg/statement_function_3.f: New test. 2018-02-12 Francois-Xavier Coudert <fxcoudert@gcc.gnu.org> PR fortran/35299 ChangeLog for r257566 * resolve.c (resolve_formal_arglist): Update error message. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/statement_function_3.f Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
Author: kargl Date: Mon Feb 12 18:26:44 2018 New Revision: 257597 URL: https://gcc.gnu.org/viewcvs?rev=257597&root=gcc&view=rev Log: 2018-02-12 Francois-Xavier Coudert <fxcoudert@gcc.gnu.org> PR fortran/35299 ChangeLog for r257566 * gfortran.dg/statement_function_3.f: New test. 2018-02-12 Francois-Xavier Coudert <fxcoudert@gcc.gnu.org> PR fortran/35299 ChangeLog for r257566 * resolve.c (resolve_formal_arglist): Update error message. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/statement_function_3.f Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/resolve.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
The patch from comment #2 has been applied to the 6-branch, 7-branch, and trunk.