https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
--- Comment #10 from Paul Thomas <pault at gcc dot gnu.org> ---
Nagfor responds to the test case with "Error: pr97122.f90, line 14: Type T has
final subroutines but is not defined in the specification part of a module"
F2018:
"C787(R753) A final-subroutine-name shall be the name of a module procedure
with exactly one dummy argument."
Since, of necessity, the argument is declared to be of the derived type with
the final binding, the gfortran and nagfor errors are correct IMHO. ifort
compiles it without complaint.
I have marked this as "waiting" pending a contrary interpretation.
Cheers
Paul
(In reply to kargl from comment #9)
> (In reply to kargl from comment #7)
> > (In reply to kargl from comment #5)
> > > (In reply to Paul Thomas from comment #3)
> > > >
> > > > I have marked this as "waiting" pending a contrary interpretation.
> > > >
> > > > Cheers
> > > >
> > >
> > > Paul,
> > >
> > > I asked on the J3 mailing list about the code.
> > >
> > > https://mailman.j3-fortran.org/pipermail/j3/2023-May/014193.html
> >
> > I haven't had a response from a current member of J3. Bob Corbett,
> > a former member, believes the code is valid Fortran. Jeff Hammond
> > notes that Cray Fortran compiled the code. So, we have Cray, Intel
> > compile the code. NAG and gfortran reject it. I'm not sure if there
> > are any other compilers with submodule support.
>
> Malcolm Cohen from NAG has responded in the J3 list
> that it's a bug in nagfor, and the code in the bug
> report is conforming Fortran.
OK That's good enough for me :-) Changing to new.
Paul
