HDTenEightyP/NetNews huggingface dataset:
From: vbl@z.eecs.umich.edu (Vic Lortz)
Subject: Template declarations in classes
Organization: Gnus Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 12:14:17 GMT

Am I confused, or should the following be accepted by the g++ compiler?


template <class T>
class container {
public:
    container(T val) : data(val) { }
    container() : data(0) { }
    T data;
};

class myc {
public:
    myc() { }
    containter<int> fp;
};

65 adirondacks>  g++ -v -c t.cc
Reading specs from /usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1.2/2.2.2/specs
gcc version 2.2.2
 /usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1.2/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 t.cc /usr/tmp/cca09492.i
GNU CPP version 2.2.2 (sparc)
 /usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1.2/2.2.2/cc1plus /usr/tmp/cca09492.i -quiet -dumpbase t.cc -version -o /usr/tmp/cca09492.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
t.cc:13: syntax error before `<'

thanx -- Vic Lortz
vbl@eecs.umich.edu

Newsgroups: gnu.g++.bug
From: sct@dcs.ed.ac.UK (Stephen Tweedie)
Subject: g++-2.2.2 dies on correct code with virtual inheritance
Organization: University of Edinburgh Dept. of Computer Science, Scotland
Distribution: gnu
Date: Tue, 21 Jul 1992 16:57:45 GMT

g++-2.2.2 on a sun 4 (sunos4.1) dies with a fatal signal 11 trying to
take the address of a reference on the following code:

----------------------------------------------------------------
class A
{
  public:
    A *a;
};

class AA : virtual public A        // Works OK if "virtual" deleted
{
  public:
    AA& foo()
    {
        return *this;
    };
};

main ()
{
    AA aa;
    aa.foo().a = &aa;            // This line compiles OK
    aa.a = &aa.foo();            // And this one.
    aa.foo().a = &aa.foo();      // Nope - internal compiler error.
}
----------------------------------------------------------------
Compiler output follows:
% g++-2.2.2 -v -c sbug3.cc
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/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 sbug3.cc /usr/tmp/cca01028.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca01028.i -quiet -dumpbase sbug3.cc -version -o /usr/tmp/cca01028.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
/usr/local/bin/gcc-2.2.2: Internal compiler error: program cc1plus got fatal signal 11

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 20 Jul 1992 15:56:40 GMT

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

> From: skohn@cs.ucsd.edu (Scott Kohn)
> Message-Id: <35055@sdcc12.ucsd.edu>
> Date: 25 Jun 92 21:41:55 GMT
> Organization: UC-San Diego CSE Department
> To: bug-g++@prep.ai.mit.edu

> Sorry if this is a repost of this bug, but I don't remember seeing it...

> There is a bug with template unification when there exist other overloaded
> functions of the same type.  For example, compiling:

> ---------------------------------------------------------------------------

> class X { public: X() { } };
> class Y { public: Y() { } };

> X& operator << (X& x, const int z) { return(x); }

> template <class T> Y& operator << (Y& y, const T& z) { return(y); }

> main(int argc, char **argv)
>   {
>    X x;
>    Y y;

>    x << 1;
>    y << 1;
>   }

> ---------------------------------------------------------------------------

> with gcc-2.2.2 (Sparc) will result in an unimplemented template unification
> message from line 1806 of cp-pt.c:

>       sorry ("use of `%s' in template type unification",
>              tree_code_name [(int) TREE_CODE (parm)]);

> Reading specs from /usr/gnu/lib/gcc-lib/sun4-sunos4.1/2.2.2/specs
> gcc version 2.2.2
>  /usr/gnu/lib/gcc-lib/sun4-sunos4.1/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 unify.c /usr/tmp/cca06799.i
> GNU CPP version 2.2.2 (sparc)
>  /usr/gnu/lib/gcc-lib/sun4-sunos4.1/2.2.2/cc1plus /usr/tmp/cca06799.i -quiet -dumpbase unify.cc -version -o /usr/tmp/cca06799.s
> GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
> unify.c:13: sorry, not implemented: use of `record_type' in template type unification
> unify.c:13: sorry, not implemented: use of `record_type' in template type unification
> unify.c:13: sorry, not implemented: use of `record_type' in template type unification
> unify.c:13: sorry, not implemented: use of `record_type' in template type unification

