HDTenEightyP/NetNews huggingface dataset:
From: joe@dharna.UUCP (Joe Linoff)
Subject: gcc-2.1 code generation problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 22:37:55 GMT

* VERSION: g++ version 2.1

* SOURCE FILE: problem.cc

    =======================================================================
    #makefile
    C++=g++
    O=problem.o

    .cc.o:
	    $(C++) -c -g $*.cc

    problem: $O
	    $(C++) -o $@ $O

    // problem.cc
    #include <iostream.h>
    /*
	This program generates a seg fault on sun4s.
    */
    class Desc {
    public:
	int data;
    };
    class DescSeq {
    public:    // formerly private
	Desc** data;
	unsigned _allocated;
	unsigned _size;
    public:
	DescSeq(unsigned sz = 4) : _allocated(sz), _size(0) { 
	    data = new Desc*[_allocated];
	}
	Desc*& operator[](unsigned i);
	DescSeq& operator+=(Desc* p) { 
	    data[_size++] = p;
	    return *this;
	}
    };
    Desc*& DescSeq::operator[](unsigned i) {
	return data[i];
    }
    void doit(char val) {
	DescSeq vars;
	vars += new Desc;

	unsigned i = 0;

	vars.data[i]->data = val == '1' ? 0: 2;  // no seg fault
	vars[i]->data = val == '1' ? 0 : 1;  // no seg fault
	vars[i]->data = val == '1' ? 0 : 2;  // SEG FAULT when val is not '1'!!!

    }
    int main() {
	doit('1');  // no seg fault 
	doit('x');  // seq fault!!
	return 0;
    }
    =======================================================================

* COMMAND ARGUMENTS:

	g++ -c -g problem.cc
	g++ -o problem problem.o

*  tm.h and md

	tm.h -> ./config/tm-sparc.h
	md -> ./config/sparc.md

* MACHINE TYPE and O/S

	SPARCstation 2
	4.1.1

* DESCRIPTION OF INCORRECT BEHAVIOR:

    The expression parser seems to get confused and generates bad code.
    The program generates a seg fault when in input val is not '1'.


Newsgroups: gnu.g++.bug
From: niklas@appli.SE (Niklas Hallqvist)
Subject: Re: Nested types cause seg fault
Organization: Applitron Datasystem AB, GOTHENBURG, SWEDEN
Distribution: gnu
Date: Tue, 14 Apr 1992 13:47:40 GMT

jason@jarthur.claremont.edu (Jason Merrill) writes:

>Trying to compile this file:

>-----
>class Bunk {
>    typedef unsigned short bunkTy;
>}
>-----

>causes a segmentation fault in cc1plus.  Somehow I don't think this is
>intended.

This has been fixed in the FSF sources, so the next release
should work.  Note! I've not fixed it, so I don't know what patches
are needed to get it work, I just tried your code to see if the problem
was fixed.

Niklas
-- 
Niklas Hallqvist	Phone: +46-(0)31-40 75 00
Applitron Datasystem	Fax:   +46-(0)31-83 39 50
Molndalsvagen 95	Email: niklas@appli.se
S-412 63  GOTEBORG, Sweden     mcsun!seunet!appli!niklas

Newsgroups: gnu.g++.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: On the trail of X(X&) and X: :operator=(X&)
Organization: Harvey Mudd College
Distribution: gnu
Date: Tue, 14 Apr 1992 06:11:55 GMT

I think I've found what the problem is, though it's not really one that can
be fixed by someone who knows the inner workings of g++ as little as I do.

The problem is conceptual:  the default X(X&) and X::operator=(X&)
functionality is handled in several different places in the code, rather
than being treated as an actual function.

My illustration code, with more precise comments:

-----
class Bunk {
    int d;
  public:
    Bunk(int i) { d = i; }
};

main() {
    Bunk b(1);			// Calls Bunk(int);
    Bunk a(b);			// Simulates Bunk(Bunk&) in expand_aggr_init();
    Bunk* ap = new Bunk(b);	
	// Calls build_method_call to get Bunk(Bunk&) and fails, since it's
	// not defined. (build_new could simulate Bunk(Bunk&), but it doesn't.
    a = b;			
	// Simulates Bunk::operator=(Bunk&) in convert_for_assignment
    a.operator=(b);
	// Calls build_method_call to get Bunk::operator=(Bunk&), and fails.
    return 0;
}
-----

