Re: A vtable thunks bug.

Re: A vtable thunks bug.

[H.J. Lu]

> 
> Ulrich Drepper writes:
> 
> > Alexandre Oliva  writes:
> >> What if libstdc++ were multilib'ed: one version compiled with
> >> -fvtable-thunks and another -fno-vtable-thunks, on appropriate hosts?
> >> This way a user could select which library to use.
> 
> > multilibs are good to provide different features but not to work
> > around bugs.
> 
> As far as I understand, object files compiled with -fvtable-thunks are
> not binary-compatible with ones compiled without this flag.  This is,
> alone, a reason either to build multiple versions of a library, so
> that users can compile their own programs with whatever option they
> want and know that they will work with their installed library (except
> for this bug), or to disable the ability to select one or another
> method at run-time.
> 

Do you want to select libc? How about libc.so? I don't like
the multilibs for this problem at all. When libc/libc.so is
involved, it becomes very complicated.


H.J.

Re: error in g++ error report

[Alexandre Oliva]

Gabriel Dos Reis writes:

> % g++ toto.C
> toto.C: In function `int main()':
> toto.C:10: no matching function for call to `A::A (A)'
> toto.C:3: candidates are: A::A()
> toto.C:4:                 A::A(A &)
> toto.C:10: in base initialization for class `A'

> A::A(A) is not a constructor and one cannot declare such a function. So
> why is g++ trying to call A::A(A) ?

I don't think this is the serious part of this bug.  First of all, it
has nothing to do with base initialization, as the last line says, and
it should say that it is trying to match a `const A' with one of the
available constructors.  Maybe a special case should be created for
copy-constructors, though.  I'll take a look into this problem.

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

Re: A vtable thunks bug.

[Alexandre Oliva]

H J Lu writes:

> Do you want to select libc? How about libc.so? I don't like
> the multilibs for this problem at all. When libc/libc.so is
> involved, it becomes very complicated.

Are we talking about the C library or about the C++ library?

If you write a piece of C++ code and embed it into the C library using
appropriate extern "C" wrappers, it automatically becomes compatible
with whatever C program you write, or even C++ ones that do not try to
cast pointers provided by this library back to C++ pointers.

However, if we're talking about a C++ library, that is, a library of
classes intended to be used by C++ programmers, then the possibility
of having two compiled versions of this library would be desirable.

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

Re: A vtable thunks bug.

[Ulrich Drepper]

meissner@cygnus.com writes:

> I will note that in general, you don't want multilib if you can avoid it....

Underline this at least three times!!!  I have no interest in even
thinking about this.

-- Uli
---------------.      drepper@cygnus.com  ,-.   Rubensstrasse 5
Ulrich Drepper  \    ,-------------------'   \  76149 Karlsruhe/Germany
Cygnus Solutions `--' drepper@gnu.ai.mit.edu  `------------------------

Re: A vtable thunks bug.

[Jason Merrill]

>>>>> Alexandre Oliva  writes:

> In fact, if such objects are not binary-compatible, it would be wise
> to mangle names of methods in a different way, so that people cannot
> link object files or libraries produced with one flag with ones
> produced with the other.

vtables are mangled differently.

Jason

Re: A vtable thunks bug.

[meissner]

| Do you want to select libc? How about libc.so? I don't like
| the multilibs for this problem at all. When libc/libc.so is
| involved, it becomes very complicated.

Multilibs used correctly, I don't see it as much of a problem.  By correct, I
mean using multilibs of libc and friends as well, and each of the libcs having
different sonames, etc.  While I've cut it down to 10, I used to support 28
different multilibs for the powerpc-eabi targets, and it is just a matter of
going through and making sure it is applied everywhere.  Of course, you do need
lots of disk space to build the multilibs as well as processor time.....

I will note that in general, you don't want multilib if you can avoid it....

Re: A vtable thunks bug.

[Alexandre Oliva]

Ulrich Drepper writes:

