HDTenEightyP/NetNews huggingface dataset:
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  template syntax
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 14:53:11 GMT

This problem should not exist in the next release of gcc.

g++ was wrong, hum, I mean is wrong. AT&T is correct.  My g++ compiles
it just fine.  :-)

> Date: Tue, 28 Jul 92 17:35:49 EDT
> From: nguyen@sol.crd.ge.com
> Message-Id: <9207282135.AA11012@etamin.crd.Ge.Com>
> Reply-To: nguyen@sol.crd.ge.com

> <..> should be specified in all functions inside a class header,
> except constructor and destructor. ARM p.350.

> The following code compiles with AT&T but not with GNU g++2.0
> (gcc-2.2.2). Who is wrong?

> ----------------------------
> #include <iostream.h>


> template<class T1, class T2>
> class foo{
> public:
>   T1 value1;
>   T2 value2;
>   foo(T1 a, T2 b) { value1 = a; value2 = b;}
>   void bar(foo<T1,T2>& t) { value1 = t.value1; value2 = t.value2;} //********
>   void print() { cout << value1 << " " << value2 << endl;}
> };



> main()
> {
>   foo<int, int> fi(10, 0), fii(0, 5);
>   foo<float, int> ff(5.0, 0);
>   foo<char, int> fc('c', 1);


>   fi.print();
>   fii.print();
>   fii.bar(fi);
>   fii.print();
>   ff.print();
>   fc.print();
>   
>   cout << "hello" << endl;
> }
> ---------------------------
> % /home/thuban/software3/gnu/bin/g++ -I /home/thuban/software3/gnu/lib/g++-incl
> ude gnu_template.C
> gnu_template.C:10: parse error before `,'
> gnu_template.C:10: parse error before `,'
> gnu_template.C:10: parse error before `,'
> gnu_template.C: In method `void  foo<char ,int>::bar (...)':
> gnu_template.C:10: `t' undeclared (first use this function)
> gnu_template.C:10: (Each undeclared identifier is reported only once
> gnu_template.C:10: for each function it appears in.)
> gnu_template.C: In method `void  foo<float ,int>::bar (...)':
> gnu_template.C:10: `t' undeclared (first use this function)
> gnu_template.C: In method `void  foo<int ,int>::bar (...)':
> gnu_template.C:10: `t' undeclared (first use this function)
> -------------

Newsgroups: gnu.g++.bug
From: chip@tct.COM (Chip Salzenberg)
Subject: Re: new int[0]
Organization: TC Telemanagement, Clearwater, FL
Distribution: gnu
Date: Thu, 3 Sep 1992 15:36:00 GMT

According to basti@orthogo.UUCP:
>I just reinstalled gcc-2.2.2 on our RS6000 (configured rs6000-ibm-aix) and
>stumbled again over this damn bug within __builtin_new of libgcc2.c:
>Allocating e.g., new int[0], fires the new_handler!

You're fixing the wrong thing.  Instead of allowing malloc() to return
NULL without complaint, you should say "p = malloc (sz ? sz : 1)".
-- 
Chip Salzenberg at Teltronics/TCT  <chip@tct.com>, <73717.366@compuserve.com>
   "Do Rush place weird subliminal backmasked messages in their songs to
 compel unwilling geeks to commit evil .sig atrocities?"  -- Dean Engelhardt

Newsgroups: gnu.g++.bug
From: solomon@cs.wisc.edu (Marvin Solomon)
Subject: Re:  g++ 2.2.2 crashes when using multiple inheritance
Organization: University of Wisconsin, Madison -- Computer Sciences Dept.
Distribution: gnu
Date: Tue, 1 Sep 1992 11:07:32 GMT

In article <9208291541.AA00156@cygnus.com> mrs@cygnus.com (Mike Stump) writes:
>cygnus bash[910] gcc -S -B./ t3.cc
>t3.cc: In function `void  g (struct A*)':
>t3.cc:15: cannot convert a pointer of type `A'
>t3.cc:15: to a pointer of type `B'
>cygnus bash[911] 
>
>is what I get now.  no dump, but I suspect it is wrong.

Yes, it is wrong. The variable ptr has type A* so ptr->f() should call A::f. 
There's absolutely no ready why the compiler should be trying to convert ptr
to a B*.  Note that if you remove the declaration of C (which is not
referenced anywhere), the problem goes away.

