HDTenEightyP/NetNews huggingface dataset:
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  template <class T, T ...> important!
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 10 Nov 1992 21:16:08 GMT

For better and worst, we will most likely follow whatever ANSI C++
says.  If you really want to see different behavior from standard
behavior then, I suggest you see about getting your opinions heard by
the ANSI C++ committee.  See comp.std.c++ for more details.

> Date: Mon, 14 Sep 92 18:17:51 +0200
> From: dak@pool.informatik.rwth-aachen.de (David Kastrup)
> Message-Id: <9209141617.AA01219@messua>
> To: bug-g++@prep.ai.mit.edu

> There was some discussion going on whether the above construction
> was legal.
> Although it is not explicitly stated in ARM, it is a very important
> construction, because:
> Templates cannot be nested. Suppose you have a sort template that
> should work as fast as possible on linked lists. It would look something
> like:
> template <class T, T * T::*link>
> You could modify the link parameter to be a parameter for the
> subroutine, but then you are replacing a compile time constant
> by a variable which would usually assume one value anyhow.

> Consider defining a Fourier transform working on arbitrary fields
> with roots of 1.

> Then you could use something like
> template <class Field, unsigned N, Field * Nthroot>
> and use it something like
> Complex const NR = exp(2*pi*Complex(0,1)/N);
> fft<Complex, 1024, &NR>.transform(...
> or
> Modular<64513> NR = 9; //Value is wrong
> fft<Modular<64513>, 1024, &NR>.transform(...

> Although it would work with complex numbers just as fast as usual,
> it would without modification work even faster with other fields
> as a base.

> Other classes and functions might need other information
> necessarily not included in the basic type, but being constant.

> PLEASE let the template scopes begin immediately after their declaration,
> not after the closing >.

Newsgroups: gnu.g++.bug
From: jcasey@netcom.com (John Casey)
Subject: gcc.2.2.2 lost typecast info for gdb (sco-sysv.3.2)
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Distribution: gnu
Date: Wed, 11 Nov 1992 03:08:03 GMT

gdb returns :

$1 = (struct <opaque> *) some addr


when trying to print out  a complex structurei or C++ class.  This
does not happen all of the time, however.  I am usually able to fix the 
problem by explicit typecasting, 

(gdb) p (struct name *) var.



Am I doing something wrong or is this how gdb is supposed to work?
I can send you a specific example if that helps.

Thanks,

John Casey



Newsgroups: gnu.g++.bug
From: rrh@tera.com (Robert R. Henry)
Subject: type cast of qualified const member breaks g++2.3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 10 Nov 1992 19:08:08 GMT

When the following program is compiled using g++2.3.1,
host=sparc, target=sparc, the construct
  j = (int)Thing::N;
generates assembly code that references the global N (in a load);
	sethi %hi(_N),%o0
	ld [%o0+%lo(_N)],%o1
this reference is never resolved;
whereas
  i = Thing::N;
does not.

This is a bug introduced into g++2.3.1; it isn't there in g++2.2.2

------------------------------------------
#include <stdio.h>
class Thing{
private: int x;
public: const int N = -1;
  Thing(int y);
};

class Bar{ public: void doit(void); };

void Bar::doit(void)
{
  int i, j;
  i = Thing::N;
  printf("i = %d\n", i);

  j = (int)Thing::N;
  printf("i = %d\n", j);
}
Thing::Thing(int y) { x = y; }
main(){ Bar x; x.doit(); }
From: bard@cutter.ssd.loral.com (J H Woodyatt)
Newsgroups: gnu.g++.bug
Subject: Release schedule query
Date: 12 Nov 92 18:11:59 GMT
Reply-To: bard@cutter.ssd.loral.com
Distribution: gnu
Organization: Abiogenesis 4 Less

Because of bugs introduced in the C++ part of GCC-2.3.1 since the
release of GCC-2.2.2, switching to the newer release will involve a
fair bit of working around.  Enough that I need to make an informed
decision about whether to use the new release or stick with the old
release.

Could one of the GCC maintainers please email me a guess for when the
next release of GCC is scheduled.  If it will only be a couple of
weeks before GCC-2.3.2 (or whatever) is released, I'll wait for it and
continue using GCC-2.2.2, otherwise I'll embark on the task of working
around the GCC-2.3.1 bugs, so I can get rid of the workarounds for bugs
in GCC-2.2.2.

Also, a one or two line tip on where to start if I want to learn how
the compiler works so I have a chance of making fixes myself, would
be a capital idea.  I'm particularly interested in understanding the
C++ front end.  (I have a copy of the Dragon book and I've been
reading up -- I figger I can probably get clued in without having to
devote years of my life to the task.)

ObSequiousFlattery: Great compiler!

-- 
+---------------------------+  ``Democracy is the theory that the common 
| J H Woodyatt              |  people know what they want, and deserve to
| bard@cutter.ssd.loral.com |  get it good and hard.''
+---------------------------+                              -- H L Mencken
Newsgroups: gnu.g++.bug
From: blevy@esd.dl.nec.COM (Britt Levy)
Subject: gcc-2.3.1: no member function `istream: :operator >>'
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 18:41:27 GMT

The following code was written to narrow down a compiler error found
when trying to compile Rogue Wave's Tools H++ with gcc-2.3.1 and
iostream.h from libg++-2.2. The code compiles and runs correctly
using SCO/HCR's port of cfront 2.1 and their iostream.h.

// g++ -v -g -O cinop.C -o cinop

#include <iostream.h>

main()
{
   int anInt;
   cin >> anInt;				  // ok
   cout << anInt << endl;
   cout.operator<<(anInt);                        // error: no member function
						  // `ostream::operator <<' 
   cin.operator>>(anInt);			  // error: no member function
						  // `istream::operator >>' 
   cout << anInt << endl;
}

cd /blevy/c++/bugtest/
g++ -v -g -O cinop.C -o cinop
Reading specs from /files/vol/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.1/specs
gcc version 2.3.1
 /files/vol/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 -D__OPTIMIZE__ -g cinop.C /usr/tmp/cca02974.i
GNU CPP version 2.3.1 (sparc)
 /files/vol/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.1/cc1plus /usr/tmp/cca02974.i -quiet -dumpbase cinop.cc -g -O -version -o /usr/tmp/cca02974.s
GNU C++ version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
cinop.C: In function `int  main ()':
cinop.C:10: no member function `ostream::operator <<'
cinop.C:12: no member function `istream::operator >>'

Compilation exited abnormally with code 1 at Thu Nov  5 11:59:50

------------------------------------------------------------------
Britt Levy, NEC AMERICA INC             1525 W WALNUT HILL LN
blevy@esd.dl.nec.com		        IRVING TX 75038-3793
					Phone: (214) 518-3829
------------------------------------------------------------------

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Forward declaration of templates fail
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 08:43:37 GMT

This problem has been fixed, and should not exist in the next release
of gcc.

> Message-Id: <9208061950.AA01898@life.ai.mit.edu>
> Date: Thu, 6 Aug 92 15:50:30 EDT
> From: w2martin@watson.ibm.com
> To: bug-gcc@prep.ai.mit.edu

> I am using the following:
> IBM RS 6000 running AIX 3.2
> g++ I believe version gcc-2.2.2 (it knows about templates)

> ----------------------------------------------------------------------------
> The following program runs without any problems:
> //template<class T> int myfunc(T x);
> template<class T> int myfunc(T x) {
>   return 2;
> }

> int myfunc2(int x);
> int myfunc2(int x) {
>  return 2;
> }

> main() {
>  myfunc(3);
>  myfunc2(0);
> }
> ----------------------------------------------------------------------------

> Now uncomment the first line to create a forward declaration, I get the
> following problem:

> bart /u/w2martin/c : g++ g++test.C
> 0706-317 ERROR: Unresolved or undefined symbols detected:
>                  Symbols in error (followed by references) are
>                  dumped to the load map.
> .myfunc__Fi
> collect: /bin/ld returned 8 exit status

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

> What is wrong? The IBM xlC C++ compiler accepts the same code, but I want
> to use g++ since we have it at MIT.

> If you could help me, write to w2martin@watson.ibm.com OR to
>                                martins@athena.mit.edu
From: mrs@cygnus.com (Mike Stump)
Newsgroups: gnu.g++.bug
Subject: Re:  Template problem with gcc 2.2.2
Date: 6 Nov 92 09:02:06 GMT
Article-I.D.: cygnus.9211060902.AA02700
Distribution: gnu
Organization: GNUs Not Usenet

Actual test cases are much preferred, over code descriptions.

The first problem has been fixed.  The second is probably fixed.  The
last one I cannot even guess at!

> Message-Id: <9208200110.AA23792@life.ai.mit.edu>
> Date: Wed, 19 Aug 92 17:57:49 MST
> From: "Andrew L. Gross" <fletch@vnet.ibm.com>
> To: bug-gcc@prep.ai.mit.edu

> I am having a problem with templates on gcc 2.2.2.  One of the problem
> arises when I have a "const" method inside my template.  Removing the
> "const" gets rid of the problem.

> Another problem occurs when I use "static" member functions.  This problem
> will also go away when the "static" is removed, but this changes the
> entire program.

> The error that comes up for both is
> [filename]: template for methode `[method name]' doesn't match any in class
>     `[Template Name]<[Instance Name]>'

> Lastly, I got a
> : method `__opP *13' not found in class `Template<XXX>'
Newsgroups: gnu.g++.bug
From: tracey@cs.wm.edu (Tracey Beauchat)
Subject: g++ fatal error
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 09:52:44 GMT

The follow code (well, plus more method definitions, etc) causes
a fatal compiler error and dumps core:

tracey@il> g++ -c new.c
cp-decl.c:9961: failed assertion `current_class_decl != NULL_TREE && TREE_CODE (current_class_decl) == PARM_DECL'
/usr/local/gnu/bin/gcc: Internal compiler error: program cc1plus got fatal signal 6
tracey@il>

The problem is that the "element" method is defined twice, once
inline.  I imagine this error should be caught, and the compiler
should not crash.  I have not included all of the source code since
the cause of the problem is known.

-Tracey

-------------------------------------------------------------------
                        Tracey A. Beauchat
-------------------------------------------------------------------
*********   *********   ********
*********   ***   ***   ***   ***    The College of William & Mary
   ***      *********   ********     Department of Computer Science
   ***      ***   ***   ***   ***    Williamsburg, VA  23185
   ***      ***   ***   ********
-------------------------------------------------------------------
       EMAIL: tracey@cs.wm.edu         PHONE: (804)221-3468
-------------------------------------------------------------------
         <-[ " The truth is a virus! " - Harry Hardon ]->


----------------------- CUT HERE --------------------------

--- SOME INCLUDES, ETC ---

template <class dtype>
class matrix
 {
  dtype ** p;
  int s1, s2;
 public:
  int ub1, ub2;
  matrix(matrix &);
  matrix(dtype, int, int);
  matrix(int, int, ...);
  matrix(const char, int, int, float);	// Create a rotation matrix, 'r' for
					// radians, 'd' for degrees
  ~matrix();
  dtype& element(int i, int j); {return p[i][j];}// Return a certain element
  void mmpy(matrix& a, matrix& b);
  friend ostream& operator << (ostream&, matrix&);	// Output a matrix
  friend istream& operator >> (istream&, matrix&);	// Input a matrix
  void fill(dtype);
  matrix& operator=(matrix&);		// Assignment operator for matrix
  matrix& operator!();		        // Transpose operator for matrix
  matrix  operator*(matrix&);		// Matrix multiplication
  matrix& operator+(matrix&);		// Matrix addition
  matrix& operator-(matrix&);		// Matrix subtraction
 };


--- SOME METHOD DEFINITIONS ---


 template <class dtype>
 dtype& matrix<dtype>::element(int i, int j)
  {
   if (i < 0 || i > ub1 || j < 0 || j > ub2)
    matrixquit(2);

   return(p[i][j]);
  }


--- MORE METHOD DEFINITIONS ---


Newsgroups: gnu.g++.bug
From: hvaisane@cs.joensuu.fi (H. Vaisanen)
Subject: Internal compiler error 116
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 12 Nov 1992 14:54:27 GMT

This program generates Internal compiler error 116

class A;
typedef double (A::*FUNC)(double x);


class A {
public:
  double f(double x);
  void b(FUNC f, double y);
};

void A::b(FUNC f, double y)
{
  f(y);          // WRONG
  (this->*f)(y); // right
}

--------

% g++ -Wall -lg++ -L/usr/local/Gnu/lib A.C -o A
A.C: In method `void  A::b (auto double (class A::*)(double ), double)':
A.C:13: Internal compiler error 116.
A.C:13: Please report this to `bug-g++@prep.ai.mit.edu'.

Compilation exited abnormally with code 1 at Thu Nov 12 17:52:21

% gcc -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: dewerk@yosemite.csufresno.edu (<dewerk@yosemite.csufresno.edu>)
Subject: sys/wait.h problem
Organization: California State University, Fresno
Distribution: gnu
Date: Sat, 7 Nov 1992 09:13:51 GMT

while using g++ (version unknown) i came across a problem with one of the
include files (sys/wait.h to be exact)...  

the problem is in the wait3() and wait4() prototyping lines...  it seems
that WaitStatus is undefined...  any help would be appreciated...  i'll
include the file sisnce it isn't too long...

thanks in advance...

 -- Paul-Joseph

--- start: sys/wait.h ---
#ifndef wait_h

#include <sys/resource.h>

#define wait WaitStatus

extern "C" {

#ifdef VMS
#include "GNU_CC_INCLUDE:[sys]wait.h"
#else
#include "//usr/include/sys/wait.h"
#endif

#undef wait

#ifndef wait_h
#define wait_h 1
#endif

extern int wait3(WaitStatus*, int options, struct rusage*);
extern int wait4(int, WaitStatus*, int, struct rusage*);
}

#endif
--- end: sys/wait.h ---

                                * - * - *

Paul-Joseph "Dragon" de Werk        | "Therefore you shall love the Lord
Department of Computer Science      | your God with all your heart, with
California State University, Fresno | all your soul, with all your mind,
dewerk@csufres.CSUFresno.EDU        | and with all your strength." Mk 12, 30

Newsgroups: gnu.g++.bug
From: lewis@sophists.COM
Subject: Parsing templates with gcc 2.3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 10 Nov 1992 13:05:32 GMT

        Getting rid of the parameter to ArrayNode::CTOR () makes
everything compile OK.

        Getting rid of the DTOR also makes things compile.
I've tried dozens of different syntaxes to try to get something
like this to compile. Is there any syntax gcc 2.3.1 will accept
for a templated class with CTOR (with arguments) and DTOR????



/*
 * This template code fails to compile with g++ 2.3.1.
 *
 * Compiled as:
 *		g++ -c Bug.cc
 *
 * Produces:
 * 	Bug.cc:18: inconsistent return types for method `ArrayNode' in class `ArrayNode<int>'
 * 	/usr/local/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11
 *
 */
template    <class  T>  class   ArrayNode {
    public:
        ArrayNode (int a);
        ~ArrayNode ();

        T   fItem;
};

template    <class  T>      ArrayNode<T>::ArrayNode (int a)
{
}
template    <class  T>      ArrayNode<T>::~ArrayNode ()
{
}

ArrayNode<int> f(1);
Lewis Gordon Pringle, Jr.                                (lewis@sophists.com)


Newsgroups: gnu.g++.bug
From: tmcconne@sedona.intel.com (Tom McConnell~)
Subject: -g option on NCR SVR4?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 8 Nov 1992 10:13:44 GMT

    System   : NCR i486 (3350)
    OS       : SVR4 version 2
    Software : gcc-2.3.1, libg++-2.2

  I have recently ported gcc-2.3.1 and libg++-2.2 to an NCR i486 box running
SVR4. The problem I am having is that I cannot link anything compiled with g++
with debugging turned on. I seem to remember that libg++-2.2 will not build
with "-g" turned on, is this the same problem?

  gcc-2.3.1 with gdb-4.7 will accept the "-g" option, and everything
seems to work fine. However, when I link with libg++ I always get this error:

    Undefined                       first referenced
     symbol                             in file
    .L_T51                              /usr/tmp/cca004XE1.o
    ld: time: fatal error: Symbol referencing errors. No output written to time

  Am I just out of luck?

  Here is a sample:

redondo> cat tmp.C
main()
{
}
redondo> g++ -Wall tmp.C -o fred
redondo> g++ -v -g -Wall tmp.C -o fred
Reading specs from /stor/gnu/iAWS/lib/gcc-lib/i486-ncr-sysv4/2.3.1/specs
gcc version 2.3.1
 /stor/gnu/iAWS/lib/gcc-lib/i486-ncr-sysv4/2.3.1/cpp -lang-c++ -v -undef
 -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Di386 -Dunix -D__svr4__ -D__i386__
 -D__unix__ -D__svr4__ -D__i386 -D__unix -D__svr4__ -Asystem(unix) -Acpu(i386)
 -Amachine(i386) -g -Wall tmp.C /usr/tmp/cca004Uy.i
GNU CPP version 2.3.1 (i386 System V Release 4)
 /stor/gnu/iAWS/lib/gcc-lib/i486-ncr-sysv4/2.3.1/cc1plus /usr/tmp/cca004Uy.i
 -quiet -dumpbase tmp.cc -g -Wall -version -o /usr/tmp/cca004Uy.s
GNU C++ version 2.3.1 (i386 System V Release 4) compiled by GNU C version
 2.3.1.
 /usr/ccs/bin/as -V -Qy -o /usr/tmp/cca004Uy1.o /usr/tmp/cca004Uy.s
as: Standard C Development Environment  (SCDE) 5.0  04/19/90
 /usr/ccs/bin/ld -V -Y P,/usr/ccs/lib:/usr/lib -Qy -o fred /usr/ccs/lib/crt1.o
 /usr/ccs/lib/crti.o /usr/ccs/lib/values-Xa.o
 /stor/gnu/iAWS/lib/gcc-lib/i486-ncr-sysv4/2.3.1/crtbegin.o
 -L/stor/gnu/iAWS/lib/gcc-lib/i486-ncr-sysv4/2.3.1 -L/usr/ccs/bin
 -L/usr/ccs/lib -L/stor/gnu/iAWS/lib /usr/tmp/cca004Uy1.o -lg++ -lgcc -lc
 /stor/gnu/iAWS/lib/gcc-lib/i486-ncr-sysv4/2.3.1/crtend.o /usr/ccs/lib/crtn.o
 -lgcc
ld: Standard C Development Environment  (SCDE) 5.0  04/19/90
Undefined                       first referenced
 symbol                             in file
.L_T51                              /usr/tmp/cca004Uy1.o
ld: fred: fatal error: Symbol referencing errors. No output written to fred


  Thanks for any help.

    Cheers,

    Tom McConnell.

 Tom McConnell          |     Internet: tmcconne@sedona.intel.com
 Intel, Corp. C3-91     |     Phone: (602)-554-8229
 5000 W. Chandler Blvd. | The opinions expressed are my own. No one in 
 Chandler, AZ  85226    | their right mind would claim them.

Newsgroups: gnu.g++.bug
From: timhu@ico.isc.com (Timothy Hu)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 10 Nov 1992 03:18:30 GMT

I'm trying to install g++ v1.42.0 on an RS/6000 running AIX 3.2. There is no
entry in the config script for this machine.

Where do I go from here?

Thanks,
Tim


Newsgroups: gnu.g++.bug
From: cat@polal.polito.it (Antonio Lioy)
Subject: gcc.2.3.1 not searching default libraries
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 12 Nov 1992 09:57:00 GMT

I have noticed the following difference between gcc.2.2.2 and gcc.2.3.1 when
used to compile and link C++ program on a DECstation running Ultrix 4.2.
By looking at the output generated by the "-v" option I see that the older
version automatically passed a "-L" option to the loader ld to search the
default library directory for libg++, while the new compiler doesn't,
forcing the user to explicitly specify the path for libg++.

Can you please tell me if this a new feature or a bug?

Thank you in advance for your kind reply.

+---------------------------------------------------------------+
| Antonio Lioy                                                  |
+-------------------------------+-------------------------------+
| Politecnico di Torino         | internet: cat@unix.polito.it  |
| Dip. Automatica e Informatica | bitnet:   cat@itopoli.bitnet  |
| Torino (Italy)                |                               |
+-------------------------------+-------------------------------+

Newsgroups: gnu.g++.bug
From: lewis@sophists.COM
Subject: Possible bug parsing nested classes with typedefs in g++ 2.3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 7 Nov 1992 14:29:36 GMT

/*
 * The following code compiles fine with qCompileFine 1, but fails
 * when compiled with qCompileFine 0.
 *
 * The file is compiled with gcc 2.3.1 as follows:
 *      g++ -c bug.c
 *
 * and the output is:
 *
 *      bug.c:28: assignment to non-static member `Fred' of enclosing class `Enclose'
 */
#define qCompileFine    0

struct  Base { Base (); };

struct  Enclose {
        struct  Fred : Base {
                Fred (const Fred& a);
        };
};


typedef Enclose::Fred   Fred;

#if     qCompileFine
Fred::Fred (const Enclose::Fred& a) :
#else
Fred::Fred (const Fred& a) :
#endif
        Base ()
{
}
Lewis Gordon Pringle, Jr.                                (lewis@sophists.com)
From: erik@ifad.DK (Erik Toubro Nielsen)
Newsgroups: gnu.g++.bug
Subject: g++-2.3.1 gets fatal signal with -g and -fhandle-exceptions
Date: 6 Nov 92 15:30:33 GMT
Article-I.D.: ifad.9211061330.AA29334
Distribution: gnu
Organization: GNUs Not Usenet

Options "-g" and "-fhandle-exceptions" seems to conflict. If one is
removed the signal does not come. g++.2.2.2 did not have this problem. 

Input: test.cc
--------
int main()
{
  return 0;
}
---END---

Machine: SPARCStation 1+, SunOS 4.1.1
Basic installation:
  ./configure --prefix=/usr/local/package/gcc-2.3.1 sparc
"make compare" went ok. 

Session log: 

erik@hermes $ g++ -v -g  -fhandle-exceptions test.cc
Reading specs from /usr/local/package/gcc-2.3.1/lib/gcc-lib/sparc/2.3.1/specs
gcc version 2.3.1
 /usr/local/package/gcc-2.3.1/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 -g test.cc /usr/tmp/cca29308.i
GNU CPP version 2.3.1 (sparc)
 /usr/local/package/gcc-2.3.1/lib/gcc-lib/sparc/2.3.1/cc1plus /usr/tmp/cca29308.i -quiet -dumpbase test.cc -g -version -fhandle-exceptions -o /usr/tmp/cca29308.s
GNU C++ version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
/usr/local/package/gcc-2.3.1/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11
erik@hermes $ 
Newsgroups: gnu.g++.bug
From: otto@fugue.UUCP (Otto Lind)
Subject: friend operator (was Re: Bug in GCC 2.3.1)
Organization: Sybase
Distribution: gnu
Date: Fri, 6 Nov 1992 09:53:18 GMT

In article <1992Nov2.151319.26943@dfv.rwth-aachen.de>, mj@dfv.rwth-aachen.DE (Martin Junius) writes:
|> In GCC 2.3.1 defining a friend operator in the class declaration 
|> no longer works, the linker reports an unresolved external. This 
|> doesn't happen with GCC 2.2.2.
|> 
|> Example program:
[deleted]

I have encountered this bug also. Is there any work around? I am trying
to use gcc for et++, and this causes a major breakdown of the code, since
the MetaDef() macro included in all the class definitions defines several
friend operators.

Any help or temp patchs would be appreciated.

Otto

-- 
Otto Lind                            Sybase, Inc.
otto@sybase.com                      6475 Christie Ave Emeryville, CA 94608
{pacbell,pyramid,sun}!sybase!otto    (510) 596-3691

Newsgroups: gnu.g++.bug