> Alexandre Oliva  writes:
>> What if libstdc++ were multilib'ed: one version compiled with
>> -fvtable-thunks and another -fno-vtable-thunks, on appropriate hosts?
>> This way a user could select which library to use.

> multilibs are good to provide different features but not to work
> around bugs.

As far as I understand, object files compiled with -fvtable-thunks are
not binary-compatible with ones compiled without this flag.  This is,
alone, a reason either to build multiple versions of a library, so
that users can compile their own programs with whatever option they
want and know that they will work with their installed library (except
for this bug), or to disable the ability to select one or another
method at run-time.

In fact, if such objects are not binary-compatible, it would be wise
to mangle names of methods in a different way, so that people cannot
link object files or libraries produced with one flag with ones
produced with the other.


However, if there's no such binary incompatibility, and I'm just
writing garbage, please disregard all this idea about multi libstdc++
because of vtable-thunks, and feel free to correct me :-)

Regards,

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

Re: A vtable thunks bug.

[meissner]

| Alexandre Oliva  writes:
| 
| > What if libstdc++ were multilib'ed: one version compiled with
| > -fvtable-thunks and another -fno-vtable-thunks, on appropriate hosts?
| > This way a user could select which library to use.
| 
| So far the libg++ uses thunks only on Linux and here we don't need
| multilibs.

Well, it would be nice if the x86 had done multilibs for -msoft-float.

Re: A vtable thunks bug.

[Ulrich Drepper]

Alexandre Oliva  writes:

> What if libstdc++ were multilib'ed: one version compiled with
> -fvtable-thunks and another -fno-vtable-thunks, on appropriate hosts?
> This way a user could select which library to use.

So far the libg++ uses thunks only on Linux and here we don't need
multilibs.

But even if there were other platforms I don't think this is a good
solution.  If you tell the people "here you have two libs, you the
second if you don't get the expected result with the first" everybody
will immediately use the second (in our case, without thinks).
multilibs are good to provide different features but not to work
around bugs.  As Joe pointed out it is probably good enough to
document the problem and somehow provide a template how to work around
this.

-- Uli
---------------.      drepper@cygnus.com  ,-.   Rubensstrasse 5
Ulrich Drepper  \    ,-------------------'   \  76149 Karlsruhe/Germany
Cygnus Solutions `--' drepper@gnu.ai.mit.edu  `------------------------

Re: A vtable thunks bug.

[Ulrich Drepper]

Joe Buck  writes:

> 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.

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.  I know
more severe problems in gcc.

So I'll leave glibc-2.0.5 as it is and will also add the think stuff
to 2.1.  Maybe even somebody could give g++ a look and examine the
problem.  Since there are solutions for this while still using thinkgs
this is no fundamental design flaw.

-- Uli
---------------.      drepper@cygnus.com  ,-.   Rubensstrasse 5
Ulrich Drepper  \    ,-------------------'   \  76149 Karlsruhe/Germany
Cygnus Solutions `--' drepper@gnu.ai.mit.edu  `------------------------

Re: A vtable thunks bug.

[Jason Merrill]

>>>>> Mike Stump <mrs@wrs.com> writes:

>> From: Jason Merrill <jason@cygnus.com>
>> Date: 28 Aug 1997 17:42:41 -0700

>> In the -fno-vtable-thunks case, we build up a temporary vtable on the stack
>> and use that in the constructor.  We should be able to do the same thing
>> for -fvtable-thunks; looking at the current code, it seems unnecessarily
>> slow; as far as I can tell, all the values can be computed at compile time,
>> but g++ is computing them in the constructor.  Mike, am I missing anything?

> With the current codegen scheme, no the offsets can't be known at
> compile time.  If you introduce a binary incompatibility as in the
> below, then you can avoid the problem.

Yep, I realized that after I posted the above.  I imagine it would work to
decide on all the vtables in the most derived class and pass them down,
but that may not be very reasonable.