>
>> From: adams@cs.wisc.edu (Paul Adams)
>> Message-Id: <9208272057.AA03920@grana.cs.wisc.edu>
>> To: bug-g++@prep.ai.mit.edu
>> Date: Thu, 27 Aug 92 15:57:10 CDT
>
>> Hi.  The following program causes g++ 2.2.2 to crash.  
>
>> Hierarchy:
>
>>         A       B
>>          \     /
>>           v   v
>>            \ /
>>             C
>
>> The crash occurs if either B or C (or both) are virtual base classes of C.
>> The program compiles fine if non-virtual base classes are used. 
>
>> --------------------------------------------------------------------------------
>> Script started on Thu Aug 27 15:28:22 1992
>> adams 21>cat bug2.c
>> struct A {
>> 	virtual void f();
>> }; 
>
>> struct B {
>> 	virtual void f() ;
>> }; 
>
>> struct C : virtual A , virtual B {
>> 	virtual void f();
>> };
>
>> void g(A *ptr)
>> {
>> 	ptr->f();
>> }
-- 
	Prof. Marvin Solomon
	Computer Sciences Department
	University of Wisconsin, Madison WI
	solomon@cs.wisc.edu

Newsgroups: gnu.g++.bug
From: warsaw@nlm.NIh.GOV (Barry A. Warsaw)
Subject: Re: g++ doesn't always generate symbol defs
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.
Distribution: gnu
Date: Thu, 3 Sep 1992 21:58:07 GMT

Just to support my claim that g++ botches the job by not making a
static const Foo& const member have external linkage, Steve Clamage in
comp.lang.c++ writes:

From: steve@taumet.com (Steve Clamage)
Subject: Re: External or internal linkage according to ARM?
Date: 3 Sep 92 17:40:22 GMT

warsaw@nlm.nih.gov (Barry A. Warsaw) writes:

|In the following example, should the symbol Singleton::OnlyOne have
|external linkage or internal linkage?  Cfront 2.1 say external, but
|g++ 2.2.2 gives only internal and the question of which is correct has
|come up.

|class Singleton
|{
|public:
|	static const Singleton& const OnlyOne;
|	...
|};

ARM section 9.4, first paragraph:

"Static members of a global class have external linkage."

Even without this explicit sentence, the semantics of static members
require global linkage.  (There is only one copy shared by all class
instances.)

Local classes cannot have static data members (also in 9.4) for
the same reason: there is no way to to provide a definition of
the static data member.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16

Newsgroups: gnu.g++.bug
From: marc@pxcl1.gi.rwth-aachen.de (Marc van Woerkom)
Subject: Mailing List
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 1 Sep 1992 02:23:12 GMT

Sorry if I asked this already -- I'm not sure, if I get the list --
please add me to the bug-g++ list!

Thanks & Bye, Marc


Marc van Woerkom  ******  Aachen Center for Solidification in Space  *******
ACCESS e.V., Intzestr. 5                E-Mail: marc@pxcl1.gi.rwth-aachen.de
D-5100 Aachen, Germany                          Marc_van-Woerkom@ac3.maus.de
Fax: +49 241 38578        "Trust me, I know what I'm doing!" (Sledge Hammer)


Newsgroups: gnu.g++.bug
From: keister@poincare.phys.cmu.edu (Bradley D. Keister)
Subject: executable crash under g++/Sun
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 26 Aug 1992 10:11:38 GMT

The following code crashes at runtime when built with g++/Sun.  It
runs without trouble under g++/DECstation and CC/DECstation.

#include <stdio.h>
#include <string.h>

// #include "strup.h"

void strup(char* string)
{
  for (; *string; string++)
    *string = ((*string >= 'a') && (*string <= 'z'))?
    *string-0x20: *string;
}
class A {
  
protected:
  int a;
  
public:
  A() {a=1;}
};

class B : public A {
  
protected:
  int b;
  
public:
  B() {b=1;}
};

A* choose_class(char* keyword)
{
  A* result;
  strup(keyword);
  if (strcmp(keyword, "CLASS_A") == 0)
    result = new A;
  if (strcmp(keyword, "CLASS_B") == 0)
    result = new B;
  
  return result;
}

