https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78737
--- Comment #24 from Damian Rouson <damian at sourceryinstitute dot org> --- (In reply to Paul Thomas from comment #21) > (In reply to Damian Rouson from comment #19) > > (In reply to Paul Thomas from comment #16) > > > (In reply to Paul Thomas from comment #15) > > > > (In reply to Damian Rouson from comment #14) > > > > > Hi Paul, > > > > > > > > > > Based on comment #12, I assume you no longer believe that type > > > > > guarding is > > > > > required. If I misinterpreted comment #12, please let me know. > > > > FWIW, I now realize I did misread comment #12. I focused in on "assert" and > > didn't notice the type-guarding in write_formatted above it. > > > > > > > > > > > > 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. > > > > The Cray and PGI compilers accept the in the original bug report. The Intel > > compiler rejects, but I've noticed a lot of problems with UDDTIO in the > > Intel compiler over the years so I'll submit a bug report to Intel. > > > > > > > > On thinking about it, is the specific instance of write_formatted allowed? > > > > I believe not. Note 7.50 of the 31 August 2016 draft Fortran 2015 standard > > includes the following: > > > > "The dynamic type of an object cannot be abstract; therefore, a deferred > > type-bound procedure cannot be invoked." > > > > I interpret the above quote to mean that write_formatted as written in > > comment #15 cannot be invoked. Presumably that also means it is invalid > > code. > > > > Damian > > Dear Damian, > > [pault@localhost pr78737]# /irun/bin/gfortran -static-libgfortran c*1.f90 -g > comment1.f90:21:16: > > write(*,*) a > 1 > Error: Data transfer element at (1) cannot be polymorphic unless it is > processed by a defined input/output procedure > [paultt@localhost pr78737]# ifort c*1.f90 > comment1.f90(21): error #5513: A polymorphic I/O list item requires a > user-defined derived-type input/output procedure. > write(*,*) a > ----^ > compilation aborted for comment1.f90 (code 1) > > ifort (IFORT) 16.0.3 20160415 > > This, I happen to think, is correct since there is no UDTIO procedure in > sight. Hi Paul, One scenario to consider: what if the module contains lots of other useful things and someone wants to be able to use the module without ever calling the "assert" procedure. If the above error messages are correct, then such a user must (1) extend the "object" type and (2) write a type-bound write_formatted procedure for the extended type whether or not the user has an use for the extended type or its write_formatted binding. I agree that invoking the procedure without extending the type would be invalid, but what if the module is compiled and linked into a program that never invokes the procedure? I'd be a little surprised if the committee intended that. If you still think the above error messages are correct, then it's probably worthwhile for me to submit a bug report to Intel to get their feedback and/or ask the committee for an interpretation. Damian
