Re: [egcs-2.92.07 19980914] Bug with STL list template instantiation.

[Alexandre Oliva <oliva at dcc dot unicamp dot br>]

Hyman Rosen <hymie@prolifics.com> writes:

> A new bug has appeared in the latest snapshot. The following code

> #include <list>
> class a { int x, y; public: a(int x, int y) : x(x), y(y) { } };
> int main() { list< a > b; b.push_back(a(1,2)); }

> egcs/include/g++-2/stl_construct.h: In function `void construct<a>(class a *)':
> egcs/include/g++-2/stl_list.h:303:   instantiated from `list<a,allocator<a> >::_M_create_node()'
> egcs/include/g++-2/stl_list.h:344:   instantiated from `list<a,allocator<a> >::insert(_List_iterator<a,a &,a *>, const a &)'
> egcs/include/g++-2/stl_list.h:381:   instantiated from `list<a,allocator<a> >::push_back(const a &)'

> In the instantiation traceback, it is claimed that _M_create_node()
> is called at line 344 of stl_list.h, but that is not true.

It is not necessarily true that _M_create_note() is being called; the
point is that it is being fully specialized when only a declaration of
it should have been specialized.

Looks like overload resolution is asking for more specialization that
needed, since removing the construct invocation from _M_create_node()
causes compilation to succeed, and _M_create_note() is not present in
the produced object file, only _M_create_node(a const&) is.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil