HDTenEightyP/NetNews huggingface dataset:
From: dcb@us-es.SEl.DE
Subject: ARM p179
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 19 Nov 1992 18:42:04 GMT

Hello there,

Given the following code

class A 
{
public :
        A() ;
        ~A() ;
private :
        struct A1
        {
                int A::*        p ;
        } ;
        static A1       tbl[] ;
} ;

then I get the following from gcc 2.2.2 and gcc 2.3.1 on a Sun4

k19.cc:11: parse error before `['
k19.cc:11: field `tbl' has incomplete type

My reading of Page 179 Section 9.4 says that this code is legal. Most of the
other compilers I have access to agree with me.

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   Tel: +49 711 821 3841
130mph in the pouring rain, and you get flashed by a BMW for not going fast
enough. There is, of course, a Ferrari 512 on his tail flashing him.

Newsgroups: gnu.g++.bug
From: dcb@us-es.SEl.DE
Subject: bug report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 19 Nov 1992 19:23:20 GMT

Hello there,

Given the following code

class A
{
public :
        A() ;
        ~A() ;
private :
} ;

struct A1 {
                int A::*        p ;
} ;

static A1       tbl[] ;

then I think the last line is illegal, and most of the compilers
I have access to agree with me. GNU 2.2.2 and GNU 2.3.1 think the code
is ok. I didn't bother checking with the ARM, this time.

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   Tel: +49 711 821 3841

Newsgroups: gnu.g++.bug
From: hvaisane@cs.joensuu.fi (H. Vaisanen)
Subject: Bug or feature: shadowing a member of this
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 13:25:18 GMT

Should the compiler give this warning?

class Foo {
  int bar;
public:
  int Bar() const {return bar;};
};

main()
{
  int Bar; // `Bar' shadows a member of `this' ??
}
---

% g++ -Wshadow -c a.C
a.C: In function `int  main ()':
a.C:9: warning: declaration of `Bar' shadows a member of `this'
% g++ -v
Reading specs from /usr/local/Gnu/lib/gcc-lib/decstation-3100/2.3.1/specs
gcc version 2.3.1

Newsgroups: gnu.g++.bug
From: mrhagger@athena.mit.edu
Subject: Extraneous warning message
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 23 Nov 1992 06:11:11 GMT

I have found a simple C++ program which causes gcc to output an extraneous
warning message.  I am using emx version 0.8e for OS/2, under OS/2 v. 2.0.
The code and compiler output follow:
 
bug3.cc -----------------------------------------------------------------
#include <complex.h>
 
double foo(complex *a)
{
  return 0.0;
}
 
 
double bar(void)
{
  complex v[10];
  return foo(v);
}
 
 
-------------------------------------------------------------------------
Compiler output ---------------------------------------------------------
[c:\emx\gnu\bugs]gcc -v -Wall -c bug3.cc 2>bug3.rpt
gcc version 2.2.2
 cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__32BIT__ 
 -D__EMX__ -Di386 -D__32BIT__ -D__EMX__ -D__i386__ -D__32BIT__ -D__EMX__ 
 -D__i386 -Wall bug3.cc ./cca00078.i
GNU CPP version 2.2.2 (80386, BSD syntax)
 cc1plus ./cca00078.i -quiet -dumpbase bug3.cc -Wall -version -o ./cca00078.s
GNU C++ version 2.2.2 (80386, BSD syntax) compiled by GNU C version 2.2.2.
bug3.cc: In function `double  bar ()':
bug3.cc:13: warning: control reaches end of non-void function
 as -o bug3.o ./cca00078.s
 
[c:\emx\gnu\bugs]
-------------------------------------------------------------------------
 
I haven't checked whether the destructors for the array are called, but
the function bar() DOES return the correct result (also for non-trivial
return values, like in the longer program that this example is boiled down 
from).
 
Yours,
Michael Haggerty
mrhagger@athena.mit.edu
From: jmz@obsbec.dnet.circe.FR (Jean-Marc Zucconi)
Newsgroups: gnu.g++.bug
Subject: minor bug in g++-2.3.1
Date: 18 Nov 92 00:09:01 GMT
Article-I.D.: ciripa.199211172209.AA27938
Distribution: gnu
Organization: GNUs Not Usenet

Hello,

I have encountered a little bug in g++-2.3.1. The following program generates
an internal compiler error.

// file foo.cc
class foo {
private:
    int t[10];
public:
    int bar(int i) {
	return t(i); // `obvious' error: should be t[i]
    }
};
// end of file

$ g++ -c foo.cc
foo.cc: In method `int  foo::bar (int)':
foo.cc:6: component `t' is not a method
/utilisateurs/jmz/bin/gcc: Internal compiler error: program cc1plus got fatal
 signal 11

Of course, this is a consequence of the syntax error and I (we) can live with 
such a bug, but I would prefer a smarter exit.

Best regards,

      Jean-Marc

    ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
    Jean-Marc Zucconi             |    internet: jmz@obsbec.dnet.circe.fr
    Observatoire de Besancon      |        or    jmz@obsbea.dnet.nasa.gov
    F 25010 Besancon cedex        |    span:     obsbea::jmz
    ======================================================================
Newsgroups: gnu.g++.bug
From: kjhopps@mmm.COM (Kevin J Hopps)
Subject: g++ bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 22:42:35 GMT

I just finished installing g++ and libg++ on a "sparc-sun-sunos4.1", and I
think I have discovered a bug.

The example on the top of page 114 of the C++ ARM does not work inside a
class.  The enum in class "test" gives errors (see below), but the enum in
main works fine.
=======================> bug.cc <=======================
class test
{
    enum { d, e, f=e+2 };
};

int main()
{
    enum { d, e, f=e+2 };
}
=======================> end source <=======================

=======================> command & output <=======================
% g++ -v bug.cc
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.1/specs
gcc version 2.3.1
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.1/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 bug.cc /usr/tmp/cca06608.i
GNU CPP version 2.3.1 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.1/cc1plus /usr/tmp/cca06608.i -quiet -dumpbase bug.cc -version -o /usr/tmp/cca06608.s
GNU C++ version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
bug.cc:3: `e' undeclared, outside of functions
bug.cc:3: enumerator value for `f' not integer constant
=======================> end command & output <=======================

Thank you.
-- 
Kevin J. Hopps			e-mail:	kjhopps@mmm.com
3M Company			phone:	(612) 737-3300
3M Center, Bldg. 235-3B-16	fax:	(612) 737-2700
St. Paul, MN 55144-1000

Newsgroups: gnu.g++.bug
From: xjzhu@math.uwaterloo.ca (Xiaojun Zhu)
Subject: bug in template?
Keywords: parse error, template
Organization: University of Waterloo
Distribution: gnu
Date: Sun, 22 Nov 1992 16:54:34 GMT

Q: Gnu C++ has parse error on L<T> ? Is this due to a bug or incomplete 
   template support?

Symptom: The following example(consists of two short files) compiles fine under 
ATT C++ 3.0, but has parse error on line 8 of the first file when use g++.

Machine: MSDOS 

Version: djgpp109.zip (uploaded to Simtel on Nov2, 1992)

Command line: gcc -x c++ main.cc

My opinion: It seems to me that this version of Gnu C++ doesn't like us to use
            L<T>, L<T1, T2> etc. in the construction of template class.
            
Example:
file1: template.h

1 template<class T>
2 class L
3 {
4   T _t;
5 
6 public:
7   L(T t) : _t(t) {}
8   L(const L < T > & l) : _t(l._t) {}
9  ~L() {}
10 };

file2: main.cc
0. #include "template.h"
1 main()
2 {
3    L<int> x(2);
4 }


--------------------------------------------------------------
   A template version of signature class is under repair.
Symptom: I can't seem to be able to dynamically allocate it.

                                       xjzhu@math.uwaterloo.ca
--------------------------------------------------------------

Newsgroups: gnu.g++.bug
From: girod@tele.nokia.fi (Marc Girod)
Subject: definition of pure virtual destructor
Reply-To: marc.girod@ntc.nokia.com
Organization: kpd
Distribution: gnu
Date: Mon, 16 Nov 1992 10:34:54 GMT

Hi netters!

I am reading a very interesting book by Scott Meyers, 'Effective C++ -
50 specific ways to improve your programs and designs', 1992 Addison
Wesley, ISBN 0-201-56364-9.

I got so far as Item 14 page 47, where I found an advice to (under
some circumstances) declare a pure virtual destructor. Nothing
actually new there so far, but the author further notes that 'you must
provide a definition for the pure virtual destructor'.

That was new to me, but sounds very reasonable. Some small surprise
because I happen never to have experimented a crash because of failing
to do so. I try, and ... g++ refuses it!

