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] AAPCS small aggregate argument passing/return inbig-endian mode [csl-arm-branch]


On Wed, 2005-01-26 at 18:38, Paul Brook wrote:
> > 2005-01-25  Julian Brown  <julian@codesourcery.com>
> >
> >  * calls.c (shift_returned_value): Delete in favour of...
> >  (shift_return_value): ...this function. Leave the caller to
> >  check for non-BLKmode values passed in the msb of a register.
> >  Take said mode and a shift direction as argument.  Operate on
> >  the hard function value, not a pseudo.
> >  * (expand_call): Adjust accordingly
> >  * expr.h (shift_return_value): Declare
> >  * function.c (expand_function_start): If a non-BLKmode return
> >  value is padded at the last significant end of the return
> >  register, use the return value's natural mode for the
> >  DECL_RESULT, not the mode of the padded register.
> >          (expand_function_end): Shift the same sort of return values left
> >  by the appropriate amount.
> >          * optabs.c (simplify_expand_binop): New function, backported
> >  from mainline.
> >          (force_expand_binop): New function, backported from mainline and
> >          exported.
> >          * optabs.h (force_expand_binop): Declare.
> >          * stmt.c (shift_return_value): Delete.
> >          (expand_return): Don't call shift_return_value
> >          * config/arm/arm-protos.h (arm_must_pass_in_stack): Declare.
> >          (arm_pad_arg_upward): Declare:
> >          (arm_pad_reg_upward): Declare.
> >          * config/arm/arm.c (TARGET_RETURN_IN_MSB): Define target hook
> 
> Ok.
> 
> You should quote the original Changelog entry in your new ChangeLog. Grep for 
> "Backport:" for existing examples. Ideally the backport bugfix and new code 
> should be separate patches. In this case I think they conveniently split on 
> file boundaries, so it's ok.

I think the two parts should be separated if at all possible.  This will
make it substantially easier to forward-port the new parts to the
mainline when we've branched for 4.0.

R.


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