HDTenEightyP/NetNews huggingface dataset:
From: shin@ews.ncl.omron.co.JP (Mukaigawa Shin'ichi)
Subject: Bug prompt \$
Reply-To: shin@ews.ncl.omron.co.jp
Organization: OMRON Corporation, Kyoto, 617 Japan.
Distribution: gnu
Date: Fri, 8 Jan 1993 03:59:01 GMT

I am running bash 1.12 on SunOS 4.1.1.
In my .bashrc, PS1 set to ...

  PS1="[\h \t \W]\$ "

but, not work \$ at su command.Same as root login.
Usually,

[myhostname 12:53:31 uc]$ 

and, I think \$ print "#" at su command and root login.

[myhostname 12:53:31 uc]#


--

No self control             $B8~@n(J $B?.0l(J <Mukaigawa Shin'ichi>
                            Internet : shin@ews.ncl.omron.co.jp

Newsgroups: gnu.bash.bug
From: chet@odin.ins.cwru.edu (Chet Ramey)
Subject: Re: Bug of prompt \$
Reply-To: chet@po.cwru.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 04:16:28 GMT

> I am running bash 1.12 on SunOS 4.1.1.
> In my .bashrc, PS1 set to ...
> 
>   PS1="[\h \t \W]\$ "
> 
> but, not work \$ at su command.Same as root login.

This assignment statement is not doing what you expect.  Backslashes which
precede dollar signs in double-quoted strings are removed during expansion. 
This is specified in Posix.2 and is the traditional sh behavior. 

Your PS1 is really being set to `[\h \t \W]$ '.  If you change the double
quotes to single quotes in the assignment statement, things will work as
you expect:

[odin 09:21:42 sun4]$ PS1='[\h \t \W]\$ '
[odin 09:21:50 sun4]$ export PS1
[odin 09:21:54 sun4]$ su
Password:
[odin 09:21:59 sun4]# 
[odin 09:22:12 sun4]# echo -"$PS1"-
-[\h \t \W]\$ -

Chet

--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu

Newsgroups: gnu.bash.bug
From: dave@mizar.csis.dit.csiro.au (David Campbell)
Subject: Why does bash log out?
Organization: CSIRO Division of Information Technology
Distribution: gnu
Date: Tue, 12 Jan 1993 02:15:03 GMT

Can somebody please explain to me why under certain conditions, the
parent shell of certain applications somehow gets the idea that it
must log out when suspended?  Is this a bug in bash?
In the example below, I remote login to a machine and start an X-server
on it, but when I suspend xinit, bash somehow gets the idea that it must
log out.  I press CTRL-Z and bang - I'm logged out.

Example:

[mizar:/users/sdss/dave] rsh alcor
Last login: Tue Jan 12 12:48:17 from mizar
SunOS Release 4.1.2 (CSIS.SYBASE.SERVER) #2: Fri Aug 7 11:39:05 EST 1992
You have mail.
[alcor:/users/sdss/dave] /usr/local/bin/X11/xinit

^Z
[1]+  Stopped                 /usr/local/bin/X11/xinit
[alcor:/users/sdss/dave] logout            [ I did not type this ]
There are stopped jobs.
[alcor:/users/sdss/dave] logout            [ I did not type this ]
Connection closed.
[mizar:/users/sdss/dave]

-- 
  +--------------------------------------------------+-----------------------+
  | Dave Campbell                                    |            UNIX & C++ |
  | Phone: + 61 6 275 0944      Fax: + 61 6 257 1052 |   _--_|\       PLEASE |
  | CSIRO Division of Information Technology         |  /      \             |
  | Centre for Spatial Information Systems           |  \_.--._/ <- Canberra |
  | PO BOX 664                                       |        v              |
  | CANBERRA ACT 2601       +------------------------+                       |
  | AUSTRALIA               | dave@csis.dit.csiro.au |                       |
  +-------------------------+------------------------+-----------------------+
  |                       Get right.....or get left.                         |
  +--------------------------------------------------------------------------+

Newsgroups: gnu.g++.bug
From: jep@world.std.com (Jaime E Pereira)
Subject: gas for 29k
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 9 Jan 1993 06:45:47 GMT

I am involved in a project that uses the Am29200 processor.
My host system consists of a SparcStation. I was hoping
to develop most of the code in C++ and thus produced a cross
compiler using gcc 2.3.2. Also I got a version of gas from Advance
Micro  Devices 29K support (since the current version of gas 1.38 does
not support the 29k processor.

Trying to compile a C++ program that uses a global object that
has a constructor, I got an error about unrecognized ".stabs"
pseudo-opcode.

After browsing though the gcc and gas documentation files, I discovered 
that gcc uses the .stabs opcode as a mechanism to handle global 
constructors and destructors. I also discovered that the gas version 
1.91 supplied by AMD does not support the .stabs opcode (it apparently 
uses an old version of coffbfd).

Do you know of another version of the assembler that works with the
the modern version of gcc and handles the ".stabs" opcode?

Thank's for your help!

Jaime Pereira
jep@world.std.com






Newsgroups: gnu.g++.bug
From: klamer@mi.eltn.utwente.NL (Klamer Schutte)
Subject: 2.3.3: templates and #pragma interface
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 14:23:16 GMT

The #pragma interface / #pragma implementation scheme does not work correct
with template classes. I have the header file:
------------ tm1.h ------------
#pragma interface

template<class T>
class A
{
public:
	A()
		{ }
};

class B
{
public:
	B()
		{ }
};
------------ EOF -------------
and the implementation file:
------------ tm1.cc ---------
#pragma implementation 

#include "tm1.h"

static A<int>	*ai;

------------ EOF ------------
In the object file should the constructor of A<int> and B both be globally
defined; however, the A<int> constructor is static:

0 klamer@mi7 13:16 68> g++ -v -c tm1.cc
Reading specs from /usr/local/lib/gcc-lib/sun4/2.3.3/specs
gcc version 2.3.3
 /usr/local/lib/gcc-lib/sun4/2.3.3/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 tm1.cc /tmp/cca11095.i
GNU CPP version 2.3.3 (sparc)
 /usr/local/lib/gcc-lib/sun4/2.3.3/cc1plus /tmp/cca11095.i -quiet -dumpbase tm1.cc -version -o /tmp/cca11095.s
GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.3.
 as -o tm1.o /tmp/cca11095.s
0 klamer@mi7 13:17 69> nm tm1.o
00000000 T B::B()
00000024 t A<int>::A()
00000048 b _ai
00000000 t gcc2_compiled.

The #pragma interface part does work to prevent generation of the templates
in files which do not have a matching #pragma implementation.

Klamer

Newsgroups: gnu.g++.bug
From: garp@isy.liu.se (Johan Garpendahl)
Subject: Re: g++ 2.3.3 and libg++: undefined symbols
Organization: Dept of EE, University of Linkoping
Distribution: gnu
Date: Tue, 5 Jan 1993 16:47:27 GMT

brendan@cygnus.com writes:

>The 2.3.3 release of gcc (g++) included a fix for how virtual table
>names are mangled.  This creates an inconsistency between names the
>compiler generates, and the names in any libg++ created with a
>compiler before 2.3.3.  For example, one of the most common problems
>people will face as a result of this change will be an error that the
>symbol `__vt$10ostrstream$3ios' is undefined at link-time.

I tried to compile InterViews3.1 with gcc 2.3.3 and libg++ 2.3.
I *did* compile libg++ 2.3 with gcc 2.3.3.

If I compiled IV with -O, it worked fine.
If I compiled IV with -O2 i got the message that `__vt$7istream$3ios'
was undefined at link-time.

	Johan

-- 
Johan Garpendahl                   | Email: garp@isy.liu.se
Linkoping University               | Phone: +46 - 13 - 28 13 24
Dept. of Electrical Engineering    | Fax  : +46 - 13 - 13 92 82
S-581 83  LINKOPING // SWEDEN      | May the Source be with you.

Newsgroups: gnu.g++.bug
From: jpalmucc@bbn.com
Subject: GCC 2.3.3 compiler crash
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 10:49:21 GMT

The *incorrect* code below crashes the compiler.

CODE:

template <class T>
class Foo
{
  public:
     Foo( int (*nfn)(T &, T &) );
};

int test(int a,int b)
{
     return a == b;
}

int main()
{
     Foo<int> foo(test);
}



COMPILER OUTPUT:

cd /nfs/kariba/u1/jpalmucci/lbug/
g++ -v -c gcc1.cc
ld.so: warning: /usr/lib/libc.so.1.6 has older revision than expected 7
Reading specs from /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/specs
gcc version 2.3.3
 /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/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 gcc1.cc /usr/tmp/cca11135.i
ld.so: warning: /usr/lib/libc.so.1.6 has older revision than expected 7
GNU CPP version 2.3.3 (sparc)
 /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/cc1plus /usr/tmp/cca11135.i -quiet -dumpbase gcc1.cc -version -o /usr/tmp/cca11135.s
ld.so: warning: /usr/lib/libc.so.1.6 has older revision than expected 7
GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.3.
gcc1.cc: In function `int  main ()':
gcc1.cc:16: Internal compiler error.
gcc1.cc:16: Please report this to `bug-g++@prep.ai.mit.edu'.

Compilation exited abnormally with code 1 at Mon Jan  4 15:44:28

Have fun.

Jeff Palmucci
BBN

Newsgroups: gnu.g++.bug
From: worsley@mel.dit.csiro.au (Andrew Worsley)
Subject: Probably bug in gcc 2.3.3 for flexfax software?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 6 Jan 1993 04:23:18 GMT

....
> My software (currently) supports Class2 modems.  If the modems
> you mention are Class2, then there is a good chance it will
> handle them (I can only promise that it handles the ones that
> I have tested against--see the README file in the distribution).
> 
> Sam

  I'm afraid that gcc 2.3.3 seems to core dump on file util/Path.c.

  2.3.3 already has the gcc patch you specify applied. But it might possibly
  be the same problem again as a look at the core file gives :
Core was generated by `cc1plus'.
Program terminated with signal 4, Illegal instruction.
#0  push_search_level (stack=0x0, obstack=0x0) at cp-search.c:107
107       tem.prev = stack;
(gdb) l
102     push_search_level (stack, obstack)
103          struct stack_level *stack;
104          struct obstack *obstack;
105     {
106       struct search_level tem;
107       tem.prev = stack;
108
109       return push_stack_level (obstack, &tem, sizeof (tem));
110     }
111
(gdb) up
Initial frame selected; you cannot go up.
(gdb) down
Bottom (i.e., innermost) frame selected; you cannot go down.
(gdb) quit

   But as the stack is stuffed (I ran out of disk space during the core dump)
   it is not advisable to pay too much attention to it.

	Andrew
/usr/local/bin/gcc -ansi -D__ANSI_CPP__       -Dsparc -Dsun -I. -I../port/sun4 -I../util -I../iv -I../libtiff -g -x c++ -c Path.c++
/usr/local/bin/gcc: Internal compiler error: program cc1plus got fatal signal 4
*** Error code 1
make: Fatal error: Command failed for target `Path.o'
Current working directory /tmp_mnt/staff/oc/worsley/src/flexfax/util
*** Error code 1
make: Fatal error: Command failed for target `default'
Current working directory /tmp_mnt/staff/oc/worsley/src/flexfax/util
*** Error code 1
make: Fatal error: Command failed for target `dirs'
Current working directory /tmp_mnt/staff/oc/worsley/src/flexfax
*** Error code 1
make: Fatal error: Command failed for target `default'

   I am running on a SparcStation II running SunOS Release 4.1.2 trying to
compile the latest version of Sam Leffler's flexfax software.

  An attempt to send you the processed input file gave:
/usr/local/bin/gcc -E -ansi -D__ANSI_CPP__ -Dsparc -Dsun -I. -I../port/sun4 -I../util -I../iv -I../libtiff Path.c++
/usr/local/bin/gcc: Path.c++: linker input file unused since linking not done

 and nothing else!

 Andrew Worsley
CSIRO, Division of Information Technology (Melbourne),     Phone +61 3 282 2614
723 Swanston St.                                           Fax   +61 3 282 2600
Carlton, Vic, 3053, Australia                   Email:worsley@mel.dit.csiro.au

Newsgroups: gnu.g++.bug
From: umrigar@bingsuns.cc.binghamton.edu (Zerksis D. Umrigar)
Subject: G++ Bug in Friend Visibility
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 12 Jan 1993 06:10:35 GMT

/* 
The following fails to compile under gcc-2.3.3 (mips-dec-ultrix4.2).
Problems are caused by the two commented lines (one of which is explicitly
declared as legal in the ARM).  The code is followed by a compilation log.
*/

class X {
  enum {a= 100};
  friend class Y;
};

class Y {
  int v[X::a];		//According to the ARM (pg. 250), this should work.
public:
  void f(int i= X::a);	//What I really want to do, but same bug as above?
};

/*---		COMPILATION LOG
cd /usr/users/zdu/pl_imp/pl3/
gcc -c bug4.cc
bug4.cc:13: enum `a' is a private value of class `X'
bug4.cc:15: enum `a' is a private value of class `X'

Compilation exited abnormally with code 1 at Sun Jan 10 16:02:49
---

-zerksis umrigar <umrigar@bingsuns.cc.binghamton.edu>
======
*/

Newsgroups: gnu.g++.bug
From: kyriazis@rdrc.rpi.edu
Subject: g++ bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 6 Jan 1993 21:33:07 GMT

Hello.

I got the following error from gcc-2.3.3:

/rdrc/vtp/bagel/src/CG/GridSizeEstimator.cc:63: Internal compiler error.
/rdrc/vtp/bagel/src/CG/GridSizeEstimator.cc:63: Please report this to `bug-g++@p
rep.ai.mit.edu'.


Do you guys need the source code?  So far, I can't reproduce the error and
the source code is not really "portable".

  --george
-- 
----------------------------------------------------------------------------
George Kyriazis       | Visual Technologies Program, Rensselaer Design
kyriazis@rdrc.rpi.edu |  Research Center, CII 7015, RPI, Troy, NY 12180
----------------------------------------------------------------------------

From: Horst Luehrsen <Horst.Luehrsen@informatik.uni-erlangen.de>
Subject: Problem Compiling groff-1.06 on DECstation
To: bug-g++@prep.ai.mit.edu
Date: Thu, 7 Jan 1993 16:42:27 +0100 (MET)
Cc: bug-groff@prep.ai.mit.edu,
        horst@faui63.informatik.uni-erlangen.de (Horst Luehrsen)
Organization: 	Universitaet Erlangen
Reply-To: Horst.Luehrsen@informatik.uni-erlangen.de
X-Mailer: ELM [version 2.4 PL17]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 21465     
Distribution: world
Approved: info-gnu@prep.ai.mit.edu
From: tmb@idiap.CH (Thomas M. Breuel)
Subject: type unification fails errorneously in gcc 2.3.2
Reply-To: tmb@idiap.ch
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 6 Jan 1993 21:32:20 GMT

There seems to be some bizarre failure in the type unification code.

[As an aside, shouldn't GNU C++ try to print syntactically correct
error messages? The error message contains the type "struct
Stk<Stk<int>>", which is not valid C++".]

cd /fs/vision01/tmb/src/rec-character/
gcc -c -v foo.cc
Reading specs from /sym/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/specs
gcc version 2.3.2
 /sym/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.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.cc /local/tmp/cca20583.i
GNU CPP version 2.3.2 (sparc)
 /sym/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/cc1plus /local/tmp/cca20583.i -quiet -dumpbase foo.cc -version -o /local/tmp/cca20583.s
GNU C++ version 2.3.2 (sparc) compiled by GNU C version 2.3.2.
foo.cc: In function `void  restore (struct _iobuf*, struct Stk<Stk<int>>&)':
foo.cc:17: type unification failed for function template `restore'

Compilation exited abnormally with code 1 at Wed Jan  6 20:29:06

================================================================
extern "C" {
#include <stdio.h>
}

template <class T>
struct Stk {
	T t[100];
	int fill;
	T &operator()(int i) {return t[i];}
};

template <class T>
void restore(FILE *stream,Stk<T> &stack) {
	int l;
	fread(&l,sizeof l,1,stream);
	stack.fill = l;
	for(int i=0;i<l;i++) restore(stream,stack(i));
}

void restore(FILE *stream,int &x) {
	fread(&x,sizeof x,1,stream);
}

main() {
	Stk< Stk<int> > foo;	// this works fine with Stk<int>
	restore(stdin,foo);
}
================================================================

Newsgroups: gnu.g++.bug
From: gnulists@ai.mit.edu (GNU Mailing List Maintenance)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 10 Jan 1993 15:31:33 GMT

Newsgroups: gnu.g++.bug
From: min@csd.uwo.ca (Wei Min)
Subject: R: Another way to work around 
Organization: Department of Computer Science, University of Western Ontario, London
Date: Mon, 11 Jan 1993 01:31:31 GMT

min          (min@csd.uwo.ca)

// gcc version 2.3.3 configured with ./configure sun4 on a Sun IPX.
// compiled with gcc -xc++ bug.c
// running ./a.out yields incorrect output
// I see:
//  D's create
//  D's create
//  D's create
//
// current workaround is to never compile the constructor from
// classes multiply-derived from the same parent in the same source
// file.  On tuesdays. 8-)
//
// -Eric uunet.uu.net!srg!enewton
//

extern "C" {
   void puts(const char *);
}

/*
	A   Q
	 \ /
	  C
	 / \
	D   E

*/

class A
{
 public:
  // virtual   CHANGE HERE. NO EMPTY VIRTUAL FUNCTION

	void f() {}
};

class Q
{
 public:
   virtual void create() { puts("Q's create"); }
};

class C : public A,public Q
{
};

class E : public C
{
 public:
   virtual void create() { puts("E's create"); }
};

class D : public C
{
 public:
   virtual void create() { puts("D's create"); }
};

main()
{
   C * p;
   p = new C; p->create();
   p = new D; p->create();
   p = new E; p->create();
}






Newsgroups: gnu.g++.bug
From: schwartz@loki-gw.den.mmc.com (  Michael Schwartz)
Subject: Problem with Template formal parameter namespace
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 21:59:25 GMT

GCC 2.3.3

I have had this problem since version 2.2, but worked around it.
Please consider fixing or caveating this problem.

I'm sorry that the example is so crude.  I hope it illustrates the
problem well enough

Output of g++ -c -v bad_gcc.cc:

Reading specs from /usr/local/lib/gcc-lib/m68k-sun-sunos4.1/2.3.3/specs
gcc version 2.3.3
 /usr/local/lib/gcc-lib/m68k-sun-sunos4.1/2.3.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dmc68000 -Dsun -Dunix -D__mc68000__ -D__sun__ -D__unix__ -D__mc68000 -D__sun -D__unix -D__HAVE_68881__ -D__mc68020__ -Dmc68020 bad_gcc3.cc /usr/tmp/cca10005.i
GNU CPP version 2.3.3 (68k, MIT syntax)
 /usr/local/lib/gcc-lib/m68k-sun-sunos4.1/2.3.3/cc1plus /usr/tmp/cca10005.i -quiet -dumpbase bad_gcc3.cc -version -o /usr/tmp/cca10005.s
GNU C++ version 2.3.3 (68k, MIT syntax) compiled by GNU C version 2.3.3.
bad_gcc3.cc: In method `int  C::Get_Reading (class A*&)':
bad_gcc3.cc:43: Internal compiler error.
bad_gcc3.cc:43: Please report this to `bug-g++@prep.ai.mit.edu'.

bad_gcc.cc:

// Use of T as template parameter clashes with uses as class member
template <class T> class D
{
  public:
    D () { storage = 0; }
    ~D () {}
    T& operator [] ( unsigned i ) { return *storage; }
    int sizeOf() { return 1; }
  private:
    T *storage;
};

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

// THIS DOESN'T WORK!  IT HAS TROUBLE WITH FORMAL TEMPLATE
// PARAMETERS WHICH MATCH CLASS MEMBER NAMES
// BUT, IF YOU DEFINE WORKAROUND, IT COMPILES FINE!
#ifdef WORKAROUND
#define T X
#endif
class C
{
  public:
    C() {}
    ~C() {}
    int Get_Reading  (A *&);
  private:
    D<A *> T;
    int curindex;
};

int C::Get_Reading (A *&pa)
{
  int max = T.sizeOf();
  for (curindex = 0; curindex < max; curindex++)
    if (T[curindex] != 0)
    {
      pa = T[curindex];
      return 1;
    }
  return 0;
}

main()
{
}

Newsgroups: gnu.g++.bug
From: f88ho@efd.lth.se (Hans Olsson)
Subject: program cc1plus got fatal signal 11
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 19:14:00 GMT

This little program:

int main() {
  return operator+(4,5);
}

crashes the compiler:
 /tmp @jupiter-5 gcc -v test.cc
Reading specs from /usr/local/lib/gcc-lib/mips-dec-ultrix4.2/2.3.1/specs
gcc version 2.3.1
 /usr/local/lib/gcc-lib/mips-dec-ultrix4.2/2.3.1/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__ANSI_COMPAT -DMIPSEL -DR3000 -DSYSTYPE_BSD -D_SYSTYPE_BSD -Dbsd4_2 -Dhost_mips -Dmips -Dultrix -Dunix -D__ANSI_COMPAT -D__MIPSEL__ -D__R3000__ -D__SYSTYPE_BSD__ -D___SYSTYPE_BSD__ -D__bsd4_2__ -D__host_mips__ -D__mips__ -D__ultrix__ -D__unix__ -D__ANSI_COMPAT -D__MIPSEL -D__R3000 -D__SYSTYPE_BSD -D___SYSTYPE_BSD -D__bsd4_2 -D__host_mips -D__mips -D__ultrix -D__unix -D__LANGUAGE_C_PLUS_PLUS__
 -D__LANGUAGE_C_PLUS_PLUS -D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C test.cc /usr/tmp/cca00537.i
GNU CPP version 2.3.1 [AL 1.1, MM 28] DECstation running ultrix
 /usr/local/lib/gcc-lib/mips-dec-ultrix4.2/2.3.1/cc1plus /usr/tmp/cca00537.i -quiet -dumpbase test.cc -version -o /usr/tmp/cca00537.s
GNU C++ version 2.3.1 [AL 1.1, MM 28] DECstation running ultrix compiled by GNU C version 2.3.1.
test.cc: In function `int  main ()':
test.cc:2: operator + not defined
gcc: Internal compiler error: program cc1plus got fatal signal 11


-- 
----------
Hans Olsson   Email: f88ho@efd.lth.se   

Newsgroups: gnu.g++.bug
From: jimc@pic.ucla.edu
Subject: g++ internal compiler error
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 07:57:08 GMT

Gnu g++ v2.3.2 for Sparc-Sun-SunOS 4.1.1

Friend function A is defined inside the class.  Member function B is
also  defined inside the class definition and uses function A.  When B
is used the invocation of A is not expanded inline; neither is a body
generated for A.  I believe it fails equally if A is a member function,
and if A is a user-named function (not overloaded operator).
 

James F. Carter        (213) 825-2897
UCLA-Mathnet;  6221 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90024-1555
Internet: jimc@math.ucla.edu            BITNET: jimc%math.ucla.edu@INTERBIT
UUCP:...!{ucsd,ames,ncar,gatech,purdue,rutgers,decvax,uunet}!math.ucla.edu!jimc

---------- Linker output

ld: Undefined symbol 
   ___ls__FR7ostreamRC5zilch 
collect: /usr/bin/ld returned 2 exit status

---------- Source code: main program

/* bug16a.c -- Nested inline function not expanded inline ("C" main program)
	Compile by:
	gcc -c bug16a.c
	Then compile and link bug16b.C (q.v.)
*/

void interface(const char* s);

int main() {
/*    interface("this is the string\n"); */
    interface__FPCc("this is the string\n");
    return 0;
}

------------ Source code (C++ subroutine)

/* bug16b.C -- Nested inline function not expanded inline

    To demonstrate:
	gcc -c bug16a.c
	g++ -c bug16b.C
	g++ bug16a.o bug16b.o
    Linker (collect2) complains that it can't find ___ls__FR7ostreamRC5zilch
		(operator << (ostream&, const zilch&) )
 */

#include <iostream.h>

class zilch {
  public:
    const char* content;
    zilch(const char* s) : content(s) { }
    friend ostream& operator << (ostream& f, const zilch& z)
	{ return f << z.content; }
    void print(ostream& f)
	{ f << *this; }		//Should expand op<< inline, but doesn't.
};

// Everything works if op << is out of line.
//ostream& operator << (ostream& f, const zilch& z)
//	{ return f << z.content; }

// Originally attributed to "extern C" and calling from "C" main program,
// but that turned out to be irrelevant.
/*extern "C"*/ void interface(const char* s) {
    zilch z(s);
    z.print(cout);
}

Newsgroups: gnu.g++.bug
From: dak@tabaqui.informatik.rwth-aachen.de (David Kastrup)
Subject: libg++-2.3 makefile problems with ISC 3.2
Organization: Rechnerbetrieb Informatik - RWTH Aachen
Distribution: gnu
Date: Sun, 10 Jan 1993 20:57:00 GMT

To summarize:
in the main directory, using make in almost any conceivable
way will core dump. Obviously, that has to do with the
Interactive make not being able to cope correctly with too
large commands in a rule.

Secondly, include files with clash considerably (builtins/vs ISC).
This is strange, because in compilation, obviously BOTH the system
includes, as well as the gnu includes (not merely extern "C" stubs)
are BOTH included. If this does not help, I can try again which files
cause the havoc.

Newsgroups: gnu.g++.bug