HDTenEightyP/NetNews huggingface dataset:
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Subject: Problem building groff-1.06 on hp730
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 9 Nov 1992 17:24:19 GMT

I am running HP-UX 8.07 on a HP Apollo 9000/730.  When I try to build
groff-1.06 with gcc-2.3.1, I get the following error:

# make
Making all in include
Making all in libgroff
Making all in libdriver
Making all in libbib
Making all in groff
Making all in troff
	gcc -O -v   -o troff env.o node.o input.o div.o symbol.o dictionary.o re g.o  number.o majorminor.o ../libgroff/libgroff.a   -lm
Reading specs from /usr/local/lib/gcc-lib/hp730-hpux/2.3.1/specs
gcc version 2.3.1
 /usr/local/lib/gcc-lib/hp730-hpux/2.3.1/ld -u main -o troff /lib/crt0.o env.o node.o input.o div.o symbol.o dictionary.o reg.o number.o majorminor.o ../libgroff/libgroff.a -lm /usr/local/lib/gcc-lib/hp730-hpux/2.3.1/libgcc.a -lc /usr/local/lib/gcc-lib/hp730-hpux/2.3.1/libgcc.a
ld: R_DATA_ONE_SYMBOL fixup in file env.o for code unsat symbol "abort" - use P' fixup
collect: /bin/ld returned 1 exit status
*** Error code 1

Stop.
*** Error code 1

Stop.

I have checked that the env.cc and related .h files don't use the abort
routine directly.  It appears to be used by gcc in setting up some class
virtual tables.  For example, in env.cc the following tables reference abort:
_vt$trie, _vt$general_reg, _vt$reg, _vt$node and _vt$request_or_macro.  Here
is a bit of the code for _vt$trie:

	.SPACE $PRIVATE$
	.SUBSPA $DATA$

	.align 8
_vt$hyphen_trie
	.half 0
	.half 0
	.word 1
	.half 0
	.half 0
	.word do_match__11hyphen_trieiPv
	.align 8
_vt$trie
	.half 0
	.half 0
	.word 1
	.half 0
	.half 0
	.word abort
        .SPACE $TEXT$
	.SUBSPA $CODE$

	.align 4
_$_20horizontal_place_reg
	.PROC


Let me know if there is a patch to fix the problem.

Dave Anglin
National Research Council of Canada
From: mrs@cygnus.com (Mike Stump)
Newsgroups: gnu.g++.bug
Subject: Your template bug
Date: 6 Nov 92 08:35:50 GMT
Article-I.D.: cygnus.9211060835.AA01779
Distribution: gnu
Organization: GNUs Not Usenet

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

As to your other question, the only way for me to give you a positive
answer, is when we have a contract to deliver them.  However, with
that said, we might be able to get them into the compiler within this
next year.

> Date: Sat, 22 Aug 92 12:35:28 -0400
> From: dov@ds20.dmi.stevens-tech.edu (Dov Kruger)
> Message-Id: <9208221635.AA01769@ds20.dmi.stevens-tech.edu>
> To: bug-gcc@prep.ai.mit.edu

> Nested classes result in a syntax error when the enclosing class is
> a template.  DEC's cxx compiler successfully swallows this, and I
> can't find anything to indicate that it should be illegal, so I
> assume it's a bug.  Thanks for a generally wonderful product.  My
> only question is -- when will you have exceptions?

> template <class T> class A {
> public:
>   T* _data;
>   class Iter {
>     T* _data;
>   };
> };


> main()
> {
>   A<int> x;
>   A<int>::Iter y;
> }
Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  g++ problems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 10 Nov 1992 20:53:02 GMT

These problems has been fixed, and should not exist in the release
after next release of gcc.  (Note, they might be fixed in the current
release, I have not tried it.)

> Message-Id: <9207061731.AA15033@julia.math.ucla.edu>
> From: Kirby A. Baker <kab@math.ucla.edu>
> To: bug-g++@prep.ai.mit.edu
> Cc: bugs@math.ucla.edu
> Date: Mon, 06 Jul 92 10:31:29 -0700

