https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84276
--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Fri, Feb 09, 2018 at 09:15:00PM +0000, mecej4 at outlook dot com wrote: > --- Comment #10 from mecej4 <mecej4 at outlook dot com> --- > (In reply to Steve Kargl from comment #9) > > On Fri, Feb 09, 2018 at 01:52:03PM +0000, mecej4 at outlook dot com wrote: > > > (In reply to Steve Kargl from comment #7) > > > > ... > > > > w = qofs(i = i, s = hh) > > > > ... > > > > > > Keyword argument lists are not allowed for statement > > > functions, are they? I realize that the compiler will > > > have to detect and flag attempts to use keyword > > > arguments as disallowed, but no code generation is needed. > > > > I cannot find a prohibition in F2018 standard. > > AFAICT, gfortran always supported keywords, and > > I've developed a patch to retain that behavior. > > I cannot find an explicit prohibition, either, but please consider > these related statements from F2003: > > Section 12.3.1: ..."The interface of a statement function is always > implicit". Yep, I found that. > Section 12.3.1.1: ..."A procedure other than a statement function > shall have an explicit interface if it is referenced and a reference > to the procedure appears with an argument keyword" Yep, I found that, too. This contains requirements for procedures that aren't statement functions. As a statement functions is an exception and a compiler builds its interface at compile time, I do not see why the standard would prohibit the use of keywords. Although I don't recall ever seeing a bug report about keywords and statement functions, over the years, I have come to expect that users can find new and unique ways to break gfortran. My patch is keeping gfortran's historical behavior. A side benefit is that an additional line of code fixes PR 54223. Unfortunately, getting expert input on c.l.f has become too much drama.
