Re: [Patch ObjC/Darwin 1/3] Fix wrong code gen for m64 Objective-C

[IainS <developer at sandoe-acoustics dot co dot uk>]

On 16 Feb 2011, at 22:05, Joseph S. Myers wrote:

> On Wed, 16 Feb 2011, Nicola Pero wrote:
>
> > > Index: gcc/objc/objc-gnu-runtime-abi-01.c
> > > ===================================================================
> > > --- gcc/objc/objc-gnu-runtime-abi-01.c  (revision 0)
> > > +++ gcc/objc/objc-gnu-runtime-abi-01.c  (revision 0)
> > >
> > > [...]
> > >
> > > +#ifndef TARGET_64BIT
> > > +#define TARGET_64BIT 0
> > > +#endif
> >
> > Hmmm.  It seems a bit vague for describing the target. ;-)

In the case under discussion,  the original author of the code  
fragments (imported from a branch) chose to make the alignment padding  
explicit in the template and the initializer.  (my speculation is that  
presumably, there was/is an intention that, at some time, ABI 0 & 1  
will be phased out and ABI 2 will be used for m32 as well).

> Furthermore, TARGET_64BIT is a macro that is private to individual  
> back
> ends.  We're trying to phase out use of target macros in front ends at
> all; use of such macros that are logically private to an individual  
> back
> end rather than part of the public target interface is especially bad.

one of the wider benefits of the patch under discussion is that it  
should provide a mechanism to facilitate the removal of the use of  
TARGET_ASM_xxx entirely from ObjC, without requiring two new hooks.

However, some further partitioning of objc-act.c and/or hook-izing is  
needed before we can lose tm.h, and that is clearly not going to  
happen for 4.6.  I reasoned that the use of the macro was essentially  
neutral in that respect.

---

in this particular case:

For 4.6, there is only one viable target for ABI 2 NeXT, (which is  
also TARGET_64BIT).
Thus, I have changed my local tree to hard-wire the placement of the  
reserved padder field - and removed all references to TARGET_64BIT  
from that file.
If a 32 bit NeXT ABI 2 target appears in the life-time of 4.6, then we  
might need to amend this (and I've placed a comment to the effect that  
the field is padding).

---

One could just remove the explicit padder field, I suppose - but one  
presumes that the original author added it with intent and that the  
code was duly reviewed and approved before it was applied to the branch.

Iain