Template bug

Template bug

[Sebastian Rittau]

If compiled with "c++ -v --save-temps -g -c egcs.cc" the following code
yields an internal compiler error. The "-g" switch seems important -
without it, there is no error.

-------------------------------------egcs.cc--------------------------

class MapSet {
public:
  template <class T>
  class Piece {
  public:
    Piece();

  private:
    T t;
  };
};


MapSet::Piece::Piece() {}

-----------------------------------egcs.ii-----------------------------

# 1 "egcs.cc"
class MapSet {
public:
  template <class T>
  class Piece {
  public:
    Piece();

  private:
    T t;
  };
};


MapSet::Piece::Piece() {}

-----------------------------Output from command-----------------------

Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release)
 /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=91 -D__ELF__ -Dunix -Di386 -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(posix) -D__EXCEPTIONS -g -Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di486 -D__i486 -D__i486__ egcs.cc egcs.ii
GNU CPP version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/g++-2
 /usr/local/include
 /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/include
 /usr/include
End of search list.
 /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/cc1plus egcs.ii -quiet -dumpbase egcs.cc -g -version -o egcs.s
GNU C++ version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release) (i486-linux) compiled by GNU C version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release).
egcs.cc: In method `MapSet::Piece<T>::Piece()':
egcs.cc:14: Internal compiler error.
egcs.cc:14: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
egcs.cc:14: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.

Re: Template bug

[Martin v. Loewis]

> If compiled with "c++ -v --save-temps -g -c egcs.cc" the following code
> yields an internal compiler error. The "-g" switch seems important -
> without it, there is no error.

Thanks for your bug report. The mainline compiler (2.96 20000223
(experimental)) compiles this without problems, so it appears the bug
has been fixed.

Regards,
Martin

Re: template bug

[Martin v. Loewis]

> g++ should be able to resolve the call to the overloaded function:

Thanks for your bug report. This is not a bug in the compiler, but in
your code. Both candidates are viable, they require the same
conversion sequences on arguments, and neither is as specialized as
the other.

If you question this line of reasoning, please discuss it in one of
the public C++ fora first, eg. comp.lang.c++.moderated, or
comp.std.c++.

Regards,
Martin
>From ovi@physics.utoronto.ca Wed Apr 19 14:16:00 2000
From: Ovidiu Toader <ovi@physics.utoronto.ca>
To: gcc-bugs@gcc.gnu.org
Subject: gcc-2_95-branch bootstrap failure
Date: Wed, 19 Apr 2000 14:16:00 -0000
Message-id: <38FE21DB.2A8CF751@physics.utoronto.ca>
X-SW-Source: 2000-04/msg00544.html
Content-length: 1791

phoenix:lang/gcc/egcs.rls> uname -a
Linux phoenix.physics.utoronto.ca 2.2.14 #5 Mon Feb 7 18:45:19 EST 2000
alpha unknown
phoenix:lang/gcc/egcs.rls> gmake CFLAGS='-O2' LIBCFLAGS='-g -O2'
LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap-lean
...
...
cp stdlist tlist
if [ x"yes" = xyes ]; then \
  sed 's,\([A-Za-z_]*\.o\),pic/\1,g' tlist > tlist2 ; \
  mv tlist2 tlist ; \
else true ; fi
mv tlist piclist
/usr/local/Packages/lang/gcc/egcs.rls/objects/gcc/xgcc
-B/usr/local/Packages/lang/gcc/egcs.rls/objects/gcc/
-B/usr/local/Packages/lang/gcc/egcs.rls/install/alph
aev6-unknown-linux-gnu/bin/ -g -O2 -fvtable-thunks -D_GNU_SOURCE
-fno-implicit-templates -Wl,-soname,libstdc++-libc6.1-2.so.3 -shared -o
libstdc++-3-libc6.1-2-2.10.0.so `cat piclist` -lm
../libio/pic/strstream.o: In function `iostream::iostream(int)':
/usr/local/Packages/lang/gcc/egcs.rls/objects/alphaev6-unknown-linux-gnu/libio/../../../egcs/libio/strstream.h:83:
multiple definition of`iostream::iostream(int)'
../libio/pic/fstream.o(.text+0x0):/usr/local/Packages/lang/gcc/egcs.rls/objects/alphaev6-unknown-linux-gnu/libio/../../../egcs/libio/fstream.cc:
first defined here
../libio/pic/pfstream.o: In function `ofstream::ofstream(int)':
/usr/local/Packages/lang/gcc/egcs.rls/objects/alphaev6-unknown-linux-gnu/libio/../../../egcs/libio/pfstream.cc:74:
multiple definition of
`ofstream::ofstream(int)'../libio/pic/PlotFile.o(.text+0x0):/usr/local/Packages/lang/gcc/egcs.rls/objects/alphaev6-unknown-linux-gnu/libio/../../../egcs/libio/PlotFile.cc:
first defined here
collect2: ld returned 1 exit status
gmake[1]: *** [libstdc++-3-libc6.1-2-2.10.0.so] Error 1
gmake[1]: Leaving directory
`/usr/local/Packages/lang/gcc/egcs.rls/objects/alphaev6-unknown-linux-gnu/libstdc++'
gmake: *** [all-target-libstdc++] Error 2
>From rolly@free.fr Wed Apr 19 14:18:00 2000
From: Arnaud Rolly <rolly@free.fr>
To: gcc-bugs@gcc.gnu.org
Subject: GCC Bug ?
Date: Wed, 19 Apr 2000 14:18:00 -0000
Message-id: <00041922441000.01083@localhost.localdomain>
X-SW-Source: 2000-04/msg00545.html
Content-length: 521

