HDTenEightyP/NetNews huggingface dataset:
From: steve@maths.warwick.ac.UK (Steve Rumsby)
Subject: g++ 2.2.2 template bug
Organization: Maths Institute, Warwick University, Coventry, UK.
Distribution: gnu
Date: Thu, 13 Aug 1992 18:06:47 GMT

cc1plus seems to get upset when it can't instantiate an appropriate version
of a template function to match a given call. This happens on Sun 3 and
Sun 4 machines running SunOS 4.1.1, and on an SGI Indigo running Irix 4.0.1.
See the attatched example to reproduce the problem. Any suggestions?

Thanks,
Steve.

$ cat x.c
template <class T>
void
g(T x)
{
}

void
f()
{
	g();	// There is no g() for this call to match
	        // so cc1plus goes gaga...
}
$ g++ -v -c x.c
Reading specs from /gnu/lib/gcc-lib/sparc-sunos4/2.2.2/specs
gcc version 2.2.2
 /gnu/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 x.c /usr/tmp/cca19409.i
GNU CPP version 2.2.2 (sparc)
 /gnu/lib/gcc-lib/sparc-sunos4/2.2.2/cc1plus /usr/tmp/cca19409.i -quiet -dumpbase x.cc -version -o /usr/tmp/cca19409.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
/gnu/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11

--
UUCP:	 ...!uknet!warwick!steve	Internet: steve@maths.warwick.ac.uk
JANET:	 steve@uk.ac.warwick.maths	PHONE:	 +44 203 524657

Newsgroups: gnu.g++.bug
From: hassey@matrix.rtp.dg.com (John Hassey)
Subject: linkage specification and const objects
Followup-To: comp.lang.c++
Organization: Data General Corporation, RTP, NC.
Distribution: gnu
Date: Thu, 13 Aug 1992 17:41:57 GMT

    I've encountered a difference between cfront 2.1 and g++ 2.2, and
    can't find anything in the ARM that explains who is right.

    Consider:

	extern "C" const int a;

    Cfront 2.1 will compile this into:

	extern int a; (or extern const int a; with +a1)

    g++ 2.2 gives: "uninitialized const `a'"  (g++ 2.1 does not)

    The code in g++ cites 7.1.6 in the ARM. "Unless explicitly
    declared extern, a const object does not have external linkage
    and must be initialized."

    So g++ wants something like this to be happy:

    	extern "C" extern const int a;

    But cfront doesn't like that at all.

    It looks to me like g++ is wrong on this one.

    extern "C" const int a; 

    is a declaration not a definition (7.4). But

    extern "C" {
    const int a;
    };

    Is a definition, so the error is justified on this, and  cfront 2.1
    does give an error.

    Comments ?

    john.  (hassey@dg-rtp.dg.com)


Newsgroups: gnu.g++.bug
From: munson@acacia.cs.berkeley.edu (Ethan V. Munson)
Subject: g++-2.2.2 profiling problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 21 Aug 1992 16:39:20 GMT

I sent this bug report to bug-gcc by mistake.

Ethan Munson
munson@cs.berkeley.edu

----------------------------------------
Compiler: g++-2.2.2 (using LibG++ 2.1)
Machine: SparcStation 2 running SunOS 4.1.2

Problem: Can't link when profiling

Description:

When performing the final link step on our large program we get
complaints from /usr/bin/ld that it can't find a number of symbols.
These symbols all match the regular expression:

	LB[BE][1-9][0-9]

For example, LBB29 and LBE29.  These symbols always come in pairs like
this.

They look like compiler-generated symbols to me and do not appear in
any of our own code.

Our final link command is:

