User account creation filtered due to spam.

Bug 48298 - [F03] User-Defined Derived-Type IO (DTIO)
Summary: [F03] User-Defined Derived-Type IO (DTIO)
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Jerry DeLisle
URL:
Keywords:
Depends on:
Blocks: 20585
  Show dependency treegraph
 
Reported: 2011-03-27 14:31 UTC by Jerry DeLisle
Modified: 2016-10-27 01:40 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-06-16 00:00:00


Attachments
A starting front end only patch (862 bytes, patch)
2011-03-27 21:18 UTC, Jerry DeLisle
Details | Diff
A starter test case (599 bytes, text/plain)
2011-03-28 03:22 UTC, Jerry DeLisle
Details
Expanded test case (732 bytes, text/plain)
2015-11-22 20:10 UTC, Jerry DeLisle
Details
Revised patch for review/testing (6.77 KB, patch)
2016-09-21 15:52 UTC, Jerry DeLisle
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jerry DeLisle 2011-03-27 14:31:37 UTC
Tracker for implementation of this new feature.
Comment 1 Jerry DeLisle 2011-03-27 21:18:40 UTC
Created attachment 23785 [details]
A starting front end only patch

This is a beginning patch to allow the DTIO syntax to be accepted and some format descriptor checking.
Comment 2 Jerry DeLisle 2011-03-28 03:22:01 UTC
Created attachment 23787 [details]
A starter test case