I've a problem with gcc :

[root@localhost audio]# g++ -c sound.cpp
sound.cpp:20: Internal compiler error.
sound.cpp:20: Please submit a full bug report.
sound.cpp:20: See <URL: http://www.gnu.org/software/gcc/faq.html#bugreport > for instructions.
[root@localhost audio]# g++ -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release) 

I've the Mandrake 7.0.

The 'problematic files' are attached to the mail.

Please keep me informed.

-- 
Arnaud Rolly
rolly@free.fr
>From martin@loewis.home.cs.tu-berlin.de Wed Apr 19 14:53:00 2000
From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
To: laufreeman@hotmail.com
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: Help me ,nested template!!!!!!!!!!!!!!!
Date: Wed, 19 Apr 2000 14:53:00 -0000
Message-id: <200004192147.XAA01514@loewis.home.cs.tu-berlin.de>
References: <20000414130908.87654.qmail@hotmail.com>
X-SW-Source: 2000-04/msg00546.html
Content-length: 1103

> I defined a template class Poly in poly.h
> template <class T,class S>
> class Poly{
>         .
>         .
>         .
>         .
> //and a friend function
> 
> friend Poly<T,S>  operator* <>(const T &c,const Poly<T,S> &pl) ;
> };

I guess you also have an operator* in that function. In standard C++,
you should now write

 friend Poly<T,S>  ::operator* <>(const T &c,const Poly<T,S> &pl) ;

because operator* probably refers to the other operator* in the class,
not to the global function.

> but I used g++2.905 and succeeded,what should I do?

A number of things. First, please try to get familiar with the bug
reporting instructions, as summarized in

http://www.gnu.org/software/gcc/bugs.html

Also, have a look at the section "Reporting Bugs". If you really want
to report a bug, you must include all details.

If you want to get your code working, I recommend removing the friend
declaration, and arranging the members that this operator needs to
access to be public members. Alternatively, you could also introduce a
helper friend function which is not called operator*.

Regards,
Martin

Template bug

[Daniel Oram]

Hullo,

 I thought you might like to know about this bug in the template handling
code thats been giving me some trouble. In case its of any use, you might as
well know that swapping the order in which the functions test1 and test2 are
declared fixes the problem. As well as being in the latest snapshot I've
got, this bug is also in gcc release 2.95.1.

