HDTenEightyP/NetNews huggingface dataset:
From: bwilson@shasta.stanford.edu (Bob Wilson)
Subject: cc1plus seg fault with illegal "switch"
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 01:48:48 GMT

version 2.2.2
configured with mips-dec-ultrix

There is a bug in cc1plus that causes it to segmentation fault when trying
to compile a switch expression that is a class without a conversion to int.
I know that's not legal C++ (apparently it was accepted by cfront1.2), but
it shouldn't crash the compiler.  The problem is in c_expand_start_case in
cp-typeck.c.  There needs to be a test for exp == 0 following the call to
build_type_conversion() (at line 6130).

If that's not good enough, here's a test case:

struct not_an_int {
    char *name;
};

main()
{
    not_an_int a, b, c;

    a.name = "a";
    b.name = "b";

    c = a;
    switch (c) {
	case a:
	    c.next = b;
	    break;
	case b:
	    c.next = a;
	    break;
    }
}

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  g++ 2.2.2 crashes when using multiple inheritance
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 15:41:43 GMT

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.

> 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();
> }
> adams 22>g++ -c -v bug2.c
> Reading specs from /usr/gnu/lib/gcc-lib/decstation/2.2.2/specs
> gcc version 2.2.2
>  /usr/gnu/lib/gcc-lib/decstation/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__ANSI_COMPAT -DMIPSEL -DR3000 -DSYSTYPE_BSD -D_SYSTYPE_BSD -Dbsd4_2 -Dhost_mips -Dmips -Dultrix -Dunix -D__ANSI_COMPAT -D__MIPSEL__ -D__R3000__ -D__SYSTYPE_BSD__ -D___SYSTYPE_BSD__ -D__bsd4_2__ -D__host_mips__ -D__mips__ -D__ultrix__ -D__unix__ -D__ANSI_COMPAT -D__MIPSEL -D__R3000 -D__SYSTYPE_BSD -D___SYSTYPE_BSD -D__bsd4_2 -D__host_mips -D__mips -D__ultrix -D__unix -D__LANGUAGE_C__ -D__LANGUAGE_C -D

