Ordering of introduced functions before replicated overridden functions from non-primary

[michaelw at ca.ibm.com]

The latest gcc 3.2 exhibits a possible error from the abi while gcc 3.0.3
conforms. Here is the testcase:

Here is a simple testcase with all covariant return functions removed to
remove their effects:
class A {
virtual void f();
//virtual A* i();
virtual void j();
int a;
};
class B  {
virtual void f();
virtual void g();
//virtual B* l();
virtual void k();
int b;
};
class C : public A, virtual public B{
virtual void f(); //OR from primary (1)
virtual void g(); // OR of fn introduced by a non-primary base (3)
virtual void h(); //introduced (2)
//virtual C* l(); // covariant OR of fns introduced in non-primary (4)
//virtual C* i(); // covariant OR of fns introduced in primary (2)
int b;
};
C dummyObjectOf_C;
main(){}

Left side is 3.0.3, right side (scrolll over to the right end) is 3.2.
There are
3 differences:
1. the round brackets beside function names
2. the  negative values in the offsets are shown as their unsigned
equivalent
3. the order of function in 3.0.3 is:
f,j,h,g while the order in 3.2 is f,j,g,h
But the ABI Section 2.5.2 cat 2 (non-virtual bases only which also applies
to sharing in mixed bases)
and Cat 3 (virtual bases only which also applies to non-sharing
bases)clearly shows that:
introduced function (h) is preferred over overriden replicated entries (g)


(Bars indicated diffs)

Vtable for C                                                       Vtable
for C
C::_ZTV1C: 15 entries                                   C::_ZTV1C: 15
entries
0     12                                                                 0
12
4     0                                                                   4
0
8     &_ZTI1C                                                    8
&_ZTI1C
12    C::f                                                           |  12
C::f()
16    A::j                                                           |  16
A::j()
20    C::h                                                         |  20
C::g()
24    C::g                                                         |  24
C::h()
28    0                                                                  28
0
32    -12                                                           |  32
4294967284
36    -12                                                           |  36
4294967284
40    -12                                                           |  40
4294967284
44    &_ZTI1C                                                   44
&_ZTI1C
48    C::_ZTv0_n12_N1C1fEv                  |  48    C::_ZTv0_n12_N1C1fEv()
52    C::_ZTv0_n16_N1C1gEv                |  52    C::_ZTv0_n16_N1C1gEv()
56    B::k                                                         |  56
B::k()


Unless I misinterpret the ABI, this is a g++3.2 bug which can seriously
affect binary compatibility. I believe 3.0.3 exhibits the correct behaviour
in this respect as intended by the ABI.

Michael Wong
VisualAge C++ Compiler kernel Development
IBM Canada Ltd., C2/KD2/8200/MKM
8200 Warden Avenue
Markham, Ontario  L6G 1C7
W:905-413-3283 F:905-413-4839