----
Command line args. used to compile it:

/usr/local/gcc/bin/g++ -v -c main.cc -o main.o
Reading specs from /usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.96/specs
gcc version 2.96 19991004 (experimental)

/usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.96/cpp -lang-c++ -v -D__GNUC_
_=2 -D__GNUG__=2 -D__GNUC_MINOR__=96 -D__cplusplus -D__ELF__ -Dunix -D__i386
__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -A
system(posix) -D__EXCEPTIONS -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D_
_i386__ -D__tune_pentiumpro__ main.cc main.ii
GNU CPP version 2.96 19991004 (experimental) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.96/../../../../include/g++-3
 /usr/local/gcc/include

/usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.96/../../../../i686-pc-linux-
gnu/include
 /usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.96/include
 /usr/include
End of search list.
The following default directories have been omitted from the search path:
End of omitted list.
 /usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.96/cc1plus
main.ii -quiet -dumpbase main.cc -version -o main.s
GNU C++ version 2.96 19991004 (experimental) (i686-pc-linux-gnu) compiled by
GNU C version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release).
main.cc:11: warning: all member functions in class `Test' are private
main.cc:11: Tree check: expected field_decl, have type_decl
main.cc:11: Internal compiler error in `finish_struct_1', at
../egcs-19991004/gcc/cp/class.c:3864
Please submit a full bug report.

----
Machine details: Celeron with Redhat Linux 6.0

----
gcc configure
commands: --prefix=/usr/local/gcc --enable-languages=c++ --with-gnu-as --ena
ble-checking

----
File main.ii: Nice simple test case to trigger the error:

# 1 "main.cc"
class Test {

  void test1(void) {
    test2(2.0);
  }

  template <class TestT>
  void test2(TestT v) {
  }

};

int main() {
  return 0;
}

Re: Template bug

[Martin v. Loewis]

>  I thought you might like to know about this bug in the template handling
> code thats been giving me some trouble. In case its of any use, you might as
> well know that swapping the order in which the functions test1 and test2 are
> declared fixes the problem. As well as being in the latest snapshot I've
> got, this bug is also in gcc release 2.95.1.

Although I can reproduce this with 2.95.1, gcc version 2.96 19991008
compiles this fine. So it seems to be fixed.

Regards,
Martin

template bug

[Arturo Montes]

Hi

I found a bug using templates.

If you compile the program with -DNO program compile OK, but if -DNO is
omitted you get the following bug:

