[Bug c++/30822] wrong choice of overloaded template functions in recursive call

["bangerth at dealii dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #5 from bangerth at dealii dot org  2007-03-09 04:14 -------
Here's a reduced code:
-----------------
struct cons_end {};

template<typename U,typename V> struct cons {
    U elem;
    V tail;
};

template<class T,typename U, typename V>
void foo(U elem, V tail)
{
  foo<T>(tail.elem,tail.tail);
}

template<class T,typename U>
void foo(U elem, cons_end tail)
{}

int main()
{
  cons<int,cons<int,cons_end> > list;
  foo<int>(list.elem,list.tail);
}
--------------------

With gcc3.3, we get this error:

tmp/g> c++ -c x.cc
x.cc: In function `void foo(U, V) [with T = int, U = int, V = cons<int, 
   cons_end>]':
x.cc:21:   instantiated from here
x.cc:11: error: call of overloaded `foo(int&, cons_end&)' is ambiguous
x.cc:10: error: candidates are: void foo(U, V) [with T = int, U = int, V = 
   cons_end]
x.cc:16: error:                 void foo(U, cons_end) [with T = int, U = int]


On the other hand, gcc 4.1 produces this:
g/x> c++ -c x.cc
x.cc: In function 'void foo(U, V) [with T = int, U = int, V = cons_end]':
x.cc:11:   instantiated from 'void foo(U, V) [with T = int, U = int, V =
cons<int, cons_end>]'
x.cc:21:   instantiated from here
x.cc:11: error: 'struct cons_end' has no member named 'elem'
x.cc:11: error: 'struct cons_end' has no member named 'tail'


Finally, icc gives me this:
tmp/g> icc -c x.cc
x.cc(21): warning #592: variable "list" is used before its value is set
    foo<int>(list.elem,list.tail);
             ^

x.cc(11): error: more than one instance of overloaded function "foo" matches
the argument list:
            function template "foo<T,U,V>(U, V)"
            function template "foo<T,U>(U, cons_end)"
            argument types are: (int, cons_end)
    foo<T>(tail.elem,tail.tail);
    ^
          detected during instantiation of "void foo<T,U,V>(U, V) [with T=int,
U=int, V=cons<int, cons_end>]" 

compilation aborted for x.cc (code 2)


So, the way I read this is that gcc3.3 and icc9.0 agree that the call is
ambiguous. I must admit that I don't know whether this is the correct
behavior.

On the other hand, gcc4.1 appears to not find an ambiguity, then goes on to
unconditionally call the first function and there hits onto a problem.

W.


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at dealii dot org


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