The following bug occurs only in the version of gfortran downloaded from ftp://ftp.equation.com/gcc/gcc-4.5-20090820-32.exe. When I compile and run the program listed below it prints: 1234567890 1234567890 end of file not detected On every other port of gfortran it prints: 1234567890 end of file detected PROGRAM read_character_string_bug CHARACTER(LEN=10) :: line_10 CHARACTER(LEN=11) :: line_11 line_10 = "1234567890" OPEN(10, FILE="test.txt", STATUS="UNKNOWN", FORM="FORMATTED") WRITE(10, 20) line_10 20 FORMAT(a) REWIND(10) DO i = 1, 2 READ(10, 20, END=99) line_11 PRINT *, line_11 ENDDO PRINT *, "end of file not detected" STOP 99 PRINT *, "end of file detected" END PROGRAM read_character_string_bug
Works for me on latest trunk. 4.5 $ ./a.out 1234567890 end of file detected Please post the output from gfortran -v and also the exact URL where you got the download. The binaries from the wiki are unofficial and provided for testing convenience. Regardless, we should see what is going on here.
oops, you got it from equation.com. Hmm, I don't know much how they create their distribution.Suggest you contact them and see what they think.
The output from typing "gfortran -v" is listed below. It is a cross-compilation, if that is significant. Built by Equation Solution <http://www.Equation.com>. Using built-in specs. Target: i386-pc-mingw32 Configured with: ../gcc-4.5-20090820-mingw/configure --host=i386-pc-mingw32 --build=x86_64-unknown-linux-gnu --target=i386-pc-mingw32 --prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.5-20090820 --with-gcc --with-gnu-ld --with-gnu-as --disable-shared --disable-nls --disable-tls --with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gmp --with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr --enable-languages=c,fortran,c++ --with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/4.5-20090820 --enable-libgomp --enable-threads=win32 --disable-win32-registry Thread model: win32 gcc version 4.5.0 20090820 (experimental) (GCC) I have not been able to build a mingw port from the source code. If anybody has a procedure for doing so, please contact me.
I can confirm I can reproduce this bug with an darwin-to-mingw cross-compiler, and running the executable under wine. I can also confirm that it's about the REWIND statement: if you have already run the test program once, you can recompile it without the WRITE and the REWIND, using the already existing testcase. Then, it passes OK. It's probably some bad counting of position on platforms with HAVE_CRLF. To investigate, it should be possible to build such a faulty linux compiler by forcing HAVE_CRLF to be true.
(In reply to comment #4) > It's probably some bad counting of position on platforms with HAVE_CRLF. To > investigate, it should be possible to build such a faulty linux compiler by > forcing HAVE_CRLF to be true. I tried to do this in the i686-pc-linux-gnu port of gfortran. In the file libgfortran/config.h.in I changed "#undef HAVE_CRLF" to "#define HAVE_CRLF". When I built gfortran, the change was propagated to libgfortran/config.h. But when I ran the test case it created a file with standard Linux carriage control.
I will add this to my list.
Is the problem described at http://gcc.gnu.org/ml/fortran/2009-09/msg00046.html the same or a different one? There, it is claimed to be a 4.5 regression.
(In reply to comment #7) > Is the problem described at http://gcc.gnu.org/ml/fortran/2009-09/msg00046.html > the same or a different one? > > There, it is claimed to be a 4.5 regression. > I verified the problem described in http://gcc.gnu.org/ml/fortran/2009-09/msg00046.html. I found that my bug does not occur under gfortran 4.4.
It is not clear whether we have two bugs or one here yet. I am investigating. One way to possibly reproduce this on linux machines is to define HAVE_CRLF in libgfortran/io/io.h. This way, all files affected by that define will be re-compiled. I am trying this and will report back if i can reproduce the problem. (I too have still been unable to build a mingw compiler. I tried an automatic script pointed out by Kai and Nightstrike and it failed. I never give up.) :) yet
I am able to reproduce this now, so I will begin to see if I can pinpoint the problem. Using: Index: io.h =================================================================== --- io.h (revision 151491) +++ io.h (working copy) @@ -30,7 +30,7 @@ /* IO library include. */ #include "libgfortran.h" - +#define HAVE_CRLF #include <setjmp.h> #include <gthr.h>
PR41328 was submitted which has a little bit easier test case to use while not requiring mingw environment. So, I am closing this bug as the duplicate even though it was reported here first. A patch has been submitted for approval. See: http://gcc.gnu.org/ml/fortran/2009-09/msg00062.html Thanks much for this bug report. The test case was very useful. In fact, I was onto the problem before the other PR was reported. *** This bug has been marked as a duplicate of 41328 ***