c++/5732: g++ not using return type for overload resolution

[Martin Staley]

>Number:         5732
>Category:       c++
>Synopsis:       g++ not using return type for overload resolution
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 19 19:36:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        3.0.3
>Organization:
	Los Alamos National Laboratory
>Environment:
System: Linux pasilla.lanl.gov 2.4.3-12smp #1 SMP Fri Jun 8 14:38:50 EDT 2001 i686 unknown
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-3.0.3/configure --prefix=/packages/gcc/gcc-3.0.3
>Description:
I ran across the following problem using g++ 3.0.3, and didn't find any mention
of it on http://www.gnu.org/software/gcc/bugs.html.  The following is (I think!)
legal C++:

     // file bug.cc
     #include <iostream>

     template<class T>
     T fun(const T &)
     {
        std::cout << "foo" << std::endl;
        return 0;
     }

     template<class T>
     typename T::value_type fun(const T &)
     {
        std::cout << "bar" << std::endl;
        return 0;
     }

     int main(void)
     {
        fun(1);
     }

I believe this should compile and print "foo".  But compiling with "g++ bug.cc"
produces the following diagnostic:

     bug.cc:15: new declaration `template<class T> typename T::value_type fun(const
        T&)'
     bug.cc:7: ambiguates old declaration `template<class T> T fun(const T&)'

Under older C++ rules, the two declarations would indeed conflict because the
formal parameters are exactly the same: const T & for both versions of fun().
But, Standard C++ as I understand it also uses a function template's return type
when determining if it's a match for a particular call.  If the return type
doesn't "work", then it's not considered a possible match.

E.g., in the above code: "typename T::value_type" makes no sense for T=int,
so the second version of fun() doesn't work.  Thus the first version of fun()
should be used.  That's the way it works with the EDG front-end, and I've
examined the standard and EDG is apparently correct.  If I'm right about this
being a bug then you're probably aware of it already, but I figured I should
report it.

Since the "Reporting Bugs" web page requests it: gcc -v gives

     Reading specs from /packages/gcc/gcc-3.0.3/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/specs
     Configured with: ../gcc-3.0.3/configure --prefix=/packages/gcc/gcc-3.0.3
     Thread model: single
     gcc version 3.0.3

Let me know if you need any further information.

Martin
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
 	Martin Staley