Using this attached file as a beginning test case.  Extracted fro F2003 Standard examples.
Comment 3 Tobias Burnus 2011-03-28 07:48:51 UTC
(In reply to comment #1)
> Created attachment 23785 [details]
> A starting front end only patch

+	  if (gfc_notify_std (GFC_STD_F2003, "Fortran 2003: DT format "
+	      "specifier not allowed at %C") == FAILURE)

I somehow have parse problems; it sounds to me as if in Fortran 2003 the DT specifier is not allowed. I would use:

+	  if (gfc_notify_std (GFC_STD_F2003, "Fortran 2003: DT format "
+	      "specifier at %C") == FAILURE)
Comment 4 Jerry DeLisle 2011-05-02 13:04:30 UTC
Status: With some significant help from Michael, we have a front-end patch generating a call to transfer_derived() which passes a pointer to the user defined DTIO procedure to libgfortran.

Next step is parsing format strings in libgfortran for the FMT_DT specifier.
Comment 5 janus 2011-09-07 21:59:27 UTC
link to Jerry's preliminary patch:

http://gcc.gnu.org/ml/fortran/2011-07/msg00180.html
Comment 6 Dominique d'Humieres 2013-06-16 14:39:03 UTC
Any progress with this PR?
Comment 7 Damian Rouson 2013-10-23 08:09:32 UTC
Any updates on this PR?  I'm teaching a graduate course on modern Fortran and will be using this feature in class.  It would be great to have an open-source compiler that supports the feature.
Comment 8 Jerry DeLisle 2014-10-03 01:59:02 UTC
Unasigning myself.
Comment 9 Damian Rouson 2014-10-03 04:45:08 UTC
Oh boy.  I'm guessing that's an indication that there won't be any movement on this anytime soon.  It seems this is one of only two major features missing for full Fortran 2003 compliance -- the other being derived type parameters.  One of the Fortran committee members recently suggested that derived type parameters be deprecated.  I wonder if the same is true of derived type I/O.  If the leading open-source Fortran compiler already supports some features of Fortran 2008 and Fortran 2015 but has major features of Fortran 2003 missing a decade after the publication of the standard, maybe that's a sign that the feature should be removed from the language.  Thoughts?
Comment 10 kargl 2014-10-03 05:15:48 UTC
(In reply to Damian Rouson from comment #9)
> Oh boy.  I'm guessing that's an indication that there won't be any movement
> on this anytime soon.  It seems this is one of only two major features
> missing for full Fortran 2003 compliance -- the other being derived type
> parameters.  One of the Fortran committee members recently suggested that
> derived type parameters be deprecated.  I wonder if the same is true of
> derived type I/O.  If the leading open-source Fortran compiler already
> supports some features of Fortran 2008 and Fortran 2015 but has major
> features of Fortran 2003 missing a decade after the publication of the
> standard, maybe that's a sign that the feature should be removed from the
> language.  Thoughts?

It's a sign that those who contribute code, do it for free
and when they have time.  No one or entity has stepped forward
to implement DTIO or provide sufficient funding.  Cray pointers
got implemented because someone at LBNL hired a summer intern.
ISO C binding got done because someone at Argonne funded a
graduate student/intern.  Almost all of my contributions came
about because I needed the feature to work.  I don't use or
need DTIO, so it's well down my list of things to hack on.
Comment 11 Damian Rouson 2014-10-03 05:21:36 UTC
Thanks for the quick response.  In recent times, I’ve had the impression that it’s harder to find developers than to find money (not that it’s all that easy to find money).  I’ve attempted to fund gfortran development at least twice — once successfully and once unsuccessfully. 

Damian


On Oct 2, 2014, at 10:15 PM, kargl at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298
> 
> kargl at gcc dot gnu.org changed:
> 
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |kargl at gcc dot gnu.org
> 
> --- Comment #10 from kargl at gcc dot gnu.org ---
> (In reply to Damian Rouson from comment #9)
>> Oh boy.  I'm guessing that's an indication that there won't be any movement
>> on this anytime soon.  It seems this is one of only two major features
>> missing for full Fortran 2003 compliance -- the other being derived type
>> parameters.  One of the Fortran committee members recently suggested that
>> derived type parameters be deprecated.  I wonder if the same is true of
>> derived type I/O.  If the leading open-source Fortran compiler already
>> supports some features of Fortran 2008 and Fortran 2015 but has major
>> features of Fortran 2003 missing a decade after the publication of the
>> standard, maybe that's a sign that the feature should be removed from the
>> language.  Thoughts?
> 
> It's a sign that those who contribute code, do it for free
> and when they have time.  No one or entity has stepped forward
> to implement DTIO or provide sufficient funding.  Cray pointers
> got implemented because someone at LBNL hired a summer intern.
> ISO C binding got done because someone at Argonne funded a
> graduate student/intern.  Almost all of my contributions came
> about because I needed the feature to work.  I don't use or
> need DTIO, so it's well down my list of things to hack on.
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 12 Jerry DeLisle 2014-10-03 13:27:04 UTC
As a volunteer, I simply do not have the time.  I am not trying to imply any opinion pro or con regarding DTIO.  The FORTRAN community as a whole needs to decide what is needed and I invite anyone interested to step up and do this.

I don't think it is as difficult to do as everyone thinks.  However, it will require a concentrated effort to 'see' what I mean.  If we could develop the conceptual design, the implementation will just fall out.
Comment 13 Jerry DeLisle 2015-09-07 22:20:48 UTC
Starting back in on this.
Comment 14 Jerry DeLisle 2015-11-22 20:10:19 UTC
Created attachment 36805 [details]
Expanded test case

Attached is an expanded test case. Could someone review and confirm this is valid.  I need to work some code in interface.c to eliminate an error I am getting and want to make sure the error is valid or not.
Comment 15 Steve Kargl 2015-11-23 18:01:44 UTC
On Sun, Nov 22, 2015 at 08:10:19PM +0000, jvdelisle at gcc dot gnu.org wrote:
> 
> Attached is an expanded test case. Could someone review and confirm this is
> valid.  I need to work some code in interface.c to eliminate an error I am
> getting and want to make sure the error is valid or not.
> 

I don't know DTIO, so can't be of much help.  You amy want to
post the example to comp.lang.fortran.  You'll likely get more
then enough opinions on the code.  Posters in clf may even give
you some difficult testcases.
Comment 16 Walter Spector 2016-07-28 17:16:54 UTC
Adding myself to the cc list.

Jerry - Your example in Comment 14 needs a little touching up to be legal.
The read methods need to have the dtv argument as intent (in out).  Also the
unformatted methods do not have iotype or vlist dummy args.

Walter
Comment 17 Paul Thomas 2016-08-31 05:36:54 UTC
Author: pault
Date: Wed Aug 31 05:36:22 2016
New Revision: 239880

URL: https://gcc.gnu.org/viewcvs?rev=239880&root=gcc&view=rev
Log:
2016-08-31  Paul Thomas  <pault@gcc.gnu.org>
	Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/48298

	* decl.c (access_attr_decl): Include case INTERFACE_DTIO as
	appropriate.
	* gfortran.h : Add INTRINSIC_FORMATTED and
	INTRINSIC_UNFORMATTED to gfc_intrinsic_op. Add INTERFACE_DTIO
	to interface type. Add new enum 'dtio_codes'. Add bitfield
	'has_dtio_procs' to symbol_attr. Add prototypes
	'gfc_check_dtio_interfaces' and 'gfc_find_specific_dtio_proc'.
	* interface.c (dtio_op): New function.
	(gfc_match_generic_spec): Match generic DTIO interfaces.
	(gfc_match_interface): Treat DTIO interfaces in the same way as
	(gfc_current_interface_head): Add INTERFACE_DTIO appropriately.
	(check_dtio_arg_TKR_intent): New function.
	(check_dtio_interface1): New function.
	(gfc_check_dtio_interfaces): New function.
	(gfc_find_specific_dtio_proc): New function.
	* io.c : Add FMT_DT to format_token.
	(format_lex): Handle DTIO formatting.
	* match.c (gfc_op2string): Add DTIO operators.
	* resolve.c (derived_inaccessible): Ignore pointer components
	to enclosing derived type.
	(resolve_transfer): Resolve transfers that involve DTIO.
	procedures. Find the specific subroutine for the transfer and
	use its existence to over-ride some of the constraints on
	derived types. If the transfer is recursive, require that the
	subroutine be so qualified.
	(dtio_procs_present): New function.
	(resolve_fl_namelist): Remove inhibition of polymorphic objects
	in namelists if DTIO read and write subroutines exist. Likewise
	for derived types.
	(resolve_types): Invoke 'gfc_verify_dtio_procedures'.
	* symbol.c : Set 'dtio_procs' using 'minit'.
	* trans-decl.c (gfc_finish_var_decl): If a derived-type/class
	object is associated with DTIO procedures, make it TREE_STATIC.
	* trans-expr.c (gfc_get_vptr_from_expr): If the expression
	drills down to a PARM_DECL, extract the vptr correctly.
	(gfc_conv_derived_to_class): Check 'info' in the test for
	'useflags'. If the se expression exists and is a pointer, use
	it as the class _data.
	* trans-io.c : Add IOCALL_X_DERIVED to iocall and the function
	prototype. Likewise for IOCALL_SET_NML_DTIO_VAL.
	(set_parameter_tree): Renamed from 'set_parameter_const', now
	returns void and has new tree argument. Calls modified to match
	new interface.
	(transfer_namelist_element): Transfer DTIO procedure pointer
	and vpointer using the new function IOCALL_SET_NML_DTIO_VAL.
	(get_dtio_proc): New function.
	(transfer_expr): Add new argument for the vptr field of class
	objects. Add the code to call the specific DTIO proc, convert
	derived types to class and call IOCALL_X_DERIVED.
	(trans_transfer): Add BT_CLASS to structures for treatment by
	the scalarizer. Obtain the vptr for the dynamic type, both for
	scalar and array transfer.

2016-08-31  Jerry DeLisle  <jvdelisle@gcc.gnu.org>
	Paul Thomas  <pault@gcc.gnu.org>

	PR libgfortran/48298
	* gfortran.map : Flag _st_set_nml_dtio_var and
	_gfortran_transfer_derived.
	* io/format.c (format_lex): Detect DTIO formatting.
	(parse_format_list): Parse the DTIO format.
	(next_format): Include FMT_DT.
	* io/format.h : Likewise. Add structure 'udf' to structure
	'fnode' to carry the IOTYPE string and the 'vlist'.
	* io/io.h : Add prototypes for the two types of DTIO subroutine
	and a typedef for gfc_class. Also, add to 'namelist_type'
	fields for the pointer to the DTIO procedure and the vtable.
	Add fields to struct st_parameter_dt for pointers to the two
	types of DTIO subroutine. Add to gfc_unit DTIO specific fields.
	(internal_proto): Add prototype for 'read_user_defined' and
	'write_user_defined'.
	* io/list_read.c (check_buffers): Use the 'current_unit' field.
	(unget_char): Likewise.
	(eat_spaces): Likewise.
	(list_formatted_read_scalar): For case BT_CLASS, call the DTIO
	procedure.
	(nml_get_obj_data): Likewise when DTIO procedure is present,.
	* io/transfer.c : Export prototypes for 'transfer_derived' and
	'transfer_derived_write'.
	(unformatted_read): For case BT_CLASS, call the DTIO procedure.
	(unformatted_write): Likewise.
	(formatted_transfer_scalar_read): Likewise.
	(formatted_transfer_scalar_write: Likewise.
	(transfer_derived): New function.
	(data_transfer_init): Set last_char if no child_dtio.
	(finalize_transfer): Return if child_dtio set.
	(st_write_done): Add condition for child_dtio not set.
	Add extra arguments for st_set_nml_var prototype.
	(set_nml_var): New function that contains the contents of the
	old version of st_set_nml_var. Also sets the 'dtio_sub' and
	'vtable' fields of the 'nml' structure.
	(st_set_nml_var): Now just calls set_nml_var with 'dtio_sub'
	and 'vtable' NULL.
	(st_set_nml_dtio_var): New function that calls set_nml_var.
	* io/unit.c (get_external_unit): If the found unit child_dtio
	is non zero, don't do any mutex locking/unlocking.  Just
	return the unit.
	* io/unix.c (tempfile_open): Revert to C style comment.
	* io/write.c (list_formatted_write_scalar): Do the DTIO call.
	(nml_write_obj): Add BT_CLASS and do the DTIO call.

2016-08-31  Jerry DeLisle  <jvdelisle@gcc.gnu.org>
	Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/48298
	* gfortran.dg/dtio_1.f90: New test.
	* gfortran.dg/dtio_2.f90: New test.
	* gfortran.dg/dtio_3.f90: New test.
	* gfortran.dg/dtio_4.f90: New test.
	* gfortran.dg/dtio_5.f90: New test.
	* gfortran.dg/dtio_6.f90: New test.
	* gfortran.dg/dtio_7.f90: New test.
	* gfortran.dg/dtio_8.f90: New test.
	* gfortran.dg/dtio_9.f90: New test.
	* gfortran.dg/dtio_10.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/dtio_1.f90
    trunk/gcc/testsuite/gfortran.dg/dtio_10.f90
    trunk/gcc/testsuite/gfortran.dg/dtio_2.f90
    trunk/gcc/testsuite/gfortran.dg/dtio_3.f90
    trunk/gcc/testsuite/gfortran.dg/dtio_4.f90
    trunk/gcc/testsuite/gfortran.dg/dtio_5.f90
    trunk/gcc/testsuite/gfortran.dg/dtio_6.f90
    trunk/gcc/testsuite/gfortran.dg/dtio_7.f90
    trunk/gcc/testsuite/gfortran.dg/dtio_8.f90
    trunk/gcc/testsuite/gfortran.dg/dtio_9.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/interface.c
    trunk/gcc/fortran/io.c
    trunk/gcc/fortran/match.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/symbol.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-io.c
    trunk/gcc/testsuite/ChangeLog
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/gfortran.map
    trunk/libgfortran/io/format.c
    trunk/libgfortran/io/format.h
    trunk/libgfortran/io/io.h
    trunk/libgfortran/io/list_read.c
    trunk/libgfortran/io/transfer.c
    trunk/libgfortran/io/unit.c
    trunk/libgfortran/io/unix.c
    trunk/libgfortran/io/write.c
Comment 18 Walter Spector 2016-08-31 17:38:48 UTC
Awesome!

I have noticed one bug so far.  The compiler is missing a check to see if the arguments in the I/O procedures have the 'optional' attribute.  It is allowing the attribute - even though it is illegal.  E.g. the following should be flagged as erroneous:

  SUBROUTINE pwf (dtv,unit,iotype,vlist,iostat,iomsg)
    ! argument definitions
    CLASS(person), INTENT(IN) :: dtv
    INTEGER, INTENT(IN), OPTIONAL :: unit
    CHARACTER (LEN=*), INTENT(IN), OPTIONAL :: iotype
    INTEGER, INTENT(IN), OPTIONAL :: vlist(:)
    INTEGER, INTENT(OUT), OPTIONAL :: iostat
    CHARACTER (LEN=*), INTENT(INOUT), OPTIONAL :: iomsg
    ...

Walter
Comment 19 Paul Thomas 2016-09-07 21:21:48 UTC
Author: pault
Date: Wed Sep  7 21:21:16 2016
New Revision: 240032

URL: https://gcc.gnu.org/viewcvs?rev=240032&root=gcc&view=rev
Log:
2016-09-07  Dominique Dhumieres  <dominiq@lps.ens.fr>

	PR fortran/48298
	* gfortran.dg/assumed_rank_12.f90: Correct tree scan.
	* gfortran.dg/assumed_type_2.f90: Correct tree scans.
	* gfortran.dg/coarray_lib_comm_1.f90: Likewise.
	* gfortran.dg/coarray_lib_this_image_2.f90: Likewise.
	* gfortran.dg/coarray_lock_7.f90: Likewise.
	* gfortran.dg/coarray_stat_function.f90: Likewise.
	* gfortran.dg/no_arg_check_2.f90: Likewise.
	* gfortran.dg/pr32921.f: Likewise.

Modified:
    branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev
    branches/fortran-dev/gcc/testsuite/gfortran.dg/assumed_rank_12.f90
    branches/fortran-dev/gcc/testsuite/gfortran.dg/assumed_type_2.f90
    branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
    branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_lib_this_image_2.f90
    branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_lock_7.f90
    branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_stat_function.f90
    branches/fortran-dev/gcc/testsuite/gfortran.dg/no_arg_check_2.f90
    branches/fortran-dev/gcc/testsuite/gfortran.dg/pr32921.f
Comment 20 Paul Thomas 2016-09-11 11:08:20 UTC
(In reply to Paul Thomas from comment #19)
> Author: pault
> Date: Wed Sep  7 21:21:16 2016
> New Revision: 240032
> 
> URL: https://gcc.gnu.org/viewcvs?rev=240032&root=gcc&view=rev
> Log:
> 2016-09-07  Dominique Dhumieres  <dominiq@lps.ens.fr>
> 
> 	PR fortran/48298
> 	* gfortran.dg/assumed_rank_12.f90: Correct tree scan.
> 	* gfortran.dg/assumed_type_2.f90: Correct tree scans.
> 	* gfortran.dg/coarray_lib_comm_1.f90: Likewise.
> 	* gfortran.dg/coarray_lib_this_image_2.f90: Likewise.
> 	* gfortran.dg/coarray_lock_7.f90: Likewise.
> 	* gfortran.dg/coarray_stat_function.f90: Likewise.
> 	* gfortran.dg/no_arg_check_2.f90: Likewise.
> 	* gfortran.dg/pr32921.f: Likewise.
> 
> Modified:
>     branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev
>     branches/fortran-dev/gcc/testsuite/gfortran.dg/assumed_rank_12.f90
>     branches/fortran-dev/gcc/testsuite/gfortran.dg/assumed_type_2.f90
>     branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
>    
> branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_lib_this_image_2.f90
>     branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_lock_7.f90
>     branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_stat_function.f90
>     branches/fortran-dev/gcc/testsuite/gfortran.dg/no_arg_check_2.f90
>     branches/fortran-dev/gcc/testsuite/gfortran.dg/pr32921.f

Sorry for the noise. I did a copy and paste for ChangeLog formatting and forgot to remove the PR number.

The above patch is concerned with fixing the fallout from merging fortran-dev and 7-branch. Fortran-dev is focussed on array descriptor reform.

Paul
Comment 21 Jerry DeLisle 2016-09-21 15:52:39 UTC
Created attachment 39669 [details]
Revised patch for review/testing

This revised patch speeds up execution on non DTIO internal units by saving and reusing the unit structure, avoiding memory allocations.  I am still testing. So far it passes regression tests.
Comment 22 Paul Thomas 2016-09-22 10:36:30 UTC
(In reply to Walter Spector from comment #18)
> Awesome!
> 
> I have noticed one bug so far.  The compiler is missing a check to see if
> the arguments in the I/O procedures have the 'optional' attribute.  It is
> allowing the attribute - even though it is illegal.  E.g. the following
> should be flagged as erroneous:
> 
>   SUBROUTINE pwf (dtv,unit,iotype,vlist,iostat,iomsg)
>     ! argument definitions
>     CLASS(person), INTENT(IN) :: dtv
>     INTEGER, INTENT(IN), OPTIONAL :: unit
>     CHARACTER (LEN=*), INTENT(IN), OPTIONAL :: iotype
>     INTEGER, INTENT(IN), OPTIONAL :: vlist(:)
>     INTEGER, INTENT(OUT), OPTIONAL :: iostat
>     CHARACTER (LEN=*), INTENT(INOUT), OPTIONAL :: iomsg
>     ...
> 
> Walter

Hi Walter,

I missed this comment - apologies. I will deal with it asap.

Cheers

Paul
Comment 23 Paul Thomas 2016-09-22 11:27:31 UTC
Author: pault
Date: Thu Sep 22 11:26:59 2016
New Revision: 240349

URL: https://gcc.gnu.org/viewcvs?rev=240349&root=gcc&view=rev
Log:
2016-09-22  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/48298
	* gfortran.h : Place the pseudo operators INTRINSIC_FORMATTED
	and INTRINSIC_UNFORMATTED after the sentinel in enum
	gfc_intrinsic_op so that they do not appear as place holders
	in module_write.
	* interface.c (dtio_op): Comment on the special nature of the
	pseudo operators INTRINSIC FORMATTED and INTRINSIC_UNFORMATTED.

Modified:
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/interface.c
Comment 24 Jerry DeLisle 2016-09-23 20:36:53 UTC
Author: jvdelisle
Date: Fri Sep 23 20:36:21 2016
New Revision: 240456

URL: https://gcc.gnu.org/viewcvs?rev=240456&root=gcc&view=rev
Log:
2016-09-23  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libgfortran/48298
	* io/inquire.c (inquire_via_unit): Adjust error check for the
	two possible internal unit KINDs.
	* io/io.h: Adjust defines for is_internal_unit and
	is_char4_unit. (gfc_unit): Add internal unit data to structure.
	(get_internal_unit): Change declaration to set_internal_unit.
	(free_internal_unit): Change name to stash_internal_unit_number.
	(get_unique_unit_number): Adjust parameter argument.
	Define IOPARM_DT_HAS_UDTIO. (gfc_saved_unit): New structure.
	* io/list_read.c (next_char_internal): Use is_char4_unit.
	* io/open.c (st_open): Adjust call to get_unique_unit_number.
	* io/transfer.c (write_block): Use is_char4_unit.
	(data_transfer_init): Update check for unit numbers.
	(st_read_done): Free the various allocated memories used for the
	internal units and stash the negative unit number and pointer to unit
	structure to allow reuse. (st_write_done): Likewise stash the freed
	unit.
	* io/unit.c: Create a fixed size buffer of 16 gfc_saved_unit's to use
	as a stack to save newunit unit numbers and unit structure for reuse.
	(get_external_unit): Change name to get_gfc_unit to better
	reflect what it does. (find_unit): Change call to get_gfc_unit.
	(find_or_create_unit): Likewise. (get_internal_unit): Change
	name to set_internal_unit. Move internal unit from the dtp
	structure to the gfc_unit structure so that it can be passed to
	child I/O statements through the UNIT.
	(free_internal_unit): Change name to stash_internal_unit_number.
	Push the common.unit number onto the newunit stack, saving it
	for possible reuse later. (get_unit): Set the internal unit
	KIND. Use get_unique_unit_number to get a negative unit number
	for the internal unit. Use get_gfc_unit to get the unit structure
	and use set_internal_unit to initialize it.
	(init_units): Initialize the newunit stack.
	(get_unique_unit_number): Check the stack for an available unit
	number and use it. If none there get the next most negative
	number. (close_units): Free any unit structures pointed to from the save
	stack.

2016-09-23  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/48298
	* gfortran.h (gfc_dt): Add *udtio.
	* ioparm.def: Add bit IOPARM_dt_f2003 to align with library use of bit
	25. Add IOPARM_dt_dtio bit to common flags.
	* resolve.c (resolve_transfer): Set dt->udtio to expression.
	* io.c (gfc_match_inquire): Adjust error message for internal
	unit KIND.
	* libgfortran.h: Adjust defines for GFC_INTERNAL_UNIT4,
	GFC_INTERNAL_UNIT, and GFC_INVALID_UNIT.
	* trans-io.c (build_dt): Set common_unit to reflect the KIND of
	the internal unit. Set mask bit for presence of dt->udtio.

2016-09-23  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/48298
	* gfortran.dg/negative_unit_check.f90: Update test.
	* gfortran.dg/dtio_14.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/dtio_14.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/io.c
    trunk/gcc/fortran/ioparm.def
    trunk/gcc/fortran/libgfortran.h
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-io.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/negative_unit_check.f90
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/inquire.c
    trunk/libgfortran/io/io.h
    trunk/libgfortran/io/list_read.c
    trunk/libgfortran/io/open.c
    trunk/libgfortran/io/transfer.c
    trunk/libgfortran/io/unit.c
Comment 25 Paul Thomas 2016-09-26 11:15:55 UTC
Author: pault
Date: Mon Sep 26 11:15:23 2016
New Revision: 240493

URL: https://gcc.gnu.org/viewcvs?rev=240493&root=gcc&view=rev
Log:
2016-09-26  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/48298
	* interface.c (gfc_find_specific_dtio_proc) : Return NULL if
	the derived type is broken, as indicated by a flavor other than
	FL_DERIVED.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/interface.c
Comment 26 Jerry DeLisle 2016-10-16 16:30:18 UTC
Author: jvdelisle
Date: Sun Oct 16 16:29:46 2016
New Revision: 241216

URL: https://gcc.gnu.org/viewcvs?rev=241216&root=gcc&view=rev
Log:
2016-10-16  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/48298
	* trans-io.c (transfer_expr): Ignore dtio procedures for inquire
	with iolength.

	* gfortran.dg/dtio_16.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/dtio_16.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-io.c
    trunk/gcc/testsuite/ChangeLog
Comment 27 Jerry DeLisle 2016-10-16 16:44:21 UTC
The patch in comment 26 addressed the behavior of inquire(iolength= ) when derived types with User Defined procedures are in the Output List.

The only other case I see not addressed yet is the size= specifier in input statements. I do not see where the Standards specifically address this for User Defined. Should it behave similar to IOLENGTH or try to accumulate the size from all child procedures?
Comment 28 Jerry DeLisle 2016-10-18 04:14:59 UTC
Author: jvdelisle
Date: Tue Oct 18 04:14:25 2016
New Revision: 241294

URL: https://gcc.gnu.org/viewcvs?rev=241294&root=gcc&view=rev
Log:
2016-10-17  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/48298
	* io/io.h: Move size_used from dtp to unit structure. Add bool
	has_size to unit structure.
	* read.c (read_x): Use has_size and size_used.
	* transfer.c (read_sf_internal,read_sf,read_block_form,
	read_block_form4): Likewise.
	(data_transfer_init): If parent, initialize the size variables.
	(finalize_transfer): Set the size variable using size_used in
	gfc_unit. (write_block): Delete bogus/dead code.

	* gfortran.dg/dtio_17.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/dtio_17.f90
Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/io.h
    trunk/libgfortran/io/read.c
    trunk/libgfortran/io/transfer.c
Comment 29 Jerry DeLisle 2016-10-27 01:40:52 UTC
Closing, thanks to all who contributed.