[Bug fortran/92569] gfortran read with end directive does not trigger in gfortran 9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569 --- Comment #3 from Bill Lipa --- Thanks for looking at it. I studied it further and it seems that -O2 is the culprit. Could you please try to reproduce with -O2? $ gfortran -O2 res.f $ ./a.out At line 8 of file res.f (unit = 1, file = 'resultav4.dat') Fortran runtime error: Read past ENDFILE record Error termination. Backtrace: #0 0x10221ea14 #1 0x10221f2c2 #2 0x10221fbca #3 0x10234fe06 #4 0x102349a14 #5 0x10234b673 #6 0x10234bf75 #7 0x10234fa6c #8 0x10234fb69 #9 0x102202cb0 #10 0x102202dde $ gfortran res.f $ ./a.out # data records = 3
[Bug fortran/92569] gfortran read with end directive does not trigger in gfortran 9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569 --- Comment #1 from Bill Lipa --- $ gfortran --version GNU Fortran (MacPorts gcc9 9.2.0_1) 9.2.0
[Bug fortran/92569] New: gfortran read with end directive does not trigger in gfortran 9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569
Bug ID: 92569
Summary: gfortran read with end directive does not trigger in
gfortran 9.2
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: dojo at masterleep dot com
Target Milestone: ---
Created attachment 47294
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47294=edit
Zip of program and datafile
The attached program attempts to read 1000 lines from the input file which has
only 3 lines. The statement read (1,*,end=1)(tdat(j,k),k=1,10) is supposed to
transfer control to statement label 1 when the end of file condition is
reached, but instead, a runtime error occurs:
Fortran runtime error: Read past ENDFILE record
This program worked correctly with gfortran 6 and earlier.
If the statement is changed to include an err=1 directive as well, the program
works. But both end=1 and err=1 must appear. Either alone will not detect the
end of file. From my read of the standard, that should not be necessary.
This program is a small part of a large and ancient program with many similar
statements.
Program:
real*8 tdat(1000,10)
OPEN (UNIT=1,FILE='resultav4.dat',STATUS='OLD',IOSTAT=MM)
IF (MM.NE.0) WRITE (*,400) MM
400 FORMAT (' An error occured (',I4,') while opening input file')
do 2, j = 1,1000
read (1,*,end=1)(tdat(j,k),k=1,10)
c The following will work correctly:
c read (1,*,end=1,err=1)(tdat(j,k),k=1,10)
2 continue
1 np = j-1
write(*,*)'# data records =',np
close (1)
end
Datafile:
0. 2.1873 -2.0924 0.69736
-5.2962 0.45357 -5.4679 -12.0633326 -6.8736
-14.198 -10.475 -14.643 -13.844
3.6011E-02 2.28749990 -2.86975002 0.85345
-7.17249966 -0.869750023 -5.42749977 -10.646 -6.34250021
-13.4749994 -10.7349997 -16.933 -15.1625004
7.0979E-02 2.3654 -2.88180017 -0.337599933
-7.2174 -1.81980002 -5.8817 -10.832 -6.1434
-12.094 -12.5879993 -15.7040005 -15.4700012
[Bug fortran/38188] Inconsistent function results depending on irrelevant write statement
--- Comment #3 from dojo at masterleep dot com 2008-11-20 17:55 --- Oops, sorry for missing that. Thank you for the help. I was led astray because for mysterious reasons it always worked before... -- dojo at masterleep dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38188
[Bug fortran/38188] New: Inconsistent function results depending on irrelevant write statement
I am getting unreliable results from a small function using the latest prepackaged Mac OS build (PPC) available from the wiki download page. The function behaves correctly if an otherwise irrelevant write statement is added. When the statement is removed, the function returns gibberish. This is ancient code which worked on older versions of gfortran, so hopefully I haven't overlooked an obvious problem... $ uname -a Darwin Numenor 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep 3 11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386 i386 $ gfortran --version GNU Fortran (GCC) 4.4.0 20080823 (experimental) [trunk revision 139508] $ cat xx.f program xx real xa(102) do 10 i=1,100 10 xa(i)=float(i) call scale (xa,23.,100,1) write (*,*) xa(101), xa(102) end subroutine scale(arr,axlen,npts,kcycle) real :: arr(*),axlen,minval,maxval,val integer :: npts,kcycle minval = +INF maxval = -INF do i=0,npts-1 val=arr(1+kcycle*i) minval=amin1(val,minval) maxval=amax1(val,maxval) end do arr(npts*kcycle+1)=minval arr(npts*kcycle+kcycle+1)=(maxval-minval)/axlen c If the following line is uncommented, the function will work c write (*,*) 3 end subroutine scale # Correct function result (write statement is left in) $ gfortran -o xx xx.f $ xx 3 0.000 4.3478260 # Incorrect function result (write statement is commented out) $ gfortran -o xx xx.f $ xx -2.13906214E+09 1.86005408E+08 -- Summary: Inconsistent function results depending on irrelevant write statement Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dojo at masterleep dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38188
[Bug fortran/34957] duplicate libgcc_s.1.dylib warning on Mac OS X Leopard
--- Comment #4 from dojo at masterleep dot com 2008-01-25 22:30 --- $ ls -l /usr/local/gfortran/lib/libgcc_s* -rw-r--r-- 1 root admin 14 Dec 31 08:43 /usr/local/gfortran/lib/libgcc_s.1.dylib -rw-r--r-- 1 root admin 17288 Dec 31 08:43 /usr/local/gfortran/lib/libgcc_s.10.4.dylib -rw-r--r-- 1 root admin 17416 Dec 31 08:43 /usr/local/gfortran/lib/libgcc_s.10.5.dylib lrwxr-xr-x 1 root gsab 16 Jan 24 10:36 /usr/local/gfortran/lib/libgcc_s_ppc64.1.dylib - libgcc_s.1.dylib lrwxr-xr-x 1 root gsab 16 Jan 24 10:36 /usr/local/gfortran/lib/libgcc_s_x86_64.1.dylib - libgcc_s.1.dylib $ ls -l /libgcc_s* ls: /libgcc_s*: No such file or directory $ file a.out a.out: Mach-O executable i386 The group on the symbolic links seems odd - that's a different user account that doesn't do coding. I didn't make any manual changes to /usr/local/gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34957
[Bug fortran/34957] duplicate libgcc_s.1.dylib warning on Mac OS X Leopard
--- Comment #2 from dojo at masterleep dot com 2008-01-25 17:20 --- From the gcc wiki: http://gcc.gnu.org/wiki/GFortranBinaries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34957
[Bug fortran/34957] New: duplicate libgcc_s.1.dylib warning on Mac OS X Leopard
Under Mac OS X Leopard using the prepackaged gfortran binaries from 12/31/2007, any fortran program emits a duplicate dylib warning when linked. This is with the Leopard version of XCode (3.0). $ cat test2.f program test2 write (*,*) 'hello' end $ gfortran test2.f ld: warning, duplicate dylib /usr/local/gfortran/lib/libgcc_s.1.dylib $ a.out hello $ gfortran --version GNU Fortran (GCC) 4.3.0 20071231 (experimental) [trunk revision 131236] Copyright (C) 2007 Free Software Foundation, Inc. -- Summary: duplicate libgcc_s.1.dylib warning on Mac OS X Leopard Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dojo at masterleep dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34957
[Bug fortran/34719] New: N_GSYM stabs warning with common blocks on Mac OS X Leopard
Under Mac OS X Leopard using the prepackaged gfortran binaries from 12/31/2007, any fortran program with a common block emits a N_GSYM stabs warning when compiled in debug mode. This is with the Leopard version of XCode (3.0). $ cat test.f program test common nrange call firmssh(1) end subroutine firmssh(curmax) common nrange return end $ gfortran -g -c test.f $ gfortran test.o can't find atom for N_GSYM stabs nrange:G(0,5) in test.o can't find atom for N_GSYM stabs nrange:G(0,5) in test.o ld: warning, duplicate dylib /usr/local/gfortran/lib/libgcc_s.1.dylib $ gfortran --version GNU Fortran (GCC) 4.3.0 20071231 (experimental) [trunk revision 131236] Copyright (C) 2007 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ ld -v @(#)PROGRAM:ld PROJECT:ld64-77 -- Summary: N_GSYM stabs warning with common blocks on Mac OS X Leopard Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dojo at masterleep dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34719