The example:
------------------------------------------------------------
class foo {
public:
  virtual ~foo() = 0;
};

foo::~foo() {}
------------------------------------------------------------
The result:
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
pure.C: In method `foo::~foo ()':
pure.C:6: redefinition of `foo::~foo ()'
pure.C:3: here is the previous declaration of `foo::~foo ()'

Sorry if this had been reported already!
Regards!
--
+-----------------------------------------------------------------------------+
| Marc Girod - Nokia Telecommunications       Phone: +358-0-511 7703          |
| TL4E - P.O. Box 12                            Fax: +358-0-511 7432          |
| SF-02611 Espoo 61 - Finland              Internet: marc.girod@ntc.nokia.com |
|    X.400: C=FI, A=Elisa, P=Nokia Telecom, UNIT=TRS, SUR=Girod, GIV=Marc     |
+-----------------------------------------------------------------------------+

Newsgroups: gnu.g++.bug
From: anton@miro.COM (Jeff Anton)
Subject: g++ 2.3.1 optimization bug
Organization: Gnus Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 18:59:06 GMT

Here is a simple little program and problem.  When compiled with
optimization, the hex manipulator has no effect.
				Jeff Anton
				anton@miro.com
-----------

#include <iostream.h>

void
foo(ostream *o) {
    *o << o->flags() << endl;
    *o << hex << o->flags() << endl;
    *o << dec << o->flags() << endl;
}

void
bar(ostream &o) {
    o << o.flags() << endl;
    o << hex << o.flags() << endl;
    o << dec << o.flags() << endl;
}

int
main(void)
{
    cout << cout.flags() << endl;
    cout << hex << cout.flags() << endl;
    cout << dec << cout.flags() << endl;

    foo(&cout);
    bar(cout);

    cout << cout.flags() << endl;
    cout << hex << cout.flags() << endl;
    cout << dec << cout.flags() << endl;
}



grail:anton[364]: g++ -v test.cc
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.3/2.3.1/specs
gcc version 2.3.1
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.3/2.3.1/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 test.cc /usr/tmp/cca02430.i
GNU CPP version 2.3.1 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.3/2.3.1/cc1plus /usr/tmp/cca02430.i -quiet -dumpbase test.cc -version -o /usr/tmp/cca02430.s
GNU C++ version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
 as -o /usr/tmp/cca024301.o /usr/tmp/cca02430.s
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.3/2.3.1/ld -e start -dc -dp /lib/crt0.o -L/usr/local/lib/gcc-lib/sparc-sun-sunos4.1.3/2.3.1 -L/usr/local/lib /usr/tmp/cca024301.o -lg++ -lgcc -lc -lgcc
grail:anton[365]: a.out
536870918
20000006
536870918
84896
14ba0
84896
84896
14ba0
84896
536870918
20000006
536870918
grail:anton[366]: g++ -O2 -v test.cc
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.3/2.3.1/specs
gcc version 2.3.1
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.3/2.3.1/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 -D__OPTIMIZE__ test.cc /usr/tmp/cca02453.i
GNU CPP version 2.3.1 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.3/2.3.1/cc1plus /usr/tmp/cca02453.i -quiet -dumpbase test.cc -O2 -version -o /usr/tmp/cca02453.s
GNU C++ version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
 as -o /usr/tmp/cca024531.o /usr/tmp/cca02453.s
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.3/2.3.1/ld -e start -dc -dp /lib/crt0.o -L/usr/local/lib/gcc-lib/sparc-sun-sunos4.1.3/2.3.1 -L/usr/local/lib /usr/tmp/cca024531.o -lg++ -lgcc -lc -lgcc
grail:anton[367]: a.out
536870918
536870918
536870918
84896
84928
84880
84896
84928
84880
536870918
536870918
536870918

Newsgroups: gnu.g++.bug
From: parry@yoyo.cc.monash.edu.au (Tom J Parry)
Subject: Problems with include files on a sparc.
Keywords: include,stdlib.g++,sparc ,sun/os 4.1.1
Organization: Monash University General Access Unix
Distribution: gnu
Date: Fri, 20 Nov 1992 02:34:44 GMT

Since installing g++ 2.3.1 on our sun here, I have had problems including
stdlib.h

eg:

#include <stdlib.h>
main()
{
}

produces:
Reading specs from /u/dibbler0/gnu/lib/gcc-lib/sparc/2.3.1/specs
gcc version 2.3.1
 /u/dibbler0/gnu/lib/gcc-lib/sparc/2.3.1/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 /dibbler0/hon/darrenp/bug/t.cc /usr/tmp/cc007631.i
GNU CPP version 2.3.1 (sparc)
 /u/dibbler0/gnu/lib/gcc-lib/sparc/2.3.1/cc1plus /usr/tmp/cc007631.i -quiet -dumpbase t.cc -version -o /usr/tmp/cc007631.s
GNU C++ version 2.3.1 (sparc) compiled by CC.
In file included from /dibbler0/hon/darrenp/bug/t.cc:1:
/u/dibbler0/gnu/lib/g++-include/stdlib.h:23: warning: type specifier omitted for parameter
/u/dibbler0/gnu/lib/g++-include/stdlib.h:24: warning: type specifier omitted for parameter
/u/dibbler0/gnu/lib/g++-include/stdlib.h:24: `void' in parameter list must be entire list
/u/dibbler0/gnu/lib/g++-include/stdlib.h:25: `size_t' undeclared, outside of functions
/u/dibbler0/gnu/lib/g++-include/stdlib.h:25: `size_t' undeclared, outside of functions
/u/dibbler0/gnu/lib/g++-include/stdlib.h:44: `size_t' undeclared, outside of functions
/u/dibbler0/gnu/lib/g++-include/stdlib.h:45: parse error before `('
/u/dibbler0/gnu/lib/g++-include/stdlib.h:45: warning: data definition has no type or storage class
/u/dibbler0/gnu/lib/g++-include/stdlib.h:50: warning: type specifier omitted for parameter
/u/dibbler0/gnu/lib/g++-include/stdlib.h:50: warning: type specifier omitted for parameter
/u/dibbler0/gnu/lib/g++-include/stdlib.h:50: `void' in parameter list must be entire list
/u/dibbler0/gnu/lib/g++-include/stdlib.h:52: warning: type specifier omitted for parameter


This all goes away if I do: typedef unsigned short size_t 
before including stdlib.h Just wondering if anyone else had a similar problem.

-- 
Tom J Parry.
Your reality is a figment of my imagination.

Newsgroups: gnu.g++.bug
From: jr@efi.sintef.NO (Jarand Roeynstrand)
Subject: Scope operator bug.
Organization: SINTEF EFI
Distribution: gnu
Date: Fri, 20 Nov 1992 09:01:09 GMT

I usually use a cfront compiler, but suddenly i decided to run some code 
through a g++ compiler as a portability test. I got the following problem:
Consider the code:

class a
{
    public:
	int x;
	void SetX( int xi ) { x=xi; }
};

class b
{
    public:
	a y;
	void SetY( a *y );
};

void b :: SetY( a *y )
{

#ifndef gcc
    b :: y.SetX( y->x ); // This code does not compile under gcc. Line 20.
#else
    this->y.SetX( y->x );  // This code compiles under both compilers.
#endif

}

The problem is, of course,that the parameter called y hides b's the member
object y, and that problem is resolved by the notation b::y, only that this
does not work on gcc.

gcc-2.3.1 complains:

testing.C: In method `void  b::SetY (class a*)':
testing.C:20: object in '.' expression is not of aggregate type.

This seems to be a compiler bug.


-- 
	Jarand Roeynstrand			Phone: 	+47-7-597275 (EFI)
	EFI						+47-7-962355 (Home)
	N-7034 Trondheim		
	Norway					email: jr@efi.sintef.no
	
	
		

	

Newsgroups: gnu.g++.bug
From: nelson@berlioz.nsc.com (Taed Nelson)
Subject: @ Incorrect warning message
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 22 Nov 1992 01:26:39 GMT

I'm running a > 2.0 G++ on a Sun SparcStation w/ SunOS 4.0.1.

I'm not sure of the version since "g++ -version" no longer works.

The following code will generate:
	test2.cc:7: warning: ordered comparison between signed and unsigned
  when clearly, it is comparing two unsigned values.  The problem only arises
  with unsigned characters.

The command line is:
	g++ -I/usr/local/gnu/include/g++ -ansi -Dunix -Dsun -Wall
		-fno-strict-prototype -DDEBUG -g -Wunused test2.cc

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

int main (void)
{
	unsigned int uint = 5;
	unsigned char uchar = 6;

	if (uint < uchar) {
		uchar = uint;
	}

	return (0);
}

Newsgroups: gnu.g++.bug
From: dgreen@cs.ucla.edu (Dan R. Greening)
Subject: G++ 2.3.1 bug: operator[] returns bizarrely behaving type?
Organization: UCLA, Computer Science Department
Distribution: gnu
Date: Mon, 16 Nov 1992 02:43:12 GMT

The following program prints out

  0x2290
  good things
  most things

but I think it should print out

  most things
  good things
  most things

Here is the program:

-------------------------- cut here ------------------
#include <iostream.h>
class thing
{
  public:
    char* const& operator[](const int& b)
    {
	static char* mostthings = "most things";
	return mostthings;
    }
};

main()
{
    thing a;
    char * const b = "good things";
    char * const& c = a[3];
    
    cout << a[3] << "\n";		// a[3] and b should be same type
    cout << b << "\n";
    cout << c << "\n";
}
-- 
____
\  /Dan Greening	Software Transformation	  1601 Saratoga-Sunnyvale Rd
 \/ dgreen@cs.ucla.edu	(408) 973-8081 x313	  Cupertino, CA 95014

Newsgroups: gnu.g++.bug
From: straw@cam.NIst.GOV (Mike_Strawbridge_x3852)
Subject: template problem
Followup-To: gnu.g++.bug
Organization: National Institute of Standards & Technology, Gaithersburg, MD
Distribution: gnu
Date: Fri, 20 Nov 1992 13:12:57 GMT

We just installed gcc-2.3.1 and libg++-2.2 on our Suns running SunOS4.1.3.

When compiling the following simple program I get the messages:

as: "/usr/tmp/cca05505.s", line 253: error: redefinition of symbol "_MX"
as: "/usr/tmp/cca05505.s", line 303: error: redefinition of symbol "_MN"

Can anyone help me? Is this a bug in gcc-2.3.1?

Thanks.

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

#include <stdlib.h>
#include <iostream.h>

template<class T>
inline T MX(T& a, T& b)
{return a > b ? a : b;}

template<class T>
inline T MN(T& a, T& b)
{return a < b ? a : b;}


main() {
int i, j, k;
float x,y,z;

x = 3.2;
y = 1.0;
i = 10;
j = 12;
 cout << "(i,j) =" << "(" << i << "," << j << ")" << "\n" ;
 cout << "(x,y) =" << "(" << x << "," << y << ")" << "\n" ;

 k = MX(i,j);
 z = MX(x,y);
 cout << "The max is " << k << "\n" ;
 cout << "The max is " << z << "\n" ;

 k = MN(i,j);
 z = MN(x,y);
 cout << "The min is " << k << "\n" ;
 cout << "The min is " << z << "\n" ;

       }


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

NAME:   Michael Strawbridge             	TELE: (301) 975-3852
USMAIL: National Institute of Standards 	ARPA: straw@cam.nist.gov
		and Technology            	UUCP: uunet!cme-durer!straw
        Rm. B-146, Bldg. 225
        Gaithersburg, MD  20899


Newsgroups: gnu.g++.bug
From: dumesnil@etca.fr (Antoine de Maricourt)
Subject: g++ bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 23 Nov 1992 12:32:15 GMT

Hi again, 

here is another bug : (gcc 2.3.1 sparc station 2 as before)

>cat bug1.cxx
typedef unsigned long  u_long;

class OBJ {
 protected:

  union {
    u_long  u_immediate;
    long    s_immediate;
    void   *extended;
  };
};

class SYMBOL : OBJ {
 public: 
  SYMBOL (const char *name);
};

/*
 * PRIVATE 
 */

class _EXTENDED {
 protected:
  long head;
};

class _SYMBOL : _EXTENDED {
  long name;
  long value;
  long plist;
};

SYMBOL::SYMBOL (const char *str) {
  _SYMBOL *symbol =  new _SYMBOL;

  extended = (void *) symbol;
}

>gcc -c bug1.cxx
bug1.cxx: In method `SYMBOL::SYMBOL (const char *)':
bug1.cxx:38: Internal compiler error 95.
bug1.cxx:38: Please report this to `bug-g++@prep.ai.mit.edu'.

Newsgroups: gnu.g++.bug
From: jeremy@sw.oz.AU (Jeremy Fitzhardinge)
Subject: GNU C++ 2.3.1 gets signal 10 with undeclared variable in class definition
Organization: Softway Pty Ltd
Distribution: gnu
Date: Tue, 24 Nov 1992 06:15:24 GMT

Hi!  Have a look at this:

gcc 2.3.1 running on a SparcStation1 under SunOS 4.1.1 fails with this
program:

--x.cc--
class x
{
	int foo;
	char glop[plim];
public:
	x::x();
};

x::x()
{
	foo = fop;
}
----

This is the output of a compile run:
: chao:p7; gcc -c -v x.cc
Reading specs from /usr/local/lib/gcc-lib/sparc-sunos4/2.3.1/specs
gcc version 2.3.1
 /usr/local/lib/gcc-lib/sparc-sunos4/2.3.1/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 -I/usr/local/libg++/2.2/include x.cc /tmp/cca14824.i
GNU CPP version 2.3.1 (sparc)
 /usr/local/lib/gcc-lib/sparc-sunos4/2.3.1/cc1plus /tmp/cca14824.i -quiet -dumpbase x.cc -version -o /tmp/cca14824.s
GNU C++ version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
x.cc:4: `plim' undeclared, outside of functions
gcc: Internal compiler error: program cc1plus got fatal signal 10
: chao:p7; adb /usr/local/lib/gcc-lib/sparc-sunos4/2.3.1/cc1plus core
core file = core -- program ``cc1plus''
SIGBUS 10: bus error
$c
_finish_struct(0x19d618,0x1a1a40,0x0,0x1a19d8,0x15,0x0)	+ 724
_yyparse(0x19d618,0x14d,0xf7ffe572,0xf7ffe568,0xc8,0x0)	+ 3184
_output_file_directive(0xf7ffea62,0x7f428,0x7f448,0x80620,0x1,0x22) + ba0
_main(0x8,0xf7ffe8a4,0xf7ffe8c8,0x170000,0x0,0x0) + e40
: chao:p7; 

	J

--
jeremy@sw.oz.au ph:+61 2 698 2322-x122 fax:+61 2 699 9174
I'm sorry I sound calm, I'm really quite hysterical.

Newsgroups: gnu.g++.help,comp.lang.c++
From: dechc00@tohi.DMI.USherb.Ca (CHRISTIAN DECHAMPLAIN)
Subject: Re: Where do templates go?
Organization: Universite de Sherbrooke -- departement de Mathematiques et
	d'Informatique
	<1992Nov13.185422.28026@muddcs.claremont.edu>
Date: Sun, 15 Nov 1992 18:44:45 GMT


Well the g++ template expansion seems to create static functions, as with
borland's static definition option.  I'm pissed, the template object code
gets duplicated many many times.

I understand the reasons why nobody wants to change the linkers, then how
about a pre-linker!

--
Christian Dechamplain|
(819) 563-8951       |
dechc00@dmi.usherb.ca|
----------------------
Newsgroups: gnu.g++.help,comp.lang.c++
From: c1dje@watson.ibm.com (David Edelsohn)
Subject: Re: demangeling
Date: Mon, 23 Nov 1992 22:05:38 GMT
Reply-To: c1dje@tweetie (David Edelsohn)
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center
Followup-To: gnu.g++.help

	A collection of subroutines to demangle C++ symbol names is
included with GCC (G++) called cp-dem.c.  Simply write a driver program to
call the entry point (and provide for the xmalloc/xalloc calls) and you're
on your way.

					David
===============================================================================
David Edelsohn                                      T.J. Watson Research Center
c$dje@watson.ibm.com                                P.O. Box 218
+1 914 945 3011 (Tieline 862)                       Yorktown Heights, NY 10598
"The Church doesn't have problems with sex; the world does" -- Vatican official
"A good theory should fit on a T-shirt" -- Astronomer at Jan 1992 AAS meeting

Newsgroups: gnu.g++.help,comp.lang.c++
From: bs@wucs1.wustl.edu (Bala SWAMINATHAN)
Subject: ET++, anyone?
Keywords: GUI, ET++, g++, C++
Organization: Washington University, St. Louis MO
Date: Mon, 23 Nov 1992 21:54:41 GMT

We have the ET++ graphics application framework
in one of machines.

The problem is that we do not have enough (actually nothing)
documentation of how to use different classes. There are
so many classes and methods and it is quite painful going
through them without knowing why/what is that for.

Is there any documentation available somewhere?
In case I must hack and understand such a Class library,
what is the ``procedure'' I can follow so that it is
somewhat less monstrous of a task.

Any pointers would be appreciated.

S_Bala


Xref: sparky gnu.g++.help:1449 comp.lang.c++:16472