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 <pa...@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 <pa...@gcc.gnu.org> > > PR fortran/78737 > * gfortran.dg/dtio_19: New test. > * gfortran.dg/dtio_20: New test.
