Hello,
I face a very strange problem with my own (big) code when compiled with windows gfortran (no problem with old lahey compiler or linux gf):
when I read information in a binary file, everything is ok during the process but, afterwards, the code is unable to read correctly real data from the keyboard or from text files, the figures after coma being systematically ignored. If I type 0.3, it understands 0., if I type 3.1416, it understands 3. and so on. From the keyboard, I can “overcome” the problem by typing 31416E-4 (nice!), etc, but no medicine from text file.
Has anyone already experienced such curious behavior? Advices are welcome, thank-you.
Welcome to the forum!
Thje problem you sketch is something I have never encountered myself. It does not ring a single bell either. Can you experiment with taking out parts of the process of reading this binary file? Is there some point where the decimal point is recognised again? Could it be a setting in your program that changed the decimal separator from a point to a comma? An OPEN statement may contain the DECIMAL keyword to change the significance of a point and a comma,
Just a few random thoughts.
Hi,
I have encountered the exact same behavior.
W11, gcc 15.2 with mingw64 13.0.0
Reading and closing a formatted file is fine
Reading and closing an unformatted file is fine
After an unformatted file has been read (even for only one value) though, fractional parts of any future formatted reads are being dropped (eg : ‘31649.08’ will be read as ‘31649.00’)
(If the unformatted file is only opened, but immediately closed without reading any value, then the problem does not appear)
Adding DECIMAL=’POINT’ to the formatted OPEN statement and/or the READ statement does not solve the issue.
Specifying the format (eg (F15.8)) in the READ statement does not solve the issue.
If the content of the formatted file is written in exponential form, then there is no issue.
Additionally, the issue only manifests itself when executing directly on Windows. If the exact same executable is launched by gdb (on Windows), then the issue is not present.
Here is a minimum example to reproduce 
subroutine readtxt
t=0.0
open(newunit=kf,file=“toto.txt”,form=‘FORMATTED’,
& status=‘OLD’,action=‘READ’,iostat=IPB)
print*,‘IPB=’,IPB
if (IPB==0) then
read(kf,*) t
print*,‘t=’,t
endif
close(kf)
return
endsubroutine readbin
OPEN(newunit=io,FILE=“toto.bin”,ACCESS=‘STREAM’,
& FORM=‘UNFORMATTED’,STATUS=‘OLD’,IOSTAT=IPB)
read(io) x
close(io)
return
endprogram toto
call readtxt
call readtxt
call readbin
call readtxt
call readtxt
return
end
With toto.txt being a simple one line ASCII file with eg 123.456 written in it, and toto.bin any non-empty binary file.
The end result produces the following output on Windows :
PS D:\Work\toto> .\a.exe
IPB= 0
t= 123.456001
IPB= 0
t= 123.456001
IPB= 0
t= 123.000000
IPB= 0
t= 123.000000
I cannot reproduce the problem with gfortran 13;2 on Windows MSYS2
I tidied up the code, but did not reproduce your error for the text file.
I included routines to first write the files and a more consistent approach to using and reporting the iostat return from open.
I think your problem may be with the files you are opening.
Does your txt file have a end of line character as <CR><LF> ?
Why do you use RETURN in the main program ?
subroutine readtxt
t = 0.0
open ( newunit=kf, file='toto.txt', form='FORMATTED', &
status='OLD', action='READ', iostat=IPB)
if (IPB==0) read(kf,*) t
print*,'readtxt : t=',t,' ipb=',ipb
close(kf)
return
end
subroutine readbin
x = 0
OPEN (newunit=io, FILE='toto.bin', ACCESS='STREAM', &
FORM='UNFORMATTED', STATUS='OLD', IOSTAT=IPB )
if (IPB==0) read(io) x
print*,'readbin : x=',x,' ipb=',ipb
close(io)
return
end
program toto
call writetxt
call writebin
do k = 1,3
call readtxt
call readtxt
call readbin
call readtxt
call readtxt
end do
return ! why this ?
end
subroutine writetxt
t = 0
open ( newunit=kf, file='toto.txt', form='FORMATTED', &
status='UNKNOWN', iostat=IPB)
if (IPB==0) then
t = 123.456
write(kf,*) t
end if
print*,'writetxt : t=',t,' ipb=',ipb
close (kf)
return
end subroutine writetxt
subroutine writebin
x = 0
OPEN (newunit=io, FILE='toto.bin', ACCESS='STREAM', &
FORM='UNFORMATTED', STATUS='unknown', IOSTAT=IPB )
if (IPB==0) then
x = 234.567
write(io) x
end if
print*,'writebin : x=',x,' ipb=',ipb
close (io)
return
end
ps : including text in posts on this forum is becoming a bit of an art !
All right.
I did some additional tests.
At first, I came to think that there was as you suggested a link with the end of line characters, as it seemed I got different results depending on if the line in the .txt file ended with CR or CR+LF.
But then I tried it again, and the issue is not systematic !!!
Here are the results of 3 successive tests against the same .txt file (ending with CR LF) :
PS D:\Work\toto> .\a.exe
IPB= 0
t= 123.456001
IPB= 0
t= 123.456001
IPB= 0
t= 123.456001
IPB= 0
t= 123.456001
PS D:\Work\toto> .\a.exe
IPB= 0
t= 123.456001
IPB= 0
t= 123.456001
IPB= 0
t= 123.000000
IPB= 0
t= 123.000000
PS D:\Work\toto> .\a.exe
IPB= 0
t= 123.456001
IPB= 0
t= 123.456001
IPB= 0
t= 123.456001
IPB= 0
t= 123.456001
For some reason, the 2nd test did reproduce the issue, but not the other ones… !
If I just manually spam the test, it will generate both kind of results, with no obvious pattern (?)
Same behavior if the EOL is just LF. Both results will be generated by the test, with no apparent reason to determine which one each time.
See this topic if your problem is the new, all-integrated editor panel. Once you get the old setup (two panels), you can embed your includes with standard three-backticks ``` syntax.
I have made a bug report to GCC
1 Like
Thanks for reporting it @ParkerLewis, that’s the way to go.