Re: Bernd Schmidt, release manager for GCC 2.95.3

[Joe Buck <jbuck at racerx dot synopsys dot com>]

> In the current form, the patch forgets to emit symbols under certain
> circumstances. I haven't been able to analyse which symbols are
> missing, or what the bug is that causes those missing symbols. I
> believe some of the symbols are also missing in libstdc++.so.

I seem to recall that some name was getting mangled differently (perhaps
of a vtable in a multiply inherited class?)  There was a link
compatibility problem.

> If that bug is fixed (and I'm willing to invest a day or so trying to
> analyse and correct the problem), then the following incompatibility
> will still remain:
> 
> A constructor with a variable arguments list (...) in a class that is
> virtually derived from a class with virtual functions will not be
> supported.

This is, I think, acceptable, as it will affect fewer people than the
bug that is fixed.

> > It would be nice to fix the vtable-thunks bug if possible, but at least
> > in original form I believe it broke iostreams compatibility, because
> > class iostream is multiply inherited from two virtual base classes
> > and this is a case that triggers the bug.  Right?
> 
> The bug in the vtable thunks stuff is that it fails to emit symbols,
> even though the code for the symbols is there - the compiler should be
> told to emit them, also. Other than that, I'm not aware of any further
> bugs.

> Please note that the original bug fixed with the vtable-thunks code is
> also not present for iostreams: the iostreams constructors don't call
> virtual functions of the base.

Sorry, I misspoke/miswrote.  I know that the iostream class works
correctly, because as you say virtual functions aren't called in the
constructor.  What I meant to say was that the symbols for such classes
come out differently with (at least an early version of) your patch.
Right?