> If the sorry(...) function call is #ifdef'ed out, the function
> unification proceeds correctly.

Newsgroups: gnu.g++.bug
From: varady@srlvx0.srl.ford.com (Art Varady)
Subject: multiply defined text
Reply-To: varady@srlvx0.srl.ford.com
Organization: Ford Motor Company Scientific Research Labs
Distribution: gnu
Date: Fri, 24 Jul 1992 15:32:06 GMT

We are experiencing some difficulties with g++ link-preprocessor
and the linker itself. The problem is the multiple definitions of
external texts. We modify some modules, the problem pops up when
we try to link the modules with the old libraries that contain
these modules (and some other modules, of course). It seems both
the preprocessor and the linker would go to the old libraries and
pull out some (not all) of the modified modules, thus presenting
us with multiple definition problem. This problem will go away,
of course, if we remove the modules that are modified from the
old libraries. But for some reason we don't want to do it that
way.

Has anybody had the same frustration? We would appreciate any help
that can lead to the solution of our problem.

By the way, we are using DEC 5100, GNU CPP version 1.39, and
g++ version 1.39.0 beta (based on GCC 1.39).

Thank you very much.


Newsgroups: gnu.g++.bug
From: bjornw@colargol.edb.tih.no (Bjoern Wennberg)
Subject: Re: looking for g++ patch
Organization: Colargol, Trondheim College of Engineering
Distribution: gnu
Date: Fri, 24 Jul 1992 10:26:13 GMT

Sm@cerberus.bhpese.oz.AU (Scott Merrilees) writes:
: I'm looking for the patch that was posted to fix the following problem
: when compiling groff.
: 
: Thanks, Sm
: --
: $ gcc -c -I. -xc++ -g1 -O1 -DHAVE_MMAP -DHAVE_RENAME -DWAIT_COREDUMP_0200 -DNO_SYS_WAIT_H errarg.c
: errarg.c: In method `errarg::errarg (const char *)':
: errarg.c:26: assignment between incompatible pointer types
: 
: $ sed -n 26p errarg.c
: errarg::errarg(const char *p) : s(p == 0 ? "(null)" : p), type(STRING)
: -- 
: Scott Merrilees, BHP Information Technology, Newcastle, Australia
: Internet: Sm@bhpese.oz.au   Phone: +61 49 40 2132   Fax: ... 2165
: 
Hi!
This is a patch to groff-1.05 
in lib/errarg.c change 
errarg::errarg(const char *p) : s(p == 0 ? "(null)" : p), type(STRING)
to
errarg::errarg(const char *p) : s(p ? p : "(null)"), type(STRING)

bjornw>

bjornw@colargol.edb.tih.no
bjornw@edb.tih.no

Newsgroups: gnu.g++.bug
From: arr@ukc.ac.UK (A.R.Runnalls)
Subject: virtual base causes spurned friendship
Organization: Computing Lab, University of Kent at Canterbury, UK.
Distribution: gnu
Date: Wed, 22 Jul 1992 16:27:18 GMT

In the following program, the compiler fails to recognise LVR::LVR() as
a friend of class L.  The problem goes away if the word `virtual' is removed.

(Environment: g++ 2.2.2 on a sparc running SunOS 4)

Script started on Wed Jul 22 17:23:56 1992
friendbug% cat friendbug.cc
// friendbug.cc

class LVR;

class L {
private:
    int foo;

    friend LVR::LVR();
};

class R {};

class LVR : public L, virtual public R {
public:
    LVR()  {foo = 0;}
};



friendbug% g_  g++ -c -g -v -Wall !$
g++ -c -g -v -Wall friendbug.cc
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/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 -Wall friendbug.cc /usr/tmp/cca25131.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca25131.i -quiet -dumpbase friendbug.cc -g -Wall -version -o /usr/tmp/cca25131.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
friendbug.cc: In method `LVR::LVR ()':
friendbug.cc:16: member `foo' is private
friendbug% exit
friendbug% 
script done on Wed Jul 22 17:24:39 1992