/usr/sww/bin/g++-2.2.2   -g -DTRACE -DDEBUG -pg -static  -Wimplicit -Wreturn-type -Wswitch    -o LDObj.sun4/ensemble main/LDObj.sun4/test5.o view/LDObj.sun4/libview.a exl/glue/LDObj.sun4/libglue.a exl/types/LDObj.sun4/libxtypes.a exl/misc/LDObj.sun4/libxmisc.a  doc/LDObj.sun4/libdoc.a  io/LDObj.sun4/libio.a  texted/LDObj.sun4/libtexted.a  supered/LDObj.sun4/libsupered.a  dispatch/LDObj.sun4/libdispatch.a  view/LDObj.sun4/libview.a  pres/LDObj.sun4/libpres.a  realize/LDObj.sun4/librealize.a  struct/LDObj.su
n4/libstruct.a  textbuf/LDObj.sun4/libtextbuf.a  textform/LDObj.sun4/libtextform.a  textrender/LDObj.sun4/libtextrender.a  location/LDObj.sun4/liblocation.a  repman/LDObj.sun4/librepman.a  ecp/LDObj.sun4/libecp.a  uspec/LDObj.sun4/libuspec.a  vtree/LDObj.sun4/libvtree.a  font/LDObj.sun4/libfont.a  common/LDObj.sun4/libcommon.a doc/LDObj.sun4/libdoc.a ecp/LDObj.sun4/libecp.a -lgsR4 -L.  -L/home/auspex/d/ensemble/lib -L/usr/sww/X11R4/lib -L/usr/sww/lib -lg++-2_1 -lm -lXm -lXt!
 -lX11


Ethan Munson
munson@cs.berkeley.edu

Newsgroups: gnu.g++.bug
From: sirott@atmos.washington.edu (Joe Sirott)
Subject: cc1plus gets fatal signal 6
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 03:02:38 GMT

The following code fragment:

---------------------------------------------------------
extern "C" {
int abs(int);
}


class FrGlobal {
  public:
    static abs(int in) { return in > 0 ? in : -in; }
};
---------------------------------------------------------


causes the compiler to exit with fatal signal 6. Here is the complete
output from the compiler:

cd /home/chaos/sirott/crdtool/src/ui/data_browse_class/
make
rm -f test.o
gcc -c -g	-v    -I../include -I../include/guide_include -I../include/icons  -I/usr/local/include -I/usr/openwin/include -I  -I -I/usr/local/interviews/include     test.C
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.1/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.1/2.2.2/cpp -lang-c++ -v -I../include -I../include/guide_include -I../include/icons -I/usr/local/include -I/usr/openwin/include -I -I -I/usr/local/interviews/include -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.C /usr/tmp/cca27375.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.1/2.2.2/cc1plus /usr/tmp/cca27375.i -quiet -dumpbase test.cc -g -version -o /usr/tmp/cca27375.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
gcc: Internal compiler error: program cc1plus got fatal signal 6
*** Error code 1
make: Fatal error: Command failed for target `test.o'

Compilation exited abnormally with code 1 at Wed Aug 19 09:57:42

Newsgroups: gnu.g++.bug
From: tmb@idiap.CH (Thomas M. Breuel)
Subject: Re: uninitialized static members
Reply-To: tmb@idiap.ch
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 17 Aug 1992 12:07:25 GMT

I wrote:
 > I'm having a problem with uninitialized static class members in GCC
 > C++ 2.2.2.
 > 
 > Basically, if I only define the static class member inside the class
 > (without explicitly initializing it), I get a link-time undefined
 > symbol error.
 > 
 > I was under the impression that I didn't have to provide any
 > definition (in addition to what is present in the header) for
 > uninitialized static class members.

Never mind; the ARM explicitly states that this doesn't work.
From: etnkna@etn.ericsson.SE
Newsgroups: gnu.g++.bug
Subject: Problems with virtual functions and multiple inheritance
Date: 13 Aug 92 16:22:41 GMT
Distribution: gnu
Organization: GNUs Not Usenet

I am using gcc-2.2.2 with the gdb-4.6 fix on a sparc using sunos4.1.

The file bugtest.cc:

------------------------------------------------------------------------------
#include <stream.h>

struct a
{
    virtual void f() = 0;
};

struct b
{
    virtual void g() = 0;
};

struct c: public a, public b
{
    virtual void f();
    virtual void g();
};

void c::f()
{
    cerr << "c::f()\n";
}

void c::g()
{
    cerr << "c::g()\n";
}

struct e: public b
{
    // virtual void g();
};

// void e::g()
// {
//    cerr << "e::g()\n";
// }

struct h
{
};

struct d: public c, public e, public h
{
    virtual void f();
    virtual void g();
};


void d::f()
{
    cerr << "d::f()\n";
}

void d::g()
{
    cerr << "d::g()\n";
}

int main(int argc, char* argv[])
{
    a* tmp = new d;
    tmp->f();
    return 0;
}
    
-------------------------------------------------------------------------------
produces the following messages when compiling:

g++ -v -o bugtest bugtest.cc
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/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 bugtest.cc /usr/tmp/cca24609.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca24609.i -quiet -dumpbase bugtest.cc -version -o /usr/tmp/cca24609.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
bugtest.cc: In function `int  main (int, char **)':
bugtest.cc:63: cannot allocate an object of type `d'
bugtest.cc:63: since the following virtual functions are abstract:
bugtest.cc:10: void  b::g ()

-------------------------------------------------------------------------------
Name:	Knut-Hevard Aksnes (ECMA 94) or		Knut-Haavard Aksnes (ASCII)
Ericsson signature: HI/ETN/U/IT KNA		Phone: +47 41 19481
Email: etnkna@etn.ericsson.se (internet)  ETN.ETNKNA (memo)
Newsgroups: gnu.g++.bug
From: keister@poincare.phys.cmu.edu (Bradley D. Keister)
Subject: static constructors and libraries
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 20 Aug 1992 05:43:47 GMT

The following output of 'nm' may shed some light on a problem I've had
with static constructors inside libraries which I posted earlier.  The
class "dummy_class" has a constructor which computes 
pi = 4 * arctan(1), and "dummy_initialize" is a static object of type
"dummy_class".  Any source module which uses pi includes a header
file containing the line

extern dummy_class dummy_initialize

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

dummy.o (g++/Sun):
00000040 T __GLOBAL_$I$dummy_initialize
00000000 T ___14dummy_class
         U _atan
00000060 D _dummy_initialize
00000008 C _pi
00000000 t gcc2_compiled.

dummy.o (g++/DECstation):
00000000 N $L1
00000000 N $L2
00000000 N $L3
00000064 T _GLOBAL_$I$dummy_initialize
00000000 T __14dummy_class
         U atan
00000000 N gcc2_compiled.
000000a0 G dummy_initialize
00000008 C pi

If dummy.o is linked directly to other modules, then the constructor
is called at run time and pi gets its correct value.  If dummy.o is
instead linked in from a library, then the DEC executable calls the
constructor, but the Sun executable does not, leaving pi=0.  Is
"dummy_initialize" for the Sun being put in the wrong segment?

Brad Keister
Department of Physics
Carnegie Mellon University
Pittsburgh, PA 15213
(412) 268-2772 (office)
(412) 681-0648 (FAX)

internet:	keister@poincare.phys.cmu.edu
BITNET:		keister%poincare.phys.cmu.edu@CARNEGIE

Newsgroups: gnu.g++.bug
From: victor@watson.ibm.com (Victor Miller)
Subject: templates not recognizing const functions
Reply-To: victor@watson.ibm.com
Organization: IBM, T.J. Watson Research Center
Distribution: gnu
Date: Fri, 21 Aug 1992 19:09:25 GMT

I have the program below (gbug.C) which gives the following results:

g++ -c -DCONST= gbug.C

	But

g++ -c -DCONST=const gbug.C
gbug.C: In function `int  main (int, char **)':
gbug.C:16: template for method `foo' doesn't match any in class `T2<int>'


// Is this a bug?

template<class T1>
class T2 {
  int l;
  T1 *x;
  int foo(const int) CONST;
public:
  T2(const int y=1): l(y) {
    x = new T1[l];
  };
  ~T2() {};
  void bar(const int y,const T1& t) {
    x[foo(y)] = t;
  }
};
template<class T1>
int T2<T1>::foo(const int n) CONST {
  return n+1;
}
int main(int argc,char * argv[]) {
  typedef T2<int> T3;
  T3 z;
  return 0;
}
--
		Victor S. Miller
		Bitnet: VICTOR at WATSON
		Internet: victor@watson.ibm.com
		IBM, TJ Watson Research Center
		"Great artists steal; lesser artists borrow" Igor Stravinsky

