[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659

Jerry DeLisle  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #16 from Jerry DeLisle  ---
Fixed on 7 and 8, closing

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659

--- Comment #15 from Jerry DeLisle  ---
Author: jvdelisle
Date: Wed May 17 18:09:48 2017
New Revision: 248166

URL: https://gcc.gnu.org/viewcvs?rev=248166=gcc=rev
Log:
2017-05-17  Jerry DeLisle  

Backport from trunk
PR fortran/78659
* io.c (dtio_procs_present): Add new function to check for DTIO
procedures relative to I/O statement READ or WRITE.
(gfc_resolve_dt): Add namelist checks using the new function.
* resolve.c (dtio_procs_present): Remove function and related
namelist checks. (resolve_fl_namelist): Add check specific to
Fortran 95 restriction on namelist objects.

* gfortran.dg/namelist_91.f90: New test.
* gfortran.dg/namelist_92.f90: New test.
* gfortran.dg/namelist_93.f90: New test.
* gfortran.dg/namelist_94.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/namelist_91.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/namelist_92.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/namelist_93.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/namelist_94.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/io.c
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659

--- Comment #14 from Jerry DeLisle  ---
Author: jvdelisle
Date: Thu May 11 20:40:49 2017
New Revision: 247930

URL: https://gcc.gnu.org/viewcvs?rev=247930=gcc=rev
Log:
2017-05-11  Jerry DeLisle  

PR fortran/78659
* io.c (dtio_procs_present): Add new function to check for DTIO
procedures relative to I/O statement READ or WRITE.
(gfc_resolve_dt): Add namelist checks using the new function.
* resolve.c (dtio_procs_present): Remove function and related
namelist checks. (resolve_fl_namelist): Add check specific to
Fortran 95 restriction on namelist objects.

* gfortran.dg/namelist_91.f90: New test.
* gfortran.dg/namelist_92.f90: New test.
* gfortran.dg/namelist_93.f90: New test.
* gfortran.dg/namelist_94.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/namelist_91.f90
trunk/gcc/testsuite/gfortran.dg/namelist_92.f90
trunk/gcc/testsuite/gfortran.dg/namelist_93.f90
trunk/gcc/testsuite/gfortran.dg/namelist_94.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659

Jerry DeLisle  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #13 from Jerry DeLisle  ---
*** Bug 78864 has been marked as a duplicate of this bug. ***

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659

--- Comment #12 from Jerry DeLisle  ---
(In reply to janus from comment #8)

The case that ICEs needs to have an error check in io.c (gfc_resolve_dt). I
have found the location and now need to build the error check.

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659

--- Comment #11 from janus at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #10)
> Agree, I will look further Janus, unless you are digging into it already?

I'm currently looking into PR 78661. Would be great if you could take care of
this one. Thanks!

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659

--- Comment #10 from Jerry DeLisle  ---
(In reply to janus from comment #8)
> I think this needs to be reopened. As mentioned in comment 0, the original
> test case in itself is valid, but is invalidated by adding an I/O statement
> that references the namelist, like so:
> 

Agree, I will look further Janus, unless you are digging into it already?

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #9 from janus at gcc dot gnu.org ---
Btw, here is another case similar to the original problem in comment 0 (from PR
78661 comment 5):


MODULE m
  IMPLICIT NONE
  TYPE :: t
CHARACTER :: c
  CONTAINS
PROCEDURE :: write_formatted
GENERIC :: WRITE(FORMATTED) => write_formatted
  END TYPE
CONTAINS
  SUBROUTINE write_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
CLASS(t), INTENT(IN) :: dtv
INTEGER, INTENT(IN) :: unit
CHARACTER(*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: v_list(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER(*), INTENT(INOUT) :: iomsg
WRITE (unit, "(A)", IOSTAT=iostat, IOMSG=iomsg) dtv%c
  END SUBROUTINE
END MODULE

PROGRAM p
  USE m
  IMPLICIT NONE
  Class(t), allocatable :: x
  NAMELIST /nml/ x
  x = t('a')
  WRITE (*, nml)
END


Although it is supposed to be valid, this is still rejected with 

   NAMELIST /nml/ x
   1
Error: NAMELIST object ‘x’ in namelist ‘nml’ at (1) is polymorphic and requires
a defined input/output procedure

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #8 from janus at gcc dot gnu.org ---
I think this needs to be reopened. As mentioned in comment 0, the original test
case in itself is valid, but is invalidated by adding an I/O statement that
references the namelist, like so:

MODULE ma
  IMPLICIT NONE
  TYPE :: ta
INTEGER, ALLOCATABLE :: array(:)
  END TYPE ta
END MODULE ma

PROGRAM p
  USE ma
  TYPE(ta) :: x
  NAMELIST /nml/ x
  WRITE (*, nml)
END PROGRAM p

This case is not rejected after r243308 and runs into an ICE.

With gfortran 6, it is rejected with the old error. Although it is not quite
correct that the error is thrown on the namelist statement instead of the write
statement, the ICE is technically a regression.

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Jerry DeLisle  ---
Fixed on trunk. Closing

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659

--- Comment #6 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Dec  6 17:13:31 2016
New Revision: 243308

URL: https://gcc.gnu.org/viewcvs?rev=243308=gcc=rev
Log:
2016-12-06  Jerry DeLisle  

PR fortran/78659
* resolve.c (resolve_fl_namelist): Remove unneeded error.
PR fortran/78659
* gfortran.dg/alloc_comp_constraint_1.f90: Update test.
* gfortran.dg/alloc_comp_constraint_7.f90: New test.
* gfortran.dg/namelist_34.f90: Update test.
* gfortran.dg/namelist_63.f90: Update test.

Added:
trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_7.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_1.f90
trunk/gcc/testsuite/gfortran.dg/namelist_34.f90
trunk/gcc/testsuite/gfortran.dg/namelist_63.f90

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #4)
> I have the ICE resolved, but also note that the Fortran 95 standard has the
> constraint on namelist statements and F2003 does not.
> 
> Constraint - namelist-group-object shall not be an array dummy argument with
> a nonconstant bound, a variable with nonconstant character length, an
> automatic object, a pointer, a variable of a type that has an ultimate
> component that is a pointer, or an allocatable array.
> 
> We can got two ways here, forget about the F95 standard and accept it, or
> give an error with -std=f95. This is sort of troublsome because we have to
> maintain two or more behaviors if a user wants to check against F95.  I
> wonder if we should get rid of the -std=f95 altogether and just keep
> -std=F2003 or similar.
> 
> Any opinions?

I would prefer an error with -std=f95.  This is what 
gfc_notify_std() is used for.  ISTR that list of things
in others places, but don't recall if we have a simply
function where you could do

   if (check_list_of_stuff () && gfc_notify_std (GFC_F95,...))

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659

--- Comment #4 from Jerry DeLisle  ---
I have the ICE resolved, but also note that the Fortran 95 standard has the
constraint on namelist statements and F2003 does not.

Constraint - namelist-group-object shall not be an array dummy argument with a
nonconstant bound, a variable with nonconstant character length, an automatic
object, a pointer, a variable of a type that has an ultimate component that is
a pointer, or an allocatable array.

We can got two ways here, forget about the F95 standard and accept it, or give
an error with -std=f95. This is sort of troublsome because we have to maintain
two or more behaviors if a user wants to check against F95.  I wonder if we
should get rid of the -std=f95 altogether and just keep -std=F2003 or similar.

Any opinions?