> If someone wants to do this, do vtable-thunks, normal vtables, and
> then the scheme used by other vendor's compilers.  Comparing against
> Sun's 4.x line, HP's newer compiler, Dec's, VC++ would give us a
> pretty good idea of what scheme is best.

I just tried to look at what HP does, and quickly decided not to bother
right now.  I've never found PA assembly particularly readable...

Jason

Re: A vtable thunks bug.

[Mike Stump]

> From: Jason Merrill <jason@cygnus.com>
> Date: 28 Aug 1997 17:42:41 -0700

> In the -fno-vtable-thunks case, we build up a temporary vtable on the stack
> and use that in the constructor.  We should be able to do the same thing
> for -fvtable-thunks; looking at the current code, it seems unnecessarily
> slow; as far as I can tell, all the values can be computed at compile time,
> but g++ is computing them in the constructor.  Mike, am I missing anything?

With the current codegen scheme, no the offsets can't be known at
compile time.  If you introduce a binary incompatibility as in the
below, then you can avoid the problem.

As to being slow, it is only slow if there are vbases and if they are
in different locations and then, only at contruction/destruction time.
If you optimize for speed for the normal case, the method below I
think will take more of a hit than the method used now.  It would be
nice to see someone benchmark the dispatch times and let us know the
tradeoffs.  People with cycle counters would be the best to try it
out.  Failing that, just do the op 100000 times...

If someone wants to do this, do vtable-thunks, normal vtables, and
then the scheme used by other vendor's compilers.  Comparing against
Sun's 4.x line, HP's newer compiler, Dec's, VC++ would give us a
pretty good idea of what scheme is best.

As to what to benchmark, simple virtual, derived virtual, vbase
virtual come to mind.

> The VC++ solution is to store the correct offset in the word just before
> the vbase subobject, so the thunks just adjust by the value stored there.
> VC++ also uses a table of vbase offsets instead of a pointer for each
> vbase.

Re: A vtable thunks bug.

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

> Ooooops. I didn't make myself clear. By "it", I meant "code with multi
> ple inheritance that calls virtual functions from constructors of
> multiply inherited objects."

To further clarify the situation, it only occurs in the presence of virtual
inheritance, where neither the base vtable nor the derived vtable are
correct for constructing the base class, because the offsets in the base
vtable are wrong.

int fail = 1;
struct B;
struct A { virtual int f(const B*) = 0; int g(const B*); };
int A::g(const B* t) { return f(t); }
struct B : virtual A { B(); int f(const B*); B* B_this; };
B::B() { if (g(this)) fail = 0; }
int B::f(const B* t) { return t == this; }
struct C : B { int f(const B*); int x; };
int C::f(const B*) { return 0; }

int main() { C c; return fail; }

Here, while we are constructing the B base subobject of C, we need to set
up the A vtable pointer so it reflects the virtual functions of B, but the
base offsets of C.  If we use the B vtable, the offset is off by
sizeof(int), so the comparison in B::f (called from A::g, from the B
constructor) fails.  If we use the C vtable, we get C::f, which is wrong.

In the -fno-vtable-thunks case, we build up a temporary vtable on the stack
and use that in the constructor.  We should be able to do the same thing
for -fvtable-thunks; looking at the current code, it seems unnecessarily
slow; as far as I can tell, all the values can be computed at compile time,
but g++ is computing them in the constructor.  Mike, am I missing anything?

The VC++ solution is to store the correct offset in the word just before
the vbase subobject, so the thunks just adjust by the value stored there.
VC++ also uses a table of vbase offsets instead of a pointer for each
vbase.

Jason

Re: A vtable thunks bug.

[Joe Buck]

> > No.  It doesn't appear to be a major problem, and it's hard to fix.  You're
> > welcome to work on it if you like.  It's just a bug, and an obscure one at
> 
> Ok. Is that mentioned somewhere in g++ doc?

Perhaps we should add a "known bugs and limitations" document for the C++
front end; this would apply to both egcs and gcc2 so it could be submitted
to both.  It could list those draft standard features not yet implemented,
plus cases like this one.