Newsgroups: gnu.g++.bug
From: rob@cs.man.ac.UK (Robert Marshall)
Subject: g++ 2.2.2 gets fatal signal 11
Reply-To: rajm@cs.man.ac.uk
Organization: Department of Computer Science, University of Manchester
Distribution: gnu
Date: Tue, 28 Jul 1992 07:58:17 GMT

leopard-robert-38>gcc-new -v incomplete.cc
Reading specs from /usr/local/gcc/gcc-lib/sparc-sun-sunos4/2.2.2/specs
gcc version 2.2.2
 /usr/local/gcc/gcc-lib/sparc-sun-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 incomplete.cc /usr/tmp/cca01994.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/gcc/gcc-lib/sparc-sun-sunos4/2.2.2/cc1plus /usr/tmp/cca01994.i -quiet -dumpbase incomplete.cc -version -o /usr/tmp/cca01994.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
incomplete.cc:5: storage size of `y' isn't known
gcc-new: Internal compiler error: program cc1plus got fatal signal 11
This is incomplete.cc:
//-------------------------------------------------------------------
class x {
public:
  x();
  static const x y[23];
};
const x x::y[23];
--
------------------------------------------------------------------
Robert A.J.Marshall,		EMAIL: rmarshall@cs.man.ac.uk
Room 3.08, IT Building, Department of Computer Science,
University of Manchester, Oxford Road, Manchester, M13 9PL, U.K.
Tel: (+44) 61-275 6269          Fax: (+44) 61-275 6280
------------------------------------------------------------------

Newsgroups: gnu.g++.bug
From: edstrom@elmer.hsc.ucalgary.ca (John Edstrom)
Subject: __builtin_new & __builtin_delete (fwd)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 21 Jul 1992 12:56:21 GMT

I think I've narrowed the problem in __builtin_delete down to a
problem with __builtin_new.  Here is the simplest program I could
imagine to test their performance:

I'm using gcc 2.2.2 on Sun SPARK, built with: "configure sun4"

------------------------
#include <fstream.h>

#define INC  100
#define TYPE int

main()
{
  int  i;
  TYPE *p1, *p2 = NULL;

  for (i = 0; i < 5; i++) {
    p1 = new TYPE[INC];
    cout.form("%3d %u %u\t", i, (int)p1, (int)p1+(sizeof(TYPE)*INC));
    if (p2 != NULL)
      cout.form("%5d", (p1-p2)/sizeof(TYPE));
    p2 = p1;
    cout << "\n";
  }
}
-----------------------------------------

here is the output of the debugger, notice that the calls to
__builtin_new request the proper number of bytes but subsequent
invocations of new get pointers located 1/4 the proper distance from
the start of the previouw block.  It seems that __builtin_new is doing
something wrong with scaling for the size of the data type when it
tracks memory usage although it does request the right amount of
memory. Any attempt to write to one array will write over newer
arrays.  God knows what happens when I delete them.

 If I use type double instead of int then the distance allocated
blocks is only sufficient for 12 doubles, not the requested 100.

This is too fundamental a problem to have been relased without
somebody having noticed so I presume I'm doing something wrong.  Does
anybody know what it is?

---------------------------------------------------------------

GDB 4.6, Copyright 1992 Free Software Foundation, Inc... 
(gdb) break __builtin_new
Breakpoint 1 at 0xa9b4
(gdb) run
Starting program: /files/home/Lukowiak/edstrom/ftp/meshcach/src/tmp 

Breakpoint 1, 0xa9b4 in __builtin_new (sz=400)
Current Language:  auto; currently c
Type checking:     auto; currently off
Range checking:    auto; currently off
(gdb) cont
Continuing.
 
Breakpoint 1, 0xa9b4 in __builtin_new (sz=8192)
(gdb) 
Continuing.
  0 76256 76656  

Breakpoint 1, 0xa9b4 in __builtin_new (sz=400)
(gdb) 
Continuing.
  1 84864 85264   538

Breakpoint 1, 0xa9b4 in __builtin_new (sz=400)
(gdb) 
Continuing.
  2 85272 85672    25

Breakpoint 1, 0xa9b4 in __builtin_new (sz=400)
(gdb) 
Continuing.
  3 85680 86080    25

Breakpoint 1, 0xa9b4 in __builtin_new (sz=400)
(gdb) 

--
 RM 2104, HSc Building,  Div. Neuroscience
 U. Calgary School of Medicine,  3330 Hospital Drive NW
 Calgary, Alberta       T2N 3Y4
 (403) 220 4493  (wk)

Newsgroups: gnu.g++.bug
From: eric@cathaus.utcs.utoronto.ca (Eric M. Carroll)
Subject: simpler example of previous g++ bug report - unresolved static member
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 17:07:14 GMT

* Environment
	Sparcstation 1+, SunOS 4.1.1 + pacthes
	GCC 2.2.2

* Problem
	static member is unresolved at link time

* Example

class A {
 public:
    void test() ;

 private:
    static int value ;
} ;

void A::test() {
    value = 0 ;
}

main() {

    return 0 ;
}

* Repeat By

g++ -v tmp.2.cc -o out
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/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 tmp.2.cc /usr/tmp/cca04974.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca04974.i -quiet -dumpbase tmp.2.cc -version -o /usr/tmp/cca04974.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
 as -o tmp.2.o /usr/tmp/cca04974.s
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/ld -e start -dc -dp -o out /lib/crt0.o -L/usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2 -L/usr/local/lib tmp.2.o -lg++ -lgcc -lc -lgcc
ld: Undefined symbol 
   __1A$value 
collect: /usr/bin/ld returned 2 exit status


Newsgroups: gnu.g++.bug
From: eric@cathaus.utcs.utoronto.ca (Eric M. Carroll)
Subject: g++ bug: unresolved static member at link time
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 15:15:31 GMT

* Environment: 
	Sun SPARCStattion 1+, SunOS 4.1.1 + many patches
	GCC 2.2.2

* Problem:
	* static member ComponentDisplay::value is unresolved at link time
	if UIDisplay::eventProc is commented out.

	* removing comments from UIDisplay::eventProc results in cc1plus
	receiving fatal signal 11 (reported in last message).

* Repeat By:

g++ -v tmp.cc -lxview -o out
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/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 tmp.cc /usr/tmp/cca04629.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca04629.i -quiet -dumpbase tmp.cc -version -o /usr/tmp/cca04629.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
 as -o tmp.o /usr/tmp/cca04629.s
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/ld -e start -dc -dp -o out /lib/crt0.o -L/usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2 -L/usr/local/lib tmp.o -lxview -lg++ -lgcc -lc -lgcc
ld: Undefined symbol 
   __16ComponentDisplay$value 
collect: /usr/bin/ld returned 2 exit status

*Code Fragment

class UIDisplay  {
protected:
//    static long eventProc (long,
//			     long *,
//			     long, 
//			     long);
} ;

class ComponentDisplay: public UIDisplay {
 protected:
    static int value ;
    static void		 backgroundEventProc () ;
    static long          eventProc (long,
				    long *,
				    long,
				    long);
} ;
void ComponentDisplay::backgroundEventProc ()
{
}

extern "C" { long  notify_interpose_event_func(long a, long (*func)()) ; } ;

long ComponentDisplay::eventProc (long win,
					  long             *event,
					  long         arg,
					  long  event_type)
{
    // Set the panel event proc
    notify_interpose_event_func (0L, eventProc);
    value = 0 ;

    return 0 ;
}

main() {

    return 0 ;
}

Newsgroups: gnu.g++.bug
From: tmb@idiap.CH (Thomas M. Breuel)
Subject: core dump
Reply-To: tmb@idiap.ch
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 23 Jul 1992 19:22:51 GMT

transcript below
================================================================
template <class T>
struct Art {
	T data[1000];
	int dim(int);
	T &operator()(int);
};

struct X {
	int dummy;
	X();
	X(int,int);
	float operator()(int);
	float operator()(int,int);
};

template <class T> void fill(Art<T> &a,T value) {
	for(int i=0;i<a.dim(0);i++) a.sub(i)=value;
}

struct Averages {
	Art<X*> averages(256);
	Art<int> counts(256);

	X *get(int i) {
		if(!averages(i)) averages(i) = new X(128,128);
		fill(*averages(i),(X*)0);
		return averages(i);
	}

	void average(int which,X &shifted) {
		X &avg = *get(which);
		for(int i=0;i<avg.dim(0);i++) for(int j=0;j<avg.dim(1);j++) {
			if(i>=shifted.dim(0)||j>=shifted.dim(1)) continue;
			avg(i,j)+=shifted(i,j);
		}
		counts(which)++;
	}
};
================================================================
cd /fs/vision01/tmb/src/char/
gcc -c -v frob.cc
Reading specs from /sym/gnu/lib/gcc-lib/sparc/2.2.2/specs
gcc version 2.2.2
 /sym/gnu/lib/gcc-lib/sparc/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 frob.cc /tmp/cca18614.i
GNU CPP version 2.2.2 (sparc)
 /sym/gnu/lib/gcc-lib/sparc/2.2.2/cc1plus /tmp/cca18614.i -quiet -dumpbase frob.cc -version -o /tmp/cca18614.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
gcc: Internal compiler error: program cc1plus got fatal signal 11

Compilation exited abnormally with code 1 at Thu Jul 23 17:22:08

Newsgroups: gnu.g++.bug
From: gjermuns@ifi.uio.no (Gjermund S|rseth)
Newsgroups: gnu.g++.bug
Subject: bug in g++
Date: 23 Jul 92 00:03:35 GMT
Distribution: gnu
Organization: GNUs Not Usenet

The following file:
/////////////////////////////////////////////////
int strlen(const char *t);

class X {
  char *text;
public:
  X(const X &v) { text = v.text; }

// The error is caused by this function declaration.
  X & xyz() { return *this; }

  operator int() { return strlen(t); }
};
//////////////////////////////////////////////////
Causes version 2.1 of gcc/g++ to enter a loop giving reeatedly the
following error message:

in conversion to type `X'
bad argument 0 for function `X::X (const class X&)' (type was int )

First of all I can't see why it should convert to type 'X' at all, since
this should be of type (X *) the expression *this is already of type 'X',
Secondly it obviously converts the *this to an int, due to the
'operation int()' declaration further below. I can't see why it should
first convert to int using this conversion operator and then in the next
moment complain that it has an argument of wrong type (int instead of X).

I may have got all this wrong, but in either case the compiler shouldn't
enter a loop with control-C as one of the few possibilities for escape.

Alf

PS: as I'm writing this bug report; is it possible to ask where one can
get info about further plans for g++: Will exception as in C++ 3.0 be
implemented (g++'s exception mechanism is not following the standard as
far as I can see), are there any plans for implementing templates?


E-mail: alfs@ifi.uio.no
Newsgroups: gnu.g++.bug
From: christos@deshaw.UUCP (Christos Zoulas)
Subject: What happened to the default copy constructor?
Organization: D. E. Shaw & Co.
Distribution: gnu
Date: Mon, 27 Jul 1992 17:21:28 GMT

This code works fine on cfront, but fails when compiled with g++-2.2.2

% cat foo
class foo {
  public:
   foo(int bar) { _bar = bar; }
  private:
   int _bar;
};


main()
{
   foo f(1);
   foo *g = new foo(f);
}

% g++ foo.C
Reading specs from /usr/local/lib/gcc-lib/sparc/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/sparc/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 foo.C /usr/tmp/cca02812.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/lib/gcc-lib/sparc/2.2.2/cc1plus /usr/tmp/cca02812.i -quiet -dumpbase foo.cc -version -o /usr/tmp/cca02812.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
foo.C: In function `int  main ()':
foo.C:14: bad argument 0 for function `foo::foo (int)' (type was class foo)

christos

Newsgroups: gnu.g++.bug
From: rob@cs.man.ac.UK (Robert Marshall)
Subject: g++-2.2.2 assertion violation
Reply-To: rajm@cs.man.ac.uk
Organization: Department of Computer Science, University of Manchester
Distribution: gnu
Date: Tue, 28 Jul 1992 07:55:17 GMT

leopard-robert-36>gcc-new -v gen_new.cc
Reading specs from /usr/local/gcc/gcc-lib/sparc-sun-sunos4/2.2.2/specs
gcc version 2.2.2
 /usr/local/gcc/gcc-lib/sparc-sun-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 gen_new.cc /usr/tmp/cca01986.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/gcc/gcc-lib/sparc-sun-sunos4/2.2.2/cc1plus /usr/tmp/cca01986.i -quiet -dumpbase gen_new.cc -version -o /usr/tmp/cca01986.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
cp-method.c:1256: failed assertion `get_binfo (DECL_CLASS_CONTEXT (cp->function), TREE_TYPE (TREE_TYPE (TREE_VALUE (parmtypes))), 1) == error_mark_node'
gcc-new: Internal compiler error: program cc1plus got fatal signal 6