The first failure could be solved by making build_new deal with default
constructors properly.  However, the second failure can only be solved by
either hacking build_method_call to simulate operator= if it's not defined
or by defining it when it is needed; this involves a significant conceptual
shift from "simulate it where it might occur" to "create it if it's not
there".

Actually creating the functions and generating function calls would be
considerably less efficient than the current method, but I think that
putting the simulation code in build_method_call only would do the trick
well.  That way, you also don't have to worry about having the same code in
several different functions.

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Incorrect non-constness warning
Organization: Harvey Mudd College
Distribution: gnu
Date: Sun, 12 Apr 1992 06:43:10 GMT

The code

bool Class::isEqual(const Object& ob) const
{ return this == castdown(&ob); }

generates the warning

Class.c: In method `int  Class::isEqual (const class Object&)const ':
Class.c:188: warning: argument passing of non-`const *' pointer from `const *'

My guess is that this warning means either that &ob is not of const * type,
or that the return value of castdown(&ob) is not of const * type.

1) ob is of const type, so &ob should be of const * type.
2) castdown is defined in a macro for each class as

static classname* castdown(Object* p)		{ return (classname*)p; } \
static const classname* castdown(const Object* p) \
	{ return (const classname*)p; } \

So g++ should choose the const function, and thus return const * from it.
I'm not sure what's going wrong here, but something seems to be.

The pertinent code is in the NIHCL 3.0, files Object.h and Class.c.

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.bug
From: joe@dharna.UUCP (Joe Linoff)
Subject: g++ 2.1 problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 21:30:15 GMT

* VERSION: g++ version 2.1

* SOURCE FILE: problem.cc

    =======================================================================
    #
    #  makefile
    #
    C++=g++
    O=problem.o

    .cc.o:
	    $(C++) -c -g $*.cc

    problem: $O
	    $(C++) -o $@ $O
    //
    // problem.cc
    //
    #include <iostream.h>
    /*
	This program should print out the following:
    Base
    Base
    Base
    Base
	instead, it prints out
    Base
    Base
    */
    class Base {
    public:
	virtual const char* name() const;  // if not virtual, 
					   // the problem goes away
    };
    const char* Base::name() const { return "Base"; }
    class BaseSeq {
	Base** data;
	unsigned _allocated;
	unsigned _size;
    public:
	BaseSeq(unsigned sz) : _allocated(sz), _size(0) { 
	    data = new Base*[_allocated];
	}
	Base*& operator[](unsigned i);
	BaseSeq& operator+=(Base* p) { 
	    data[_size++] = p;
	    return *this;
	}
    };
    Base*& BaseSeq::operator[](unsigned i) {
	return data[i];
    }
    void doit() {
	BaseSeq seq(4);
	seq += new Base;
	seq += new Base;
	seq += new Base;
	seq += new Base;
	// 
	// If you make BaseSeq::data public and then access it directly
	// instead of through BaseSeq::operator[], the problem goes away.
	// Making operator[] inline does not help.
	//
	unsigned i = 0;
	while (i < 4)
	    cout << seq[i++]->name() << '\n';
	    
    }
    int main() {
	doit();
	return 0;
    }
    =======================================================================

* COMMAND ARGUMENTS:

	g++ -c -g problem.cc
	g++ -o problem problem.o

*  tm.h and md

	tm.h -> ./config/tm-sparc.h
	md -> ./config/sparc.md

* MACHINE TYPE and O/S

	SPARCstation 2
	4.1.1

* DESCRIPTION OF INCORRECT BEHAVIOR:

	This program should print out the following:
    Base
    Base
    Base
    Base
	instead, it prints out
    Base
    Base



Newsgroups: gnu.g++.bug
From: dougm@cs.rice.edu (Doug Moore)
Subject: cc1plus fatal signal 6: address-of constructor
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 12 Apr 1992 03:39:07 GMT

