[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #30 from Jerry DeLisle  ---
Agree, closing.  PR78670 will have some followup for READ related issues.

Fixed on trunk.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #29 from janus at gcc dot gnu.org ---
AFAICS r246546 should fully fix this PR, so I think it can be closed. Do you
agree, Jerry?

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #28 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Mar 28 17:01:05 2017
New Revision: 246546

URL: https://gcc.gnu.org/viewcvs?rev=246546=gcc=rev
Log:
2017-03-28  Janus Weil  

PR fortran/78661
* trans-io.c (transfer_namelist_element): Perform a polymorphic call
to a DTIO procedure if necessary.

2017-03-28  Janus Weil  

PR fortran/78661
* gfortran.dg/dtio_25.f90: Modified test case.
* gfortran.dg/dtio_27.f90: New test case.

2017-03-28  Janus Weil  

PR fortran/78661
* io/write.c (nml_write_obj): Build a class container only if
necessary.

Added:
trunk/gcc/testsuite/gfortran.dg/dtio_27.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-io.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dtio_25.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write.c

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #27 from Jerry DeLisle  ---
With the patch applied and the following test case:

MODULE m
  IMPLICIT NONE
  TYPE :: t
integer :: j
CHARACTER :: c
integer :: k
  CONTAINS
PROCEDURE :: write_formatted
GENERIC :: WRITE(FORMATTED) => write_formatted
PROCEDURE :: read_formatted
GENERIC :: READ(FORMATTED) => read_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, "(i10,3x,A,3x,i10)", IOSTAT=iostat, IOMSG=iomsg) dtv%j, dtv%c,
dtv%k
  END SUBROUTINE
  SUBROUTINE read_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