Re: A vtable thunks bug.

[H.J. Lu]

> 
> I wrote:
> 
> > > If we can characterize the bug carefully and satisfy ourselves that it
> > > will rarely bite people, it still could be useful in its current form.
> > > The buggy cases should be documented.  In this case, it shouldn't be
> > > hard to exactly describe what cases will get different results.
> 
> HJ writes:
> 
> > If that is case, please emphasize that it should not be used in any
> > C++ code with gcc even if it works with your gcc.
> 
> Wait a minute!  "any C++ code"?  Come on.  First, only code with multiple
> inheritance that calls virtual functions from constructors of multiply
> inherited objects can possibly be affected.  Even then, only certain
> cases are affected.  Given how kludgy C++ multiple inheritance is,
> many programmers completely avoid it, so they can't possibly be affected.

Ooooops. I didn't make myself clear. By "it", I meant "code with multi
ple inheritance that calls virtual functions from constructors of
multiply inherited objects."

FYI, I have just resent a patch to enable thunks in glibc 2.1.


H.J.

Re: A vtable thunks bug.

[Per Bothner]

> > Of course it can make sense to use an incomplete feature.
> 
> You know better than that.

Huh?  I don't see how your response contradicts my claim.
Please read before you respond.

> The thunks support directly
> affects stdio in glibc. Right now the thunks support is
> enabled for Linux in glibc. That means you have to use g++
> with the thunks support to use libio in glibc and get a MT safe
> stdio/iostream. If we turn off the thunks support in g++,
> we have to put in a replacement of libio in libstdc++,
> which is not MT safe and inefficient. It is also very confusing
> to user.

So you seem to be arguing in favor of thunks.  Fine.  We're agreed.

> It doesn't work that way, at least not for glibc. glibc and libstdc++
> have to know if vtable thunks is used or not. You can not compile
> glibc and libstdc++ with one, then use a different one for your
> programs. It won't work.

No-one is suggesting that.   We are dicussing whether to use thunks
consistently or not use thunks consistently (as the default for
Linux with glibc).

> If that is case, please emphasize that it should not be used in any
> C++ code with gcc even if it works with your gcc. We don't know
> if that C++ code will work with the same release of gcc on the same
> hardware.

This is incomprehensible.  What is "it"?  What is "gcc" as in contrast
with "our gcc"?  What is "that C++ code"?  (I'm guess that little
test snippet.)

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: A vtable thunks bug.

[Joe Buck]

I wrote:

> > If we can characterize the bug carefully and satisfy ourselves that it
> > will rarely bite people, it still could be useful in its current form.
> > The buggy cases should be documented.  In this case, it shouldn't be
> > hard to exactly describe what cases will get different results.

HJ writes:

> If that is case, please emphasize that it should not be used in any
> C++ code with gcc even if it works with your gcc.

Wait a minute!  "any C++ code"?  Come on.  First, only code with multiple
inheritance that calls virtual functions from constructors of multiply
inherited objects can possibly be affected.  Even then, only certain
cases are affected.  Given how kludgy C++ multiple inheritance is,
many programmers completely avoid it, so they can't possibly be affected.
As for the rest, they are still unlikely to encounter it.  Yes, at least
one user was affected (since Cygnus has a PR).  I suspect that that user
quickly found a workaround.

Given all this, how can you say that it "should not be used in any C++ code"?
Please be careful in any public statements you make about this.  Lately,
your outcries over any known gcc bug that has ever been found have been
wildly excessive, and here you are, doing it again.  If you can't restrain
yourself, you risk doing grave damage to gcc's reputation, since *any*
release will have bugs, and excessive screaming about them may convince
users that they must use some other compiler.

> We don't know
> if that C++ code will work with the same release of gcc on the same
> hardware.

Sure we do.  We know exactly what cases will trigger the bug.

Yes, we should figure out a way of fixing it if we can.  But in real life,
software ships with known bugs.  Sorry.

