Bug 48298 - [F03] User-Defined Derived-Type IO (DTIO)
Summary: [F03] User-Defined Derived-Type IO (DTIO)
Status: NEW
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-07-28 17:16 UTC (History)
5 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

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