------- Additional Comments From david dot c dot gregory at gmail dot com 2005-06-13 14:13 ------- I too would happily test gfortran, if this bug were resolved. However, my code-base makes heavy use of function overloading at a core level. Thus until this bug is fixed, the compiler is all but useless to me.
Consider this a begging plea for one of the developers to take up this bug!!! (In reply to comment #0) > The current gfortran rejects the following code: > > module foo > implicit none > > interface bar > module procedure bar1, bar2 > end interface > > contains > > function bar1 (arg) > integer arg > logical bar1 > > bar1 = (arg==0) > end function > > function bar2 (arg) > real arg > logical bar2 > > bar2 = (arg==0) > end function > > subroutine baz > logical l > > l = bar (3) > end subroutine > > end module foo > > > ~/tmp>gfortran -v gfbug.f90 > Driving: gfortran -v gfbug.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc > Reading specs from > /afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/specs > Configured with: /scratch/gcc/configure --quiet > --prefix=/afs/mpa/data/martin/ugcc --enable-languages=c++,f95 > --with-gmp=/afs/mpa/data/martin/mygmp > Thread model: posix > gcc version 4.0.0 20041021 (experimental) > /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.0.0/f951 gfbug.f90 > -quiet -dumpbase gfbug.f90 -mtune=pentiumpro -auxbase gfbug -version -o > /tmp/ccTKCcxy.s > GNU F95 version 4.0.0 20041021 (experimental) (i686-pc-linux-gnu) > compiled by GNU C version 4.0.0 20041021 (experimental). > GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 > In file gfbug.f90:27 > > l = bar (3) > 1 > Error: Symbol 'bar' at (1) has no IMPLICIT type > > In principle gfortran should be able to choose the correct variant of "bar" > with the information it has. All other compilers I tried (ifc, NAG, xlf95) > accept this code. (In reply to comment #11) > (In reply to comment #10) > > > Does this mean that calling twice is a verified workaround solution? > > Should I > > have confidence in the results of this workaround? > > Even if it was, this is not a practical solution in for large code bases like > the one I have to maintain. > What's worrying me most is that nobody appears to understand what's going > wrong. > (And that for a very long time now.) > > Since half a year, this is the one bug preventing me from using gfortran to > compile my code base and report more bugs :( > (In reply to comment #11) > (In reply to comment #10) > > > Does this mean that calling twice is a verified workaround solution? > > Should I > > have confidence in the results of this workaround? > > Even if it was, this is not a practical solution in for large code bases like > the one I have to maintain. > What's worrying me most is that nobody appears to understand what's going > wrong. > (And that for a very long time now.) > > Since half a year, this is the one bug preventing me from using gfortran to > compile my code base and report more bugs :( > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18108