bugs1.cpp: In function `static class Datum * X<Datum,Mutex>::instance()':
bugs1.cpp:94:   instantiated from here
bugs1.cpp:80: initializing non-const `Mutex *&' with `TMUTEX *' will use a
temporary
bugs1.cpp:43: in passing argument 1 of `get_singleton_lock(Mutex *&)'

Thanks

Arturo



begin 666 bugs1.cpp
M(VEN8VQU9&4@/'-T9&EO+F@^"@IC;&%S<R!$871U;0I["G!U8FQI8SH*(" @
M;&]N9R!L7SL*(" @1&%T=6TH*3L*?3L*"D1A='5M.CI$871U;2@I"B @.B!L
M7R@Q*0H*>PI]"@IC;&%S<R!-=71E> I["G!U8FQI8SH*(" @375T97@H*3L*
M(" @=F]I9"!A8W%U:7)E*"D["B @('9O:60@<F5L96%S92@I.PI].PH*375T
M97@Z.DUU=&5X*"D*"GL*?0H*=F]I9"!-=71E>#HZ86-Q=6ER92@I"@I["B @
M('!R:6YT9B@B86-Q=6ER95QN(BD["GT*"G9O:60@375T97@Z.G)E;&5A<V4H
M*0H*>PH@("!P<FEN=&8H(G)E;&5A<V5<;B(I.PI]"@II;G0@9V5T7W-I;F=L
M971O;E]L;V-K*$UU=&5X*B8@;&]C:RD*"GL*(" @<W1A=&EC($UU=&5X*B!L
M;V-K7R ](# ["B @(&EF("AL;V-K7ST],"D*(" @(&QO8VM?(#T@;F5W($UU
M=&5X*"D["B @(&QO8VL@/2!L;V-K7SL*(" @<F5T=7)N(# ["GT*"B-I9F1E
M9B!.3PHC9&5F:6YE(%1-551%6"!-=71E> HC96QS90IT>7!E9&5F($UU=&5X
M(%1-551%6#L*(V5N9&EF"@IT96UP;&%T92 \8VQA<W,@>C$L8VQA<W,@>C(^
M"F-L87-S(%@*>PH@('HQ('HQ7SL*<'5B;&EC.@H@("!8*"D["B @<W1A=&EC
M('HQ*B!I;G-T86YC92@I.PI].PH*=&5M<&QA=&4@/&-L87-S('HQ+&-L87-S
M('HR/@I8/'HQ+'HR/CHZ6"@I"@I["GT*"G1E;7!L871E(#QC;&%S<R!Z,2QC
M;&%S<R!Z,CX*>C$J(%@\>C$L>C(^.CII;G-T86YC92@I"@I["B @('-T871I
M8R!8*B!I;G-T86YC95\@/2 P.PH@("!I9B H:6YS=&%N8V5?/3TP*0H@(" @
M>PH@(" @("!S=&%T:6,@>C(J(&QO8VL@/2 P.PH@(" @("!G971?<VEN9VQE
M=&]N7VQO8VLH;&]C:RD["B @(" @(&QO8VLM/F%C<75I<F4H*3L*(" @(" @
M:68@*&EN<W1A;F-E7ST],"D*(" @(" @(&EN<W1A;F-E7R ](&YE=R!8*"D[
M"B @(" @(&QO8VLM/G)E;&5A<V4H*3L*(" @('T*(" @<F5T=7)N("9I;G-T
M86YC95\M/GHQ7SL*?0H*='EP961E9B!8/$1A='5M+%1-551%6#X@>3L*"FEN
M="!M86EN*&EN="!A<F=C+"!C:&%R*B!A<F=V6UTI"@I["B @<')I;G1F*")X
>/25L9%QN(BQY.CII;G-T86YC92@I+3YL7RD["GT*
`
end

Re: Template bug

[Alexandre Oliva]

On Jan 19, 1999, Richard Heller <rheller@prime.cs.ohiou.edu> wrote:

> friend ostream& operator<< (ostream&,list<T>&);

> the compiler gave a warning that I must have <> after the funtion
> name.

http://egcs.cygnus.com/faq.html#friend

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Template bug

[Richard Heller]

Hey,

  I was attempting to make a template class and wanted to overload the <<
operator.  In the class declaration, I had

template<class T>
class list{
  ...
  friend ostream& operator<< <T>(ostream&,list<T>&);
  ...
};

If I declared the operator<< line as

friend ostream& operator<< (ostream&,list<T>&);

the compiler gave a warning that I must have <> after the funtion name.  I
took this to mean that I needed to put <T> so that it would be treated as
a template instantiation, so I changed it to

friend ostream& operator<< <T>(ostream&,list<T>&);

In the declaration part of the code, I had

template<class T> ostream& operator<<(ostream& s,list<T>& l){
...
}

In this case, when I compiled I got an error that there was no match for
`_IO_ostream_withassign & << list<int> &' (I used list<int> for my
instantiation).  Anyway, I realized that I had left out the <T> after the
function name, so I changed it to

template<class T> ostream& operator<< <T>(ostream& s,list<T>& l){
...
}

When I tried to compile this, I got

list.C:163: Internal compiler error.
list.C:163: Please submit a full bug report to `egcs-bugs@cygnus.com'.

So that's what I'm doing.

Thanks,
Rich

template bug.

[Oskar Enoksson]

