This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH: PR3637
- From: Peter Schmid <schmid at snake dot iap dot physik dot tu-darmstadt dot de>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 28 Nov 2001 00:45:59 +0100 (CET)
- Subject: 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