Re: c++ code that egcs kills ...

Re: c++ code that egcs kills ...

[Glenn W. Bach]

> Per Bothner said your code `is a fairly bogus and arcane (i.e.
> difficult-to-understand)'

> Joe Buck said `Leave the thunks in, and document the case that doesn't
> work.  It is very rare that it will arise in real code, and when it does
> it can be worked around. [...]

> Ulrich Drepper said `I agree with Joe.  I don't want to get in panic just
> because a well known but seldomly used feature does not work as
> expected'.

The reason we found this bug was that it hit us in "real" code. This was
not "bogus". The example code I sent was created to demonstrate in a simple
way what is happening in our code (which is not so simple). For us, this is
not a "seldomly used feature". It is at times the best way to solve a
problem, and is often unavoidable.

In a large loosly-coupled system like ours it becomes increasingly hard to
avoid this situation as the system grows.

p.s. Is there any way we can get around it by just recompiling *our* code?
Telling all of our users that they need to replace all of their libraries
is not going to work.

Glenn

Re: c++ code that egcs kills ...

[Glenn W. Bach]

> 	if (flag_vtable_thunks)
> 	  {
> 	    /* We don't have dynamic thunks yet!
> 	       So for now, just fail silently.  */
> 	  }

That's scary!  Most users have never even heard of a thunk, so a silent
failure means that they will get incorrect code and never know why it
subsequently crashes.

> I believe this is a known problem in the vtable-thunks implementation.
> You may work around it by rebuilding libstdc++ with -fno-vtable-thunks 
> and compiling any C++ program with -fno-vtable-thunks.

When it is the compiler that is at fault, it is unacceptable for a widely
distributed library to require a custom version of a standard library like
libstdc++ .

> My preference was for people to finish off the implementation of
> thunks, and then if they are a codegen win, to default all
> architectures over to thunks.

I agree.  Either put in a fully functional feature or don't put it in at
all.

Glenn

Re: c++ code that egcs kills ...

[Mike Stump]

> Date: Fri, 21 Aug 1998 11:24:45 -0700
> From: "Glenn W. Bach" <glenn@dodgson.wonderland.caltech.edu>
> To: egcs-bugs@cygnus.com

> p.s. Is there any way we can get around it by just recompiling *our* code?

No. Not unless you have a "C" only interface to your code, or unless
the compiler is fixed, sorry.

Re: c++ code that egcs kills ...

[Mike Stump]

> Date: Thu, 20 Aug 1998 16:52:52 -0700
> From: "Glenn W. Bach" <glenn@dodgson.wonderland.caltech.edu>
> To: egcs-bugs@cygnus.com

> Does this mean it will be fixed in egcs-1.1?

Nope, not unless someone steps forward to fix it.  People have know
about it for about a year, and it remains unfixed.

Re: c++ code that egcs kills ...

[Mike Stump]

> From: hjl@innovix.com (H.J. Lu)
> To: egcs-bugs@cygnus.com
> Date: Fri, 21 Aug 1998 10:01:34 -0700 (PDT)

> What is the unfinished part of the thunks implemantation?

The below.

> The only thing I can find is that expand_indirect_vtbls_init () in
> search.c has

> 	if (flag_vtable_thunks)
> 	  {
> 	    /* We don't have dynamic thunks yet!
> 	       So for now, just fail silently.  */
> 	  }
> 	else
> 	  {
> 	     ....
> 	  }

> If the dynamic thunks is working, will that bug be fixed?

Yes.

> Do we need a new thunks implemantation to fix it?

It's more vbase related than thunk related; Jason talks of a new way
to organize vbases, that is one way to fix it.  Implementation of
dynamic thunks would also do it.

> If the dynamic thunks is not implemanted and it does generate
> incorrect codes, why doesn't egcs issue a warning to user?

A warning isn't realistic I feel.  You would have to warn about _any_
vbase code.  This is like saying, sorry, we don't know how to code a
compiler, and we will bite you if you try and use this sucker...

I'd rather just turn off thunks than do a warning.

Re: c++ code that egcs kills ...

[H.J. Lu]

What is the unfinished part of the thunks implemantation? The only
thing I can find is that expand_indirect_vtbls_init () in search.c has

	if (flag_vtable_thunks)
	  {
	    /* We don't have dynamic thunks yet!
	       So for now, just fail silently.  */
	  }
	else
	  {
	     ....
	  }

If the dynamic thunks is working, will that bug be fixed? Do we need
a new thunks implemantation to fix it? If the dynamic thunks is
not implemanted and it does generate incorrect codes, why doesn't
egcs issue a warning to user?

Thanks.


-- 
H.J. Lu (hjl@gnu.org)

Re: c++ code that egcs kills ...

[Alexandre Oliva]

Glenn W Bach <glenn@dodgson.wonderland.caltech.edu> writes:

>> I believe this is a known problem in the vtable-thunks implementation.
>> You may work around it by rebuilding libstdc++ with -fno-vtable-thunks 
>> and compiling any C++ program with -fno-vtable-thunks.

> Does this mean it will be fixed in egcs-1.1?

Unfortunately, no.  The problem is known but, AFAIK, fixing it is
quite hard.  However, it only affects a few rare cases (i.e., virtual
dispatching within constructors of classes with multiple and virtual
inheritance), and there *is* a work around.  Thus, since vtable-thunks
are much faster and work on *most* cases, it is enabled by default on
x86 and some other platforms.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: c++ code that egcs kills ...

[Mike Stump]

> Date: Thu, 20 Aug 1998 10:44:11 -0700
> From: "Glenn W. Bach" <glenn@dodgson.wonderland.caltech.edu>
> To: egcs-bugs@cygnus.com

> The following code demonstrates a bug in how egcs handles c++. 

> Has this been seen before? Is there hope of fixing it in a future version?
> We are stuck, because RedHat Linux uses egcs, so we can't get any of our
> code to work.

If this is the bug I think it is, H.J. Lu (hjl@gnu.ai.mit.edu)
broke your code, and checked in:

Wed Aug 27 01:24:25 1997  H.J. Lu   (hjl@gnu.ai.mit.edu)

       * config/linux.h (DEFAULT_VTABLE_THUNKS): New. Defined as 1 if
        USE_GNULIBC_1 is not defined.

I knew it would break your code, and told him `Some users will expect
this testcase to work. The failure mode of this with thunks is
particularly bad as the this pointer will be wrong at times, and that
shift can cause all sorts of very hard to figure out problems' (see
http://www.cygnus.com/ml/egcs/1997-Aug/0668.html ).  Per Bothner said
your code `is a fairly bogus and arcane
(i.e. difficult-to-understand)' (see
http://www.cygnus.com/ml/egcs/1997-Aug/0676.html ), Joe Buck said
`Leave the thunks in, and document the case that doesn't work.  It is
very rare that it will arise in real code, and when it does it can be
worked around. [...] This particular bug is the least harmful type: it
is 100% predictable what the result will be so informed users will
never be surprised' (see
http://www.cygnus.com/ml/egcs/1997-Aug/0702.html ), and Ulrich Drepper
said `I agree with Joe.  I don't want to get in panic just because a
well known but seldomly used feature does not work as expected'.

My preference was for people to finish off the implementation of
thunks, and then if they are a codegen win, to default all
architectures over to thunks.

You can use -fno-vtable-thunks to solve your problem, but you will
need to recompile _all_ C++ code, and all C++ libraries and libstdc++.

Re: c++ code that egcs kills ...

[Glenn W. Bach]

>> Has this been seen before? Is there hope of fixing it in a future version?
>
>>   B
>>  / \
>> A   D - E
>>  \ /
>>   C
>
>> In the above inheritance tree, B and C inherit virtually from A. When an
>> object of type E is constructed, D's constructor calls a function in A
>> which in turn calls a virtual function overridden by D. This requires a
>> downcast from type A to type D, and egcs incorrectly adjusts the object
>> pointer, forgetting the size of E's member data.
>
> I believe this is a known problem in the vtable-thunks implementation.
> You may work around it by rebuilding libstdc++ with -fno-vtable-thunks 
> and compiling any C++ program with -fno-vtable-thunks.

Does this mean it will be fixed in egcs-1.1?

Glenn W. Bach
PMA Network/Systems Manager
California Institute of Technology

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2

mQCNAzQxQucAAAEEAKDRj+qxIVg4sk71CigXG+DanD23/JSi4PxR78F0qVVnyCV3
qejYSw8wHdisMeWQb+m6jvm7MpfYar+H3DlalMJ69Tm4DLKMU4Bams+kVEiETis9
8Vj9jLaZ0SvG4vOZj69HcqhEnX8COtqmCBjECy/5wQMFCB1K3h6QzWp9VWLlAAUR
tClHbGVubiBXLiBCYWNoIDxnbGVubkBkb2Rnc29uLmNhbHRlY2guZWR1Pg==
=Uwn5
-----END PGP PUBLIC KEY BLOCK-----

Re: c++ code that egcs kills ...

[Alexandre Oliva]

Glenn W Bach <glenn@dodgson.wonderland.caltech.edu> writes:

> Has this been seen before? Is there hope of fixing it in a future version?

>   B
>  / \
> A   D - E
>  \ /
>   C

> In the above inheritance tree, B and C inherit virtually from A. When an
> object of type E is constructed, D's constructor calls a function in A
> which in turn calls a virtual function overridden by D. This requires a
> downcast from type A to type D, and egcs incorrectly adjusts the object
> pointer, forgetting the size of E's member data.

I believe this is a known problem in the vtable-thunks implementation.
You may work around it by rebuilding libstdc++ with -fno-vtable-thunks 
and compiling any C++ program with -fno-vtable-thunks.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

c++ code that egcs kills ...

[Glenn W. Bach]

The following code demonstrates a bug in how egcs handles c++. 

Has this been seen before? Is there hope of fixing it in a future version?
We are stuck, because RedHat Linux uses egcs, so we can't get any of our
code to work.

-----------

The following code demonstrates a bug in egcs 1.0.3. 

  B
 / \
A   D - E
 \ /
  C

In the above inheritance tree, B and C inherit virtually from A. When an
object of type E is constructed, D's constructor calls a function in A
which in turn calls a virtual function overridden by D. This requires a
downcast from type A to type D, and egcs incorrectly adjusts the object
pointer, forgetting the size of E's member data.

The correct output, produced by g++ 2.7.2, is: 

starting test
A::foo  0xbffffb30
B::foo  0xbffffb18
C::foo  0xbffffb20
D::foo  0xbffffb18
E::foo  0xbffffb18
object constructed
E::foo  0xbffffb18
test finished

egcs 1.0.3 produces the incorrect output indicated below: 

starting test
A::foo  0xbffffb40
B::foo  0xbffffb38
C::foo  0xbffffb38
D::foo  0xbffffb2c	<------ incorrect
E::foo  0xbffffb28
object constructed
E::foo  0xbffffb28
test finished

The minimal source code required to reproduce the problem is listed below.
Changing the size of E's member data changes the difference between the
output of D::foo() and E::foo() by exactly the same amount.

Also note that B::foo() and C::foo() should probably not be printing the same result. (They don't with g++ 2.7.2.) 

#include <iostream.h>

class A
{
public:

        A() { bar(); };
        virtual void foo() { cout << "A::foo  " << this << endl; };
        void bar() { foo(); };

private:

        int a;
};

class B : virtual public A
{
public:

        B() { bar(); };
        virtual void foo() { cout << "B::foo  " << this << endl; };

private:

        int b;
};

class C : virtual public A
{
public:

        C() { bar(); };
        virtual void foo() { cout << "C::foo  " << this << endl; };

private:

        int c;
};

class D : public B, public C
{
public:

        D() { bar(); };
        virtual void foo() { cout << "D::foo  " << this << endl; };

private:

        int d;
};

class E : public D
{
public:

        E() { bar(); };
        virtual void foo() { cout << "E::foo  " << this << endl; };

private:

        int e;
};

int
main()
{
        cout << "starting test" << endl;
        E e;
        cout << "object constructed" << endl;
        e.bar();
        cout << "test finished" << endl;
        return 0;
}