This is gen_new.cc:
// ------------------------------------------------------------------
typedef union uptr * ptr;
enum ObjectType {a,b,c,d};

ObjectType Kind(const ptr n);

class ITEM;
class OBJECT_ITEM;
 
virtual class Entity {  
public:
  Entity(ObjectType Kind);
};

virtual class NAME_EXP :    public virtual Entity {
public:
  NAME_EXP (ptr Vif_ptr);
};
virtual class OBJ_NAME: public NAME_EXP{
public:
  OBJ_NAME(ptr Vif_ptr);
};

virtual class FORMAL_DESIGNATOR {
public:
  FORMAL_DESIGNATOR(ptr Vif_ptr);
};
virtual class TARGET : public virtual Entity {
public:
  TARGET (ptr Vif_ptr);
};

virtual class IMPORTED_ITEM  : public virtual Entity  {
  public:  
   IMPORTED_ITEM(ptr Vif_ptr);
   const virtual int has_id() const;
};
virtual class ITEM : public IMPORTED_ITEM{
public:
  ITEM (ptr Vif_ptr);
};

virtual class OBJECT_ITEM  : public ITEM,
                             public TARGET {
public:
};

class subp_param_decl: 
    public FORMAL_DESIGNATOR,
    public OBJECT_ITEM,
    public IMPORTED_ITEM {
public:
  subp_param_decl(ptr Vif_ptr);
 ~subp_param_decl();
  const int has_id() const { return IMPORTED_ITEM::has_id();}

};