GNU C++ compiler version 2.1, with Tiemann and Stump patches.  Sunos
4.1. Sparc 2.  Compiling the program below crashes the cc1plus with
fatal error 6.  It has been stripped to its essential elements.  In
particular, the destructor defined for Atoms is essential for creating
the conditions for the crash, as are the dots and arrows of the final
assignment statement.

Doug Moore
(dougm@cs.rice.edu)

Compiler output:
c++ -c -g -v -Wall Sexpr.value.cc
Reading specs from /marsh/comp212/lib/gcc-lib/sun4/2.1/specs
gcc version 2.1
 /marsh/comp212/lib/gcc-lib/sun4/2.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 -Wall Sexpr.value.cc /usr/tmp/cca05820.i
GNU CPP version 2.1 (sparc)
 /marsh/comp212/lib/gcc-lib/sun4/2.1/cc1plus /usr/tmp/cca05820.i -quiet -dumpbase Sexpr.value.cc -g -Wall -version -o /usr/tmp/cca05820.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
/marsh/comp212/bin/sun4/gcc: Internal compiler error: program cc1plus got fatal signal 6

Compilation exited abnormally with code 1 at Sat Apr 11 22:27:17

Source code:
----------------cut here--------------------------------------------
enum AtomName  {NUL};

class Atom
{
public:
  AtomName type;
  Atom(AtomName);
  ~Atom();
};

class Pair;

class Sexpr
{
private:
  Atom *sAtom;
  
public:
  Sexpr value() const;
};

class Pair
{
public:
  Sexpr head;
  Sexpr tail;
};

Sexpr Sexpr::value() const
{
  Pair* tempPtr;
  tempPtr->tail.sAtom = &Atom(NUL);
}



Newsgroups: gnu.g++.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: g++ 2.1 does not allow constructors to be friends
Organization: Harvey Mudd College
Distribution: gnu
Date: Fri, 3 Apr 1992 01:08:58 GMT

Compiling this code from Object.h in the NIHCL 3.0 library:

