https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
Jerry DeLisle changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
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
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.
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
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
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:
> >
> > +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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
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
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
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 >
>>
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
>
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
Jerry DeLisle changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
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
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=*,
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
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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
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?
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 ::
29 matches
Mail list logo