--
------------------------------------------------------------------
Robert A.J.Marshall,		EMAIL: rmarshall@cs.man.ac.uk
Room 3.08, IT Building, Department of Computer Science,
University of Manchester, Oxford Road, Manchester, M13 9PL, U.K.
Tel: (+44) 61-275 6269          Fax: (+44) 61-275 6280
------------------------------------------------------------------

Newsgroups: gnu.g++.bug
From: heiko@uwesa.hanse.DE (Heiko Weber)
Subject: g++2.2.2, duplicate symbol: __CTOR_LIST__
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 21 Jul 1992 23:17:39 GMT

I am sure, thats not realy a bug, but every C++ program I try
to compile will result in the following:

ld: /usr/local/lib/gcc-lib/i386-sysv4/2.2.2/crtbegin.o: \
   fatal error: symbol `__CTOR_LIST__` multiply-defined, \
   also in file /usr/tmp/cca002e4.o
collect: /usr/bin/ld returned 1 exit status

What is the workaround ? I use libg++ Version 2.2

Thanks
   Heiko
--
| Heiko Weber jun. | heiko@uwesa.hanse.de | carrier: 049-4169-448 |
| D-2151 Sauensiek | Loehe 5 |  Germany   | voice:  049-4169-1366 |
+------------------+----------------------+-----------------------+

Newsgroups: gnu.g++.bug