Problem in locate_and_pad_parm

[Franz Sirl]

On Wed, 18 Oct 2000, Richard Kenner wrote:
> The change was:
>
> I can confirm that change caused the problem.

OK.

>     But the code is vastly different between the 2 branches of the #ifdef
>     anyway, and since I can't test on any such platform, I didn't tackle
>     it. The ARGS_GROW_DOWNWARD case doesn't init alignment_pad in all
>     cases either.
>
> No, but it doesn't test in_regs either and I still don't understand
> how it can be right to only test it on one side of the conditional.

Probably because there are only 5 ARGS_GROW_DOWNWARD targets and of these 
only PA is in heavy use? And PA has REG_PARM_STACK_SPACE > 0 so it makes no 
difference there. This code certainly looks like only the stuff immediately 
necessary was added. I don't think we should care about this too much.

>     Hmm, maybe the patch below is enough to solve your problems? Do you
> need initial_offset_ptr to get aligned for the partial reg case?
>
> I have no idea if that's right or wrong becaue I can't begin to understand
> this code.  Perhaps you might want to send a patch that adds comments so we
> know what this code is supposed to be doing?  Then we might be able to
> figure out how to have it do it.

I don't know this code well either, but it's certainly wrong to align the 
stack for args only residing in regs. I can't quite imagine how stack 
alignment would be handled for args residing partly in registers and partly 
on stack, but probably aligning would be wrong there too, so my proposed 
patch should fix it. Can you think of a case where aligning the stack for a 
partial arg would be the right thing to do? Or do you need alignment_pad set 
to something non-zero by pad_to_arg_alignment for partial args?

Hmm, maybe I should ask the other way round, why is expand_call looking at 
alignment_pad for an arg being partial in a register?

Franz.