[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 DeLislePR 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
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
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
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
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
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
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
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
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
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
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
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
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