[Bug fortran/78737] [OOP] linking error with deferred, undefined user-defined derived-type I/O

["janus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #17 from janus at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #15)
> Dear Damian and Janus,
> 
> What I meant is that we did not implement dynamic dispatch of the dtio
> procedures. In the corrected testcase of comments #12 and #13, where the
> first argument of write_formatted has declared type 'object', it is
> necessary to use type guarding within write_formatted to obtain the
> appropriate IO.
> 
> I have to confess that this "interpretation" is arrived at by the absence of
> any mention of the need for dynamic dispatch and by the implementation by
> other vendors.

Huh, but I still don't see that the standars would forbid polymorphic uses of
DTIO. To the contrary, the F03 standard says explicitly in section 9.5.2:

"A list item shall not be polymorphic unless it is processed by a user-defined
derived-type input/output
procedure (9.5.3.7)."

I don't see any useful interpretation of code like

    class(object):: a
    write(*,*) a

except making a polymorphic call to the DTIO procedure corresponding to the
dynamic type (i.e. taken from the vtable). That should not be very hard to
implement in gfortran technically (with all our exisiting machinery for classes
and polymorphism) and I don't see anything that would impose a different
interpretation in the standard. If I'm missing anything, please let me know.


> See this further example, which works with the last version of the patch.
> 
> [...]
> 
> Is this now OK?

Your last patch seems to produce the expected results for this particular case,
but only due to the introduction of the awkward SELECT TYPE workaround.
Actually no polymorphic invocation of the DTIO procedures is performed here.

Also your patch now rejects comment 0 with:

     write(*,*) a
                 1
Error: Data transfer element at (1) cannot be polymorphic unless it is
processed by a defined input/output procedure

Is that intentional? AFAICS the code in comment 0 should be valid, right?