> Here are a bug (g++ or gcc?) and a possible g++ bug, although you
> may already be aware of them.  I am not sure of our g++ version
> number, but we acquired it from Qualix just recently and some
> documentation seems to be dated 12/27/91.  The gcc version is said
> to be 2.1.

> A) The following produces the error comment

> "/Starter-C++/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11"

> The program, in stripped but compilable form:

> 	template<class X>  class vector{};

> 	template<class X>  void print(vector<X>& v){}

> 	class scalar{};

> 	void print(scalar& s){}

> 	main(){
> 		scalar s;
> 		print(s);
> 	}


> B) The following seems to show an incompatibility of  const  functions
> with templates.  It does not compile as is, but does compile and
> run if either the const 's are removed or template references are
> removed.  (However, since I am a new C++ user, I may simply have
> misunderstood the spec's of C++.)

> 	#include "stream.h"

> 	template<class X> class base{
> 	public:
> 		void print() const;
> 	};

> 	template<class X> void base<X>::print() const{
> 		cout << "done\n";
> 	}

> 	main(){
> 		base<int> b;
> 		b.print();
> 	}

Newsgroups: gnu.g++.bug
From: jws@aaii.oz.au (Jeff Schultz)
Subject: G++ 2.3.1 Nested Class Constructor Bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 7 Nov 1992 02:14:26 GMT

The behavior below is a change from that of 2.2.2 and seems wrong to me.


	Jeff Schultz


------------------------------------------------------------------
Gcc 2.3.1 configured for 'decstation'.

class A {
public:
        int p;
        class B {
        public:
                B(A &a) { a.p = 23; }
                B(A *a) { a->p = 45; }
                void f(A &a) { a.p = 56; }
        };
};

g++ -c x.C
x.C: In method `B::B (class A&)':
x.C:6: assignment to non-static member `p' of enclosing class `A'
------------------------------------------------------------------

Newsgroups: gnu.g++.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Failed assertion in g++ 2.3.1
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: gnu
Date: Tue, 10 Nov 1992 06:08:00 GMT

The code below produces this output from g++ 2.3.1, compiled for the
Sequent Symmetry and GAS:

g++ -V 2.3.1 test.cc
test.cc:10: inconsistent return types for method `extendable_array' in class `extendable_array<int>'
../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 4

It looks to me like these are two separate but related bugs; removing the
code for the destructor eliminates the failed assertion, but removing the
constructor and adding a null definition for it in the class declaration
allows the program to compile happily.

template <class T> class extendable_array
  {
public:
  extendable_array(int);
  ~extendable_array();
protected:
  void error_termination(char *msg);
  T *array;
  int current_size;
  };

template <class T> extendable_array<T>::extendable_array(int initial_size)
  {
  if( initial_size < 1 )
    error_termination("improper extendable_array initial size");
  array = new T[initial_size];
  current_size = initial_size;
  }

template <class T> extendable_array<T>::~extendable_array()
{ delete [] array; }

extendable_array<int> e(10);

main() {}
From: mrs@cygnus.com (Mike Stump)
Newsgroups: gnu.g++.bug
Subject: Re:  template - const bug
Date: 6 Nov 92 08:45:25 GMT
Article-I.D.: cygnus.9211060845.AA02236
Distribution: gnu
Organization: GNUs Not Usenet

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

Folks, please remember that g++ bugs should be reported to the bug-g++ list.

> From: jonas@beppe.ericsson.se (Jonas Nygren)
> Message-Id: <1992Aug5.061842.3278@ericsson.se>
> Organization: Ericsson Telecom, Stockholm, Sweden
> Date: Wed, 5 Aug 1992 06:18:42 GMT
> Apparently-To: gnu-gcc-bug@sunet.se
> To: bug-gcc@prep.ai.mit.edu

> Here follows a template bug related to const member functions. If
> 'const' is removed or the definition is kept within the class
> declaration everything works OK.

> template<class T> class X {
> public:
>   int f() const;
> };

> template<class T> int X<T>::f() const {
>   return 0;
> }

> main(){
>   X<int> x;
> }


> gcc 2.1 and 2.2.1 complains as follows:

> /u/jonas/z.cc: In function `int  main ()':
> /u/jonas/z.cc:5: template for method `f' doesn't match any in class `X<int>'
Newsgroups: gnu.g++.bug
From: armbru@karlsruhe.gmd.DE (Markus Armbruster)
Subject: Failure to call destructors of global objects
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 14:17:54 GMT

Syndrome:

The notorious hello.cc

#include <stream.h>

int main()
{
  cout << "hello, world!\n";
}

compiled with gcc-2.3.1, binutils-2.0, glibc-1.05, libg++-2.2 on a
sun-4, sunos4.1 yields no output.


Diagnosis:

Destructors of global objects are never called.

Citation from __do_global_dtors() : 
   /* Some systems place the number of pointers
      in the first word of the table.
      On other systems, that word is -1.
      In all cases, the table is null-terminated.  */

   /* If the length is not recorded, count up to the null.  */
   if (nptrs == -1)
     for (nptrs = 0; __DTOR_LIST__[nptrs + 1] != 0; nptrs++);

Well, on my configuration (see above) the first word is always zero.

Citation from gbl-ctors.h concerning macro DO_GLOBAL_CTORS_BODY :
   /* The first word may or may not contain the number of pointers in the table.
      In all cases, the table is null-terminated.
      We ignore the first word and scan up to the null.  */

Now, that sounds reasonable.


Cure:

*** libgcc2.c~	Fri Nov  6 13:02:50 1992
--- libgcc2.c	Fri Nov  6 12:59:59 1992
*************** __do_global_dtors ()
*** 1540,1553 ****
    unsigned nptrs = (unsigned HOST_WIDE_INT) __DTOR_LIST__[0];
    unsigned i;
  
!   /* Some systems place the number of pointers
!      in the first word of the table.
!      On other systems, that word is -1.
!      In all cases, the table is null-terminated.  */
  
!   /* If the length is not recorded, count up to the null.  */
!   if (nptrs == -1)
!     for (nptrs = 0; __DTOR_LIST__[nptrs + 1] != 0; nptrs++);
  
    /* GNU LD format.  */
    for (i = nptrs; i >= 1; i--)
--- 1540,1550 ----
    unsigned nptrs = (unsigned HOST_WIDE_INT) __DTOR_LIST__[0];
    unsigned i;
  
!   /* The first word may or may not contain the number of pointers in the table.
!      In all cases, the table is null-terminated.
!      We ignore the first word and scan up to the null.  */
  
!   for (nptrs = 0; __DTOR_LIST__[nptrs + 1] != 0; nptrs++);
  
    /* GNU LD format.  */
    for (i = nptrs; i >= 1; i--)

Hope that helps.

	Markus

Newsgroups: gnu.g++.bug
From: srm@matrx.matrix.COM (Steve Morris)
Subject: reference arguments and g++
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 10:21:46 GMT

I believe the following program illustrates a bug in g++ 2.2.2.


// grt.c - g++ reference test

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

// Types.
typedef char  tName [100];

// Local data.
tName MyName;
char *MyNewName = "I like summer best";

// Forward declarations.
void func (tName & Name);

int main ()
    {
    (void)strcpy (MyName, "too bad it's winter");

    func (MyName);         // BROKEN HERE, g++ 2.2.2 reports...
                           //   grt.c:20: cannot convert to a reference type

    func (&MyName);        // This works !!

    func (MyNewName);      // This works !!

    return 0;
    }

void func (tName & Name)
    {
    printf ("func: name is %s.\n", Name);
    }

/*--*/

Newsgroups: gnu.g++.bug
From: joseph@iac.UUCP ( Joseph )
Subject: ifstream: :gets long line bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 9 Nov 1992 16:00:27 GMT

When reading lines longer than 512 characters, ifstream::gets "loses" the
512'th character.
libg++ has been compiled with gcc-2.2.2, the same compiler used to compile
the small test program. compiler specs below.

/* g++ code */

#include <std.h>
#include <fstream.h>

int
main(int ac, char *av[])
{
  ifstream f(av[1]);
  char* Line;
  f.gets(&Line);

  cout << Line << "\n";
}

/* compilation */
g++ -v b4.cc -o b4

Reading specs from /lusr/local/lib/gcc-lib/sparc-sunos4/2.2.2/specs
gcc version 2.2.2
 /lusr/local/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 b4.cc /usr/tmp/cca12539.i
GNU CPP version 2.2.2 (sparc)
 /lusr/local/lib/gcc-lib/sparc-sunos4/2.2.2/cc1plus /usr/tmp/cca12539.i -quiet -dumpbase b4.cc -version -o /usr/tmp/cca12539.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
 as -o b4.o /usr/tmp/cca12539.s
 /lusr/local/lib/gcc-lib/sparc-sunos4/2.2.2/ld -e start -dc -dp -o b4 /lib/crt0.o -L/lusr/local/lib/gcc-lib/sparc-sunos4/2.2.2 -L/lusr/local/lib b4.o -lg++ -lgcc -lc -lgcc


/* input file */
0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890






123


/* run result */

0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890






13
From: witold@gaga.maschinenbau.uni-dortmund.de
Newsgroups: gnu.g++.bug
Subject: (none)
Date: 12 Nov 92 08:46:43 GMT
Distribution: gnu
Organization: GNUs Not Usenet

Hi!

It's me again.

After typing:
 
 gcc -lg++ wbug2.cc

where "wbug2.cc" looks like:

 #include <fstream.h>

 main()
 {
  fstream MyFile;
  int N = 5;
  double Aux;

  MyFile.open("ble.ble", ios::out);
  MyFile << N;
  MyFile.close();
 }

I obtained:

 wbug2.cc: In function 'int main()':
 wbug2.cc:10: undefined fstream operator << ()



Other informations:

computer and system:
 IBM RISC System/6000 AIX Version 3.2.1

compiler:
 gcc version 2.3.1

library:
 GNU C++ library v. 2.0

Unfortunately I am not able to say something about configure command. 
As a matter of fact I remember that the compilation of the compiler wasn't
very smooth but afterwards we run checking procedures without any problems.

We didn't make any modifications to the compiler itself.

To be frank it seems to me impossible, that you forgot to define "<<" for
integer numbers, so inform me, please, if my informations have any value
or I just have damaged compiler, wrong configuration or something like that.

Sincerely yours, W.

 witold@gaga.maschinenbau.uni-dortmund.de
From: mrs@cygnus.com (Mike Stump)
Newsgroups: gnu.g++.bug
Subject: Re:  template with const bug?
Date: 6 Nov 92 08:14:39 GMT
Article-I.D.: cygnus.9211060814.AA00623
Distribution: gnu
Organization: GNUs Not Usenet

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

> Message-Id: <199207030837.AA14425@teal.csn.org>
> From: Steve Sullivan <sullivan@csn.org>
> To: bug-gcc@prep.ai.mit.edu
> Date: Fri, 3 Jul 1992 02:37:19 -0600

> It appears that gcc 2.2.2 is not recognizing
> "const" with "template" properly.

> For example, Listing A (below) produces:
>   > g++ -c testd.cc
>   testd.cc: In function `int  main ()':
>   testd.cc:9: template for method `print' doesn't match any in class `QI<int>'
>   Exit 1

>   > gcc -v
>   Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
>   gcc version 2.2.2

> But after removing the "const" on line 5 it
> compiles successfully.  My understanding of
> C++, however, is that the "const" is required
> on _both_ the declaration and definition of
> the function (both lines 5 and 18).
> See Lippman, page 231 bottom.

> Also, after removing the template code,
> as in Listing B, it compiles successfully.

> What gives?
> Many thanks for the help ...

> Steve Sullivan
> sullivan@csn.org



> ======== Listing A start. cut here =============
> template <class T>
> class QI {
> public:
>   QI(); 
>   void print() const;             // line 5
> private:
>   T item;
>   QI *next;
>   };



> template <class T>
> QI<T>::QI() {}


> template <class T>
> void QI<T>::print() const {};     // line 18


> main () {
>    QI<int> alpha();
>    }
> ======== Listing A end. cut here =============





> ======== Listing B start. cut here =============
> class QI {
> public:
>   QI(); 
>   void print() const;          // line 4
> private:
>   int item;
>   QI *next;
>   };




> QI::QI() {}



> void QI::print() const {};   // line 17


> main () {
>    QI alpha();
>    }
> ======== Listing B end. cut here =============
Newsgroups: gnu.g++.bug
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Segmentation Fault
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 10 Nov 1992 11:33:21 GMT

I do not believe that compiler crashes usually have anything to do
with a particular line in the source.
From: mrs@cygnus.com (Mike Stump)
Newsgroups: gnu.g++.bug
Subject: You bug report
Date: 6 Nov 92 08:53:25 GMT
Article-I.D.: cygnus.9211060853.AA02492
Distribution: gnu
Organization: GNUs Not Usenet

Please do not include uuencoded files, or shar files, or tar files...
Reduce the problem into a single short file if you can.

g++ does not yet support the infinite link cycle type templates.  What
this means is that in files that use templates, the compiler has to
have had seen all the relevant code for the template instantiation, so
that it has a chance to generate code from it.

> Date: Tue, 21 Jul 92 11:16:29 EDT
> From: bnell@cadillac.siemens.com (Bill Nell)
> Message-Id: <9207211516.AA04895@cadillac.siemens.com>
> To: bug-gcc@prep.ai.mit.edu

> Here is a bug I found in gcc 2.1 it seems to have something to do
> with templates (in C++). I'm assuming that gcc 2.1 actually supports
> templates because it compile my file without complaining.  Anyway,
> after compiling I looked at my .o file and it was a whopping 64 bytes
> long.  Obviously it was too small to hold all the class info.  But
> I tried to link it with a test program anyway and found not-surprisingly
> that it couldn'y find any of the member functions I used from that class.

> Unfortunately I don't know how gcc was configured when it was installed
> so I can't give you that info.  I also noticed this bug on a port of
> gcc to the atari st.  At first I thought it was a problem with the port
> but then I tried it at work on my sparc and got the same results.

> Here is a listing of my source and the commands I used to compile.
> (If you need any more info then please mail me back)

>                                             Thanks,
>                                             Bill

> begin 644 bug.tar.Z
> M'YV0=/+ *3-GC)PT<.@ 6,BPH<.'$"-*G$BQ8D40&&W0H $"0,88,6YTQ%C#
> MQ@T9(S&JE &2!@R2,F;,@!%3XPR5-F;4N.'1HL^?0(,*'4JTJ-&C2),J7<J4
> MZ12#".F F$,GC!PZ9<B >.,&!)4Z94 HJ<,&!$L0,6#HJ!%#AXP<:'/DD*' 
> M3!DY<JRFT>'GQ1PY8U[0:0/'!X@S8\: :&%GL6*K>?.X2-R@@0(I9<*02>/F
...
> M>>P)AVS_U\YT!WVMONLO8(!#QYOD3NO.?G^@XX#R8XG7)8>:6(%EE1AHI58;
> $B%BU!6S_
>  
> end
Newsgroups: gnu.g++.bug
From: cko@wald.UUCP (Carsten Koch)
Subject: Doubly defined class brings compiler into infinite loop.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 10 Nov 1992 10:35:47 GMT

A doubly defined class that has both an explicit constructor and destructor
puts the compiler into an infinite loop. In the following example, I killed
cc1plus after 138 seconds:

------------------------------------------------------------------------
% cat bug.C
class loop
{
   loop();
   ~loop();
};
class loop
{
   loop();
   ~loop();
};
% time gcc -v bug.C
Reading specs from /usr/local/lib/gcc-lib/mips-sgi-irix4/2.3.1/specs
gcc version 2.3.1
 /usr/local/lib/gcc-lib/mips-sgi-irix4/2.3.1/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dunix -Dmips -Dsgi -DSVR3 -Dhost_mips -DMIPSEB -DSYSTYPE_SYSV -D__unix__ -D__mips__ -D__sgi__ -D__SVR3__ -D__host_mips__ -D__MIPSEB__ -D__SYSTYPE_SYSV__ -D__unix -D__mips -D__sgi -D__SVR3 -D__host_mips -D__MIPSEB -D__SYSTYPE_SYSV -D__CHAR_UNSIGNED__ -D__EXTENSIONS__ -D_MIPSEB -D_SYSTYPE_SYSV -D_LANGUAGE_C_PLUS_PLUS bug.C /usr/tmp/cca00632.i
GNU CPP version 2.3.1 [AL 1.1, MM 28] Silicon Graphics Mips
 /usr/local/lib/gcc-lib/mips-sgi-irix4/2.3.1/cc1plus /usr/tmp/cca00632.i -quiet -dumpbase bug.cc -version -o /usr/tmp/cca00632.s
GNU C++ version 2.3.1 [AL 1.1, MM 28] Silicon Graphics Mips compiled by GNU C version 2.3.1.
bug.C:5: warning: all member functions in class `loop' are private
bug.C:0: warning: class `loop' only defines a private destructor and has no friends
bug.C:5: warning: class `loop' only defines private constructors and has no friends
bug.C:7: redefinition of `struct loop'
gcc: Internal compiler error: program cc1plus got fatal signal 15
138.2u 0.8s 2:20 99%
---------------------------------------------------------------------------

gcc has been installed without changes, but it has been compiled with "-O2" 
instead of the suggested "-g -O".

regards, Carsten.

  +---------------------------------------------------------+
  | Carsten Koch               E-Mail: carsten.koch@icem.de |
  | ICEM Systems GmbH          Phone:  +49-4264-2424        |
  | Waldsiedlung 7             Fax:    +49-4264-2464        |
  | 2730 Elsdorf-Hatzte, Germany                            |
  +---------------------------------------------------------+


Newsgroups: gnu.g++.bug
From: mt00@etherm.co.UK (Martin Tomes)
Subject: g++ 2.3.1 does not recognise +e[012] options.
Organization: Eurotherm Controls Limited.
Distribution: gnu
Date: Tue, 10 Nov 1992 16:50:07 GMT

The fix for +e* options present in gcc 2.3.1 does not quite fix the
bug.  The following patch is also required:

------------------------------------------------------------------------------
*** toplev.c-dist	Thu Nov  5 13:24:32 1992
--- toplev.c	Tue Nov 10 16:46:14 1992
***************
*** 562,570 ****
    "-Wall",
  
    /* These are for C++.  */
!   "+e0",
!   "+e1",
!   "+e2",
    "-fsave-memoized",
    "-fno-save-memoized",
    "-fSOS",
--- 562,570 ----
    "-Wall",
  
    /* These are for C++.  */
!   "-+e0",
!   "-+e1",
!   "-+e2",
    "-fsave-memoized",
    "-fno-save-memoized",
    "-fSOS",
------------------------------------------------------------------------------

If the - is not put before the + here then this bit of code at line
2853 in toplev.c will not find the option and lang_decode_option()
will not be called.

      for (j = 0; lang_options[j] != 0; j++)
	if (!strncmp (argv[i], lang_options[j],
		      strlen (lang_options[j])))
	  break;
      if (lang_options[j] != 0)
	/* If the option is valid for *some* language,
	   treat it as valid even if this language doesn't understand it.  */
	lang_decode_option (argv[i]);

Martin Tomes

Janet:    mtomes@uk.co.eurotherm
Internet: mtomes@eurotherm.co.uk
UUCP:     {uknet,uunet}!etherm!mtomes
From: dcb@us-es.SEl.DE
Newsgroups: gnu.g++.bug
Subject: minor bug report
Date: 5 Nov 92 11:28:34 GMT
Distribution: gnu
Organization: GNUs Not Usenet

hello there,

Given the following code, on a Sun4, compiled with a derivative of GNU C++
2.2.2


enum X {a , b } ;

class X
{
public :
        X() ;
} ;

Then I get the following error message from the compiler

bug23.cc:5: `X' defined as wrong kind of tag
cc1plus got fatal signal 11 in bug23.cc:5.

I accept that the code is wrong. I think the compiler should not crash,
and I think the error message should be better.

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