Re: A vtable thunks bug.

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

>> I'd like to go with -fvtable-thunks now.  This bug will be fixed
>> eventually.

> It doesn't work that way, at least not for glibc. glibc and libstdc++
> have to know if vtable thunks is used or not.

I know that.  And libstdc++ depends on that regardless of libc.

> You can not compile glibc and libstdc++ with one, then use a different
> one for your programs. It won't work. BTW, glibc and libstdc++ dont have
> to be same on vtable thunks support. But that will lead to non MT-safe
> and less efficient libstdc++.

Right.

> We need to know how serious this bug is. Say the Cygnus customer
> who sent that PR now wants to port that application to Linux which
> uses vtable thunks support. Should I worry about it?

No.  This is very unlikely, since the customer in question was writing for
an embedded system.

> Should I tell them in order to get a MT-safe, working libstdc++, they
> have to recompile glibc/libstdc++ and they cannot use libstdc++.so?

Or just libstdc++, yes.  I currently use a thunk libio with libc 5, and it
mostly works.

> BTW, any idea when people will work on that bug?

No.  It doesn't appear to be a major problem, and it's hard to fix.  You're
welcome to work on it if you like.  It's just a bug, and an obscure one at
that.  There are lots of bugs in the compiler, and we have to prioritize.

Jason

Re: A vtable thunks bug.

[Joe Buck]

> > > It doesn't make any senses to use an incomplete g++ feature anyway.
> > 
> > You mean like templates?
> > 
> > Of course it can make sense to use an incomplete feature.

In this case, it can still make sense to use thunks even though this
case doesn't match spec.

> You know better than that. The thunks support directly
> affects stdio in glibc. Right now the thunks support is
> enabled for Linux in glibc. That means you have to use g++
> with the thunks support to use libio in glibc and get a MT safe
> stdio/iostream. If we turn off the thunks support in g++,
> we have to put in a replacement of libio in libstdc++,
> which is not MT safe and inefficient. It is also very confusing
> to user.

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.

HJ, you have a tendency to over-react to bugs.  This particular bug
is the least harmful type: it is 100% predictable what the result
will be so informed users will never be surprised.

Re: A vtable thunks bug.

[H.J. Lu]

> 
> > It doesn't make any senses to use an incomplete g++ feature anyway.
> 
> You mean like templates?
> 
> Of course it can make sense to use an incomplete feature.

You know better than that. The thunks support directly
affects stdio in glibc. Right now the thunks support is
enabled for Linux in glibc. That means you have to use g++
with the thunks support to use libio in glibc and get a MT safe
stdio/iostream. If we turn off the thunks support in g++,
we have to put in a replacement of libio in libstdc++,
which is not MT safe and inefficient. It is also very confusing
to user.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: A vtable thunks bug.

[H.J. Lu]

> 
> >>>>> Per Bothner <bothner@cygnus.com> writes:
> 
> > feature.  Do real programs (i.e. not deliberately constructed
> > test-cases) depend on the exact semantics of vtables during
> > construction?  I would be surprised if that were the case.
> 
> At least one real program depends on those semantics, since this testcase
> came from a Cygnus PR.  However, I agree that it is extremely uncommon, and
> very few compilers get it right currently.  As far as I know, VC++ is the
> only other one that does.  Even EDG gets it wrong.
> 
> > Still, given that the existing implementation works, even if it is
> > less efficient, it may be reasonable to not make it the default
> > quite yet.  I think this is Jason's call.
> 
> I'd like to go with -fvtable-thunks now.  This bug will be fixed
> eventually.

It doesn't work that way, at least not for glibc. glibc and libstdc++
have to know if vtable thunks is used or not. You can not compile
glibc and libstdc++ with one, then use a different one for your
programs. It won't work. BTW, glibc and libstdc++ dont have to be
same on vtable thunks support. But that will lead to non MT-safe and
less efficient libstdc++.
 
