-fvtable-gc

[Richard Henderson]

Why was this re-enabled?  It hasn't accurately been updated
properly for MI under the v3 abi.

For instance, for Multisv0 from g++.dg/opt/vtgc1.C, we get

_ZTV8Multisv0:
        .long   8
        .long   0

	// Here begins the vtable for Multisv0 derived from Side0

        .long   _ZTI8Multisv0
        .long   _ZN8Multisv0D1Ev
        .long   _ZN8Multisv0D0Ev
        .long   _ZN5Side02x1Ev
        .long   _ZN8Multisv02xxEv
        .long   _ZN8Multisv02f6Ev
        .long   _ZN8Multisv02f1Ev
        .long   _ZN8Multisv02f2Ev
        .long   _ZN8Multisv02f3Ev
        .long   0
        .long   -8
        .long   -8
        .long   -8
        .long   -8
        .long   -8

	// Here begins the vtable for Multisv0 derived from Base2

        .long   _ZTI8Multisv0
        .long   _ZTv0_n12_N8Multisv0D1Ev
        .long   _ZTv0_n12_N8Multisv0D0Ev
        .long   _ZTv0_n16_N8Multisv02f1Ev
        .long   _ZTv0_n20_N8Multisv02f2Ev
        .long   _ZTv0_n24_N8Multisv02f3Ev
        .long   _ZN5Base22f4Ev

The existing vtable-gc implementation in ld requires that
each derived vtable have its own symbol, so that it can
build up the single-inheritance vtable tree, so that it 
can mark derived vtable entries as used when a base vtable
entry is used.

This is still in serious need of being re-implemented in
binutils, but right now you'll get incorrect collection.


r~