CLASS(t), INTENT(INOUT) :: dtv
INTEGER, INTENT(IN) :: unit
CHARACTER(*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: v_list(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER(*), INTENT(INOUT) :: iomsg
READ (unit, "(i10,3x,A,3x,i10)", IOSTAT=iostat, IOMSG=iomsg) dtv%j, dtv%c,
dtv%k
  END SUBROUTINE read_formatted
END MODULE

PROGRAM p
  USE m
  IMPLICIT NONE
  class(t), allocatable :: x
  NAMELIST /nml/ x
  x = t(55,'a',42)
  WRITE (10, nml)
  REWIND(10)
  READ(10, nml)
END

On the write I see what I expect, but we need to adjust list_read.c to handle
the parsing of input correctly.

$ ./a.out 
At line 42 of file 1test.f03 (unit = 10, file = 'fort.10')
Fortran runtime error: namelist read: misplaced = sign
$ cat fort.10 

 X=55   a   42
 /

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #26 from Jerry DeLisle  ---
(In reply to janus from comment #25)
> (In reply to Jerry DeLisle from comment #24)
> > I dont think the parent is suppose to emit the Object name. What if there
> > are multiple components?
> 
> Huh, I'm not sure. But your statement contradicts Ian's claim in comment #0:
> 
> > UDDTIO procedures are responsible for writing/reading the value part of the
> > name-value subsequence, the processor still has responsibility for the name=
> > part.

yes I am contradicting, but really asking the question.  Suppose a derived type
has 10 components.  If the parent is to emit the object names there are two
choices for the parent:


1) Only emit the parent name and do not emit the component names, allowing the
child procedure to emit all component values with one procedure call from the
parent. User could emit the child object names in some manner if they choose.

2) Emit parent and component names and call the user defined procedure once per
component, in other words 10 calls to get the whole thing. This makes no sense
at all.

Under option 1) we could do something like this:

! parent emits this line
 X= ! parent emits this line
 !child emits whatever they want component names or no component names
 !entirely up to the users definition
 x%data1 = value1
 x%data2 = value2
 x%data3 = value3
 Y=! parent emits this line
 !ditto on child


 /

 snip 
> "When the designator in the input record represents an array variable or a
> variable of derived type, the effect is as if the variable represented were
> expanded into a sequence of scalar list items, in the same way that
> formatted input/output list items are expanded (9.6.3)."
> 


> None of them makes a clear statement about DTIO namelist output. Apparently
> two forms are possible: Either having the whole DT variable, or its
> components separately.
> 
> To me it sounds like we should print the variable name (and not the
> component names) if the namelist contains a full DT variable (and not just
> some components).
> 

I agree with your last statement here in the case where there is a user defined
procedure.  Where there is not a user defined procedure, we do exactly what we
have done all along with gfortran, and print the component qualifier.

Let me apply you latest patch, I will prepare the two cases with and without
user defined I/O and show results here.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #25 from janus at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #24)
> I dont think the parent is suppose to emit the Object name. What if there
> are multiple components?

Huh, I'm not sure. But your statement contradicts Ian's claim in comment #0:

> UDDTIO procedures are responsible for writing/reading the value part of the
> name-value subsequence, the processor still has responsibility for the name=
> part.

I hope one should be able to settle this by having a deeper look in the
standard?!?

I found the following in F08 section 10.11.2:

"If the namelist group object is of derived type, the designator in the input
record may be either the name of the variable or the designator of one of its
components, indicated by qualifying the variable name with the appropriate
component name."

And then in section 10.11.3.2:

"When the designator in the input record represents an array variable or a
variable of derived type, the effect is as if the variable represented were
expanded into a sequence of scalar list items, in the same way that formatted
input/output list items are expanded (9.6.3)."

None of them makes a clear statement about DTIO namelist output. Apparently two
forms are possible: Either having the whole DT variable, or its components
separately.

To me it sounds like we should print the variable name (and not the component
names) if the namelist contains a full DT variable (and not just some
components).

What do other compilers do?

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #24 from Jerry DeLisle  ---
I dont think the parent is suppose to emit the Object name. What if there are
multiple comments?

should be:

I dont think the parent is suppose to emit the Object name. What if there are
multiple components?

Spell checker got me.  Anyway, this is new territory, so easy to adjust my test
case.  I can see some logic to emitting just the parent component name, but the
user needs to also do an appropriate READ dtio procedure and parent needs to
handle reading the parent object name before the call to child in that case.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #23 from Jerry DeLisle  ---
(In reply to janus from comment #22)
> (In reply to janus from comment #21)
> > The testcase seems to be working properly by now, but unfortunately the
> > patch breaks dtio_25.f90 (execution test), i.e. the test case from PR 78854.
> 
> What fails there is the execution check in line 36, which expects the buffer
> to be
> 
>  x%c="a",x%k=5  /
> 
> but with my patch the buffer becomes
> 
>   X=x%c="a",x%k=5  /
> 
> Are we actually supposed to write out the variable name ('X=') for types
> with DTIO procedures or not?

I believe one or the other of us has a misunderstanding of how this is suppose
to work. This is why I did dtio_25.f90 as I did, to catch this.

I dont think the parent is suppose to emit the Object name. What if there are
multiple comments? We do not have an established namelist representation for a
parent and child situation.  If we emit X= as the parent, how do we represent
and parse child components.  If we say "anyway the user wants to" then the test
case with mixed DTIO write followed by default namelist read is bogus and
should fail. If emitting X= is correct for the parent without also emitting
child object names, then dtio_25.f90 is bogus. I am happy to change the test
case, just was not sure what is right.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
Bug 78661 depends on bug 78854, which changed state.

Bug 78854 Summary: [F03] DTIO namelist output not working on internal unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #22 from janus at gcc dot gnu.org ---
(In reply to janus from comment #21)
> The testcase seems to be working properly by now, but unfortunately the
> patch breaks dtio_25.f90 (execution test), i.e. the test case from PR 78854.

What fails there is the execution check in line 36, which expects the buffer to
be

 x%c="a",x%k=5  /

but with my patch the buffer becomes

  X=x%c="a",x%k=5  /

Are we actually supposed to write out the variable name ('X=') for types with
DTIO procedures or not?

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #21 from janus at gcc dot gnu.org ---
Created attachment 40953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40953=edit
rebased patch

Here is the rebased patch. There was one conflict in libgfortran/io/write.c.
The testcase seems to be working properly by now, but unfortunately the patch
breaks dtio_25.f90 (execution test), i.e. the test case from PR 78854.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #20 from janus at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #19)
> > Here is an updated patch, which fixes all wrong-code issues AFAICS. It
> > includes improved handling of CLASS-vs-TYPE variables (analogous to PR
> > 78848) and a full-featured test case (which currently fails due to PR 
> > 78854).
> > 
> I would suggest committing this with no internal unit test or those parts
> commented out and then when I do get 78854 fixed we can update the test or
> add a new one.

Jerry, sorry for being so unresponsive on this (and thanks for fixing the other
PR by now). I have just updated my patch to the current trunk ...

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #19 from Jerry DeLisle  ---
(In reply to janus from comment #18)
> Created attachment 40364 [details]
> updated patch
> 
> Here is an updated patch, which fixes all wrong-code issues AFAICS. It
> includes improved handling of CLASS-vs-TYPE variables (analogous to PR
> 78848) and a full-featured test case (which currently fails due to PR 78854).
> 
> Note that the patch does not handle the rejects-valid problem of comment 5
> (which rather belong into PR 78659).

I would suggest committing this with no internal unit test or those parts
commented out and then when I do get 78854 fixed we can update the test or add
a new one.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|diagnostic  |
   Target Milestone|--- |7.0

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #40357|0   |1
is obsolete||

--- Comment #18 from janus at gcc dot gnu.org ---
Created attachment 40364
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40364=edit
updated patch

Here is an updated patch, which fixes all wrong-code issues AFAICS. It includes
improved handling of CLASS-vs-TYPE variables (analogous to PR 78848) and a
full-featured test case (which currently fails due to PR 78854).

Note that the patch does not handle the rejects-valid problem of comment 5
(which rather belong into PR 78659).

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #17 from janus at gcc dot gnu.org ---
(In reply to paul.richard.tho...@gmail.com from comment #16)
> I suppose that one would have to set up the namelist or the input
> stream to determine what the dynamic type is, have the code allocate
> the variable to that type and then do the input.

Huh, is it actually valid to do input on an unallocated CLASS (or TYPE)
variable? If it is, one can only rely on the declared type for choosing the
input procedure.

When doing input on an allocated variable, which has a well-defined dynamic
type, one can certainly do a polymorphic call of the input procedure.


> Best of all would be that namelist incorporated constructors :-)

Yes, that would also determine the dynamic type, but I assume the Fortran
standard does not support anything like this?


> I see no reason to require that both input and output be present.

Good. Then my patch is partially wrong and incomplete.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[paul.richard.thomas at gmail dot com]

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

--- Comment #16 from paul.richard.thomas at gmail dot com  ---
Dear Janus,

What troubles me is that most times I have used namelist, it has been
primarily for input to codes; especially where there is a default set
of initial conditions
and a subset is changed for each run.

I suppose that one would have to set up the namelist or the input
stream to determine what the dynamic type is, have the code allocate
the variable to that type and then do the input. Namelist output is,
of course, rather more obvious.

Best of all would be that namelist incorporated constructors :-)

I see no reason to require that both input and output be present.

Cheers

Paul

On 17 December 2016 at 19:07, janus at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
>
> --- Comment #14 from janus at gcc dot gnu.org ---
> (In reply to paul.richard.tho...@gmail.com from comment #13)
>> Why do you think that both input and output is required?
>
> Don't know. My intuitive reaction was that comment 5 should be valid, but I
> haven't looked in the standard. If it is valid, we probably need to move the
> check, which currently triggers on the namelist declaration, regardless of
> whether it's actually used in any input or output statements.
>
>
>> How is namelist supposed to work with classes? Just with the declared type?
>
> As with 'normal' I/O, I'd say, i.e. calling the DTIO procedure according to 
> the
> dynamic type (not the declared type!). At least that's what my patch does ...
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle  ---
(In reply to janus from comment #11)
> (In reply to janus from comment #10)
> > The attached patch seems to make the original comment 0 as well as the
> > polymorphic version in comment 7 work. Regtesting now ...
> 
> Regtesting was successful. There might be some commas missing in the output,
> though (not sure). Comments welcome.

The other half of this bug is the namelist reading which is 78670, the
description is misleading. So a similar approach in the library is needed in
list_read.c.  The placement of the call to the dtio procedures is important.
One must note that we can have arrays of objects and there is a mechanism for
looping over the array.

We should probably create a test case with more complex types with a mix of
derived and non derived components with mutliple levels of derived. One thing I
have not tried is to define a namelist within the use module such that one
could assign the dtv object into a namelist and invoke a namelist read/write
within the child procedure and nest these things. (is it legal to do so?, I
need to check) There is also a responsibility on the user to match there child
reads to there child writes so that things come out making sense. (generally
speaking, the child procedure should query the iotype variable to see if the
parent was a namelist read/write and do the right thing)

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #14 from janus at gcc dot gnu.org ---
(In reply to paul.richard.tho...@gmail.com from comment #13)
> Why do you think that both input and output is required?

Don't know. My intuitive reaction was that comment 5 should be valid, but I
haven't looked in the standard. If it is valid, we probably need to move the
check, which currently triggers on the namelist declaration, regardless of
whether it's actually used in any input or output statements.


> How is namelist supposed to work with classes? Just with the declared type?

As with 'normal' I/O, I'd say, i.e. calling the DTIO procedure according to the
dynamic type (not the declared type!). At least that's what my patch does ...

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[paul.richard.thomas at gmail dot com]

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

--- Comment #13 from paul.richard.thomas at gmail dot com  ---
Hi Janus,

Why do you think that both input and output is required?

How is namelist supposed to work with classes? Just with the declared type?

Cheers

Paul

On 17 December 2016 at 15:23, janus at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
>
> --- Comment #6 from janus at gcc dot gnu.org ---
> (In reply to janus from comment #5)
>> Btw, this variant is wrongly rejected:
>>
>> [..]
>>
>>NAMELIST /nml/ x
>>1
>> Error: NAMELIST object ‘x’ in namelist ‘nml’ at (1) is polymorphic and
>> requires a defined input/output procedure
>
> Sorry, false alarm. In principle the error message is correct, although the
> wording is maybe a bit off: Both an input *and* output procedure is required!
>
> I'd suggest this change:
>
> Index: gcc/fortran/resolve.c
> ===
> --- gcc/fortran/resolve.c   (revision 243773)
> +++ gcc/fortran/resolve.c   (working copy)
> @@ -13871,8 +13871,8 @@ resolve_fl_namelist (gfc_symbol *sym)
>if (nl->sym->ts.type == BT_CLASS && !dtio)
> {
>   gfc_error ("NAMELIST object %qs in namelist %qs at %L is "
> -"polymorphic and requires a defined input/output "
> -"procedure", nl->sym->name, sym->name, 
> >declared_at);
> +"polymorphic and requires defined input and output "
> +"procedures", nl->sym->name, sym->name,
> >declared_at);
>   return false;
> }
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle  ---
(In reply to janus from comment #9)
> Jerry, I don't want to steal this PR from you ;) but I think I have a rather
> complete patch by now. If you have any comments, please let me know!

You save me a lot of time. I will will review and test what you have. Very few
people delve into namelist.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org ---
(In reply to janus from comment #10)
> The attached patch seems to make the original comment 0 as well as the
> polymorphic version in comment 7 work. Regtesting now ...

Regtesting was successful. There might be some commas missing in the output,
though (not sure). Comments welcome.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org ---
Created attachment 40357
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40357=edit
draft patch

The attached patch seems to make the original comment 0 as well as the
polymorphic version in comment 7 work. Regtesting now ...

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|jvdelisle at gcc dot gnu.org   |janus at gcc dot gnu.org

--- Comment #9 from janus at gcc dot gnu.org ---
Jerry, I don't want to steal this PR from you ;) but I think I have a rather
complete patch by now. If you have any comments, please let me know!

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
This patch seems to produce the correct dump for the example in comment 7:

Index: gcc/fortran/trans-io.c
===
--- gcc/fortran/trans-io.c  (revision 243773)
+++ gcc/fortran/trans-io.c  (working copy)
@@ -1713,6 +1713,32 @@ transfer_namelist_element (stmtblock_t * block, co
  vtable = gfc_build_addr_expr (pvoid_type_node, vtable);
}
 }
+  else if (ts->type == BT_CLASS)
+{
+  gfc_symbol *derived = ts->u.derived->components->ts.u.derived;
+  gfc_symtree *tb_io_st = gfc_find_typebound_dtio_proc (derived,
+   last_dt == WRITE,
true);
+  if (tb_io_st)
+   {
+ gfc_se se;
+ gfc_symtree *st = gfc_find_symtree (sym->ns->sym_root, sym->name);
+ // build vtable expr
+ gfc_expr *expr = gfc_get_variable_expr (st);
+ gfc_add_vptr_component (expr);
+ gfc_init_se (, NULL);
+ se.want_pointer = 1;
+ gfc_conv_expr (, expr);
+ vtable = se.expr;
+ // build dtio expr
+ gfc_add_component_ref (expr,
+tb_io_st->n.tb->u.generic->specific_st->name);
+ gfc_init_se (, NULL);
+ se.want_pointer = 1;
+ gfc_conv_expr (, expr);
+ gfc_free_expr (expr);
+ dtio_proc = se.expr;
+   }
+}

   if (ts->type == BT_CHARACTER)
 tmp = ts->u.cl->backend_decl;


The library call with this looks like:

_gfortran_st_set_nml_dtio_var (_parm.3, , &"x"[1]{lb: 1 sz: 1}, 0, 0, 56,
x._vptr->write_formatted, (struct __vtype_m_T *) x._vptr);

That seems correct to me, but still the output is wrong:


 X=�
 /

So I guess something in the library still fails, and I already have a suspicion
...

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
So, here is a corrected test for the polymorphic case:

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

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


It currently prints (with my patch from comment 4, but probably also without):


 X=
 /

Apparently 'write_formatted' is not called. The dump for the non-poly version
from comment 0/3 shows:

_gfortran_st_set_nml_dtio_var (_parm.3, x, &"x"[1]{lb: 1 sz: 1}, 0, 0, 40,
write_formatted, (void *) &__vtab_m_T);

But for the polymorphic version it has:

_gfortran_st_set_nml_dtio_var (_parm.3, , &"x"[1]{lb: 1 sz: 1}, 0, 0, 56,
0B, 0B);

Neither the DTIO procedure nor the vtab is called. The DTIO procedure we need
here is "x._vptr->write_formatted".

Btw why do we actually pass the vtab in the first case?

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> Btw, this variant is wrongly rejected:
> 
> [..]
> 
>NAMELIST /nml/ x
>1
> Error: NAMELIST object ‘x’ in namelist ‘nml’ at (1) is polymorphic and
> requires a defined input/output procedure

Sorry, false alarm. In principle the error message is correct, although the
wording is maybe a bit off: Both an input *and* output procedure is required!

I'd suggest this change:

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 243773)
+++ gcc/fortran/resolve.c   (working copy)
@@ -13871,8 +13871,8 @@ resolve_fl_namelist (gfc_symbol *sym)
   if (nl->sym->ts.type == BT_CLASS && !dtio)
{
  gfc_error ("NAMELIST object %qs in namelist %qs at %L is "
-"polymorphic and requires a defined input/output "
-"procedure", nl->sym->name, sym->name, >declared_at);
+"polymorphic and requires defined input and output "
+"procedures", nl->sym->name, sym->name,
>declared_at);
  return false;
}