🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.gcc.bug
Article #1599

bugs in gcc-2.3.3

#1599
From: Wolfgang Anton Sommerer
Date: Thu, 07 Jan 1993 12:04
129 lines
3445 bytes
I have to report two bugs which occured while installing InterViews3.1
and libg++-2.3. Hardware configuration is a SUN4/60 running SunOS4.1.1.


1.) Bug in handling of multpile inheritance

This bug actually occured when running the doc Apllication of InterViews3.1.
It resulted in a segmentation violation with the following phenomenon.

	The line 
	
		x->request(y);
		
	resulted in a call to
	
		x->event(y);
	
I was able to isolate the problem and reproduce it in a samll example program.

**** file : a.h ******

class Z {
public:
	virtual void z();
};

class A : public Z {
public:
	virtual void a1();
	virtual void a2();
};

class B : public Z {
public:
	virtual void b1();
	virtual void b2();
	virtual void b3();
};

class C : public A, public B {
	virtual void a1();
	virtual void a2();
	virtual void b1();
	virtual void b2();
};

**** file : a.C ******

#include "a.h"
#include "iostream.h"

void Z::z()  { }

void A::a1() { cout << " A::a1() called" << endl; }
void A::a2() { cout << " A::a2() called" << endl; }

void B::b1() { cout << " B::b1() called" << endl; }
void B::b2() { cout << " B::b2() called" << endl; }
void B::b3() { cout << " B::b3() called" << endl; }

void C::a1() { cout << " C::a1() called" << endl; }
void C::a2() { cout << " C::a2() called" << endl; }
void C::b1() { cout << " C::b1() called" << endl; }
void C::b2() { cout << " C::b2() called" << endl; }


**** file : main.C *****

main()
{
C c;

A& c1 = c;
B& c2 = c;

	c1.a2();
	c1.a1();
	c2.b1();
	c2.b2();
	c2.b3();
}


**** result of running the program ****

C::b2() called			<--- should be C::a2()
C::b1() called			<--- should be C::a1()
C::b1() called
C::b2() called
B::b3() called

The reason for this behaviour is a wrong vtable generated in file 
main.C (or a.C if #pragma interface and #pragma implementation is used).

_vt$C entries do not point to class A methods. They rather point to the
class B mehtods which reside at the same slot index. Changing the vtable 
in the assembler code manually did at least result in the expected behaviour 
of the program.

This workaround also fixed the problem at hand in the InterViews applicaiton.
But there the bug occurs many times, so manually changing the assembeler code
is impossible.



2.) Bug when compiling libg++-2.3

Compiling iostream.cc will generate a symbol named __vt$istream$3ios.
Compiling another file which includes iostream.h will generate 
a symbol __vt$7istream$3ios. So when linking the two files you'll get an
undefined symbol (__vt$7istream$3ios).

I solved the problem by putting a forward declaration of class istream into
streambuf.h.

I changed line 39 from :
	class ostream; class streambuf; class backupbuf;
to:
	class istream; class ostream; class streambuf; class backupbuf;

This works fine !



If there exists a patch for the first problem please let me know.

Regards,

Wolfgang Sommerer
Technical Details
Message-ID: <9301071004.AA18966@oberon.hai.siemens-austria>
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!garwein.hai.siemens.co.AT!was%oberon

Show Full Headers
Complete Article Headers
Newsgroups: gnu.gcc.bug
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!garwein.hai.siemens.co.AT!was%oberon
From: was%oberon@garwein.hai.siemens.co.AT (Wolfgang Anton Sommerer)
Subject: bugs in gcc-2.3.3
Message-ID: <9301071004.AA18966@oberon.hai.siemens-austria>
Sender: gnulists@ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 12:04:20 GMT
Approved: bug-gcc@prep.ai.mit.edu
Lines: 133