[Bug fortran/18108] [gfortran] overloading does not work for functions

["david dot c dot gregory at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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