I have a problem with accessing a template class member of a partially
specialized template class, although I must admit I'm not 100% sure
that the code is 100% ANSI legal (please tell me!)

The problem occurs with snapshot 980921 aswell as 980914, but not
egcs 1.1. My platform is Digital Alpha ev56 OSF 4.0. The native OSF4.0
compiler cxx also accepts the code.

///// Error example tst.cc

template<int N, class T>
class A;

template<int N>
class A<N,int> {
public:
  template<int K>
  class B {
  public:
  };
};

main() {
  A<1,int>::B<1> x;
}

///// End of tst.cc

Compilation results follow:

> snapshot-980921/bin/gcc -c tst.cc

tst.cc: In function `int main()':
tst.cc:15: wrong number of template arguments (2, should be 1)
tst.cc:8: provided for `template <int const N> template <int const K>
A<N,int>::B<K>'
tst.cc:15: confused by earlier errors, bailing out

Also, if I change the declaration in main to

15c15
<   A<1,int>::B<1> x;
---
>   A<1,int>::template B<1> x;

the compiler responds

tst.cc: In function `int main()':
tst.cc:15: Internal compiler error.
tst.cc:15: Please submit a full bug report to `egcs-bugs@cygnus.com'.

Regards
/Oskar

Re: Template bug

[Ian Haggard]

Actually, it's easy in practice to force a template parameter to obey fairly
arbitrary constraints, including that a template parameter is derived from some
class.  For example:

class A {}; class B: public A {};
template<class T>
class foo {
  static void verifyderivation() { T* t=0; A* a=t; }
public:
#if CTOR_VERIFY
  foo() { verifyderivation(); }
  foo(const foo&) { verifyderivation(); }
#endif
#if DTOR_VERIFY
  ~foo() { verifyderivation(); }
#endif
};

main() {
  foo<A> fa;
  foo<B> fb;
  foo<int> fi;
}

The way this works is simple -- in order to actually use almost any class, one
of the constructors has to be called somewhere, by someone.  So if you just
insert a call to the verification function into all constructors, then you'll
get an error message whenever someone attempts to construct an object.  The
lazy man's way to perform verification is just to put it into the destructor. 
While it's only slightly less certain that the destructor of a class will be
used, it's a lot simpler than remembering to add a verifyderivation() call
whenever you add a new constructor.  The one added complication is that if you
have public static members or friend functions that are useful even when there
hasn't been a class object created, then you'll need to add a
verifyderivation() call to each them, also.
-- 
Ian Haggard  ||  ian@shellus.com (work)  ||  IanHaggard@juno.com (home)
GNU/Linux -- "Oh, no, Mr Bill!" || #define employer_opinion !my_opinion

Template bug

[Theron Lewis]

I have attached a file that produces an internal compiler error when I try
to compile it.  This really isn't an inconvenience for me, but I thought
I'd send this to you FYI: 

[theron@zippy theron]$ uname -a
Linux zippy 2.0.33 #5 Wed Apr 22 23:41:30 PDT 1998 i586 unknown

[theron@zippy theron]$ g++ -v 
Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.90.27/specs
gcc version egcs-2.90.27 980315 (egcs-1.0.2 release)

