Killing old abi remnants

Killing old abi remnants

[Nathan Sidwell]

Hi,
We have old & new abi code in the compiler. This is selected via the
following #defines
#define vbase_offsets_in_vtable_p() (1)
#define vcall_offsets_in_vtable_p() (1)
#define vptrs_present_everywhere_p() (1)
#define all_overridden_vfuns_in_vtables_p() (1)
#define merge_primary_and_secondary_vtables_p() (1)

will a patch which removes all old abi remnants be acceptable?
As time progresses those old abi parts are going to suffer bitrot.

and what about flag_honor_std?


nathan
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: Killing old abi remnants

[Joseph S. Myers]

On Wed, 18 Jul 2001, Nathan Sidwell wrote:

> will a patch which removes all old abi remnants be acceptable?
> As time progresses those old abi parts are going to suffer bitrot.

If you get rid of old ABI remnants, there's the -fno-new-abi support in
lang-specs.h to remove as well.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Killing old abi remnants

[Mark Mitchell]

--On Wednesday, July 18, 2001 03:46:34 PM +0100 Nathan Sidwell 
<nathan@codesourcery.com> wrote:

> Hi,
> We have old & new abi code in the compiler. This is selected via the
> following #defines
> #define vbase_offsets_in_vtable_p() (1)
> #define vcall_offsets_in_vtable_p() (1)
> #define vptrs_present_everywhere_p() (1)
> #define all_overridden_vfuns_in_vtables_p() (1)
> #define merge_primary_and_secondary_vtables_p() (1)
>
> will a patch which removes all old abi remnants be acceptable?

Yes.  I meant to remove this stuff, but didn't get around to it.

> As time progresses those old abi parts are going to suffer bitrot.
>
> and what about flag_honor_std?

I don't know.  In practice, very little will work with -fno-honor-std, 
because the compiler assumes that pieces of the support library are
probably in `std', but I'd probably keep the flag, for now.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com