...
class Class : public VIRTUAL Object {	// class descriptor object 
private:			// static member variables
...
	friend Object::Object(OIOin&);
	friend Object::Object(OIOifd&);
...

produces these warnings:

Object.h:365: warning: constructors cannot be declared virtual or friend
Object.h:366: warning: constructors cannot be declared virtual or friend

I assume that this was intended to prevent class Object from declaring
Object::Object to be a friend, rather than to prevent class Class from
doing so.

This error is on line 7172 of cp-decl.c

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.bug
From: gokhale@enws237.eas.asu.edu (Aniruddha S. Gokhale)
Subject: g++ install problems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 01:27:05 GMT

Dear Sir/Madam :


I am trying to install the g++-1.40.3 compiler and am getting some 
errors while linking.

After I give a make command, while making the g++ compiler, I get some
error messages as follows :



gcc -g -DGATHER_STATISTICS -DNO_DYNAMIC_LIBS -O -B../gcc-test/  -o g++ gcc.o version.o obstack.o  malloc.o 
sysdeps/unix/bsd/sun/sun4/start.c:64: (_start): undefined reference to `___libc_init'
getenv.o: undefined reference to `_environ'
getenv.o: undefined reference to `_environ'
execv.o: undefined reference to `_environ'
execv.o: undefined reference to `_environ'
*** Error code 1
make: Fatal error: Command failed for target `g++'
% 
%

I have installed the same compiler a few days back in my home directory
and it never gave any such problems, but now I am trying to install it
in /usr/local/gnu/bin directory.

I have gcc-1.40, gas, gcc-ld, gnu-make already installed.

I would appreciate if you could let me know what type of problem I am
facing and what should I do to correct it.



Sincerely yours,


Aniruddha Gokhale 

Newsgroups: gnu.g++.bug
From: dougm@cs.rice.edu (Doug Moore)
Subject: bad symtab entries for member function pointer
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 06:52:36 GMT

In the following program:
==========================================
class c;
int (c::*f) (int); 

main()
{
}
==========================================
compiled as follows, with g++ 2.1 (Tiemann, Stump patches, sparc2, sunos4.1):
==========================================
c++ -g -v bug.cc
Reading specs from /marsh/comp212/lib/gcc-lib/sun4/2.1/specs
gcc version 2.1
 /marsh/comp212/lib/gcc-lib/sun4/2.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 bug.cc /usr/tmp/cca05680.i
GNU CPP version 2.1 (sparc)
 /marsh/comp212/lib/gcc-lib/sun4/2.1/cc1plus /usr/tmp/cca05680.i -quiet -dumpbase bug.cc -g -version -o /usr/tmp/cca05680.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
 as -o bug.o /usr/tmp/cca05680.s
 /marsh/comp212/lib/gcc-lib/sun4/2.1/ld -e start -dc -dp /lib/crt0.o -L/marsh/comp212/lib/gcc-lib/sun4/2.1/ -L/marsh/comp212/lib/ bug.o -lg++ -lm -lgcc -lc -lg -lgcc

Compilation finished at Tue Apr 14 01:47:08
==========================================
gdb 4.5 dies on the following sequence of operations:
==========================================
Current directory is /marsh/comp212/.jnkk/
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.5, Copyright 1992 Free Software Foundation, Inc...
(gdb) break main
Breakpoint 1 at 0x22a8: file bug.cc, line 6.
(gdb) run
Starting program: /marsh/comp212/.jnkk/a.out 

Breakpoint 1, main () at bug.cc:6
(gdb) ptype f

Inferior Gdb segmentation fault
==========================================
I conclude that the fault lies partially in g++ 2.1, because the same problem
does not arise when the program is compiled with the same options by
g++ 1.40.3:
==========================================
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.5, Copyright 1992 Free Software Foundation, Inc...
(gdb) break main
Breakpoint 1 at 0x251c: file bug.cc, line 6.
(gdb) run
Starting program: /marsh/comp212/.jnkk/a.out 

Breakpoint 1, main () at bug.cc:6
(gdb) ptype f
type = (int  struct c::*)(int)
(gdb) c
Continuing.

Program exited normally.
(gdb) 
==========================================

Doug Moore
(dougm@cs.rice.edu)

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  data member initialization wrongly accepted
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 10:19:41 GMT

This is a GNU extension.  All versions (probably) can flag this as an
error.  Just ask it to, -ansi -pedantic to make it grip and moan about
everything under the sun.

> Date: Thu, 9 Apr 92 14:26:10 CDT
> From: dougm@cs.rice.edu (Doug Moore)
> Message-Id: <9204091926.AA03439@cs.rice.edu>
> To: bug-g++@prep.ai.mit.edu

> The following code:
> ====================
> class foo
> {
> public:
>   int a = 0;
> };

> foo baz;
> ====================
> not compile under Sun C++, with the error message:
> ====================
> CC  test.cc:
> "test.cc", line 2: error:  initializer for member a
> 1 error
> ====================

> Looking through my C++ reference books, I cannot find anything to
> indicate what the compiler should do with an attempt to initialize a
> class data member within the class definition.  Nor can I find a
> mention of this as a gnu extension in the documentation that
> accompanies gcc 2.1.  Yet both g++ 1.40.3 and g++ 2.1 accept such
> initializations without complaint.

> Since my students attempt such initializations all the time and,
> worse, sometimes the initializations achieve what the student
> intended, I'd appreciate it if an upcoming version of GNU C++ flagged
> this as an error.

> BTW: The failure to warn occurs under GNU GCC 2.1, w/ Tiemann inf.
> loop patches, and patches from Mike Stump for the Sabre detected bugs,
> running on a SUN sparc2 running Sunos 4.1.  The same behavior occurred
> under g++ 1.40.3.

Newsgroups: gnu.g++.bug
From: jason@jarthur.claremont.edu (Fool on a Pedestal)
Subject: Re: Incorrect 'conversion to reference of read-only variable' error
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 08:22:40 GMT

>>>>> On Fri, 10 Apr 92 10:05:08 +0200, Ulrich Windl <c9524@rrzc1.rz.uni-regensburg.de> said:

The code in question:

-----
...
	static Object* const nil;  // pointer to sole instance of nil object
...
Object*& Arraychar::at(int)
{
	shouldNotImplement("at");
	return (Object*&)nil;		
}
...
-----

>>   Arraychar.c:291: conversion to reference of read-only variable `nil'

>>   Here g++ should quietly cast away nil's const-ness.

> I think it should NOT, because there's a good reason:
> If you tell the compiler that a variable (nil) is to be const.
> In most cases it is an error if you cast away const-ness.

I disagree.  If you are deliberately casting it, that is sufficient
indication that you want its status to change.  In any case, this is an
issue that should be taken up in comp.lang.c++, not here; the current C++
standard states that (Object*&)nil returns nil cast to a non-const
pointer reference.  I refer you to the ARM, section 5.4:

"An object of a const type or a reference to an object of a const type can
be cast into a reference to a non-const type.  The resulting reference will
refer to the original object.  The result of attempting to modify that
object through such a pointer or reference will either cause an addressing
exception or be the same as if the original pointer or reference had
referred a non-const object.  It is implementation dependent whether the
addressing exception occurs."

So g++ has the option of protecting nil from being written to, but it
cannot prevent the programmer from casting it into a non-const reference
and still maintain compatibility with the ARM standard.

> Furthermore it make the code optimizer less efficient.
> Maybe the compiler should warn, but what's a constant, if you can change it?

That's a philosophical issue which is not really relevant to this
discussion.

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.bug
From: jxl@krell.pwx.bull.com (John X. Laporta)
Subject: ssignal redefined i386-sco
Reply-To: <news@pws.ma30.bull.com>
Organization: Bull Worldwide Information Systems Inc.
Distribution: gnu
Date: Wed, 8 Apr 1992 19:09:39 GMT

Bull ProStation running PWS UNIX 1.3.4.0 based on SCO SysV 3.2.2

PROBLEM:

	Building src/bin/examples/clock/clock.cc from the
	  GO package from contrib on export.lcs.mit.edu

	Using GCC 2.1 and libg++-2.0

	clock.cc includes signal.h

	g++-include/signal.h has #include_next <signal.h>

	g++-include/signal.h defines ssignal()

	/usr/include/signal.h defines ssignal() differently

	compiler reports redefinition as an error when
	#include <signal.h> appears in source code.

SOLUTION:

	change g++-include/signal.h "#include_next <signal.h>"
	  to "#include_next <sys/signal.h>" (two places)

REPORT:

	With this change the compile succeeds.
--
    John X. Laporta
    Senior Software Engineer
    Bull Worldwide Information Systems, Inc.
    M.S. MA30-806A
    300 Concord Road
    Billerica MA 01821
    FAX (508) 294-0108
    email: jxl@pwx.bull.com
           !uunet!zion!know!laporta

Newsgroups: gnu.g++.bug
From: gb@cs.purdue.edu (Gerald Baumgartner)
Subject: GCC 2.1: core dump when class name not declared
Organization: Department of Computer Science, Purdue University
Distribution: gnu
Date: Fri, 10 Apr 1992 05:23:56 GMT

class ByteSink;

Given the following code:

	class OutputStream {
	public:
		OutputStream( ByteSink & );
	};

	inline
	OutputStream::OutputStream( ByteSink & bs )
	{
	}

GCC 2.1 produces a

	stdin:3: parse error before `&'

in the class declaration.  It would be nicer to get an error message
that says that ByteSink is undeclared, but at least the compiler doesn't
die.  In the declaration of OutputStream::OutputStream, we get a
better error message

