This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch to fix several compat failures on irix6.5
On Mon, Aug 25, 2003 at 02:00:33PM +0100, Richard Sandiford wrote:
> *** calls.c 20 Aug 2003 21:46:48 -0000 1.293
> --- calls.c 25 Aug 2003 08:28:02 -0000
> *************** initialize_argument_information (int num
> *** 1238,1243 ****
> --- 1238,1251 ----
> #endif
> args[i].pass_on_stack ? 0 : args[i].partial,
> fndecl, args_size, &args[i].locate);
> + #ifdef BLOCK_REG_PADDING
> + else
> + /* The argument is passed entirely in registers. See at which
> + end it should be padded. */
> + args[i].locate.where_pad =
> + BLOCK_REG_PADDING (mode, type,
> + int_size_in_bytes (type) <= UNITS_PER_WORD);
> + #endif
>
> /* Update ARGS_SIZE, the total stack space for args so far. */
>
Won't FUNCTION_ARG_PADDING do here? That's what you get in
locate_and_pad_parm.
> ! #define BLOCK_REG_PADDING(MODE, TYPE, FIRST) \
> ! (mips_pad_reg_upward (MODE, TYPE) ? upward : downward)
Ignoring FIRST might cause a problem in emit_group_{load,store}.
> + /* Likewise BLOCK_REG_PADDING (MODE, TYPE, ...). Return !BYTES_BIG_ENDIAN
> + if the least significant byte of the register has useful data. Return
> + the opposite if the most significant byte does. */
> +
> + bool
> + mips_pad_reg_upward (enum machine_mode mode, tree type)
> + {
> + /* No shifting is required for floating-point arguments. */
> + if (type != 0 ? FLOAT_TYPE_P (type) : GET_MODE_CLASS (mode) == MODE_FLOAT)
> + return !BYTES_BIG_ENDIAN;
Can the above be pushed into mips_pad_arg_upward? I'm envisaging the
day when BLOCK_REG_PADDING is defined for all targets in terms of
FUNCTION_ARG_PADDING.
> + /* Otherwise, apply the same padding to register arguments as we do
> + to stack arguments. */
> + return mips_pad_arg_upward (mode, type);
> + }
--
Alan Modra
IBM OzLabs - Linux Technology Centre