Re: Bernd Schmidt, release manager for GCC 2.95.3

[Martin von Loewis <loewis at informatik dot hu-berlin dot de>]

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

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.

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.

To give an example, the following code compiles with gcc 2.95.2, but
won't compile with vtable-thunks=2:

struct Base{
  int x;
  Base(int val):x(val){}
  virtual int foo(){
    return x;
  }
};

struct Middle:virtual Base{
  Middle(int y, ...):Base(y){}
};

struct Derived:Middle{
  Derived():Base(10),Middle(20,30,40){}
};

Since the library does not use vararg constructors, that causes no
problem for the library itself. I also believe that varargs
constructors in classes with polymorphic virtual bases are extremely
rare; users running into that problem could compile with
-fvtable-thunks=1 (and accept the resulting bugs).

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

Regards,
Martin