	stdin:7: `ByteSink' undeclared, outside of functions
	stdin:7: `bs' undeclared, outside of functions

but this time followed by a core dump (abort).

The abort happens in `grokdeclarator' in file cp-decl.c, line 6297.
`grokdeclarator' was called by `start_function'.  The code surrounding
the call to `abort' is

        if (parmlist_is_random (TREE_OPERAND (decl, 1)))
          {
	    decl = TREE_OPERAND (decl, 0);
	    if (TREE_CODE (decl) == SCOPE_REF)
	      {
		if (TREE_COMPLEXITY (decl))
->		  abort ();
		decl = TREE_OPERAND (decl, 1);
	      }
	    if (TREE_CODE (decl) == IDENTIFIER_NODE)
	      name = IDENTIFIER_POINTER (decl);
	    if (name)
	      error ("bad parameter list specification for function `%s'",
		     name);
	    else
	      error ("bad parameter list specification for function");
            return 0;
          }
      bot:

According to the code, the problem seems to be that the tree is too complex.

So, let's try to make it less complex; we delete `inline'.  The result
is an additional (bogus) error message instead of aborting:

	stdin:6: `ByteSink' undeclared, outside of functions 
	stdin:6: `bs' undeclared, outside of functions 
	stdin:7: no `OutputStream' member function declared in class 

--Gerald

Newsgroups: gnu.g++.bug
From: jakov@vlsi.cs.caltech.edu (Jakov Seizovic)
Subject: pointer to member bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 18:37:25 GMT

------------------------------------------------------------------------------
machine used:  SPARCstation 2
------------------------------------------------------------------------------


------------------------------------------------------------------------------
g++ version used:
------------------------------------------------------------------------------

% g++ -v -S bug.c
Reading specs from /usr/local/lib/gcc-lib/sun4/2.1/specs
gcc version 2.1
 /usr/local/lib/gcc-lib/sun4/2.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.c /usr/tmp/cca15524.i
GNU CPP version 2.1 (sparc)
 /usr/local/lib/gcc-lib/sun4/2.1/cc1plus /usr/tmp/cca15524.i -quiet -dumpbase bug.cc -version -o bug.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
%


------------------------------------------------------------------------------
source code:
------------------------------------------------------------------------------

class   C
{
public:
        int     i0;
        int     i1;
};


typedef         int C::*        PMC;


int     j;


void
f ()
{
    PMC  pmc = &C::i1;
    C   c;
    C* cp = &c;
    j = cp->*pmc;		// problem occurs here
}


------------------------------------------------------------------------------
produced assembly code:
------------------------------------------------------------------------------

gcc2_compiled.:
.text
        .align 4
        .global _f__Fv
        .proc 1
_f__Fv:
        !#PROLOGUE# 0
        save %sp,-136,%sp
        !#PROLOGUE# 1
        mov 4,%o0
        st %o0,[%fp-20]
        add %fp,-32,%o0
        st %o0,[%fp-36]
        sethi %hi(_j),%o0
        ld [%fp-20],%o1
        ld [%fp-36],%o2
        ld [%o1],%o3		// memory(0x0004) is accessed here
        add %o2,%o3,%o1
        ld [%o1],%o2
        st %o2,[%o0+%lo(_j)]
        b,a L2
        b,a L1
L2:
L1:
        ret
        restore
        .global _j
        .common _j,8,"bss"



Newsgroups: gnu.g++.bug
From: mlm@cs.brown.edu (Moises Lejter)
Subject: Patches to G++ 2.1 ?
Reply-To: mlm@cs.brown.edu
Organization: Dept. of Computer Science, Brown University
Distribution: gnu
Date: Thu, 16 Apr 1992 00:05:32 GMT

Someone here managed to prod  g++ 2.1 into an internal error.  The
error message it prints before dying is:

cp-class.c:2371: failed assertion `IDENTIFIER_TEMPLATE (t) != NULL_TREE'
/cs/bin/gcc: Internal compiler error: program cc1plus got fatal signal 6

I'm reasonable certain I saw a fix for this bug in this newsgroup some
time back, but I did not keep it... :-(  Was there such a fix posted?
If so, could some kind soul send me a copy of the patch?  And in a
more general vein, has anyone kept all fixes posted for 2.1 so far?
Perhaps I should just apply them all at once...

Moises
--
-----------------------------------------------------------------------------
Internet/CSnet:   mlm@cs.brown.edu		BITNET:  mlm@browncs.BITNET
UUCP:    ...!uunet!cs.brown.edu!mlm		Phone:	 (401)863-7664
USmail:  Moises Lejter, Box 1910 Brown University, Providence RI 02912

Newsgroups: gnu.g++.bug