This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ PATCH: PR3637

[Get raw message]
Dear Mr Mitchell,

first of all, thank you very much for fixing gcc 3.0.2 regressions.

After applying your patches, current gcc does compile memtemp.C without
an internal compiler error, but I am not sure if the printout of
the executable compiled by gcc 3.1 20011125 is indeed correct.

gcc version 3.1 20011125 (experimental)
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/cc1plus -v -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -W -Wall -D_GNU_SOURCE -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ memtemp100.C -D__GNUG__=3 -D__DEPRECATED -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -quiet -dumpbase memtemp100.C -W -Wall -version -o /tmp/ccWXDGh9.s
GNU CPP version 3.1 20011125 (experimental) (cpplib) (i386 Linux/ELF)
GNU C++ version 3.1 20011125 (experimental) (i686-pc-linux-gnu)
	compiled by GNU C version 3.1 20011125 (experimental).
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include/g++-v3
 /usr/local/include/g++-v3/i686-pc-linux-gnu
 /usr/local/include/g++-v3/backward
 /usr/local/include
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/include
 /usr/include
End of search list.
 as -V -Qy -o /tmp/cclpDVyU.o /tmp/ccWXDGh9.s
GNU assembler version 2.11.90.0.29 (i486-suse-linux) using BFD version 2.11.90.0.29
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/collect2 -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o memtemp100 /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/crtbegin.o -L/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1 -L/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/../../.. /tmp/cclpDVyU.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/crtend.o /usr/lib/crtn.o

Running memtemp100 prints

./memtemp100
void foo() [with _T = int]
c1<_T>::c2<_U>::c2() [with _U = void, _T = int]

I believe the type of _T in the second line should read _T = long int.

In order to understand my point of view consider the following source
code recursivetemplate2.C (cf. PR c++/3638) which only differs by a
second call of c1<traits<int>::next>::c2<void>() outside of a member
function from memtemp100.C. 

recursivetemplate2.C
#include <iostream>

using namespace std;

template <class _T> struct traits
{
	typedef long next;
};


template <class _T>
	struct c1
	{
		c1()
		{
			cout << __PRETTY_FUNCTION__ << endl;
		}

		template <class _U>
			struct c2
			{
				c1 c;
			};
	};


template <class _T>
	void foo()
	{
		cout << __PRETTY_FUNCTION__ << endl;
		c1<typename traits<_T>::next>::c2<void>();
	}


int main()
{
	foo<int>();
	c1<traits<int>::next>::c2<void>();
}

Running recursivetemple2 has the output:

./recursivetemplate2
void foo() [with _T = int]
c1<_T>::c1() [with _T = int]
c1<_T>::c1() [with _T = long int]


I thought that both final lines should read c1<_T>::c1() [with _T =
long int]. Does it make a difference if this function is called inside
or outside of a member function? I do not think so.

I apologise if I am wrong.

Once again thanks.

Peter Schmid



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]