* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
@ 2007-06-18 14:49 ` dir at lanl dot gov
2007-06-18 14:52 ` dominiq at lps dot ens dot fr
` (30 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dir at lanl dot gov @ 2007-06-18 14:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from dir at lanl dot gov 2007-06-18 14:48 -------
Here are the mingw32 results -
$ gfortran -g -o g95Test01 g95Test01.f
rantad@XP-RANTAD ~/tests
$ g95Test01
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.1600E+02
row 2 0.9000E+01 0.2000E+02
row 3 0.1100E+02 0.1200E+02 0.2600E+02
rantad@XP-RANTAD ~/tests
$ gfortran -O3 -o g95Test01 g95Test01.f
rantad@XP-RANTAD ~/tests
$ g95Test01
1
lower triangular matrix with 3 rows
row 1 0.0000E+00
row 2 0.1000E+01 0.2000E+01
row 3 0.3000E+01 0.4000E+01 0.5000E+01
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.0000E+00
row 2 0.1000E+01 0.4000E+01
row 3 0.3000E+01 0.4000E+01 0.1000E+02
rantad@XP-RANTAD ~/tests
$ cat g95Test01.f
*deck vr2
subroutine vr2 ( intp, ivg, ccrans, cc, ns, stdb, stdm, t,
$ k2, nlin, istab )
save
c+---------------------------------------------------------------------+
c| master foutine for |
c| second variation of the strain energy |
c| at an integration point |
c| |
c| output quantities |
c| t local accumulator for elt second variation|
c| w global accumulator for elt second variatio|
c+---------------------------------------------------------------------+
c+---------------------------------------------------------------------+
c| t y p e & d i m e n s i o n |
c+---------------------------------------------------------------------+
character its1*4
character title*72
integer t
real cc, ctrans, dprod2, sdb, sdm,
$ stdb, stdm, sum, ttt, uf,
$ vf, wsf
real tgc
dimension cc(1), ccrans(1),ivg(1), stdb(1), stdm(1),
$ t(100)
c+---------------------------------------------------------------------+
c| e q u i v a l e n c e s |
c+---------------------------------------------------------------------+
equivalence (jt,tt)
c+---------------------------------------------------------------------+
c| c o m m o n & g l o b a l s |
c+---------------------------------------------------------------------+
common/comvd1/ jelt, jntp
common/comvd2/ plva, plvb, lpr, iulpr, wplv(8)
common/comvd3/ wsf(12,9),uf(20), vf(20)
common/con5 / dmy(3), icom(18)
common/corot1/ iadcor(30), lcor, kcor
common/corot8/ ctrans(150)
common/fmloc / jf(6), js(6), jp(6), l1, l2,
$ l3, l4, l5, l6
common/forms / mtrans(40), itrans(150), sdb(540),
$ sdm(1008),npform
common/hybcom/ ihyb, ihres(9), ttt(78)
common/nitnot/ nit, not
common/prec / iprec
common/scrat1/ w(600)
common/test / ktest
common/titcom/ title
common/vr410c/ tgc(3,3,4)
common/vrdat / np, np1, np2, np3, np4,
$ np5, np6, np7, np8, np9,
$ np10
common/vrdat1/ nmsh, ntyp, nods, neta, nitp,
$ nst, ntr, nmp, nth, nvg,
$ nvl, nvb, nvm, nvr2, idvr,
$ ifab
common a(100)
c+---------------------------------------------------------------------+
c| d a t a |
c+---------------------------------------------------------------------+
data its1 / 'dbug' /
c+---------------------------------------------------------------------+
c| l o g i c |
c+---------------------------------------------------------------------+
ielt=jelt
npr=iprec
npd=3-npr
nvr2 = 1
if(intp.gt.1) go to 20
c+---------------------------------------------------------------------+
c| begin new element |
c+---------------------------------------------------------------------+
nj=nvg+5
nn=nvg+4+(nvg*nvg+nvg)/npd
nnl=nvg+4+(nvl*nvl+nvl)/npd
t(1)=nvg
t(4)=1
call mover (ivg,1,t(5),1,nvg)
if(k2.eq.0.or.nvr2.gt.0) go to 5
if(istab.eq.1.or.nlin.eq.1) go to 5
return
5 continue
c+---------------------------------------------------------------------+
c| clear t for element stiffness matrix |
c+---------------------------------------------------------------------+
call mover (0.,0,t,1,nnl)
t(1)=nvg
t(4)=1
call mover (ivg,1,t(5),1,nvg)
c
nl1 = nvl
if(lpr+iulpr.gt.0) nl1=nvl
20 continue
if(istab.eq.1.or.nlin.eq.1) go to 25
if(k2.eq.0.or.nvr2.gt.0) go to 25
return
25 continue
c+---------------------------------------------------------------------+
c| skip second variation if cc matrix = 0 |
c+---------------------------------------------------------------------+
call scprod (ns*ns,1,1,cc,cc,sum)
if (sum.le.0.)go to 180
c+---------------------------------------------------------------------+
c| choose appropriate computational routine |
c| |
c| one-dimensional continuum element (beam/stiffener) |
c+---------------------------------------------------------------------+
if (idvr.eq.1) call vr21d (cc,ns,stdb,nlin,istab,t)
c+---------------------------------------------------------------------+
c| two-dimensional continuum element (plate/shell) |
c+---------------------------------------------------------------------+
if (idvr.eq.2) call vr22d (cc,ns,stdb,stdm,nlin,istab,t,t(nj))
c+---------------------------------------------------------------------+
c| three-dimensional continnum element (solid) |
c+---------------------------------------------------------------------+
if (idvr.eq.3) call vr23d (cc,ns,stdm,nlin,istab,t)
if(intp.lt.nitp) return
ll=l1+np6+7
if (ntyp.eq.411) ll=ll+iprec*144
if(ntyp.eq.411) call penal(a(ll),istab,t(nj))
if (title(1:4).ne.its1 .or. ielt.gt.4) go to 180
write (6,905) ielt,intp
if (ntyp.lt.410 .or. ntyp.gt.411) go to 170
write (6,906)
906 format (/40h bending penalty constraint conditions )
do 160 i=1,4
call scopu (12,a(ll),w)
ll=ll+iprec*12
160 write (not,908) i, (w(j),j=1,12)
908 format (/i5,4x,6e12.4/9x,6e12.4)
170 continue
905 format (//30x,26h stiffness matrix for elt ,i3,7h intp ,i3)
call prmx (t(nj),nvl)
180 jj=nj
if (ntyp.ne.410 .and. ntyp.ne.415) go to 190
c+---------------------------------------------------------------------+
c| special procedures for 410,415 |
c+---------------------------------------------------------------------+
call mid2 (4,tgc,t(nj),t(nj))
if (title(1:4).eq.its1 .and. ielt.le.4) call prmx(t(nj),nvg)
return
190 continue
do 200 i=1,nvl
j2=jj+iprec*(i-1)
c+---------------------------------------------------------------------+
c| divide main diagonals by 2 before collecting |
c+---------------------------------------------------------------------+
jt=t(j2)
tt=.5*tt
t(j2)=jt
200 jj=jj+iprec*i
210 call scopu (nnl,t,w)
nj1=nn-nj+1
call mover (0.,0,t(nj),1,nj1)
call clect2 (t(nj),w(nj),nvg,nl1,mtrans,ctrans,itrans)
call prmx(t(nj),nvg)
jj=nj
do 242 i=1,nvg
j2=jj+iprec*(i-1)
c+---------------------------------------------------------------------+
c| multiply main diagonals by 2 |
c+---------------------------------------------------------------------+
jt=t(j2)
tt=tt+tt
t(j2)=jt
242 jj=jj+iprec*i
write(*,*)' iprec =',iprec
call prmx(t(nj),nvg)
return
end
program main
common/nitnot/ nit, not
common/vrdat1/ nmsh, ntyp, nods, neta, nitp,
$ nst, ntr, nmp, nth, nvg,
$ nvl, nvb, nvm, nvr2, idvr,
$ ifab
common/prec / iprec
dimension t(20)
do 10 i=1,20
t(i)=i
10 continue
not=6
nvg=3
iprec = 1
call vr2 ( intp, ivg, ccrans, cc, ns, stdb, stdm, t,
$ k2, nlin, istab )
stop
end
subroutine clect2
return
end
subroutine mid2
return
end
subroutine mover
return
end
subroutine penal
return
end
subroutine prmx (a,n)
save
c+---------------------------------------------------------------------+
c| print nxn lower triangular matrix a |
c+---------------------------------------------------------------------+
c+---------------------------------------------------------------------+
c| t y p e & d i m e n s i o n |
c+---------------------------------------------------------------------+
real a
dimension a(1)
c+---------------------------------------------------------------------+
c| c o m m o n & g l o b a l s |
c+---------------------------------------------------------------------+
common/nitnot/ nit, not
c+---------------------------------------------------------------------+
c| l o g i c |
c+---------------------------------------------------------------------+
write (not,900) n
900 format ('1'// ' lower triangular matrix with ',i3,' rows'/)
jj=0
do 200 i=1,n
write (not,910) i, (a(jj+j),j=1,i)
910 format (5h row ,i3,2x,10e12.4/(10x,10e12.4))
200 jj=jj+i
return
end
subroutine scopu
return
end
subroutine scprod
return
end
subroutine vr21d
return
end
subroutine vr22d
return
end
subroutine vr23d
return
end
rantad@XP-RANTAD ~/tests
$ gfortran --v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20070522 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
2007-06-18 14:49 ` [Bug fortran/32393] " dir at lanl dot gov
@ 2007-06-18 14:52 ` dominiq at lps dot ens dot fr
2007-06-18 15:05 ` dir at lanl dot gov
` (29 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-06-18 14:52 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from dominiq at lps dot ens dot fr 2007-06-18 14:52 -------
Compiling your code with g95 gives a lot of warnings. You should probably check
the use of the different subroutines.
In file pr32393.f:189
subroutine clect2
1
In file pr32393.f:155
call clect2 (t(nj),w(nj),nvg,nl1,mtrans,ctrans,itrans)
2
Warning (154): Inconsistent number of arguments in reference to 'clect2' at (1)
and (2)
In file pr32393.f:168
call prmx(t(nj),nvg)
1
In file pr32393.f:201
subroutine prmx (a,n)
2
Warning (155): Inconsistent types (INTEGER(4)/REAL(4)) in actual argument lists
at (1) and (2)
In file pr32393.f:156
call prmx(t(nj),nvg)
1
In file pr32393.f:201
subroutine prmx (a,n)
2
Warning (155): Inconsistent types (INTEGER(4)/REAL(4)) in actual argument lists
at (1) and (2)
In file pr32393.f:140
if (title(1:4).eq.its1 .and. ielt.le.4) call prmx(t(nj),nvg)
1
In file pr32393.f:201
subroutine prmx (a,n)
2
Warning (155): Inconsistent types (INTEGER(4)/REAL(4)) in actual argument lists
at (1) and (2)
In file pr32393.f:133
call prmx (t(nj),nvl)
1
In file pr32393.f:201
subroutine prmx (a,n)
2
Warning (155): Inconsistent types (INTEGER(4)/REAL(4)) in actual argument lists
at (1) and (2)
In file pr32393.f:195
subroutine mover
1
In file pr32393.f:154
call mover (0.,0,t(nj),1,nj1)
2
Warning (154): Inconsistent number of arguments in reference to 'mover' at (1)
and (2)
In file pr32393.f:192
subroutine mid2
1
In file pr32393.f:139
call mid2 (4,tgc,t(nj),t(nj))
2
Warning (154): Inconsistent number of arguments in reference to 'mid2' at (1)
and (2)
In file pr32393.f:198
subroutine penal
1
In file pr32393.f:120
if(ntyp.eq.411) call penal(a(ll),istab,t(nj))
2
Warning (154): Inconsistent number of arguments in reference to 'penal' at (1)
and (2)
In file pr32393.f:230
subroutine scprod
1
In file pr32393.f:101
call scprod (ns*ns,1,1,cc,cc,sum)
2
Warning (154): Inconsistent number of arguments in reference to 'scprod' at (1)
and (2)
In file pr32393.f:227
subroutine scopu
1
In file pr32393.f:152
210 call scopu (nnl,t,w)
2
Warning (154): Inconsistent number of arguments in reference to 'scopu' at (1)
and (2)
In file pr32393.f:236
subroutine vr22d
1
In file pr32393.f:112
if (idvr.eq.2) call vr22d (cc,ns,stdb,stdm,nlin,istab,t,t(nj))
2
Warning (154): Inconsistent number of arguments in reference to 'vr22d' at (1)
and (2)
In file pr32393.f:233
subroutine vr21d
1
In file pr32393.f:108
if (idvr.eq.1) call vr21d (cc,ns,stdb,nlin,istab,t)
2
Warning (154): Inconsistent number of arguments in reference to 'vr21d' at (1)
and (2)
In file pr32393.f:185
call vr2 ( intp, ivg, ccrans, cc, ns, stdb, stdm, t,
1
In file pr32393.f:2
cc, ns, stdb, stdm, t,
2
Warning (155): Inconsistent types (REAL(4)/INTEGER(4)) in actual argument lists
at (1) and (2)
In file pr32393.f:239
subroutine vr23d
1
In file pr32393.f:116
if (idvr.eq.3) call vr23d (cc,ns,stdm,nlin,istab,t)
2
Warning (154): Inconsistent number of arguments in reference to 'vr23d' at (1)
and (2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
2007-06-18 14:49 ` [Bug fortran/32393] " dir at lanl dot gov
2007-06-18 14:52 ` dominiq at lps dot ens dot fr
@ 2007-06-18 15:05 ` dir at lanl dot gov
2007-06-18 15:29 ` dominiq at lps dot ens dot fr
` (28 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dir at lanl dot gov @ 2007-06-18 15:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from dir at lanl dot gov 2007-06-18 15:05 -------
The only subroutine actually used is prmx. The rest are dummies to make the
linker happy. With g95, you get the correct results with -g and incorrect
results with -O3 -
[QuadG5:~/junk] dir% g95 -O3 -d8 -fstatic -Wno=121,155,154 -o g95Test01
g95Test01.f
[QuadG5:~/junk] dir% g95Test01
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
[QuadG5:~/junk] dir% g95 -g -d8 -fstatic -Wno=121,155,154 -o g95Test01
g95Test01.f
[QuadG5:~/junk] dir% g95Test01
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.1600E+02
row 2 0.9000E+01 0.2000E+02
row 3 0.1100E+02 0.1200E+02 0.2600E+02
[QuadG5:~/junk] dir% g95 --v
Using built-in specs.
Target:
Configured with: ../configure --enable-languages=c
Thread model: posix
gcc version 4.0.3 (g95 0.91!) Jun 4 2007
[QuadG5:~/junk] dir%
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (2 preceding siblings ...)
2007-06-18 15:05 ` dir at lanl dot gov
@ 2007-06-18 15:29 ` dominiq at lps dot ens dot fr
2007-06-18 16:16 ` burnus at gcc dot gnu dot org
` (27 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-06-18 15:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from dominiq at lps dot ens dot fr 2007-06-18 15:29 -------
> The only subroutine actually used is prmx. The rest are dummies to make the linker happy.
One thing which is obviously wrong is that 't' is declared as integer in vr2,
but is real in the calling program and in the prmx subroutine. Now I don't
know how the compiler is supposed to behave when there is a mismatch between
the arguments in the subroutines and their call. I suspect that the code is
badly invalid and as such can produce any result (as it is the case).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (3 preceding siblings ...)
2007-06-18 15:29 ` dominiq at lps dot ens dot fr
@ 2007-06-18 16:16 ` burnus at gcc dot gnu dot org
2007-06-18 18:13 ` dir at lanl dot gov
` (26 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-06-18 16:16 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from burnus at gcc dot gnu dot org 2007-06-18 16:15 -------
> Now I don't know how the compiler is supposed to behave when there is a
> mismatch between the arguments in the subroutines and their call.
Well it is always said that it may do anything such as starting the third world
war; however, I think the program is only allowed to produce wrong results, to
overwrite/delete any file and to crash ;-)
NAG f95 fails to compile the program with the errors:
Error: g95Test01.f, line 86: Inconsistent datatype for arg 1 in call to MOVER
Error: g95Test01.f, line 152: Inconsistent datatype for arg 2 in call to SCOPU
Error: g95Test01.f, line 154: Inconsistent datatype for arg 1 in call to MOVER
For gfortran such a whole-file check is planned
(http://gcc.gnu.org/wiki/GFortran43).
Close as INVALID. If the problem also occurs with a valid Fortran program, feel
free to re-open this bug. (Please attach longer programs, if you include them
inline the report gets a bit messy.)
--
burnus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu dot
| |org
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (4 preceding siblings ...)
2007-06-18 16:16 ` burnus at gcc dot gnu dot org
@ 2007-06-18 18:13 ` dir at lanl dot gov
2007-06-18 18:44 ` dominiq at lps dot ens dot fr
` (25 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dir at lanl dot gov @ 2007-06-18 18:13 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from dir at lanl dot gov 2007-06-18 18:13 -------
> Now I don't know how the compiler is supposed to behave when there is a
> mismatch between the arguments in the subroutines and their call.
I do - since the beginning of FORTRAN, well, at least since FORTRAN 2, it
simply passes the starting address down for simple data types. I have worked
several commercial finite element codes over the years and at least half of
them call routines with wrong data type for various reasons - to do extremely
efficient low cost dynamic memory management, to create objects, to overload
modules, to do multiple inheritance, etc... Fortran 90 has not always been
around to do these things legally.
That is all not relevant anyway, if you would look at the output, you would
realize that the only this wrong is that the loop -
do 242 i=1,nvg
j2=jj+iprec*(i-1)
c+---------------------------------------------------------------------+
c| multiply main diagonals by 2 |
c+---------------------------------------------------------------------+
jt=t(j2)
tt=tt+tt
t(j2)=jt
242 jj=jj+iprec*i
does not compile correctly - The program prints the data before and after the
loop. If you look at the assembly language output for that loop, it is
incorrect for O2. I make a quick try at pulling it out of the routine, but that
fail - so I just submitted the whole routine as I had already spent several
hours eliminated the other 100,000 lines of code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (5 preceding siblings ...)
2007-06-18 18:13 ` dir at lanl dot gov
@ 2007-06-18 18:44 ` dominiq at lps dot ens dot fr
2007-06-18 18:46 ` dominiq at lps dot ens dot fr
` (24 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-06-18 18:44 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from dominiq at lps dot ens dot fr 2007-06-18 18:44 -------
> I do ...
I am not in the position to argue about what f90 compilers are supposed to do
with the original code. I just attach a modified one I hope is valid: g95 does
not complain and gives:
karma] f90/bug% bg95 pr32393_db.f
[karma] f90/bug% a.out
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.1600E+02
row 2 0.9000E+01 0.2000E+02
row 3 0.1100E+02 0.1200E+02 0.2600E+02
[karma] f90/bug% bg95 -O3 pr32393_db.f
[karma] f90/bug% a.out
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.1600E+02
row 2 0.9000E+01 0.2000E+02
row 3 0.1100E+02 0.1200E+02 0.2600E+02
as does xlf. On the other hand gfortran gives:
[karma] f90/bug% gfc pr32393_db.f
[karma] f90/bug% a.out
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.1600E+02
row 2 0.9000E+01 0.2000E+02
row 3 0.1100E+02 0.1200E+02 0.2600E+02
[karma] f90/bug% gfc -O3 pr32393_db.f
[karma] f90/bug% a.out
1
lower triangular matrix with 3 rows
row 1 0.0000E+00
row 2 0.1000E+01 0.2000E+01
row 3 0.3000E+01 0.4000E+01 0.5000E+01
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.0000E+00
row 2 0.1000E+01 0.4000E+01
row 3 0.3000E+01 0.4000E+01 0.1000E+02
So if the attached code is deemed valid there is indeed a bug in gfortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (6 preceding siblings ...)
2007-06-18 18:44 ` dominiq at lps dot ens dot fr
@ 2007-06-18 18:46 ` dominiq at lps dot ens dot fr
2007-06-18 21:04 ` burnus at gcc dot gnu dot org
` (23 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-06-18 18:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from dominiq at lps dot ens dot fr 2007-06-18 18:46 -------
Created an attachment (id=13731)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13731&action=view)
valid test case(?)
I have removed the dummy subroutines and type mismatch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (7 preceding siblings ...)
2007-06-18 18:46 ` dominiq at lps dot ens dot fr
@ 2007-06-18 21:04 ` burnus at gcc dot gnu dot org
2007-06-19 12:48 ` dominiq at lps dot ens dot fr
` (22 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-06-18 21:04 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from burnus at gcc dot gnu dot org 2007-06-18 21:04 -------
> valid test case(?)
> I have removed the dummy subroutines and type mismatch.
Still not fully valid as NAG f95 complains
Error: yyy.f: Argument IVG (no. 2) in reference to VR2 from MAIN is not an
array
[...]
However, ignoring this issue ("-dusty"), NAG f95 shows another issue:
Subscript 1 of A (value 2) is out of range (1:1) in PRMX, line 191
(gfortran -fbounds-check finds it also.)
Otherwise on x86_64-unknown-linux-gnu I get the same result with all my
compilers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (8 preceding siblings ...)
2007-06-18 21:04 ` burnus at gcc dot gnu dot org
@ 2007-06-19 12:48 ` dominiq at lps dot ens dot fr
2007-06-20 14:15 ` dir at lanl dot gov
` (21 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-06-19 12:48 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from dominiq at lps dot ens dot fr 2007-06-19 12:48 -------
Even the code in comment #8 is invalid: several variables are used but not set:
at least intp and sum.
If I set them to 0, gfortran gives the same results with or without -O3. (tests
done on PPC Darwin7).
In my opinion the bug is invalid, but I'll let others make the final call.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (9 preceding siblings ...)
2007-06-19 12:48 ` dominiq at lps dot ens dot fr
@ 2007-06-20 14:15 ` dir at lanl dot gov
2007-06-20 15:43 ` dominiq at lps dot ens dot fr
` (20 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dir at lanl dot gov @ 2007-06-20 14:15 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from dir at lanl dot gov 2007-06-20 14:15 -------
It is easy to make this test case to a completely legal FORTRAN program.
Keeping the BUG and making it into a completely legal FORTRAN program is more
difficult, but likely possible. However, the problem that gfortran is having
with the program is that it does not take the full effect of the "equivalence
(jt,tt)" into account. This is where the real problem is and where I expected
some disagreement. Each line of code in the important loop is legal and the
loop has compiled and run correctly on dozens of FORTRAN compilers with and
without optimization, but one could argue with some justification that the
sequence instructions does something illegal. I will consider it "RESOLVED
INVALID" on that basis.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (10 preceding siblings ...)
2007-06-20 14:15 ` dir at lanl dot gov
@ 2007-06-20 15:43 ` dominiq at lps dot ens dot fr
2007-06-20 16:21 ` burnus at gcc dot gnu dot org
` (19 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-06-20 15:43 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from dominiq at lps dot ens dot fr 2007-06-20 15:43 -------
With the following changes to the original code:
[karma] f90/bug% diff -u pr32393.f pr32393_mod.f
--- pr32393.f Mon Jun 18 16:46:48 2007
+++ pr32393_mod.f Wed Jun 20 17:40:03 2007
@@ -16,7 +16,7 @@
c+---------------------------------------------------------------------+
character its1*4
character title*72
- integer t
+! integer t
real cc, ctrans, dprod2, sdb, sdm,
$ stdb, stdm, sum, ttt, uf,
$ vf, wsf
@@ -99,6 +99,7 @@
c| skip second variation if cc matrix = 0 |
c+---------------------------------------------------------------------+
call scprod (ns*ns,1,1,cc,cc,sum)
+ sum = 0
if (sum.le.0.)go to 180
c+---------------------------------------------------------------------+
c| choose appropriate computational routine |
@@ -182,8 +183,10 @@
not=6
nvg=3
iprec = 1
- call vr2 ( intp, ivg, ccrans, cc, ns, stdb, stdm, t,
- $ k2, nlin, istab )
+! call vr2 ( intp, ivg, ccrans, cc, ns, stdb, stdm, t,
+! $ k2, nlin, istab )
+ call vr2 ( 0, ivg, ccrans, cc, ns, stdb, stdm, t,
+ $ 0, 0, 0 )
stop
end
subroutine clect2
I get with gfortran:
[karma] f90/bug% gfc -g -O3 pr32393_mod.f
[karma] f90/bug% a.out
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.1600E+02
row 2 0.9000E+01 0.2000E+02
row 3 0.1100E+02 0.1200E+02 0.2600E+02
[karma] f90/bug% gfc -g -O1 pr32393_mod.f
[karma] f90/bug% a.out
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.1600E+02
row 2 0.9000E+01 0.2000E+02
row 3 0.1100E+02 0.1200E+02 0.2600E+02
[karma] f90/bug% gfc -g -O1 -ffast-math -funroll-loops pr32393_mod.f
[karma] f90/bug% a.out
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.1600E+02
row 2 0.9000E+01 0.2000E+02
row 3 0.1100E+02 0.1200E+02 0.2600E+02
[karma] f90/bug% gfc -g pr32393_mod.f
[karma] f90/bug% a.out
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.1600E+02
row 2 0.9000E+01 0.2000E+02
row 3 0.1100E+02 0.1200E+02 0.2600E+02
Note that I have only given some values to variables used in tests (plus set t
to real).
BTW I do not see (beside obfuscation) the interest of the constructs:
jt=t(j2)
tt=.5*tt
t(j2)=jt
where jt and tt are equivalenced!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (11 preceding siblings ...)
2007-06-20 15:43 ` dominiq at lps dot ens dot fr
@ 2007-06-20 16:21 ` burnus at gcc dot gnu dot org
2007-06-21 12:58 ` dir at lanl dot gov
` (18 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-06-20 16:21 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from burnus at gcc dot gnu dot org 2007-06-20 16:20 -------
> However, the problem that gfortran is having with the program is that it does
> not take the full effect of the "equivalence (jt,tt)" into account. This is
> where the real problem is and where I expected some disagreement.
I would not be surprised if some bug is lurking there, but my problem is that
if the program is invalid and produces different results with different
compilers, it is a bit difficult to pinpoint the problem.
What is actually the expected result? Depending on the compiler and compiler
setting, I get completely different results for the second triangular matrix.
(The first matrix remains always the same.)
NAG f95 -dusty refuses to compile the program.
gfortran with -O0 to -O3, sunf95 (default settings), g95 (-O0) and Intel's
ifort (-O1) give:
row 1 0.1600E+02
row 2 0.9000E+01 0.2000E+02
row 3 0.1100E+02 0.1200E+02 0.2600E+02
ifort -O2 (= ifort w/ default settings) and gfortran -O3 -ffast-math give:
row 1 0.0000E+00
row 2 0.9000E+01 0.0000E+00
row 3 0.1100E+02 0.1200E+02 0.0000E+00
g95 -O2 gives:
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
Thus which compiler is right? Are all right? What exactly is the bug / expected
output? Is it fixed meanwhile as I get for -O3 w/o -ffast-math the same output
as for -O0?
Is it platform dependent? I use 4.3.0 20070620 (x86_64-unknown-linux-gnu) and
the unmodified version (or equivalently the version as modified by Dominique).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (12 preceding siblings ...)
2007-06-20 16:21 ` burnus at gcc dot gnu dot org
@ 2007-06-21 12:58 ` dir at lanl dot gov
2007-06-21 13:23 ` dir at lanl dot gov
` (17 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dir at lanl dot gov @ 2007-06-21 12:58 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from dir at lanl dot gov 2007-06-21 12:57 -------
>What is actually the expected result? Depending on the compiler and compiler
>setting, I get completely different results for the second triangular matrix.
>(The first matrix remains always the same.)
What the program does in this section is multiply the diagonal of the matrix by
2 with the line -
tt=tt+tt
and so (0.8000E+01 -> 0.1600E+02), (0.1000E+02 -> 0.2000E+02) and (0.1300E+02
-> 0.2600E+02 ) and the other three elememts should stay the same. In debug
mode, most compilers will give the correct answer, but the addition is
sometimes being optmized away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (13 preceding siblings ...)
2007-06-21 12:58 ` dir at lanl dot gov
@ 2007-06-21 13:23 ` dir at lanl dot gov
2007-06-21 16:16 ` dir at lanl dot gov
` (16 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dir at lanl dot gov @ 2007-06-21 13:23 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from dir at lanl dot gov 2007-06-21 13:23 -------
>BTW I do not see (beside obfuscation) the interest of the constructs:
It is the construct:
jt=t(j2)
tt=tt+tt
t(j2)=jt
that is being optmized away or done incorrectly when the second matrix stays
the same. The obfuscation is required because the program is doing virtual
memory management and at this point floating point data is in one of the raw
integer virtual arrays and so that is the game that is played to do the
floating point add.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (14 preceding siblings ...)
2007-06-21 13:23 ` dir at lanl dot gov
@ 2007-06-21 16:16 ` dir at lanl dot gov
2007-06-21 16:29 ` dir at lanl dot gov
` (15 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dir at lanl dot gov @ 2007-06-21 16:16 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from dir at lanl dot gov 2007-06-21 16:16 -------
Created an attachment (id=13759)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13759&action=view)
Warning free version
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (15 preceding siblings ...)
2007-06-21 16:16 ` dir at lanl dot gov
@ 2007-06-21 16:29 ` dir at lanl dot gov
2007-06-21 16:48 ` burnus at gcc dot gnu dot org
` (14 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dir at lanl dot gov @ 2007-06-21 16:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from dir at lanl dot gov 2007-06-21 16:29 -------
I have attached version that generates no warnings with gfortran or g95. As I
reduced, it the bug changed - that is the problem with optmization bugs - they
are hard to trap. Anyway there is still a bug for some compilers. gfortran on
the Macintosh and Linux are Ok. g77 is happy and gets the correct answer -
[dranta:~/tests] dir% g77 -o g95Test02 g95Test02.f
[dranta:~/tests] dir% g95Test02
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.1600E+02
row 2 0.9000E+01 0.2000E+02
row 3 0.1100E+02 0.1200E+02 0.2600E+02
g95 cannot decide which wrong answer it likes -
[dranta:~/tests] dir% g95 -Wall -g -o g95Test02 g95Test02.f
[dranta:~/tests] dir% g95Test02
1
lower triangular matrix with 3 rows
row 1 -0.2000E+01
row 2 0.1000E+01 0.2000E+01
row 3 0.3000E+01 0.4000E+01 0.5000E+01
iprec = 1
1
lower triangular matrix with 3 rows
row 1 -0.3999E+01
row 2 0.1000E+01 0.4000E+01
row 3 0.3000E+01 0.4000E+01 0.1000E+02
[dranta:~/tests] dir% g95 -Wall -O3 -o g95Test02 g95Test02.f
[dranta:~/tests] dir% g95Test02
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
gfortran (i386-pc-mingw32) on windows now gets the wrong answer with -O3 -
rantad@XP-RANTAD ~/tests
$ gfortran -g -o g95Test02 g95Test02.f
rantad@XP-RANTAD ~/tests
$ g95Test02
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.1600E+02
row 2 0.9000E+01 0.2000E+02
row 3 0.1100E+02 0.1200E+02 0.2600E+02
rantad@XP-RANTAD ~/tests
$ gfortran -O3 -o g95Test02 g95Test02.f
rantad@XP-RANTAD ~/tests
$ g95Test02
1
lower triangular matrix with 3 rows
row 1 0.0000E+00
row 2 0.1000E+01 0.2000E+01
row 3 0.3000E+01 0.4000E+01 0.5000E+01
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.0000E+00
row 2 0.1000E+01 0.4000E+01
row 3 0.3000E+01 0.4000E+01 0.1000E+02
rantad@XP-RANTAD ~/tests
$ gfortran --v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20070522 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (16 preceding siblings ...)
2007-06-21 16:29 ` dir at lanl dot gov
@ 2007-06-21 16:48 ` burnus at gcc dot gnu dot org
2007-06-21 17:04 ` dominiq at lps dot ens dot fr
` (13 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-06-21 16:48 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from burnus at gcc dot gnu dot org 2007-06-21 16:48 -------
> Created an attachment (id=13759)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13759&action=view) [edit]
> Warning free version
Thanks, it finally compiles with NAG "f95 -dusty", which finds directly one
problem:
Subscript 1 of IA (value 2) is out of range (1:1)
In PRMX, line 134 of test.f
I changed ia(1) to ia(20) - then it works. Actually, it works on my system
(x86_64-unknown-linux-gnu, 4.3.0 20070621) up to the option
-O3 -ffast-math -ftree-vectorize -funroll-all-loops
It also works now with ifort -O3 -xW, NAG f95, sunf95 and gfortran 4.1.0.
Interestingly, both gfortran 4.2.0 and g95 now produce (no options) for the
first matrix:
row 1 0.0000E+00
row 2 0.1000E+01 0.2000E+01
row 3 0.3000E+01 0.4000E+01 0.5000E+01
g95 produces the same result as the others using "-fzero". Using NAG f95 with
-nan the program crashes with an arithmetic exception, which means that either
cc or sum in vr2 must be uninitialized when calling scprod. (-nan initializes
the variables with signalling NaN.) Thus there is still a bug lurking in the
source code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (17 preceding siblings ...)
2007-06-21 16:48 ` burnus at gcc dot gnu dot org
@ 2007-06-21 17:04 ` dominiq at lps dot ens dot fr
2007-06-21 17:14 ` burnus at gcc dot gnu dot org
` (12 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-06-21 17:04 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from dominiq at lps dot ens dot fr 2007-06-21 17:04 -------
> Subscript 1 of IA (value 2) is out of range (1:1)
I don't think it really matter as
dimension ia(1),a(20)
is the old style for passing arrays. However there are many uninitialized
variables:
call vr2 ( intp, ivg, cc, ns, it)
as far as I can tell none of them are initialized. On ppc-darwin7 latest 4.3
snapshot the new code
gives the expected result as does xlf, but not g95. Tracing what is wrong with
this code explains why so many people don't like fortran!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (18 preceding siblings ...)
2007-06-21 17:04 ` dominiq at lps dot ens dot fr
@ 2007-06-21 17:14 ` burnus at gcc dot gnu dot org
2007-06-21 20:06 ` dir at lanl dot gov
` (11 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-06-21 17:14 UTC (permalink / raw)
To: gcc-bugs
------- Comment #20 from burnus at gcc dot gnu dot org 2007-06-21 17:14 -------
> as far as I can tell none of them are initialized.
This is why I'm eagerly waiting for Asher fixing PR20441 and why g95 has
-fzero.
> Tracing what is wrong with this code explains why so many people don't like
> fortran!
Well, modern Fortran code should be much better manageable; and initializing
all variables by (signalling) NaN helps finding these errors for real/complex
variables. Initializing all variables by zero circumvents these errors (and may
yield the correct result if zero is the correct number for the initialization
;-).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (19 preceding siblings ...)
2007-06-21 17:14 ` burnus at gcc dot gnu dot org
@ 2007-06-21 20:06 ` dir at lanl dot gov
2007-06-21 20:11 ` dir at lanl dot gov
` (10 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dir at lanl dot gov @ 2007-06-21 20:06 UTC (permalink / raw)
To: gcc-bugs
------- Comment #21 from dir at lanl dot gov 2007-06-21 20:06 -------
Created an attachment (id=13761)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13761&action=view)
All Used Variables intialized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (20 preceding siblings ...)
2007-06-21 20:06 ` dir at lanl dot gov
@ 2007-06-21 20:11 ` dir at lanl dot gov
2007-06-22 9:41 ` burnus at gcc dot gnu dot org
` (9 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dir at lanl dot gov @ 2007-06-21 20:11 UTC (permalink / raw)
To: gcc-bugs
------- Comment #22 from dir at lanl dot gov 2007-06-21 20:11 -------
This version has all the variables that are actually used intialized. I will
have to try the windows version later, but g95 has switched the way that it is
wrong again -
[dranta:~/tests] dir% g95 -Wall -O3 -o g95Test03 g95Test03.f
[dranta:~/tests] dir% g95Test03
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
iprec = 1
1
lower triangular matrix with 3 rows
row 1 0.8000E+01
row 2 0.9000E+01 0.1000E+02
row 3 0.1100E+02 0.1200E+02 0.1300E+02
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (21 preceding siblings ...)
2007-06-21 20:11 ` dir at lanl dot gov
@ 2007-06-22 9:41 ` burnus at gcc dot gnu dot org
2007-06-22 13:27 ` burnus at gcc dot gnu dot org
` (8 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-06-22 9:41 UTC (permalink / raw)
To: gcc-bugs
------- Comment #23 from burnus at gcc dot gnu dot org 2007-06-22 09:41 -------
> All Used Variables intialized
Do you actually get still wrong results with gfortran? If yes, which platform
and compiler version?
Here, I fail to get a wrong result with ifort, NAG f95, sunf95, gfortran 4.1.3,
4.2.0 and 4.3(of today) with several optimization flags and both for 32 and 64
bit on x86-64.
As Dominique, I still get an error for "g95 -O2", but that is a different
compiler (usually found with GCC 4.0.x backend; note GCC < 4.1.x is no longer
maintained.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (22 preceding siblings ...)
2007-06-22 9:41 ` burnus at gcc dot gnu dot org
@ 2007-06-22 13:27 ` burnus at gcc dot gnu dot org
2007-06-22 14:28 ` dir at lanl dot gov
` (7 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-06-22 13:27 UTC (permalink / raw)
To: gcc-bugs
------- Comment #24 from burnus at gcc dot gnu dot org 2007-06-22 13:26 -------
Additional note - as pointed out by Ian of NAG:
program main
implicit none
integer :: jt, it(100)
real :: tt
equivalence (jt,tt)
do i=1,100
tt=i
it(i)=jt
end do
end program main
Here "jt" is *undefined*. The Fortran 2003 standard has in Section 16.5.6:
"When a variable of a given type becomes defined, all associated
variables of different type become undefined." (There is an exception for real
vs. complex variables.)
That mean "jt" can contain any value according to the standard (cf. "union" in
C). In reality, after assigning real(ii) to tt, jt has a defined value - which
some programs make use of.
Fortran 2003 standard conform would be not: "it(i) = jt", but
"it(i)=transfer(tt,0)", which gives however the same result in practice.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (23 preceding siblings ...)
2007-06-22 13:27 ` burnus at gcc dot gnu dot org
@ 2007-06-22 14:28 ` dir at lanl dot gov
2007-06-22 14:32 ` burnus at gcc dot gnu dot org
` (6 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: dir at lanl dot gov @ 2007-06-22 14:28 UTC (permalink / raw)
To: gcc-bugs
------- Comment #25 from dir at lanl dot gov 2007-06-22 14:28 -------
I was tracking what appeared to be the similar bugs in gfortran and g95, but
some where in the last few steps when I could not test with gfortran - I lost
the gfortran link.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (24 preceding siblings ...)
2007-06-22 14:28 ` dir at lanl dot gov
@ 2007-06-22 14:32 ` burnus at gcc dot gnu dot org
2007-06-24 10:51 ` dominiq at lps dot ens dot fr
` (5 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-06-22 14:32 UTC (permalink / raw)
To: gcc-bugs
------- Comment #26 from burnus at gcc dot gnu dot org 2007-06-22 14:32 -------
(In reply to comment #25)
> I was tracking what appeared to be the similar bugs in gfortran and g95, but
> some where in the last few steps when I could not test with gfortran - I lost
> the gfortran link.
You are looking for the following, are you?
http://gcc.gnu.org/wiki/GFortranBinaries
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (25 preceding siblings ...)
2007-06-22 14:32 ` burnus at gcc dot gnu dot org
@ 2007-06-24 10:51 ` dominiq at lps dot ens dot fr
2007-06-24 11:12 ` Andrew Pinski
2007-06-24 11:13 ` pinskia at gmail dot com
` (4 subsequent siblings)
31 siblings, 1 reply; 35+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-06-24 10:51 UTC (permalink / raw)
To: gcc-bugs
------- Comment #27 from dominiq at lps dot ens dot fr 2007-06-24 10:51 -------
> As Dominique, I still get an error for "g95 -O2", but that is a different
> compiler (usually found with GCC 4.0.x backend; note GCC < 4.1.x is no longer
> maintained.)
Note that g95 can be compiled with 4.1:
Using built-in specs.
Target:
Configured with: ../configure
--prefix=/sw/lib/gcc-lib/powerpc-apple-darwin7/4.1.2 --enable-languages=c
--with-as=/sw/lib/odcctools/bin/as --with-ld=/sw/lib/odcctools/bin/ld
--with-nm=/sw/lib/odcctools/bin/nm --with-included-gettext
Thread model: posix
gcc version 4.1.2 (g95 0.91!) Jun 24 2007
which gives the expected result. So it seems that the problem is a bug in
gcc4.0 (besides the conformity to f2003 that I am not sure to really
understand).
Caveat:
(1) when compiled with 4.1, g95 gives ICE on derived type I/O when compiled
with -O (at least on Mac OSX 10.3.9):
! Related to PR 19928. Check that foo() is only called once per statement.
! { dg-do run }
program main
implicit none
type t
integer, dimension (5) :: field
end type t
type (t), dimension (2) :: a
integer :: calls, i, j
forall (i = 1:2, j = 1:5) a(i)%field(j) = i * 100 + j
print *, a
end program main
[karma] bug/ice_g95_4.1% g95 -O type_1_red.f90
type_1_red.f90:3: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.g95.org or mail andyv@firstinter.net for instructions.
(2) I have an infinite loop with the following code and -O3:
! { dg-do run }
! Program to check corner cases for DO statements.
program do_1
implicit none
integer i, j, k
! Bound near smallest value
j = 0;
print *, -HUGE(i)
k = -HUGE(i)
do i = -HUGE(i), -HUGE(i)
! do i = -HUGE(i)+3, -HUGE(i)+3, 4
! do i = -HUGE(i)+9, -HUGE(i)+9, 10
! do i = k, k, 10
j = j + 1
end do
print *, j
if (j .ne. 1) call abort
end program
A long time ago, I have reported the problem to Andy who is blaming the gcc
middle-end, so if someone working in this area have an idea ...!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Bug fortran/32393] gfortran - incorrect run time results
2007-06-24 10:51 ` dominiq at lps dot ens dot fr
@ 2007-06-24 11:12 ` Andrew Pinski
0 siblings, 0 replies; 35+ messages in thread
From: Andrew Pinski @ 2007-06-24 11:12 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
On 24 Jun 2007 10:51:42 -0000, dominiq at lps dot ens dot fr
<gcc-bugzilla@gcc.gnu.org> wrote:
>
> (1) when compiled with 4.1, g95 gives ICE on derived type I/O when compiled
> with -O (at least on Mac OSX 10.3.9):
>
> [karma] bug/ice_g95_4.1% g95 -O type_1_red.f90
> type_1_red.f90:3: internal compiler error: Bus error
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://www.g95.org or mail andyv@firstinter.net for instructions.
So what is the backtrace inside the middle-end? If possible (and
knowing) give the output of the tree dumps (-fdump-tree-all). If Andy
is blaming us, he might as well report real bugs instead of just
saying it is our bug. I would say if Andy does not want even to
report any bugs about the middle-end going wrong (or right, see
below), I would strongly recommend you stay away from g95.
> (2) I have an infinite loop with the following code and -O3:
>
> ! { dg-do run }
> ! Program to check corner cases for DO statements.
Try with -fwarpv, I bet this is really a bug in g95's IR. Can you
provide me (us) with the tree dumps?
> A long time ago, I have reported the problem to Andy who is blaming the gcc
> middle-end, so if someone working in this area have an idea ...!
Some cases are our fault, others are g95's fault and Andy might not
want to say it is his fault if the middle-end optimizes away stuff
based on undefined code (which I bet is happening in the last case).
Thanks,
Andrew Pinski
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (26 preceding siblings ...)
2007-06-24 10:51 ` dominiq at lps dot ens dot fr
@ 2007-06-24 11:13 ` pinskia at gmail dot com
2007-06-24 19:28 ` dominiq at lps dot ens dot fr
` (3 subsequent siblings)
31 siblings, 0 replies; 35+ messages in thread
From: pinskia at gmail dot com @ 2007-06-24 11:13 UTC (permalink / raw)
To: gcc-bugs
------- Comment #28 from pinskia at gmail dot com 2007-06-24 11:12 -------
Subject: Re: gfortran - incorrect run time results
On 24 Jun 2007 10:51:42 -0000, dominiq at lps dot ens dot fr
<gcc-bugzilla@gcc.gnu.org> wrote:
>
> (1) when compiled with 4.1, g95 gives ICE on derived type I/O when compiled
> with -O (at least on Mac OSX 10.3.9):
>
> [karma] bug/ice_g95_4.1% g95 -O type_1_red.f90
> type_1_red.f90:3: internal compiler error: Bus error
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://www.g95.org or mail andyv@firstinter.net for instructions.
So what is the backtrace inside the middle-end? If possible (and
knowing) give the output of the tree dumps (-fdump-tree-all). If Andy
is blaming us, he might as well report real bugs instead of just
saying it is our bug. I would say if Andy does not want even to
report any bugs about the middle-end going wrong (or right, see
below), I would strongly recommend you stay away from g95.
> (2) I have an infinite loop with the following code and -O3:
>
> ! { dg-do run }
> ! Program to check corner cases for DO statements.
Try with -fwarpv, I bet this is really a bug in g95's IR. Can you
provide me (us) with the tree dumps?
> A long time ago, I have reported the problem to Andy who is blaming the gcc
> middle-end, so if someone working in this area have an idea ...!
Some cases are our fault, others are g95's fault and Andy might not
want to say it is his fault if the middle-end optimizes away stuff
based on undefined code (which I bet is happening in the last case).
Thanks,
Andrew Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (27 preceding siblings ...)
2007-06-24 11:13 ` pinskia at gmail dot com
@ 2007-06-24 19:28 ` dominiq at lps dot ens dot fr
2007-06-24 19:37 ` Andrew Pinski
2007-06-24 19:37 ` pinskia at gmail dot com
` (2 subsequent siblings)
31 siblings, 1 reply; 35+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-06-24 19:28 UTC (permalink / raw)
To: gcc-bugs
------- Comment #29 from dominiq at lps dot ens dot fr 2007-06-24 19:28 -------
>Try with -fwarpv, I bet this is really a bug in g95's IR.
-fwarpv is not recognized by g95.
> Can you provide me (us) with the tree dumps?
Do you want all of them? If yes, what is the best way to send them?
Otherwise which ones do you want among the ~70 of them?
Without optimization the asembly code is:
...
L2:
lwz r0,68(r30)
cmpwi cr7,r0,0
beq cr7,L3
lwz r2,84(r30)
addi r0,r2,1
stw r0,84(r30)
lwz r2,60(r30)
addi r0,r2,1
stw r0,60(r30)
lwz r2,68(r30)
addi r0,r2,-1
stw r0,68(r30)
b L2
L3:
...
with -O3, it is:
...
L2:
b L2
...
> Some cases are our fault, others are g95's fault and Andy might not
> want to say it is his fault if the middle-end optimizes away stuff
> based on undefined code (which I bet is happening in the last case).
I did report the problems I have seen with g95 and gcc4.1, just to let people
know that they might see them. Also I have read the Andy's reply more on the
mode:
problems with -O* => middle-end problem (and I don't have time to dig them)
rather than putting an explicit blame on the gcc part.
I am aware of these problems probably for over a year, so you might guess that
I did not give them a very high priority. Now i'll be glad if someone is
willing to have a look at their possible origin.
BTW should we keep this discussion in this PR or open a new one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Bug fortran/32393] gfortran - incorrect run time results
2007-06-24 19:28 ` dominiq at lps dot ens dot fr
@ 2007-06-24 19:37 ` Andrew Pinski
0 siblings, 0 replies; 35+ messages in thread
From: Andrew Pinski @ 2007-06-24 19:37 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
On 24 Jun 2007 19:28:45 -0000, dominiq at lps dot ens dot fr
<gcc-bugzilla@gcc.gnu.org> wrote:
> ------- Comment #29 from dominiq at lps dot ens dot fr 2007-06-24 19:28 -------
> >Try with -fwarpv, I bet this is really a bug in g95's IR.
>
> -fwarpv is not recognized by g95.
How can it not be recognize by g95???? It is a generic GCC option
that has been with GCC since at least 3.4.0. Guess it is time for g95
issues to be ignored then if it removes common options.
-- Pinski
^ permalink raw reply [flat|nested] 35+ messages in thread
* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (28 preceding siblings ...)
2007-06-24 19:28 ` dominiq at lps dot ens dot fr
@ 2007-06-24 19:37 ` pinskia at gmail dot com
2007-06-24 19:45 ` burnus at gcc dot gnu dot org
2007-06-24 19:52 ` dominiq at lps dot ens dot fr
31 siblings, 0 replies; 35+ messages in thread
From: pinskia at gmail dot com @ 2007-06-24 19:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #30 from pinskia at gmail dot com 2007-06-24 19:37 -------
Subject: Re: gfortran - incorrect run time results
On 24 Jun 2007 19:28:45 -0000, dominiq at lps dot ens dot fr
<gcc-bugzilla@gcc.gnu.org> wrote:
> ------- Comment #29 from dominiq at lps dot ens dot fr 2007-06-24 19:28 -------
> >Try with -fwarpv, I bet this is really a bug in g95's IR.
>
> -fwarpv is not recognized by g95.
How can it not be recognize by g95???? It is a generic GCC option
that has been with GCC since at least 3.4.0. Guess it is time for g95
issues to be ignored then if it removes common options.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (29 preceding siblings ...)
2007-06-24 19:37 ` pinskia at gmail dot com
@ 2007-06-24 19:45 ` burnus at gcc dot gnu dot org
2007-06-24 19:52 ` dominiq at lps dot ens dot fr
31 siblings, 0 replies; 35+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-06-24 19:45 UTC (permalink / raw)
To: gcc-bugs
------- Comment #31 from burnus at gcc dot gnu dot org 2007-06-24 19:45 -------
> -fwarpv is not recognized by g95.
Try: -fwrapv
"This option instructs the compiler to assume that signed arithmetic overflow
of addition, subtraction and multiplication wraps around using twos-complement
representation. This flag enables some optimizations and disables others."
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread* [Bug fortran/32393] gfortran - incorrect run time results
2007-06-18 14:42 [Bug fortran/32393] New: gfortran - incorrect run time results dir at lanl dot gov
` (30 preceding siblings ...)
2007-06-24 19:45 ` burnus at gcc dot gnu dot org
@ 2007-06-24 19:52 ` dominiq at lps dot ens dot fr
31 siblings, 0 replies; 35+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-06-24 19:52 UTC (permalink / raw)
To: gcc-bugs
------- Comment #32 from dominiq at lps dot ens dot fr 2007-06-24 19:52 -------
mid-air collision!
> > >Try with -fwarpv, I bet this is really a bug in g95's IR.
> >
> > -fwarpv is not recognized by g95.
>
> How can it not be recognize by g95????
Sorry, I did not unfold the typo, g95 recognizes -fwrapv and with it there is
still the infinite loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
^ permalink raw reply [flat|nested] 35+ messages in thread