main()
{
  A* Atest = choose_class("class_B");
  delete Atest;
  return 0;
}

Segmentation fault (core dumped)
cm5comp.psc.edu% dbx declare
Reading symbolic information...
Read 194 symbols
program terminated by signal SEGV (access to address exceeded protections)
(dbx) run
Running: declare 
signal SEGV (access to address exceeded protections) in strup__FPc at 0x22f8
strup__FPc+0x68:	stb    	%o1, [%o0]

Brad Keister
Department of Physics
Carnegie Mellon University
Pittsburgh, PA 15213
(412) 268-2772 (office)
(412) 681-0648 (FAX)

internet:	keister@poincare.phys.cmu.edu
BITNET:		keister%poincare.phys.cmu.edu@CARNEGIE

Newsgroups: gnu.g++.bug
From: basti@orthogo.UUCP (Sebastian Wangnick)
Subject: Re: new int[0]
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 4 Sep 1992 11:46:24 GMT

According to basti@orthogo.UUCP:
>I just reinstalled gcc-2.2.2 on our RS6000 (configured rs6000-ibm-aix) and
>stumbled again over this damn bug within __builtin_new of libgcc2.c:
>Allocating e.g., new int[0], fires the new_handler!

According to chip@tct.com (Chip Salzenberg):
>You're fixing the wrong thing.  Instead of allowing malloc() to return
>NULL without complaint, you should say "p = malloc (sz ? sz : 1)".

Chip, you're wrong. The ARM is quite specific in this case. On page 280
it says:
	If operator new() cannot allocate storage or if it is called
	with the argument 0 it will return 0.
and:
	If operator new() cannot find storage to return, it calls
	a function -- often referred to a the new-handler -- [...].

Calling operator new() with an argument of 0 should thus return 0 WITHOUT
calling the new-handler (which is, by the way, also the behavior of all
the other C++ compilers).

Sebastian Wangnick   Orthogon System GmbH
(basti@orthogo.uucp) Linzer Strasse 4
Tel +49 421 219136   D-2800 Bremen 33
Fax +49 421 213093   Germany

Newsgroups: gnu.g++.bug
From: lah@unh.edu (Lance A. Hartford)
Subject: 2.2.2 on RS/6000
Organization: UNH Interoperability Lab
Distribution: gnu
Date: Tue, 1 Sep 1992 18:31:04 GMT

I'm trying to compile gcc 2.2.2 on the RS/6000 running AIX 3.2.2. This
is the error that I am getting:

_muldi3
Assembler:
/tmp/ccLOsDM2.s: line 25: 1252-142 Syntax error.
make: 1254-004 The error code from the last command is 1. 

has anyone has an error like this compiling with 3.2.2? I read the
README.RS6000 file about the problem with /bin/as. Does that fix apply
to this problem? Thanks...
--
________________________________________________________________________
| Lance A. Hartford             | Computer Science Junior              |
| UNH InterOperability Lab      | Internet: lah@unh.edu                |
| University of New Hampshire   | 32 Coe Drive, Durham NH 03824        |
|----------------------------------------------------------------------|


Newsgroups: gnu.g++.bug
From: steve@maths.warwick.ac.UK (Steve Rumsby)
Subject: g++ 2.2.2 bug with extern "C" friends
Organization: Maths Institute, Warwick University, Coventry, UK.
Distribution: gnu
Date: Tue, 25 Aug 1992 13:15:51 GMT