We need to know how serious this bug is. Say the Cygnus customer
who sent that PR now wants to port that application to Linux which
uses vtable thunks support. Should I worry about it? Should I tell
them in order to get a MT-safe, working libstdc++, they have to
recompile glibc/libstdc++ and they cannot use libstdc++.so?

BTW, any idea when people will work on that bug?

Thanks.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: A vtable thunks bug.

[Joe Buck]

> Do real programs (i.e. not deliberately constructed
> test-cases) depend on the exact semantics of vtables during
> construction?  I would be surprised if that were the case.

Unfortunately, they sometimes do.  There's a good rationale for
things working the way they do, and now that I understand it
I like its elegance.  But then, I avoid C++ multiple inheritance
like the plague, so for me thunks just halve the size of vtables
and as long as iostreams work odd behavior in certain multiple
inheritance cases won't matter that much; they won't break any
of my code.

Anyway, since in many cases it would be natural to have most-derived
methods called during construction, many programmers avoid
virtual method calls during constructors and add a separate
initialization mechanism.

If we can characterize the bug carefully and satisfy ourselves that it
will rarely bite people, it still could be useful in its current form.
The buggy cases should be documented.  In this case, it shouldn't be
hard to exactly describe what cases will get different results.

Re: A vtable thunks bug.

[Per Bothner]

> It doesn't make any senses to use an incomplete g++ feature anyway.

You mean like templates?

Of course it can make sense to use an incomplete feature.

The advantage of using thunks is that it provides a more compact and
faster implementation of virtual function calls.  The problem is
that it does not correctly handle virtual functions calls made
while constructing and destroying an object.  On the other hand,
that is a fairly bogus and arcane (i.e. difficult-to-understand)
feature.  Do real programs (i.e. not deliberately constructed
test-cases) depend on the exact semantics of vtables during
construction?  I would be surprised if that were the case.

Still, given that the existing implementation works, even if it is
less efficient, it may be reasonable to not make it the default
quite yet.  I think this is Jason's call.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: A vtable thunks bug.

[H.J. Lu]

> 
> > From: hjl@lucon.org (H.J. Lu)
> > To: mrs@wrs.com (Mike Stump)
> > Date: Wed, 27 Aug 1997 17:16:28 -0700 (PDT)
> 
> > Since it is a bug, how hard to fix it?
> 
> Hard enough that it remain unfixed.  Essentially the entire way virual
> bases are laidout and accessed can be changed, or you can teach g++
> how to create a thunk at runtime given the this offset as a runtime
> variable.
> 
> > Is it a design flaw or an implementation error?
> 
> I view it as an implementation incompleteness.

In another word, the vtable thunks support in gcc is incomplete.

> 
> > How long will it take to fix that?
> 
> I have no plans to work on it.
> 
> > Can it be fixed before the first egcs release?
> 
> I don't know.

Ulrich, it looks like it is very unlikely the vtable thunks support in
gcc will be completed any time soon. I believe it was a mistake to
use the vtable thunks in glibc. I suggest we rollback the vtable thunks
changes in glibc 2.0.5 before it is too late. Although my patch to
libio in libstdc++ can detect the compatibility between libc and
compiler, it also disables the MT support in libio. It doesn't make
any senses to use an incomplete g++ feature anyway. Redhat will beta
test glibc 2 based Linux system any time now. I think glibc 2.0.5.1 
is in order to address this problem. We can re-enable thunks support
with glibc 3 or deal it with ELF versioning when the vtable thunks
is really working in gcc.

Sorry for that. If necessary, I can provide a patch for glibc 2.0.5.
Glibc 2.1 hasn't enabled thunks yet. It is ok.

Thanks.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: A vtable thunks bug.

[Mike Stump]

> From: hjl@lucon.org (H.J. Lu)
> To: mrs@wrs.com (Mike Stump)
> Date: Wed, 27 Aug 1997 17:16:28 -0700 (PDT)

> Since it is a bug, how hard to fix it?