Newsgroups: gnu.g++.bug
From: munroe@dmc.COM (Shut up, Grow up, Lighten up!)
Subject: What do I need to do to file this bug report...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 13 Aug 1992 18:34:40 GMT

From:	MX%"youngdale@v6550c.nrl.navy.mil"   13-AUG-1992 11:45:21.72
To:	MUNROE
CC:	
Subj:	RE: Bug in GAS inhibits DEBUGger functioning.

Return-Path: <youngdale@v6550c.nrl.navy.mil>
Received: by DMC.COM (MX V3.1C) with UUCP; Thu, 13 Aug 1992 11:45:13 EDT
Received: from V6550C.NRL.NAVY.MIL by relay1.UU.NET with SMTP
          (5.61/UUNET-internet-primary) id AA03823; Thu, 13 Aug 92 10:50:56
          -0400
Received: by v6550c.nrl.navy.mil (MX V2.3) id 11338; Thu, 13 Aug 1992 10:50:40
          EDT
Date: Thu, 13 Aug 1992 10:50:40 EDT
From: Eric Youngdale <youngdale@v6550c.nrl.navy.mil>
To: munroe@DMC.COM
CC: youngdale@v6550c.nrl.navy.mil
Subject: RE: Bug in GAS inhibits DEBUGger functioning.


>garning(debugger output):Forward reference error, dbx type 66
>gcc-as warning(debugger output):Forward reference error, dbx type 71
>gcc-as warning(debugger output):Unable to resolve 1 circular references.

	OK, I have looked at the problem, and the core issue is that the
compiler is generating incomplete debugging information.  In particular,
the declaration:

.stabs "K560_R_TRACKING_DATA:T73=u10
	k560_t_asCharacter:74=ar1;0;9;11,0,80;
	k560_r_asReply:75=ar1;0;1;76,0,80;
	k560_r_asDevices:77,0,80;;",128,0,0,0

references an array in k560_r_asReply of dbx type 76, and dbx type 76
is not defined anywhere in the file.  This is what is responsible for
the unresolved circular reference.  The other two messages, about dbx
types 66 and 71 represent similar situations, where a dbx type is
used, but not defined.  In these two cases the references are such
that the assembler can work around the problem, but the circular
reference really throws the assembler off.

	The reason that I am giving this to you is that I would like you to
make a bug report to the mailing list bug-g++@prep.ai.mit.edu (it appears
to be g++ code), and you will need to supply source code and my explanation
of what the trouble it.

	In the mean time, I will try to come up with a patch to the
assembler that will make it more fault tolerant.  In this situation, I
will fix it so that structure elements of undefined dbx types will not
be visible from the debugger.

	I also want to mention that I am about to go away for a week,
and I may not get back to this for a little while.  I hope that you
can find a work-around in the mean time.

-Eric

--
Dick Munroe				Internet: munroe@dmc.com
Doyle Munroe Consultants, Inc.		UUCP: ...uunet!thehulk!munroe
267 Cox St.				Office: (508) 568-1618
Hudson, Ma. 01749 USA			FAX: (508) 562-1133

GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection.

Newsgroups: gnu.g++.bug
From: earl@jade.ab.CA (Earl Locken)
Subject: g++ 2.2.2 on HP710 puts extern const in wrong segment
Organization: Jade Simulations International, Inc., Calgary, AB, Canada
Distribution: gnu
Date: Fri, 21 Aug 1992 22:19:15 GMT


     g++ 2.2.2 on an HP 9000/710 imports "extern const" variables from
the $CODE$ segment, even class variables with constructors.  The
definition of these variables is placed into the $DATA segement
(correctly).  The final link will fail, but will work on a Sun3 or Sun4.

     g++ 2.2.2 was created using "configure hp700".

     Compile the following three small files on an HP 710 using "g++
-o loc loc1.C loc2.C".  The compile will fail due to "Unsatisfied symbols:".

--------------- Cut here for loc.h ---------------------

class loc {
public:
	int i;
	loc() { i = 0; };
};

extern const loc x;

