[Bug fortran/32393] New: gfortran - incorrect run time results

[Bug fortran/32393] New: gfortran - incorrect run time results

[dir at lanl dot gov]

This program runs Ok on the Macintosh versions of gfortran. It runs Ok on the
i386-pc-mingw32 version of gfortran using -g, but fails using -O3. It always
fails on the cygwin version of gfortran -

> gfortran -o g95Test01 g95Test01.f
> ./g95Test01
1

 lower triangular matrix with   3 rows

 row   1    0.3214E-38
 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.6428E-38
 row   2    0.1000E+01  0.4000E+01
 row   3    0.3000E+01  0.4000E+01  0.1000E+02
STOP 0
> 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


> gfortran --v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../gcc43/configure --prefix=/usr/local/gfortran --enable-lan
ges=c,fortran --enable-bootstrap --enable-threads=posix --enable-sjlj-excepti
 --enable-version-specific-runtime-libs --enable-nls --disable-libmudflap --d
ble-shared --disable-win32-registry --with-system-zlib --enable-checking=rele
 --enable-werror --without-included-gettext --without-x --enable-libgomp
Thread model: posix
gcc version 4.3.0 20070512 (experimental)
>


-- 
           Summary: gfortran - incorrect run time results
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dir at lanl dot gov
  GCC host triplet: i686-pc-cygwin


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393

[Bug fortran/32393] gfortran - incorrect run time results

[dir at lanl dot gov]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dominiq at lps dot ens dot fr]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dir at lanl dot gov]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dominiq at lps dot ens dot fr]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[burnus at gcc dot gnu dot org]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dir at lanl dot gov]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dominiq at lps dot ens dot fr]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dominiq at lps dot ens dot fr]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[burnus at gcc dot gnu dot org]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dominiq at lps dot ens dot fr]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dir at lanl dot gov]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dominiq at lps dot ens dot fr]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[burnus at gcc dot gnu dot org]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dir at lanl dot gov]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dir at lanl dot gov]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dir at lanl dot gov]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dir at lanl dot gov]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[burnus at gcc dot gnu dot org]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dominiq at lps dot ens dot fr]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[burnus at gcc dot gnu dot org]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dir at lanl dot gov]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dir at lanl dot gov]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[burnus at gcc dot gnu dot org]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[burnus at gcc dot gnu dot org]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dir at lanl dot gov]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[burnus at gcc dot gnu dot org]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dominiq at lps dot ens dot fr]

------- 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

Re: [Bug fortran/32393] gfortran - incorrect run time results

[Andrew Pinski]

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

[Bug fortran/32393] gfortran - incorrect run time results

[pinskia at gmail dot com]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dominiq at lps dot ens dot fr]

------- 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

Re: [Bug fortran/32393] gfortran - incorrect run time results

[Andrew Pinski]

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

[Bug fortran/32393] gfortran - incorrect run time results

[pinskia at gmail dot com]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[burnus at gcc dot gnu dot org]

------- 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

[Bug fortran/32393] gfortran - incorrect run time results

[dominiq at lps dot ens dot fr]

------- 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