LANGUAGE_C bug2.c /usr/tmp/cca03756.i
> GNU CPP version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix
>  /usr/gnu/lib/gcc-lib/decstation/2.2.2/cc1plus /usr/tmp/cca03756.i -quiet -dumpbase bug2.cc -version -o /usr/tmp/cca03756.s
> GNU C++ version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix compiled by GNU C version 2.2.2.
> bug2.c: In function `void  g (struct A*)':
> bug2.c:15: cannot convert a pointer of type `A'
> bug2.c:15: to a pointer of type `B'
> pid 3767 (cc1plus) was killed on an unaligned access, at pc 0x449c4c 
> /usr/gnu/bin/gcc: Internal compiler error: program cc1plus got fatal signal 10
> adams 23>exit
> exit

> script done on Thu Aug 27 15:29:03 1992




Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  g++ bug: static data members
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 12:13:19 GMT

This is not a known bug in g++, in fact it is a known ``not a bug'' in g++.

Try putting a definition for C::I someplace in the top level, like:

int C::I;

after all your code.  Please read a good C++ book for more details.

> Date: Tue, 4 Aug 1992 20:05:50 -0600
> From: "Alexander L. Wolf" <alw@anchor.cs.colorado.edu>
> Message-Id: <199208050205.AA10485@anchor.cs.colorado.edu>
> To: bug-gcc@prep.ai.mit.edu
> Cc: alw@cs.colorado.edu

> Compiling the following very simple C++ program 

>         struct C {
>                 static int I;
>         };

>         int main ()
>         {
>                 C::I = 0;
>         };

> produces the following error output

>         ld: Undefined symbol
>            __1C$I
>         collect: /usr/bin/ld returned 2 exit status

> The version of g++ used is 2.2.2.

> Please let me know whether is this is a known bug in g++.

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  g++ and groff's c++test.c
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 12:35:31 GMT

I suspect you probably already have this fixed, but incase not...

The installation of the compiler was someone messaged up.  You need to
make sure that either GNU ld is installed and used by the compiler or
that collect (collect2.c) is build and used by the compiler.

This problem has nothing to do with the optimizer.

> Date: Tue, 11 Aug 92 00:03:17 PDT
> From: gregor@kafka.saic.com (gregg hanna)
> Message-Id: <9208110703.AA19545@kafka.saic.com>

>   I was trying to build groff but it didn't pass the c++
> compiler test in c++test.c, which is:

> #include <stdio.h>

> struct A {
>   A() { fputs("A\n", stdout); }
>   ~A() { fputs("~A\n", stdout); }
> };

> A a;

> main()
> {
>   return 0;
> }

> I thought maybe the optimizer trashed it, but I tried it
> several different ways.  It appears that g++ does not call
> the creator for statically declared variables.  Is this
> correct behavior?  The following, however, works fine:

> #include <stdio.h>

> struct A {
>   A() { fputs("A\n", stdout); }
>   ~A() { fputs("~A\n", stdout); }
> };

> main()
> {
>   A a;
>   return 0;
> }

> If this is not a bug, perhaps the groff people should
> be notified, since groff-1.05 currently will not compile
> if it fails the c++test.  By the way, the groff people
> expect the output of the program to be:
> A
> ~A

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Linker is missing symbols, when profiling is enabled with g++
Organization: Gnus Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 19:22:36 GMT

This can be fixed with almost any other version of gcc.  gcc 2.2.1
should not have this problem.  This problem should not exist in the
next release of gcc.

> Date: Fri, 21 Aug 92 14:45:22 +0200
> From: schoenfr@ibr.cs.tu-bs.de (Erik Schoenfelder)
> Message-Id: <9208211245.AA28975@helios>
> To: bug-g++@prep.ai.mit.edu
> Reply-To: schoenfr@ibr.cs.tu-bs.de

> The host is a Sparcstation 2 with SunOS 4.1.1

> GCC version 2.2.2 was configured:

> >	# GCC was configured as follows:
> >	../gcc-2.2.2/configure sun4

> and libg++ version 2.2 was configured:

> >	# This directory was configured as follows:
> >	./configure sun4 -norecursion 


> Compiling with the -pg switch, causes the linker to report undefined
> symbols.  (This does not happen, if the libg++ is compiled without the
> -g flag; but the default installation is with -g).  Below an example:

> >	% cat pp.cc
> >	#include <fstream.h>
> >	
> >	main ()
> >	{
> >	        cout << "hi nase\n";
> >	}
> >	% g++ -v -pg pp.cc
> >	Reading specs from /usr/local/lib/gcc-lib/sun4/2.2.2/specs
> >	gcc version 2.2.2
> >	 /usr/local/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 pp.cc
> >	 /usr/tmp/cca21887.i
> >	GNU CPP version 2.2.2 (sparc)
> >	 /usr/local/lib/gcc-lib/sun4/2.2.2/cc1plus /usr/tmp/cca21887.i -quiet
> >	 -dumpbase pp.cc -version -p -o /usr/tmp/cca21887.s
> >	GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
> >	 as -o pp.o /usr/tmp/cca21887.s
> >	 /usr/local/lib/gcc-lib/sun4/2.2.2/ld -e start -dc -dp /lib/gcrt0.o
> >	 -L/usr/local/lib/gcc-lib/sun4/2.2.2 -L/usr/local/lib pp.o -lg++ -lgcc
> >	 -lc_p -lgcc
> >	Undefined
> >	LBE60
> >	LBB60
> >	LBE50
> >	LBB50
> >	[...]
> >	LBB38
> >	LBE39
> >	LBB39
> >	collect: /usr/bin/ld returned 2 exit status
> >	% nm /usr/local/lib/libg++.a | grep LBE60
> >	         U LBE60
> >	%

> These undefined symbols seems to be contained in the stabs of libg++.a
> (compiled with default CFLAGS=-g).  It's seems to be an error in the
> output of the debugging information, but i have no idea how to fix it.

Newsgroups: gnu.g++.bug
From: doug@foxtrot.ccmrc.ucsb.edu (Douglas Scott)
Subject: g++2.2.2: initialization of static member denied access to friend's static private members
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 19:07:46 GMT

I hope that was a descriptive enough title.

Here is the example:

struct Base {
friend class FriendOfBase;
static int *a;
};

class FriendOfBase {
static int m;
};

int *Base::a = &FriendOfBase::m;

The initialization of Base::a should have access to
FriendOfBase::a, but compiling this gives the
following: 


member `m' is a private member of class `FriendOfBase'

Newsgroups: gnu.g++.bug
From: dov@ds20.dmi.stevens-tech.edu (Dov Kruger)
Subject: function overload "bug?"
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 4 Sep 1992 08:25:37 GMT

Let's just say that g++ works differently than cxx (DEC's implementation)
and that it does not make sense to me.  Given the following code:

class Link1 {
  Link1*  _next;
public:
  void next(Link1* new_next);
};

You can pass the integer constant 0 to the function, which is correct.

Link1 x;
x.next(0); // this works!

However, you can't declare an integer constant of zero, as has been my habit:

const int nil = 0;
x.next(nil);

It doesn't work.

Thanks,
Dov Kruger

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  g++ 2.2.2 bug with extern "C" friends
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 17:05:28 GMT

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

Here is a patch in the mean time:

*** cp-class.c.~1~	Sat Aug 29 04:07:47 1992
--- cp-class.c	Sat Aug 29 09:56:46 1992
*************** finish_struct (t, list_of_fieldlists, em
*** 2581,2587 ****
  
  	  if (! fields) fields = x;
  	  DECL_FIELD_CONTEXT (x) = t;
! 	  DECL_CLASS_CONTEXT (x) = t;
  	  DECL_FIELD_SIZE (x) = 0;
  
  	  /* We set DECL_BIT_FIELD tentatively in grokbitfield.
--- 2581,2589 ----
  
  	  if (! fields) fields = x;
  	  DECL_FIELD_CONTEXT (x) = t;
! 	  /* We could be making an extern "C" function a friend. */
! 	  if (DECL_LANG_SPECIFIC (x))
! 	    DECL_CLASS_CONTEXT (x) = t;
  	  DECL_FIELD_SIZE (x) = 0;
  
  	  /* We set DECL_BIT_FIELD tentatively in grokbitfield.

> Date: Tue, 25 Aug 1992 12:15:51 +0100
> From: Steve Rumsby <steve@maths.warwick.ac.uk>
> Message-Id: <11787.199208251115@amazon>
> To: bug-g++@prep.ai.mit.edu
> Organization: Maths Institute, Warwick University, Coventry, UK.

> 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.

> ------
> 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?

> $ 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

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  typedef A: :B A_B in class A causes g++ assertion fail
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 16:23:24 GMT

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

> To: bug-g++@prep.ai.mit.edu
> Date: Wed, 26 Aug 92 17:16:37 +1200
> Message-Id: <9609.714813397@cs.mu.OZ.AU>
> From: Jeff Schultz <jws@cs.mu.oz.au>

> Gcc-2.2.2 installed on a SGI 4D/340 with configure mips-sgi-irix

> The code below causes

>     cp-class.c:2378: failed assertion `IDENTIFIER_TEMPLATE (t) != NULL_TREE'


> # 1 "typedef.C"
> class A {
>     class B;
>     typedef A::B A_B;
> };
From: lewis@sophists.COM (Lewis G. Pringle)
Newsgroups: gnu.g++.bug
Subject: Possible bug with overloading operator new in gcc 2.2.1
Date: 3 Sep 92 20:26:00 GMT
Reply-To: lewis@sophists.com
Distribution: gnu
Organization: GNUs Not Usenet

// Compiling this file with gcc 2.2.1:
// as follows: g++ -c g.cc
// produces the messages:
// 	g.cc: In method `ArrayNode::ArrayNode (int)':
//	g.cc:20: too few arguments for method `operator new'
//
// I can almost believe this is right, since I have overloaded
// operator new here so that the obvious call that might be generated
// silently in the CTOR would not match. However, that it supposed
// to be an implementation detail of the compiler, and should not
// show thru. In fact, you should generate a call to the two argument
// version - I think. In this particular instance, I have no intention
// of ever allocating any of these nodes on the free store anyhow, and
// so its silly that I should have to overload new here additionally
// to take one arg, just so that can get stuck into my CTOR code.
// BTW, this compiles fine with CFront 2.1.
typedef unsigned size_t;
class ArrayNode {
	public:
		ArrayNode (int item): fItem (item){}		// I am line 20
		~ArrayNode (){}
		int	fItem;

		static void* operator new (size_t, void* p) { return (p); }
		static void  operator delete (void*) {}
};
Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Init of static members inside class def
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 13:24:50 GMT

g++ -ansi -pedantic will reject this construct with the error message:

t3.cc:2: fields cannot have initializers

This is proper behavior.

The other bevahior that you are seeing is an extension.

> Message-Id: <199208201131.AA19238@inpbox.inp.nsk.su>
> Date: 20 Aug 92 19:23:00 +0007 (GMT+7:00)
> From: "LOPATIN" <lopatin@inp.nsk.su>
> To: "bug-gcc" <bug-gcc@prep.ai.mit.edu>

> 	I admire how your gcc 2.1 works on my DECstation 5000/200
> (Ultrix 4.2), but it seems to be erroneous not to reject
> initialization of the static member inside class definition. Let me
> illustrate it by example:

> [ 191 > cat one.C
> #include <iostream.h>

> struct item {
>     static int y = 1;
> };

> main(){
>     item x;
>     cout << x.y <<"\n";
> }

> [ 192 > cat two.C
> struct item {
>     static int y;
> };

> int item::y = 2;

> [ 193 > g++ one.C two.C
> [ 194 > a.out
> 2

> 	For those who only red the first edition of Stroustrup's book
> it is not obvious that "one.C" is invalid,  so it is very suitable to
> report error on this, like Borland C++ does.

Newsgroups: gnu.g++.bug
From: ebubra@anah.ericsson.COM (Bertil Askelid 6344)
Subject: #include <arpa/inet.h>
Reply-To: ebubra@anah.ericsson.com (Bertil Askelid)
Organization: Ericsson Business Communications, Anaheim, California
Distribution: gnu
Date: Thu, 3 Sep 1992 22:46:57 GMT

   Hardware:         Sparc IPX
   Operating system: SunOs 4.1.1
   gcc version:      2.1
   libg++ version:   2.0

   The gcc compiler needs to have its own version of this include file.

   The standard include file in /usr/include/arpa/inet.h has function
   declarations according to an older C standard, i.e. without argument
   declarations. Obviously the gcc C++ compiler reports this as an
   error, when the I try to invoke the function according to its
   description in the man page.

         Bertil Askelid
         Ericsson Business Communications
         525 North Muller Street
         Anaheim
         California 92801
         Phone: + 1 714 491 6344
         Fax:   + 1 714 535 1789
         Email: ebubra@ebu.ericsson.se


Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  g++ V2.2.2: conditional operator cannot handle const char * operand
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 12:59:35 GMT

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

> Date: Mon, 17 Aug 92 14:48:21 -0400
> From: mtn@cs.duke.edu (Michael T. Naseef)
> Message-Id: <9208171848.AA06346@tupelo.cs.duke.edu>
> To: bug-gcc@prep.ai.mit.edu
> Cc: khera@cs.duke.edu

> SOFTWARE:  g++ (gcc) version 2.2.2

> BUG REPORT:  conditional operator ?: cannot handle const char * operand.

> I discovered the following bug while recompiling groff using g++
> version 2.2.2.

> PROBLEM: compiling the following code produces the error
> 	try.cc: In function `int  main ()':
> 	try.cc:5: assignment between incompatible pointer types

> EXAMPLE CODE:
> main()
> {
>     const char *p = "abcd";
>     const char *c;
>     c = ((p == 0) ? "1234" : p);
> }


> Note: changing the declaration of p to char * will allow g++ to compile the
> code without error.  No casting of any members has any affect on the problem.

> Mike Naseef
> --
> Mike Naseef
> Department of Computer Science, Duke University, Durham, NC 27706
> Internet:	mtn@cs.duke.edu	|  Phone:	919/660-6577
> UUCP:		mcnc!duke!mtn	|



Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Bug with dependency generation g++2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 01:59:03 GMT

I believe this problem has been fixed, you can ask over in bug-gcc if
it has for sure.

Yes, probably most people that use the extension .cxx have.

> Date: Fri, 28 Aug 92 17:29 PDT
> To: bug-g++@prep.ai.mit.edu
> From: Kambiz Aghaiepour   <kambiz@indetech.com>
> Message-Id: <KAMBIZ.92Aug28172309@booboo.indetech.com>

> System: sun4 (IPC) running sunOS 4.1.x with GNU gcc/g++ version 2.2.2

> Has anyone else experienced this problem?

> ------- Start of forwarded message -------
> From: tilman (Tilman Sporkert)
> To: kambiz (Kambiz Aghaiepour)
> Date: Tue, 4 Aug 92 13:13:41 PDT

> It appears that dependency generation with the new compiler is broken. The
> output of "g++ -MM" looks like:

>    allowance_tables.cxx.o : allowance_tables.cxx ../../tilman/util/ItiString.hxx \
>   ../../tilman/util/ItiObject.hxx ../../tilman/util/ItiObjMacros.hxx ../../tilman/main/r2drug_svc.hxx \


> Please note that it says "allowance_tables.cxx.o", not "allowance_tables.o"!
> ------- End of forwarded message -------

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Gnu C++ bugs in classes
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 13:09:59 GMT

This is not a bug.  Please read an up-to-date book on C++.

int mousecatcher::mice; at top level cures your broken code.

> Message-Id: <MAILQUEUE-101.920819095700.744@fs1.metallurgy.umist.ac.uk>
> From: A.APPLEYARD@fs1.mt.umist.ac.uk
> Date: 19 Aug 92 09:57:00 GMT

> BUG REPORT: In Gnu C version 2.0, static members of classes are not allocated
> storage space, and thus the linker complains that these symbols are missing if
> I use them.
> This bug was not present in the last version of Gnu C which I had (1.39?).
> Herewith a C++ program, and its translation into assembler by Gnu C++.
> Notice that there is no assembler line 'comm __12mousecatcher$mice,4'.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> class mousecatcher{public:
> int cat,ferret,owl,trap;
> static int mice;};
> int i,j,k; mousecatcher Tom;
> main(){i=Tom.cat; j=Tom.ferret; k=Tom.mice;}
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 	.file	"t$$.cc"
> gcc2_compiled.:
> .text
> 	.align 2
> .globl _main
> _main:
> 	pushl %ebp
> 	movl %esp,%ebp
> 	call ___main
> 	movl _Tom,%edx
> 	movl %edx,_i
> 	movl _Tom+4,%edx
> 	movl %edx,_j
> 	movl __12mousecatcher$mice,%edx
> 	movl %edx,_k
> 	xorl %eax,%eax
> 	jmp L1
> 	.align 2,0x90
> 	jmp L1
> 	.align 2,0x90
> L1:
> 	leave
> 	ret
> .comm _i,4
> .comm _j,4
> .comm _k,4
> .comm _Tom,16



Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  initializer for virtual base class.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 17:49:13 GMT

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

Here is a patch in the mean time:

*** cp-init.c.~1~	Tue Aug 25 16:38:30 1992
--- cp-init.c	Sat Aug 29 10:33:51 1992
*************** emit_base_init (t, immediately)
*** 257,263 ****
  	      /* Virtual base classes are special cases.  Their initializers
  		 are recorded with this constructor, and they are used when
  		 this constructor is the top-level constructor called.  */
! 	      if (! TREE_VIA_VIRTUAL (binfo) || pedantic)
  		{
  		  /* Otherwise, if it is not an immediate base class, complain.  */
  		  for (i = n_baseclasses-1; i >= 0; i--)
--- 257,263 ----
  	      /* Virtual base classes are special cases.  Their initializers
  		 are recorded with this constructor, and they are used when
  		 this constructor is the top-level constructor called.  */
! 	      if (! TREE_VIA_VIRTUAL (binfo))
  		{
  		  /* Otherwise, if it is not an immediate base class, complain.  */
  		  for (i = n_baseclasses-1; i >= 0; i--)


> Date: Sun, 23 Aug 92 15:38:46 -0500
> From: solomon@cs.wisc.edu (Marvin Solomon)
> Message-Id: <9208232038.AA22890@gjetost.cs.wisc.edu>
> To: bug-g++@prep.ai.mit.edu

> When -pedantic is specified, g++ 2.2.2 won't allow an initializer for
> a virtual base class, but it also complains that the initializer is missing.

> 	extern "C" void printf(...);

> 	struct A {
> 		A(int i) { printf("A::A(%d)\n", i); }
> 	};

> 	struct B : virtual A {
> 		B(int i) : A(i+1) { printf("B::B(%d)\n", i); }
> 	};

> 	struct C : B {
> 		C(int i) : B(i+1), A(i+2) { printf("C::C(%d)\n", i); } // line 12
> 	};

> 	main() {
> 		C(1);
> 	}
> When compiled with 'g++ -pedantic', the messages are:
> 	foo.c: In method `C::C (int)':
> 	foo.c:12: type `A' is not an immediate base class of type `C'
> 	foo.c:12: virtual baseclass `A' does not have default initializer
> 	foo.c:12: type `A' is not an immediate base class of type `C'
> When compiled without -pedantic (even if -Wall is specified) there are
> no errors or warnings, and the correct output is produced:
> 	A::A(3)
> 	B::B(2)
> 	C::C(1)
> If line 12 is changed to
> 		C(int i) : B(i+1) { printf("C::C(%d)\n", i); } // line 12
> there is only one message (with or without -pedantic):
> 	foo.c:12: virtual baseclass `A' does not have default initializer

Newsgroups: gnu.g++.bug