[theron@zippy theron]$ g++ goober.cc 
goober.cc:20: Internal compiler error.
goober.cc:20: Please submit a full bug report to `egcs-bugs@cygnus.com'.

If you need any further information, please email me at
theron@cs.ucsb.edu.  Hope this helps you out. 

-Theron

template bug

[Mark van Doesburg]

If compiling the attached program the compiler gives the message:

vector-bug.cpp: In function `int main()':
vector-bug.cpp:126: Internal compiler error.
vector-bug.cpp:126: Please submit a full bug report to `egcs-bugs@cygnus.com'.

If I change the functions for recurse to use a reference instead of a
value it compiles without errors (I've not yet checked if the code is
correct)

I'm using egcs-1.0.1 for the strongarm with the options:

gcc -barm-bare-aout -Vegcs-2.90.23 -mcpu=strongarm110 -msoft-float -O3 -funroll-loops

I am not on any egcs mailing list, for questions or comments please mail 
me directly.

- Mark van Doesburg.

------------------------------------------------------------------------
template<class T,int S> 
class vector {
	T c[S];
public: 
	vector() {} 

	T &operator[](int i) { return c[i]; }
	vector<T,S> &operator=(vector<T,S> &o);
	T operator*(vector<T,S> &o);
};

template<class T,int S> 
inline vector<T,S> &vector<T,S>::operator=(vector<T,S> &o)
{
	for(int i=0;i<S;i++) 
		c[i]=o.c[i]; 
	return *this; 
}

template<class T,int S> 
inline T vector<T,S>::operator*(vector<T,S> &o)
{
	T t=c[0]*o.c[0];
	for(int i=1;i<S;i++)
		t+=c[i]*o.c[i];
	return t;
}

template<class T,int S> 
class matrix {
	vector<T,S> r[S];
public:
	matrix() {}

	vector<T,S> &operator[](int i) { return r[i]; }
	vector<T,S> operator*(vector<T,S>&);
	matrix<T,S> operator*(matrix<T,S>&);
	matrix<T,S> &operator=(matrix<T,S>&);

	vector<T,S> col(int);
};

template<class T,int S>
inline vector<T,S> matrix<T,S>::operator*(vector<T,S> &o)
{
	vector<T,S> t;
	for(int i=0;i<S;i++)
		t[i]=r[i]*o;
	return t;
}

template<class T,int S>
inline matrix<T,S> matrix<T,S>::operator*(matrix<T,S> &o)
{
	matrix<T,S> t;
	for(int i=0;i<S;i++)
		for(int j=0;j<S;j++)
			t[i][j]=r[i]*o.col(j);
	return t;
}

template<class T,int S>
inline matrix<T,S> &matrix<T,S>::operator=(matrix<T,S> &o)
{
	for(int i=0;i<S;i++)
		r[i]=o.r[i];
	return *this;
}

template<class T,int S>
inline vector<T,S> matrix<T,S>::col(int i)
{
	vector<T,S> t;
	for(int j=0;j<S;j++)
		t[j]=r[j][i];
	return t;
}

template<class T>
inline T recurse(matrix<T,1> m)
{
	return m[0][0];
}

template<class T,int S>
inline T recurse(matrix<T,S> m)
{
	matrix<T,S-1> t;
	return det(t);
}

template<class T,int S>
inline T det(matrix<T,S> m)
{
	if(S>0)
		return recurse(m);
	else
		return 1;
}

template<class T,int S>
inline vector<T,S> prod(matrix<T,S> m)
{
	for(int i=0;i<S;i++)
		m[0][i]=0;
	vector<T,S> t;
	for(int i=0;i<S;i++) { 
		m[0][i]=1;
		t[i]=det(m);
		m[0][i]=0;
	}
}

extern int nonsense(int); 

main()
{
	vector<int,3> c;
	c[0]=3; c[1]=4; c[3]=5;
	vector<int,3> d;
	d[0]=6; d[1]=4; d[3]=33;
	matrix<int,3> m;
	m[1]=c;
	m[2]=d;
	prod(m); 
}

Template bug

[Mark Mitchell]

>>>>> "Konstantin" == Konstantin Baumann <kostab@ESCHER.UNI-MUENSTER.DE> writes:

    Konstantin> template<unsigned long SIZE> struct Array { };

    Konstantin> template<unsigned long SIZE> Array<SIZE + 1>
    Konstantin> test_error(const Array<SIZE>& a) { Array<SIZE + 1>
    Konstantin> result; return(result); }

    Konstantin> int main(int argc, char* argv[]) { Array<2> a;

    Konstantin>     test_ok(a); test_error(a); // <<< MARKED LINE!

    Konstantin>     return(0); }

I've figured out what's happening here, but not how to fix it.  The
C++ standard says that the signature of a function template consists
of its function signature, its return type, and its template parameter
list.  And, the signature of a function template specialization
consists of the signature of the function template and the actual
template arguments.  So, we (sort-of correctly) try to put Array<SIZE
+ 1> into the mangled name, only that we don't have a way of mangling
that.  Jason, do we have a conceptual bug in the name-mangling scheme,
or should I just try to concoct a way of mangling arbitrary
expressions and have build_overload_int do that in cases like these?

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

Template bug

[Konstantin Baumann]

Compiling the following program gives me an assembler-error (error-ouput
below). If I omit the marked line everything compiles fine.

==========testit.cc=====================================================

template<unsigned long SIZE>
struct Array { };

template<unsigned long SIZE>
Array<SIZE> test_ok(const Array<SIZE>& a) {
    Array<SIZE> result;
    return(result);
}

template<unsigned long SIZE>
Array<SIZE + 1> test_error(const Array<SIZE>& a) {
    Array<SIZE + 1> result;
    return(result);
}

int main(int argc, char* argv[]) {
    Array<2> a;

    test_ok(a);
    test_error(a); // <<< MARKED LINE!

    return(0);
}

========================================================================

[wotan] /tmp $ egcs-g++ -v -Wall testit.cc -o testit
Reading specs from
/u/kostab/packages/egcs-1.0/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.90.21/specs
gcc version egcs-2.90.21 971202 (egcs-1.00 release)

/u/kostab/packages/egcs-1.0/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.90.21/cpp
-lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus
-D__GNUC_MINOR__=90 -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 -Wall -D__GCC_NEW_VARARGS__
-Acpu(sparc) -Amachine(sparc) testit.cc /tmp/cca002Rp.ii
GNU CPP version egcs-2.90.21 971202 (egcs-1.00 release) (sparc)
#include "..." search starts here:
#include <...> search starts here:
 /u/kostab/packages/egcs-1.0/include/g++
 /usr/local/include
 /u/kostab/packages/egcs-1.0/sparc-sun-solaris2.5.1/include

/u/kostab/packages/egcs-1.0/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.90.21/include
 /usr/include
End of search list.

/u/kostab/packages/egcs-1.0/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.90.21/cc1plus
/tmp/cca002Rp.ii -quiet -dumpbase testit.cc -Wall -version -o
/tmp/cca002Rp.s
GNU C++ version egcs-2.90.21 971202 (egcs-1.00 release)
(sparc-sun-solaris2.5.1) compiled by GNU C version egcs-2.90.21 971202
(egcs-1.00 release).
 /usr/ccs/bin/as -V -Qy -s -o /tmp/cca002Rp1.o /tmp/cca002Rp.s
/usr/ccs/bin/as: SC4.2 dev 30 Nov 1995
/usr/ccs/bin/as: "/tmp/cca002Rp.s", line 72: error: invalid operand
/usr/ccs/bin/as: "/tmp/cca002Rp.s", line 73: error: statement syntax
/usr/ccs/bin/as: "/tmp/cca002Rp.s", line 75: error: unknown opcode
"test_error__H1Ul2_RCt5Array1UlY01_t5Array1Ul"
/usr/ccs/bin/as: "/tmp/cca002Rp.s", line 75: error: statement syntax
/usr/ccs/bin/as: "/tmp/cca002Rp.s", line 93: error: statement syntax
/usr/ccs/bin/as: "/tmp/cca002Rp.s", line 31: error: expression must
evaluate to a nonrelocatable (absolute) value

-- 
Konstantin Baumann                   Westfaelische Wilhelms-Universitaet 
Institut fuer Informatik (Zi. 603),  Einsteinstr. 62,   D-48149 Muenster
mailto:kostab@math.uni-muenster.de                  Tel:+49-251-83-32701
http://wwwmath.uni-muenster.de/cs/u/kostab/         Fax:+49-251-83-33755