Re: Bernd Schmidt, release manager for GCC 2.95.3

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

Bernd writes:
> > I'll need to rely on people with more knowledge of the C++ frontend
> > for this issue.  Martin, Jason, as far as I know the vtable-thunks
> > patch has been applied to the 2.95 branch already.  Is there any
> > chance whatsoever that it breaks binary compatibility?  If so, it
> > will have to be reverted.

Martin writes:
> In its current form, it does break binary compatibility. 
> 
> Before you outright revert it, I'd like to present the cases in which
> it currently breaks binary compatibility. With some effort, it would
> be possible to reduce these case so that the remaining cases are
> unlikely to occur in real life; in those cases, it would also then
> reject compilation instead of producing incompatible code.

(or issue a warning)

OK, please present the cases.  The critical thing is that existing C++ shared
libraries in common use, built by 2.95.2, need to link correctly against
2.95.3, and ideally the reverse should be true as well.  Incompatible
libstdc++.so with 2.95.2 would be a disaster, as it means that people
can't share binaries without having yet another extra .so and then we'll
have trouble assigning a number (we're boxed in by numbers chosen by
Red Hat and by snapshots).

I'll arbitrarily define "in common use" as "likely to be installed on
a Debian 2.2 system" (I choose that system because it uses gcc 2.95.2).
Can any Debian folks on this list come up with a list of shared libraries
in potato that have C++ code in them?  In an ideal world, the upgrade
to 2.95.3 would be so smooth that the Debian folks, if they chose, could
include it in a point release.

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?

If you can get it so that the breakage only occurs in rare cases, and we
can describe or detect those cases, that might be acceptable because
fixing the nasty bug is worth asking people to rebuild.

> Also, if that extra effort cannot be invested, it is straight-forward
> to disable the entire patch with two lines of linux-configuration
> changes, instead of removing that code.
> 
> Regards,
> Martin
>