A problems with templates

[Topi Maenpaa]

Hi,

Lately, I have been having some very nasty problems with templates and
gcc. This far I have been able to work around some bugs by changing the
order of template definitions, but this one seems not to be affected by
anything... Well, let's have some code first:

---------------8<---- Test11.cc ----8<------------------

#include <iostream>

template <class T> class Test
{
public:
	Test() { contents = new T[256]; }
	~Test() { delete contents; }
	template <class U> Test(const Test<U>& other);

	Test foo(void);

	template <class U> Test& operator= (const Test<U>& other);
	template <class U> friend ostream& operator << (ostream& out, Test<U>&
test);
	
private:
	template <class U> void copy(const Test<U>& other);
	T* contents;
};

template <class T>
template <class U> Test<T>::Test(const Test<U>& other)
{
	contents = NULL;
	copy(other);
}

template <class T>
template <class U> Test<T>& Test<T>::operator= (const Test<U>& other)
{
	copy(other);
	return *this;
}

template <class T>
template <class U> void Test<T>::copy(const Test<U>& other)
{
	T* tmp = new T[256];
	for (int i=0;i<256;i++)
		tmp[i] = T(other.contents[i]);
	delete contents;
	contents = tmp;
}

template <class T> ostream& operator << (ostream& out, Test<T>& test)
{
	out << (int)test.contents << endl;
	return out;
}


template <class T> Test<T> Test<T>::foo(void)
{
	Test<T> result;
	return result;
}


int main(void)
{
	Test<int> tests[4], test;
	for (int i=0;i<4;i++)
		tests[i] = test.foo();
	for (int i=0;i<4;i++)
		cerr << tests[i];
}

---------------8<-------------------8<------------------

In the application I encountered this bug, "Test" is a matrix class. I
want it to be assignable from any matrix type, hence the template copy
constructor and assignment operator. The program works fine if I provide
the classical copy constructor - assignment operator pair (i.e. no
templates). (Actually, to demonstrate the problem, only the copy
constructor is needed.) For some reason, the template copy constructor
(or any other constructor) is not called before "result" is deleted in
Test:foo(void). For this reason, the "contents" of each of the four Test
objects in "main" point to the same memory location. This results in ...
well, you know what this kind of thing can result in. I have been
tracking this bug for a week more or less full-time and I have to say my
blood pressure has never been this high. I hope this really is a
compiler bug so that I don't have to blame myself :) You should see what
happens when I run my program with gdb. I don't know whether DDD (my
front end) also has bugs, but the execution order of the instructions
seems to be fairly random after the first memory allocation error. Good
luck in correcting this.


$ g++ -v -save-temps -o test11 Test11.cc
Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs
gcc version 2.95.2 19991024 (release)
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/cpp -lang-c++ -v
-D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -Dsparc
-Dsun -Dunix -D__svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__
-D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix -Asystem(unix)
-Asystem(svr4) -D__EXCEPTIONS -D__GCC_NEW_VARARGS__ -Acpu(sparc)
-Amachine(sparc) Test11.cc Test11.ii
GNU CPP version 2.95.2 19991024 (release) (sparc)
#include "..." search starts here:
#include <...> search starts here:

/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/../../../../include/g++-3
 /usr/local/include

/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/../../../../sparc-sun-solaris2.7/include
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/include
 /usr/include
End of search list.
The following default directories have been omitted from the search
path:
End of omitted list.
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/cc1plus Test11.ii
-quiet -dumpbase Test11.cc -version -o Test11.s
GNU C++ version 2.95.2 19991024 (release) (sparc-sun-solaris2.7)
compiled by GNU C version 2.95.1 19990816 (release).
 /usr/ccs/bin/as -V -Qy -s -o Test11.o Test11.s
/usr/ccs/bin/as: Sun WorkShop 6 99/08/18
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/collect2 -V -Y
P,/usr/ccs/lib:/usr/lib -Qy -o test11
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crt1.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crti.o
/usr/ccs/lib/values-Xa.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crtbegin.o
-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2 -L/usr/ccs/bin
-L/usr/ccs/lib -L/usr/local/lib Test11.o -lstdc++ -lm -lgcc -lc -lgcc
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crtend.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crtn.o
ld: Software Generation Utilities - Solaris-ELF (4.0)

-Topi-
 << http://ee.oulu.fi/~topiolli >>
Test11.ii.bz2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Test11.ii.bz2
Type: application/x-bzip2
Size: 5796 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-bugs/attachments/20001101/01cf47c7/attachment.bz2>