[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

Jerry DeLisle  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #29 from Jerry DeLisle  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #28)

> It would be nice to backport the patch to the gcc-7 branch after some
> soak time on mainline.
> 
> Thanks.
>   Rainer

After confirming it also fixed the issue on a free-BSD system and regression
testing on gcc-7, this was backported.

Now closing.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #27 from Jerry DeLisle  ---
> (In reply to Rainer Orth from comment #15)
>> The new testcase FAILs on 64-bit Solaris/SPARC:
>> 
>> +FAIL: gfortran.dg/dtio_26.f03   -O0  execution test
>
> See if fixed on trunk now after commit to fix 80767.

I've now completed sparc-sun-solaris2.12 (and i386-pc-solaris2.12 for
good measure) bootstraps: the 64-bit sparc failures are gone and no
regressions on either sparc or x86.

It would be nice to backport the patch to the gcc-7 branch after some
soak time on mainline.

Thanks.
Rainer

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #27 from Jerry DeLisle  ---
(In reply to Rainer Orth from comment #15)
> The new testcase FAILs on 64-bit Solaris/SPARC:
> 
> +FAIL: gfortran.dg/dtio_26.f03   -O0  execution test

See if fixed on trunk now after commit to fix 80767.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #26 from Jerry DeLisle  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #25)
--- snip ---
> 
> Btw., I happened to notice that this "int * length" (and many more
> instances throughout the file and probably all of libgfortran) is
> in violation of the GNU Coding Standard: this should be "int *length"
> instead.
> 
>   Rainer

I noticed those too. I will try to clean them up soon. Probably a separate
patch that does only this cleanup. Not sure where it propagated from and it
does not matter at this point, so will just fix it.

Regarding the other failure. Its hard to debug without a machine. Maye set up a
virtual machine? Is this Solaris OS available for to do this with?

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #24 from Jerry DeLisle  ---
[...]
> Can you try this patch. From what I read there can be issues with char pointer
> sizes between these architectures.
>
> diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
> index 1e56b5de..daa741b4 100644
> --- a/libgfortran/io/transfer.c
> +++ b/libgfortran/io/transfer.c
> @@ -272,7 +272,7 @@ read_sf_internal (st_parameter_dt *dtp, int * length)
>return NULL;
>  }
>
> -  if (base && *base == 0)
> +  if (base && *base == '\0')
>  {
>generate_error (>common, LIBERROR_EOR, NULL);
>return NULL;

Doesn't make any difference.

Btw., I happened to notice that this "int * length" (and many more
instances throughout the file and probably all of libgfortran) is
in violation of the GNU Coding Standard: this should be "int *length"
instead.

Rainer

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #24 from Jerry DeLisle  ---
(In reply to Christophe Lyon from comment #23)
> (In reply to Jiong Wang from comment #22)
> > (In reply to Rainer Orth from comment #15)
> > > The new testcase FAILs on 64-bit Solaris/SPARC:
> > 
> > + AArch64
> > 
> 
> For me, the tests pass on aarch64 (using qemu), but as I reported in
> https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01370.html
> the tests fails for arm*linux-gnueabihf and pass for arm*linux-gnueabi
> (using qemu too)

Can you try this patch. From what I read there can be issues with char pointer
sizes between these architectures.

diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 1e56b5de..daa741b4 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -272,7 +272,7 @@ read_sf_internal (st_parameter_dt *dtp, int * length)
   return NULL;
 }

-  if (base && *base == 0)
+  if (base && *base == '\0')
 {
   generate_error (>common, LIBERROR_EOR, NULL);
   return NULL;

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #23 from Christophe Lyon  ---
(In reply to Jiong Wang from comment #22)
> (In reply to Rainer Orth from comment #15)
> > The new testcase FAILs on 64-bit Solaris/SPARC:
> 
> + AArch64
> 

For me, the tests pass on aarch64 (using qemu), but as I reported in
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01370.html
the tests fails for arm*linux-gnueabihf and pass for arm*linux-gnueabi (using
qemu too)

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jiwang at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

Jiong Wang  changed:

   What|Removed |Added

 CC||jiwang at gcc dot gnu.org

--- Comment #22 from Jiong Wang  ---
(In reply to Rainer Orth from comment #15)
> The new testcase FAILs on 64-bit Solaris/SPARC:

+ AArch64


> 
> +FAIL: gfortran.dg/dtio_26.f03   -O0  execution test
> +FAIL: gfortran.dg/dtio_26.f03   -O1  execution test
> +FAIL: gfortran.dg/dtio_26.f03   -O2  execution test
> +FAIL: gfortran.dg/dtio_26.f03   -O3 -fomit-frame-pointer -funroll-loops
> -fpeel-loops -ftracer -finline-functions  execution test
> +FAIL: gfortran.dg/dtio_26.f03   -O3 -g  execution test
> +FAIL: gfortran.dg/dtio_26.f03   -Os  execution test
> 
> Thread 2 received signal SIGABRT, Aborted.
> [Switching to Thread 1 (LWP 1)]
> 0x7f0e6920 in __lwp_sigqueue () from /lib/64/libc.so.1
> (gdb) where
> #0  0x7f0e6920 in __lwp_sigqueue () from /lib/64/libc.so.1
> #1  0x7f02949c in raise () from /lib/64/libc.so.1
> #2  0x7eff8174 in abort () from /lib/64/libc.so.1
> #3  0x2d039dc4 in _gfortrani_sys_abort ()
> at /vol/gcc/src/hg/trunk/local/libgfortran/runtime/error.c:180
> #4  0x2d11840c in _gfortran_abort ()
> at /vol/gcc/src/hg/trunk/local/libgfortran/intrinsics/abort.c:32
> #5  0x0001236c in p ()
> at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/dtio_26.f03:64
> #6  0x000124d8 in main (argc=1, argv=0x784c)
> at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/dtio_26.f03:46
> #7  0x000114ac in _start ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> #5  0x0001236c in p ()
> at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/dtio_26.f03:64
> 64if (imsg.ne."End of record") call abort
> (gdb) p imsg
> $1 = ' ' 
> 
>   Rainer

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #20 from Jerry DeLisle  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #19)
>
>> [...]
>> 
>> Here's the output I get:
>> 
>>   63
>> 
>>   65
>> 
>>  Rainer
>
> So its internal units, aka a string. and its not detecting the EOR.  I will
> have to think on this a bit and get back a little later. If you are OK , I 
> will
> go off list with you to spare everyone the back and forth on here.

Sure, fine with me.

Thanks.
Rainer

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #20 from Jerry DeLisle  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #19)

> [...]
> 
> Here's the output I get:
> 
>   63
> 
>   65
> 
>   Rainer

So its internal units, aka a string. and its not detecting the EOR.  I will
have to think on this a bit and get back a little later. If you are OK , I will
go off list with you to spare everyone the back and forth on here.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #18 from Jerry DeLisle  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #17)
>> 
>> ro@colima 27 >
>> LD_LIBRARY_PATH=../../../sparc-sun-solaris2.12/sparcv9/libgfortran/.libs
>> ./dtio_26.exe 
>> 
>> 
>> 
>> Program aborted. Backtrace:
>> Abort
>
> I am sorry, I was not being clear. There are four similar lines that need to
> replace abort with the print. We are invoking the Fortran ABORT procedure when
> ever a test condition is not met. So I need to see what the condition is saved
> in the iomsg variable and which line without aborting.

Ah, I see.

> So something like this in place of the lines starting at line 57:
[...]

Here's the output I get:

  63
  65
Rainer

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #18 from Jerry DeLisle  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #17)
> 
> ro@colima 27 >
> LD_LIBRARY_PATH=../../../sparc-sun-solaris2.12/sparcv9/libgfortran/.libs
> ./dtio_26.exe 
> 
> 
> 
> Program aborted. Backtrace:
> Abort

I am sorry, I was not being clear. There are four similar lines that need to
replace abort with the print. We are invoking the Fortran ABORT procedure when
ever a test condition is not met. So I need to see what the condition is saved
in the iomsg variable and which line without aborting.

So something like this in place of the lines starting at line 57:

  read(unit=10, fmt='(dt)', iostat=istat, iomsg=imsg) foo
  if (imsg.ne."End of record") print *, 57, imsg
  rewind(10)
  read(unit=10, fmt=*, iostat=istat, iomsg=imsg) foo
  if (imsg.ne."End of record") print *, 60, imsg
  s = "hello"
  read( unit=s, fmt='(dt)', iostat=istat, iomsg=imsg) foo
  if (imsg.ne."End of record") print *, 63, imsg
  read( unit=s, fmt=*, iostat=istat, iomsg=imsg) foo
  if (imsg.ne."End of record") print *, 65
end program p

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #16 from Jerry DeLisle  ---
> (In reply to Rainer Orth from comment #15)
>
> Can you change line:
>
> if (imsg.ne."End of record") call abort
>
> to:
>
> if (imsg.ne."End of record") print *, imsg
>
> and lets see what its saying.

Sure.  I see

ro@colima 27 >
LD_LIBRARY_PATH=../../../sparc-sun-solaris2.12/sparcv9/libgfortran/.libs
./dtio_26.exe 


Program aborted. Backtrace:
Abort

matching the 256 x ' ' printed by gdb.

Rainer

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

Jerry DeLisle  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #16 from Jerry DeLisle  ---
(In reply to Rainer Orth from comment #15)

Can you change line:

if (imsg.ne."End of record") call abort

to:

if (imsg.ne."End of record") print *, imsg

and lets see what its saying.

My guess is I may need to initialize something before calling the child I/O
procedure.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #15 from Rainer Orth  ---
The new testcase FAILs on 64-bit Solaris/SPARC:

+FAIL: gfortran.dg/dtio_26.f03   -O0  execution test
+FAIL: gfortran.dg/dtio_26.f03   -O1  execution test
+FAIL: gfortran.dg/dtio_26.f03   -O2  execution test
+FAIL: gfortran.dg/dtio_26.f03   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gfortran.dg/dtio_26.f03   -O3 -g  execution test
+FAIL: gfortran.dg/dtio_26.f03   -Os  execution test

Thread 2 received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0x7f0e6920 in __lwp_sigqueue () from /lib/64/libc.so.1
(gdb) where
#0  0x7f0e6920 in __lwp_sigqueue () from /lib/64/libc.so.1
#1  0x7f02949c in raise () from /lib/64/libc.so.1
#2  0x7eff8174 in abort () from /lib/64/libc.so.1
#3  0x2d039dc4 in _gfortrani_sys_abort ()
at /vol/gcc/src/hg/trunk/local/libgfortran/runtime/error.c:180
#4  0x2d11840c in _gfortran_abort ()
at /vol/gcc/src/hg/trunk/local/libgfortran/intrinsics/abort.c:32
#5  0x0001236c in p ()
at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/dtio_26.f03:64
#6  0x000124d8 in main (argc=1, argv=0x784c)
at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/dtio_26.f03:46
#7  0x000114ac in _start ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

#5  0x0001236c in p ()
at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/dtio_26.f03:64
64if (imsg.ne."End of record") call abort
(gdb) p imsg
$1 = ' ' 

  Rainer

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Jerry DeLisle  ---
Fixed on trunk, closing.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #13 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Mar 25 18:48:01 2017
New Revision: 246478

URL: https://gcc.gnu.org/viewcvs?rev=246478=gcc=rev
Log:
2017-03-25  Jerry DeLisle  

PR libgfortran/78881
* io/io.h (st_parameter_dt): Rename unused component last_char to
child_saved_iostat. Move comment to gfc_unit.
* io/list_read.c (list_formatted_read_scalar): After call to
child READ procedure, save the returned iostat value for later
check. (finish_list_read): Only finish READ if child_saved_iostat
was OK.
* io/transfer.c (read_sf_internal): If there is a saved character
in last character, seek back one. Add a new check for EOR
condition. (read_sf): If there is a saved character
in last character, seek back one. (formatted_transfer_scalar_read):
Initialize last character before invoking child procedure.
(data_transfer_init): If child dtio, set advance
status to nonadvancing. Move update of size and check for EOR
condition to before child dtio return.

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

Added:
trunk/gcc/testsuite/gfortran.dg/dtio_26.f03
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/list_read.c
trunk/libgfortran/io/transfer.c

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #12 from Jerry DeLisle  ---
Another issue:

In the case with file I/O if the child procedure consumes the EOR character,
upon return, the parent is also wanting to complete the EOR the check for EOR
and hits EOF.

Lets see what I get from c.l.f

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #11 from Jerry DeLisle  ---
I finally figured out what is happening. 

The parent READ begins with eating any leading spaces. If a non-space character
is found, rather than seek backward (which can't be done with some units) we
unget the character and save it in the dtp structure.

The dtp structure is not passed to the child procedure, only the unit structure
is passed. This means the first READ in the child procedure does not know that
first character even exists.

To fix it I will move the saved character to the unit structure rather than the
dtp structure (or something similar) so that it is seen by the child procedure.

Since the parent is list directed and the child is formatted I/O this does
create some complications since in our library, we have different next_char()
functions for formatted and list directed.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #10 from Jerry DeLisle  ---
The test cases I have been working on uses:

   read( unit=s, fmt='(dt)', iostat=istat, iomsg=imsg, pad='yes' ) foo

versus:

   read( unit=s, fmt=*, iostat=istat, iomsg=imsg, pad='yes' ) foo

With fmt=*, the first character is still getting eaten and I think is related
to parent. Needless to say, this PR has uncovered multiple issues so is taking
me a lot of time.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #9 from Jerry DeLisle  ---
Created attachment 41014
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41014=edit
Preliminay Patch

Here is a preliminary patch. I have spent a lot of time looking at the DTIO
problem case as well as a non DTIO version. I am still encountering differences
in behavior depending on the advance= and the pad= status used.  I am not
satisfied with the results yet, but this patch is better than before.  I
suspect we have uncovered some latent issues. I will attach a test case with he
current problem area, which is not hitting an EOF with advance=yes and pad=yes
with file I/O

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

Jerry DeLisle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #8 from Jerry DeLisle  ---
We have the exact issue with external units, so not specific to strings.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #7 from Jerry DeLisle  ---
This is interesting.

If I use:

read( unit=s, fmt='(DT)', iostat=istat, iomsg=imsg ) foo

then we do not lose the first character. However, the loop in the dtio
procedure does not exit.

So I inserted in the loop: if (i.gt.10) exit loop_read

resulting in:

$ ./a.out 
loop i:  1
i = 1, c = H
loop i:  2
i = 2, c = e
loop i:  3
i = 3, c = l
loop i:  4
i = 4, c = l
loop i:  5
i = 5, c = o
loop i:  6
i = 6, c =  
loop i:  7
i = 7, c =  
loop i:  8
i = 8, c =  
loop i:  9
i = 9, c =  
loop i: 10
i = 10, c =  
loop i: 11
i = 11, c =  

(I am printing the loop variable before the read)

Regardless in this case we are not losing the first character. I am speculating
that the parent procedure is starting the read based on the format specifier
and eating the first character.  As I said, this is interesting.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #6 from Jerry DeLisle  ---
(In reply to Paul Thomas from comment #5)
> (In reply to Jerry DeLisle from comment #3)
> > (In reply to janus from comment #2)
> > > (In reply to janus from comment #0)
> > > > It seems like the first character is being swallowed somewhere ...
> > > 
> > > Moreover the EOF is supposed to be an EOR?
> > 
> > I will start looking at this. I wonder off hand if we have an EOF because we
> > start reading one position off. I will see what I can figure out.
> 
> Hi Jerry,
> 
> I was just reviewing all the outstanding DTIO PRs. Did you get anywhere with
> this one?
> 
> Cheers
> 
> Paul

I have been digging around and found one place where we were not passing the
correct unit number to the child procedure. 

$ git diff libgfortran/io/unit.c
diff --git a/libgfortran/io/unit.c b/libgfortran/io/unit.c
index ed3bc323..9535b004 100644
--- a/libgfortran/io/unit.c
+++ b/libgfortran/io/unit.c
@@ -461,6 +461,7 @@ set_internal_unit (st_parameter_dt *dtp, gfc_unit *iunit,
int kind)
 {
   gfc_offset start_record = 0;

+  iunit->unit_number = dtp->common.unit;
   iunit->recl = dtp->internal_unit_len;
   iunit->internal_unit = dtp->internal_unit;
   iunit->internal_unit_len = dtp->internal_unit_len;

This fixes part of the problem. I have not nailed down why we fail to write out
the value in the child procedure once we have the internal unit number. Likely
we are exiting the write machinery too soon.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas  ---
(In reply to Jerry DeLisle from comment #3)
> (In reply to janus from comment #2)
> > (In reply to janus from comment #0)
> > > It seems like the first character is being swallowed somewhere ...
> > 
> > Moreover the EOF is supposed to be an EOR?
> 
> I will start looking at this. I wonder off hand if we have an EOF because we
> start reading one position off. I will see what I can figure out.

Hi Jerry,

I was just reviewing all the outstanding DTIO PRs. Did you get anywhere with
this one?

Cheers

Paul

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-25
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #3 from Jerry DeLisle  ---
(In reply to janus from comment #2)
> (In reply to janus from comment #0)
> > It seems like the first character is being swallowed somewhere ...
> 
> Moreover the EOF is supposed to be an EOR?

I will start looking at this. I wonder off hand if we have an EOF because we
start reading one position off. I will see what I can figure out.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #0)
> It seems like the first character is being swallowed somewhere ...

Moreover the EOF is supposed to be an EOR?

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #1 from janus at gcc dot gnu.org ---
It seems that this problem not only appears when reading from internal units,
but also from std input:



module t_m
   implicit none

   type, public :: t
  character(len=:), allocatable :: m_s
   contains
  procedure, pass(this) :: read_t
  generic :: read(formatted) => read_t
   end type

contains

subroutine read_t(this, lun, iotype, vlist, istat, imsg)
  ! argument definitions
  class(t), intent(inout) :: this
  integer, intent(in) :: lun
  character(len=*), intent(in):: iotype
  integer, intent(in) :: vlist(:)
  integer, intent(out):: istat
  character(len=*), intent(inout) :: imsg
  ! local variables
  character :: c
  integer :: i

  do i=1,5
 read( unit=lun, fmt="(a1)", iostat=istat, iomsg=imsg ) c
 select case ( istat )
case ( 0 )
   write( *, *) "i = ", i, ", c = ", c
case default
   write( *, *) "i = ", i, ", istat = ", istat, imsg
   return
 end select
  end do

   end subroutine

end module


program p
   use t_m
   implicit none

!character(len=5) :: s = "Hello"
   type(t) :: foo

   read( unit=*, fmt=*) foo
end