Why don't we just FIX the damn vthunk problem?

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 > That's an ABI change, isn't it? If the derived class is old code, and
 > the base class is recompiled, it'll crash - it gets a vtable ptr in
 > _vptr instead of a vtable array.

Yep, you're right.  I don't know why we currently set the vptrs before
calling base and member ctors, but we do.  That's something we could change
for -fnew-abi.

 > I much prefer if incompatible code won't link: Replace the implicit 'int
 > in_chrg' with an implicit 'void *vtable_list'.  Passing 0 as this
 > argument indicates we are the most derived class, passing a pointer to
 > the array is for base classes. If necessary, we can emit the current
 > implicit-int constructor with delegation to the new ABI as a limited
 > form of backwards-compatibility, and abort() if this gets called from a
 > derived class.

Hmm...or we could make vtable_list an additional parameter; that way, we
would still check in_chrg for its old meaning, and use the vtable_list if
available or revert to the old semantics if not.  That would avoid the need
to abort in some situations.

Another thing to consider is that in_chrg is not a boolean for destructors;
it also controls whether to call operator delete.

Jason