Re: 970828 snapshot

Re: 970828 snapshot

[Joe Buck]

Ignore previous msg about ChangeLog.  Of course I was looking in the
wrong place, having been used to gcc snapshots.  Duh.

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: 970828 snapshot

[Joe Buck]

> Diffs are included to bring 970825 up to 970828.  There are no changes
> in the testsuite directory itself, so there's no need to fetch the
> diff.gz files for the testsuites.

Did something go wrong with the ChangeLog entries?  There's only one
entry in the ChangeLog for the top level despite many changes.

Re: 970828 snapshot

[Jeffrey A Law]

  In message <m0x4EZF-0004ekC@ocean.lucon.org>you write:
  > > 
  > > 
  > > I'm away from the office right now, but I figured I'd go ahead and
  > > put the 970828 snapshot up for ftp.
  > > 
  > 
  > They are not readable.
Thanks.  Fixed.

jeff

970828 snapshot

[Jeffrey A Law]

I'm away from the office right now, but I figured I'd go ahead and
put the 970828 snapshot up for ftp.

Diffs are included to bring 970825 up to 970828.  There are no changes
in the testsuite directory itself, so there's no need to fetch the
diff.gz files for the testsuites.

I'll update the snapshot web page when I get back to the office later
tonight.  I'll also look through some of the submissions from today
(like the sh rtems port).


Enjoy!
Jeff

Jeff Law (law@cygnus.com)
Cygnus Solutions		EGCS GNU Compiler System
http://www.cygnus.com		http://www.cygnus.com/egcs

Re: 970828 snapshot

[H.J. Lu]

> 
> 
> I'm away from the office right now, but I figured I'd go ahead and
> put the 970828 snapshot up for ftp.
> 

They are not readable.

H.J.