--------------- Cut here for loc1.C ---------------------

#include "loc.h"

const loc y;
main()
{
	if (&y == &x) return 0;
}

--------------- Cut here for loc2.C ---------------------

#include "loc.h"
const loc x;		/* Where we define "extern const loc x"		*/

-- 
Earl Locken						earl@jade.ab.ca
Jade Simulations International

Newsgroups: gnu.g++.bug
From: tiemann@cygnus.com
Subject: Re: uninitialized static members
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 17 Aug 1992 00:48:11 GMT

   Return-Path: gnulists@ai.mit.edu
   Date: Sun, 16 Aug 92 19:04:40 +0200
   From: tmb@idiap.ch (Thomas M. Breuel)
   Sender: gnulists@ai.mit.edu
   To: bug-g++@prep.ai.mit.edu
   Subject: uninitialized static members
   Reply-To: tmb@idiap.ch
   
   I'm having a problem with uninitialized static class members in GCC
   C++ 2.2.2.
   
   Basically, if I only define the static class member inside the class
   (without explicitly initializing it), I get a link-time undefined
   symbol error.
   
   I was under the impression that I didn't have to provide any
   definition (in addition to what is present in the header) for
   uninitialized static class members.
   
   				Thomas.
   
   PS: A little more concretely:
   
   struct NISTDigitImages {
   	static int *table;
   	...
   };
   
    ...
   
   gcc -L/homes/tmb/src/nvis/lib  rec-gh.o loadihdr.o ihead.o g4decomp.o winlib.o -lX11 -lvis -lm   -o rec-gh
   ld: Undefined symbol 
      __15NISTDigitImages$table 
   collect: /usr/bin/ld returned 2 exit status
   make: *** [rec-gh] Error 1
   
We have changed the behavior of G++ to match the ANSI spec.  The
behavior you are now seeing is "correct".  I'm sorry that it's less
convenient.

Michael
  

Newsgroups: gnu.g++.bug
From: arr@ukc.ac.UK (A.R.Runnalls)
Newsgroups: gnu.g++.bug
Subject: Re: Miscompiled vtbl
Date: 14 Aug 92 08:06:18 GMT
Reply-To: arr@ukc.ac.uk (A.R.Runnalls)
Distribution: gnu
Organization: Computing Lab, University of Kent at Canterbury, UK.

In article <5@larch.ukc.ac.uk> arr@ukc.ac.UK I (A.R.Runnalls) wrote
>The following program gives the output `I'm an LR' instead of the
>correct output `I'm an LR2'.  The problem, which appears to be due to
>the virtual table for LR2 being wrongly set up, disappears if either the
>virtual destructor for class L is removed, or if a virtual destructor is
>added to class R.

Whilst these observations about virtual destructors were true for the
example program posted, inserting a virtual destructor for (the analogue
of) class R failed to cure the problem in the original program from
which the example was distilled.
Newsgroups: gnu.g++.bug
From: hoelzle@xenon.stanford.edu (Urs Hoelzle)
Subject: Re: Bug on SUN4 with -O option
Organization: CS Department, Stanford University, California, USA
Distribution: gnu
Date: Fri, 21 Aug 1992 16:44:25 GMT

In gnu.g++.bug you write:

>   The following program has a SEGV when compiled with -O option on SUN4C
>  ( SunOs 4.1.1 ).
>

I think I just hit the same bug.  The problem is that teh delay slot
of a conditional branch is filled with an instruction that faults when
the condition is true.  Here's a small example:

struct A {
  virtual void print() { printf("xxx"); }
  void f();
};

void A::f() {
  if (this) {
    print();
  } else {
    printf("0");
  }
}

g++ -v -O -S x.c
Reading specs from /home/super/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 /home/super/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cpp -lang-c++ -v -undef\
 -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__s\
un__ -D__unix__ -D__sparc -D__sun -D__unix -D__OPTIMIZE__ x.c /usr/tmp/cca04347\
.i
GNU CPP version 2.2.2 (sparc)
 /home/super/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca043\
47.i -quiet -dumpbase x.cc -O -version -o x.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.

And here's the code generated for A::f:

_f__1A:
    !#PROLOGUE# 0
    save %sp,-112,%sp
    !#PROLOGUE# 1
    cmp %i0,0
    be L6
    ld [%i0],%o1      <---- this is wrong!  will deref this if this==0
    ldsh [%o1+8],%o0
    ld [%o1+12],%o1
    call %o1,0
    add %i0,%o0,%o0
    b,a L8
L6:
    sethi %hi(LC1),%o0
    call _printf,0
    or %o0,%lo(LC1),%o0
L8:
    ret
    restore

-Urs

----------------------------------------------------------------------------
Urs Hoelzle                                              urs@cs.stanford.EDU
Computer Systems Laboratory, CIS 57, Stanford University, Stanford, CA 94305


Newsgroups: gnu.g++.bug
From: victor@watson.ibm.com (Victor Miller)
Subject: exception in g++?
Reply-To: victor@watson.ibm.com
Organization: IBM, T.J. Watson Research Center
Distribution: gnu
Date: Thu, 20 Aug 1992 13:54:46 GMT

Are exception implemented in g++ (I have ver. 2.2.2)?  Although it
isn't mentioned the documentation, I find that it will accept a throw
statement, but not try or catch.  I quick perusal of the source code
shows that cp-except.c seems to have the stuff in there to implement
code-generation for these statements, and the grammar seems to have
stuff for the keywords try, catch and throw.  Is there some sort of
option that needs to be given?
--
		Victor S. Miller
		Bitnet: VICTOR at WATSON
		Internet: victor@watson.ibm.com
		IBM, TJ Watson Research Center
		"Great artists steal; lesser artists borrow" Igor Stravinsky

Newsgroups: gnu.g++.bug
From: jody@shell.COM (Jody Winston)
Subject: g++ Version 2.2.2 core dump in cc1plus
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 18 Aug 1992 20:30:39 GMT

In g++ 2.2.2 and the current snapshot 920814, the following two code
fragement show two possible locations for NULL derferences in cc1plus.
The diff is from the snapshot and it doesn't attempt to solve the
problem NULL pointer problem, but instead it tries to avoid a core
dump.  I'll try to get a small C++ example that causes the above
failures.


*** 1.9	1992/08/11 16:18:26
--- cp-class.c	1992/08/18 20:12:18
***************
*** 928,936 ****
  	  tree context_binfo = binfo_value (base_context, base, 0);
  	  prepare_fresh_vtable (vbases, context_binfo, t);
  	}
!       modify_vtable_entry (get_vtable_entry (BINFO_VIRTUALS (vbases), base_fndecl),
! 			   build_vtable_entry (this_offset, pfn),
! 			   fndecl, base_context);
      skip: {}
      }
  }
--- 928,942 ----
  	  tree context_binfo = binfo_value (base_context, base, 0);
  	  prepare_fresh_vtable (vbases, context_binfo, t);
  	}
!       if (! BINFO_VIRTUALS (vbases))
!       {
! 	 modify_vtable_entry (get_vtable_entry (BINFO_VIRTUALS (vbases), base_fndecl),
! 			      build_vtable_entry (this_offset, pfn),
! 			      fndecl, base_context);
!       }
!       else
! 	 fprintf(stderr, "Warning BINFO_VIRTUALS (vbases) == NULL\n");
! 
      skip: {}
      }
  }
*** 1.8	1992/08/11 16:18:26
--- cp-typeck.c	1992/08/18 20:11:56
***************
*** 1575,1580 ****
--- 1575,1587 ----
      }
  
    itype = TREE_TYPE (index);
+ 
+   if (!itype)
+   {
+      error("itype is equal to NULL");
+      return error_mark_node;
+   }
+   
    if (TREE_CODE (itype) == REFERENCE_TYPE)
      {
        index = convert_from_reference (index);


Jody Winston		jody@shell.com
..!{sun,psuvax1,bcm,rice,decwrl,cs.utexas.edu}!shell!jody
Consultant to:
Shell Development Company, Bellaire Research Center
P.O. Box 481, Room 4205, Houston, TX 77001	(Voice: 713 245-7574)


Newsgroups: gnu.g++.bug