Re: 2.95.4 plans

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

At 17:37 21.03.2001, Bernd Schmidt wrote:
>On Tue, 20 Mar 2001, Franz Sirl wrote:
>
> > Find appended the first bunch of patches I would like to commit.
>
>I'll look into these.
>
> > - the rtx_equal_function_matters change fixes
> >   gcc.c-torture/execute/complex-5.c on PPC
>
>Probably OK.

Fine.


> > - the c-common.c change fixes gcc.c-torture/execute/align-1.c
>
>Probably OK as well, but there are some differences in the code between
>the mainline and 2.95; I'll need to dig in the archives a bit to see
>what's going on.

This is already the 2nd corrected version of the patch, Jim Wilson mentions 
it in the ChangeLog entry.


> > - the stor-layout.c change fixes gcc.c-torture/execute/991014-1.c
>
>I think I vaguely remember problems with this patch.  There may have been
>followup changes.  This makes me slightly nervous, especially since the
>failure it fixes is not really all that critical.

I can't remember any followup discussion on this patch mentioning problems.

> > - the function.c change fixes gcc.c-torture/execute/20001017-1.c
> >
> > We've already talked about the last one, this patch is more 
> conservative than
> > the one that went into the mainline and 3.0. I guess you still don't feel
> > comfortable, that's why I want to get it in early in 2.95.4 for a long
> > testing phase.
>
>I'd like to see a bit more analysis of the problem first.  You told me the
>compiler currently doesn't behave symmetrically, i.e. calls.c and function.c
>don't agree on where the argument is placed.  Can you show me the
>corresponding place in the code where we handle the argument differently?

Analysis? Again? Oh no ;-). The problem is that locate_and_pad_parm() 
aligns the stackpointer for each argument even if the target ABI puts this 
argument in a register and doesn't mean to allocate any stack space for it 
(REGPARM_STACK_SPACE()==0). Now, if the stackpointer is currently on a 
"odd" 32bit boundary and you pass for example a double in a register, the 
stackpointer gets aligned to an "even" 32bit boundary. This means that all 
arguments that don't fit into registers are now put into the wrong stackslot.

The testcase nicely illustrates the bug. The PPC SYSV ABI needs 32bit 
alignment for values <= SImode and 64bit alignement for double etc. The 
first 8 integer and float args are passed in registers. Now, passing 9 
int's in a row to a function puts 8 of them in registers and the 9th on the 
stack, meaning that the stack is now aligned on an "odd" 32bit boundary. 
Next arg is a double passed in the first float register. But, because 
locate_and_pad_parm() doesn't honor REG_PARM_STACK_SPACE, passing this 
double also aligns the stackpointer to an "even" 32bit boundary! That means 
that the next integer argument passed will end up in the wrong stack slot.

Franz.