--- Comment #4 from dtprice at shaw dot ca 2009-07-03 14:54 ---
Sorry. In the middle of uploading the attachment I had a power cut! To respond
to your queries: Program and input file are now uploaded.
Yes it was compiled with
gfortran -Wall testfile.f
and no further options. I have found it necessary to use -static on some
installations but all of these compiles run fine.
gfortran -v produces:
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.2
--enable-version-specific-runtime-libs --without-system-libunwind
--with-cpu=generic --host=i586-suse-linux
Thread model: posix
gcc version 4.2.1 (SUSE Linux)
mika:/~%lo
Connection to mika.nofc.cfs.nrcan.gc.ca closed.
locatelli:/~/ibis/prog/source%gfortran -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64
--libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --program-suffix=-4.3
--enable-version-specific-runtime-libs --enable-linux-futex
--without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE
Linux)
I should not be mixing libraries... this is a brand new installation on a new
machine (bought two weeks ago!). The gcc-4.3 collection were installed as part
of the initial SuSE installation. I only tried building gcc-4.4 after this
problem manifested. My build of gcc-4.4 was installed into /usr/local/ and the
only test I did was to substitute the gfortran executable (using a temporary
symlink) to compile the test program.
Thanks
David
> > gfortran 4.3.1. Attached 15 line test program reproduces the effect
>
> Can you attach the program?
>
> I assume you compiled it with "gfortran -Wall testfile.f" and no further
> option
> such a -malign-double or similar?
>
> Can you also show the output of: gfortran -v?
>
> You are not by chance mixing the library of an older gfortran with a binary
> of
> a newer gfortran or vice versa?
>
> (Not a issue for your single-file test, but combining files compiled with
> 4.2.x
> with 4.3.x/4.4.x compiled files, might also cause problems. 4.3 and 4.4 should
> be compatible.)
>
>
> > stops at line 8 with the error message:
> > At line 8 of file testlun.f
> > Fortran runtime error: Unit number in I/O statement too large
>
> > I am guessing this is hardware-related. It is a new system--ASUS MB with
> > Intel Core I7 CPU. Identical code runs fine with same gfortran installed
> > on a system equipped with an earlier Intel chip.
>
> As GCC/gfortran is continuously tested one a wide range of systems (x86,
> x86-64, ia64, sparc, s930, ...), I think it is unlikely that it is a Core i7
> problem; I rather think that somehow the installation was messed up or some
> strange option was used. After we solved the problem, we will know ...
>
--
dtprice at shaw dot ca changed:
What|Removed |Added
GCC build triplet||version 4.3.1 20080507
||(prerelease) [gcc-4_3-branch
||revision 135
GCC target triplet||x86_64_sise-linux_
Keywords||diagnostic
Summary|RTE: "Unit number in I/O|RTE: "Unit number in I/O
|statement too large" -- |statement too large" --
|falls with any low value|fails with any low value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