This seems to have got lost (I haven't seen it in gnu.g++.bug) so I'm
resending it. If some people see it twice, sorry.

Steve.
------
Classes with extern "C" friend functions seem to give cc1plus gastric distress.
This happens on Sparc (SunOS 4.1.1), Sun 3 (SunOS 4.1.1), and SGI MIPS
(Irix 4.0.1) boxes, so I guess it is pretty fundamental! Any suggestions?

Thanks,
Steve.

$ cat kb.c
extern "C" int bar();

struct foo {
	friend int bar();
};
$ g++ -v kb.c
Reading specs from /gnu/lib/gcc-lib/sparc-sunos4/2.2.2/specs
gcc version 2.2.2
 /gnu/lib/gcc-lib/sparc-sunos4/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix kb.c /usr/tmp/cca00897.i
GNU CPP version 2.2.2 (sparc)
 /gnu/lib/gcc-lib/sparc-sunos4/2.2.2/cc1plus /usr/tmp/cca00897.i -quiet -dumpbase kb.cc -version -o /usr/tmp/cca00897.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
/gnu/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11
--
UUCP:	 ...!uknet!warwick!steve	Internet: steve@maths.warwick.ac.uk
JANET:	 steve@uk.ac.warwick.maths	PHONE:	 +44 203 524657

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  static member bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 14:56:22 GMT

You and hundreds of other have found this ``bug,'' the only problem
is, this is not a bug.  Please consult a recent book on c++ on how to
specify the definition for a static data member of a class.

(Hint:  Looks like int Class::Member = 4; outside the class's {})

> From: grosjean@masi.ibp.fr (Christophe GROSJEAN)
> Message-Id: <9207301247.AA01155@cao-vlsi.ibp.fr>
> To: bug-gcc@prep.ai.mit.edu
> Date: Thu, 30 Jul 92 13:44:48 BST

> I think i have found a bug with g++.  Static data members compile
> well but don't link.  It seems the job is done, except that compiler
> wont allocate space for that kind of data This problem appears with
> g++ 2.2.2 and 2.1. on SparcStation under SunOs 4.1.1.

> Below is a small sample program showing off the problem :

> ---------------------------------------------
> #include <stdio.h>

> class Bug 
> {
> 	public:
> 	static int i = 0;
> 	Bug() {	printf("%d ",i++); }
> };


> main()
> {
> 	Bug b;
> 	Bug c;
> 	Bug d;
> }
> -----------------------------------------

> (yes, I know i should use streams for I/O, but that's not the point...)

> When I compile this code (it provide a class that counts it's instances)

> I get the message :

> ld: Undefined symbol
> 	__3Bug$i

> I think it's a major problem, 'cause static members are the only clean way
> to implement shared data between every members of a class.

> Still, i've found a way (a very very dirty way...) to patch the problem
> so i can go with it.
> However, you'll understand that i'm not quite satifsfied...

> The following code will compile, link and work perfectly...

> ----------------------------------------------------
> #include <stdio.h>

> static int _3Bug$i = 0;

> class Bug 
> {
> 	public:
> 	static int i = 0;
> 	Bug() {	printf("%d ",i++); }
> };


> main()
> {
> 	Bug b;
> 	Bug c;
> 	Bug d;
> }

Newsgroups: gnu.g++.bug
From: brendan@cygnus.com (Brendan Kehoe)
Subject: gcc 2.2.2 Internal Compiler Error
Reply-To: brendan@cygnus.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 05:10:15 GMT

> When compiling the file BitSet.cc in the libg++ 2.0 distribution, I
> get the following:
> 
> gcc -I. -I./../iostream -I./../g++-include  -c BitString.cc
> gcc: Internal compiler error: program cc1plus got fatal signal 11
> 
> This does not happen with version 2.0 of gcc.

And it won't happen with the next release of gcc.  (I don't know when
that will be.)

Oh, as a point of order...you should only send g++-related problems to
bug-g++, not both bug-g++ and bug-gcc.

Brendan
--
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Support, Palo Alto, CA                                  +1 415 322 3811

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  failed assertion `current_binding_level != global_binding_level'
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 02:32:42 GMT

Folks, please do not assume that I will want to run arbitrary shell
commands that people send me, like shar files, and make file.

Bug reports should contain one single source file, probably the output
from gcc -E, not shar files and makefiles.

I will accept this one as is for now, but the next one I will spit back.

> From: warsaw@nlm.nih.gov (Barry A. Warsaw)
> Message-Id: <WARSAW.92Aug31150224@anthem.nlm.nih.gov>
> Organization: Century Computing, Inc.
> Date: 31 Aug 92 20:02:24 GMT
> Apparently-To: gnu-g++-bug@uunet.uu.net
> To: bug-g++@prep.ai.mit.edu

> The following shar file illustrates a bug in gcc 2.2.2 on a Sun SS2,
> SunOS 4.1.1.  Unshar, then enter "make" and you should see this
> message:

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  A severe bug with statics members.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 13:37:29 GMT

The decclaration of a static member does not serve as its definition.

Please find a recent book on C++ for more details.

> Message-Id: <9208221844.AA21654@life.ai.mit.edu>
> Date:         Sat, 22 Aug 92 14:34:04 COL
> From: Luis Armando Cobo <LCOBO%ANDESCOL.BITNET@mitvma.mit.edu>
> Organization: Universidad de Los Andes - Bogota, Colombia

> In a DECstation 5000/125 with ULTRIX 4.2, and gcc/g++ 2.2.2 and with
> this program:

>     class ONE {
>        protected:
>           static int a_member;
>        public:
>           ONE(void) {a_member = 1;}
>           set(int x) {a_member = x; }
>      };
>      ONE p;
>      int main(void)
>      {
>          p.set(5);
>          return 0;
>      }

> I obtain:
> % g++ ONE.cc -o ONE
> ld:
> Undefined:
> _3ONE$a_member
> collect: /usr/bin/ld returned 1 exit status

> Any ideas?

> ///LuiX

> +----------------------------------------+
> | Luis Armando Cobo Campo                |
> | Centro de Computacion                  |
> | Ingeniero                              |
> | Universidad de los Andes +------------------------------------------+
> | Santafe de Bogota D.C.   | Fax:    +57 1 281 56 80                  |
> +--------------------------| Tel:    +57 1 284 18 90                  |
>                            | E-Mail:                                  |
>                            |  lcobo@andescol.uniandes.edu.co  Internet|
>                            |  LCobo@ANDESCOL.BITNET           BITNET  |
>                            +------------------------------------------+



Newsgroups: gnu.g++.bug
From: rtm@das.harvard.edu
Subject: redefinition of method of templated class causes core-dump
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 31 Aug 1992 19:13:19 GMT

I'm running g++ 2.2.2 on a SPARCstation ELC under SunOS 4.1.2.
The following C++ code, which redefines a method of a templated
class, causes cc1plus to get signal 11:

template<class T> class a{
public:
    void foo(int);
private:
    T v;
};

template<class T> void
a<T>::foo(int x)
{
}

template<class T> void
a<T>::foo(int x)
{
}

main()
{
    a<int> zz;

    zz.foo(99);
}

The above file is twice.cc. When I run
g++ -v twice.cc
here's what it says:

Reading specs from /home/glan/lib/gcc-lib/sun4/2.2.2/specs
gcc version 2.2.2
 /home/glan/lib/gcc-lib/sun4/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG
__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__spa
rc -D__sun -D__unix twice.cc /usr/tmp/cca02423.i
GNU CPP version 2.2.2 (sparc)
 /home/glan/lib/gcc-lib/sun4/2.2.2/cc1plus /usr/tmp/cca02423.i -quiet -dumpbase
twice.cc -version -o /usr/tmp/cca02423.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
/home/glan/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11

I didn't compile cc1plus with debugging turned on, so the backtrace
from the core file isn't very interesting. But here it is anyway:
#0  0x24498 in start_function ()
#1  0xe7bc in yyparse ()
#2  0x7c4e0 in output_file_directive ()
#3  0x7f0a4 in main ()

Newsgroups: gnu.g++.bug
From: dcb@us-es.SEl.DE
Subject: gnu C++ 222 bug report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 17:57:14 GMT

Hello there,

Given the code at the end of this mail message I get the following error from a stock copy
of GNU C++ 2.2.2 on SUN 4 hardware

../gcc-2.2.2/cp-class.c:2378: failed assertion `IDENTIFIER_TEMPLATE (t) != NULL_TREE'
cc1plus: inherit.C:19: internal error - abort.
gcc-2.2.2: Internal compiler error: program cc1plus got fatal signal 6

BTW, any clues on GNU 2.3 delivery schedules or bugs fixed status ?

Regards

David C Binderman  Dept US/ESI, Bau 60, SEL-Alcatel AG, Lorenz Strasse 10,
D-7000 Stuttgart 40, Germany     dcb@us-es.sel.de    +49 711 821 3841

---------------- cut here ------------------------------------------
extern "C" int printf( const char *, ...);

class A {
public :
	virtual void f()	{	printf( "A::f() called\n"); }
	virtual void g()	{	printf( "A::g() called\n"); }
} ;

class B : public A {
	typedef A			superclass ;
public :
	virtual void g()	{
							printf( "B::g() called\n");
							superclass::g() ;
						}
} ;

class C : public B {
	typedef B			superclass ;
public :
	virtual void f()	{
							printf( "C::f() called\n");
							superclass::f() ;
						}
} ;

int main() {
	C	c ;
	c.f() ;
	c.g() ;
	return 0 ;
}
---------------- cut here ------------------------------------------


Newsgroups: gnu.g++.bug
From: turlais@rechser.total.fr (Rech TURLAIS Tel 4216 15-01-92 MJ )
Subject: abort in delete of virtual derived class.
Reply-To: turlais@rechser.total.fr
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 20:29:37 GMT

  The following program aborts in s2::~s2. s2 is virtualy derived
from s1 and destructor is virtual. This appears on SUN4 SUNOS 4.1.1.

 Thank you.
 
 P. Turlais.

The commands :

190 halley % gcc -g -v s.cc
Reading specs from /d/turlais/lib/gcc-lib/sun4/2.2.2/specs
gcc version 2.2.2
 /d/turlais/lib/gcc-lib/sun4/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix -g s.cc /usr/tmp/cca03231.i
GNU CPP version 2.2.2 (sparc)
 /d/turlais/lib/gcc-lib/sun4/2.2.2/cc1plus /usr/tmp/cca03231.i -quiet -dumpbase s.cc -g -version -o /usr/tmp/cca03231.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
 as -o s.o /usr/tmp/cca03231.s
 /d/turlais/lib/gcc-lib/sun4/2.2.2/ld -e start -dc -dp /lib/crt0.o -L/d/turlais/lib/gcc-lib/sun4/2.2.2 -L/d/turlais/lib s.o -lgcc -lc -lg -lgcc
191 halley % a.out
IOT trap (core dumped)

The code :

class s1 {
public:
    s1() {}
    virtual int f(int) = 0;
    virtual ~s1() = 0;

 };

class s2 : virtual public s1 {
public:
    s2(int i) : val(i) {}
    ~s2();
    int f(int);

    int val;
};

s2::~s2()
{}

int s2::f(int i)
{ return i + j;
}

main()
{
    s1 *s = new s2(4);

    delete s;
}


Newsgroups: gnu.g++.bug
From: lewis@sophists.COM (Lewis G. Pringle)
Subject: Possible overloading bug with gcc 2.2.1
Reply-To: lewis@sophists.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 04:57:00 GMT

//
//Possible problem with overloading in gcc 2.2.1.
// For what I belive is valid code we get the error message:
//x.cc: In function `int  f (class Derived*)':
//x.cc:30: in base initialization for class `BaseOwner',
//x.cc:30: invalid initializer to constructor for type `BaseOwner'
//x.cc:38: warning: control reaches end of non-void function


class	Base	{ int a; };
class	Derived : public Base { int b; };

class	BaseOwner {
	public:
		BaseOwner (Base* b);
};

class	TEST {
	public:
	TEST ();
	operator Derived* ();
};


int f (Derived* d)
{
	BaseOwner bo1 (d);		// Obviously this compiles
	Derived* d2 = TEST ();		// Not too surprising that this does too
	BaseOwner bo2 (d2);		// this is really just like the first test...
	BaseOwner b03 (TEST ());	// BUT: why does this not compile??
		// According to ARM 12.3.2 I get one user defined conversion
		// (and no more). This is Test::operator Derived* ().
		// And according to page 326 (13.2) "Standard Conversions
		// may be appled tothe argument for a user-defined conversion,
		// and to the result of the user defined conversion.". This would seem
		// to imply that the Derived* gets converted to a Base*, and so
		// the last line of code should compile.
}

Newsgroups: gnu.g++.bug
From: lewis@sophists.COM (Lewis G. Pringle)
Subject: trouble with nested typedefs in gcc 2.2.1
Reply-To: lewis@sophists.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 19:04:00 GMT

// This file when compiled with gcc 2.2.1 (with no command line options)
// produces the following output:
// 	cp-class.c:2378: failed assertion `IDENTIFIER_TEMPLATE (t) != NULL_TREE'
// 	/usr/local/bin/gcc: Internal compiler error: program cc1plus got fatal signal 6

struct	String {
};

class	Font {
	public:
		typedef	String	Name;
};

Newsgroups: gnu.g++.bug