This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR 14262 breakage on Darwin


Jim Wilson wrote:
> On Thu, 2004-03-25 at 08:36, Ulrich Weigand wrote:
> > Anyway, would you agree that gcc should keep its old behaviour in this
> > case (as implemented by my patch)?  Or do say that this is just a
> > libffi bug?
> 
> I think Apple cares deeply about maintaining ABI compatibility across
> releases.  So it is probably not safe to change the ABI.  We could
> perhaps fix this by modifying the rs6000 backend to return a PARALLEL in
> this case, and then document it as compatibility for a historical
> error.  This is probably better than hacking up the calls.c code if it
> works.

That may be the case, but I'd defer to the rs6000 maintainers here, as
I have neither the experience with that backend nor the required test 
setup to provide such an patch.

> If we can't make that work, then we have to go with the calls.c patch. 
> This patch desperately needs comments explaining why this weirdness is
> needed though.

What about something like:

  /* For targets that do not define BLOCK_REG_PADDING, we default to
     what DEFAULT_FUNCTION_ARG_PADDING would do: usually pad upward,
     but pad short args downward on big-endian machines.  (All args
     that arrive here are short.)

     However, this does not apply to arguments passed *both* on the
     stack and in a register -- here we simply load a copy of the
     stack slot into the register, using the same padding as was
     chosen for the stack slot.  Note that e.g. the Darwin ABI
     depends on this historical behavior.  */

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]