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

[Janus Weil]

Hi Paul,

> The original testcase appears here as dtio_19.f90. I gather that some
> vendors accept this, while fort does not. IMHO ifort is correct here
> since there is no specific DTIO procedure present.

to be honest, I kind of disagree with ifort here (wouldn't be the
first time ;) ...

dtio_19.f90 looks like perfectly valid Fortran 2003 code to me. You
are right that there is no specific DTIO in the module at hand, but
certainly any variable that you could possibly pass to the 'assert'
routine must be a non-abstract extension of the abstract basetype
'object' and therefore must implement the deferred TBP
'write_formatted' that acts as a DTIO output procedure. So, at worst
the test case is incomplete, but not invalid IMHO. In ifort's view of
things, would the invalidity at least disappear if one adds another
module which implements an extended type (similar to what you do in
the second test case, but using two separate modules)?

Moreover I think your patch still mishandles my example in comment 18.

As commented several times in bugzilla, my feeling is that the
solution for this PR would be to utilize the vtable machinery, in
order to generate a truly polymorphic call to the DTIO procedure.
However, it might well be that I'm missing some central point of DTIO
which forbids this or makes it unnecessary. In that case I hope that
you can enlighten me :)

Cheers,
Janus



> 2016-12-12  Paul Thomas  <pault@gcc.gnu.org>
>
>     PR fortran/78737
>     * interface.c (gfc_compare_interfaces): Whitespace.
>     (gfc_find_specific_dtio_proc): Return NULL if dtio_sub is an
>     abstract interface.
>     * resolve.c (resolve_transfer): Formatting.
>     (resolve_typebound_procedure): Ditto.
>
> 2016-12-12  Paul Thomas  <pault@gcc.gnu.org>
>
>     PR fortran/78737
>     * gfortran.dg/dtio_19: New test.
>     * gfortran.dg/dtio_20: New test.