Hard enough that it remain unfixed.  Essentially the entire way virual
bases are laidout and accessed can be changed, or you can teach g++
how to create a thunk at runtime given the this offset as a runtime
variable.

> Is it a design flaw or an implementation error?

I view it as an implementation incompleteness.

> How long will it take to fix that?

I have no plans to work on it.

> Can it be fixed before the first egcs release?

I don't know.

Re: A vtable thunks bug.

[H.J. Lu]

> 
> > From: hjl@lucon.org (H.J. Lu)
> > Date: Wed, 27 Aug 1997 14:57:10 -0700 (PDT)
> 
> > Should I worry about it?
> 
> That is up to you.  I do, but then I worry about any regression.
> Turning on thunks causes this regression.  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.
> 

That is what I am afraid of. Since this bug is not specific to
x86 and glibc has changed to use thunks by default, that is
very bad. It will be hard to make a working, compatible libstdc++.so
for glibc since libio glibc has to know if thunks are used or not.
Although my patch to libio in egcs deals with it, it is not good.

Since it is a bug, how hard to fix it? Is it a design flaw or
an implementation error? How long will it take to fix that? Can
it be fixed before the first egcs release?

FWIW, Visual C++ 5.0 does it right.

Thanks.


H.J.

Re: A vtable thunks bug.

[Mike Stump]

> From: hjl@lucon.org (H.J. Lu)
> Date: Wed, 27 Aug 1997 14:57:10 -0700 (PDT)

> Should I worry about it?

That is up to you.  I do, but then I worry about any regression.
Turning on thunks causes this regression.  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.

> What does ANSI C++ standard say we should get?

It mandates that the test work.

> If gcc with thunk support doesn't work the way the standard
> specifies, it should be bug.

Yes, and it is.

Re: A vtable thunks bug.

[H.J. Lu]

> 
> This is a flaw with thunk support.  The testcase can just be marked as
> expected to fail on your system.
> 

I don't feel very comfortable about it. BTW, it fails
on Sparc/Solaris also. Should I worry about it?

What does ANSI C++ standard say we should get? If gcc
with thunk support doesn't work the way the standard
specifies, it should be bug.

We just enabled thunk support by default on Linux/glibc. Maybe
it is a bad idea. Ulrich, if it is a bug and unfixable in gcc,
I think we should disable thunk support in glibc now before it
is too late.

Ulrich, in case you don't know. gcc gives different results
with -fvtable-thunks or -fno-vtable-thunks.

# gcc x.cc -fvtable-thunks
# a.out
# echo $?
1
# gcc x.cc -fno-vtable-thunks
# a.out
# echo $?
0

Thanks.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)
----
int fail = 1;
struct B;
struct A { virtual int f(const B*) = 0; int g(const B*); };
int A::g(const B* t) { return f(t); }
struct B : virtual A { B(); int f(const B*); B* B_this; };
B::B() { if (g(this)) fail = 0; }
int B::f(const B* t) { return t == this; }
struct C : B { int f(const B*); int x; };
int C::f(const B*) { return 0; }
 
int main() { C c; return fail; }

Re: A vtable thunks bug.

[Mike Stump]

This is a flaw with thunk support.  The testcase can just be marked as
expected to fail on your system.

A vtable thunks bug.

[H.J. Lu]

This test failed with

# gcc  g++.mike/p6610a.C -fvtable-thunks
# a.out
# echo $?
1
# gcc  g++.mike/p6610a.C -fno-vtable-thunks
# a.out
# echo $?
0

I am using Linux/x86.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)
---g++.mike/p6610a.C----
// prms-id: 6610

int fail = 1;
struct B;
struct A { virtual int f(const B*) = 0; int g(const B*); };
int A::g(const B* t) { return f(t); }
struct B : virtual A { B(); int f(const B*); B* B_this; };
B::B() { if (g(this)) fail = 0; }
int B::f(const B* t) { return t == this; }
struct C : B { int f(const B*); int x; };
int C::f(const B*) { return 0; }

int main() { C c; return fail; }