Re: PREFERRED_STACK_BOUNDARY clarification desired

[Bernd Schmidt <crux at pool dot informatik dot rwth-aachen dot de>]

>   int subr1(int a, int b, int c);
> 
>   int subr2(int a, int b, int c);
> 
>   void
>   func(a, b)
>     {
> 
>     printf("a = %d  b = %d  subr1 = %d  subr2 = %d\n",
>       a, b, subr1(a, b, 1), subr2(a, b, 1));
>     }
> 
> resultings in:
> 
> func:
>         pushl %ebp
>         movl %esp,%ebp
>         pushl %esi
>         pushl %ebx           ; prologue ends here
>         movl 8(%ebp),%esi
>         movl 12(%ebp),%ebx
>         addl $-4,%esp
>         addl $-4,%esp
>         pushl $1
>         pushl %ebx
>         pushl %esi
>         call subr2
> 
>   1) The total stack change prior to the call is 20 bytes (two adds +
>      three pushes).  This doesn't result in a 64 bit boundary unless
>      you include the return PC which is pushed by the call.
> 
>   2) The two adds cancel each other out ... they should be eliminated,
>      or at the very least combined.

The two adds appear to be an artefact of the nested function calls.  This
appears to be a bug: it causes the stack to become unaligned in the presence
of nested function calls.  Ugh :-(

> I believe that I have the i386 machine specific changes necessary to
> preserve the preferred stack boundary completed ... I'm just unclear
> as to if they need to take the pushed PC into consideration, or if
> the generic back end does this.

calls.c only tries to align the argument list.  The PC, saved registers,
and stack frame must be taken into account by the backend when generating
the function prologue.

I sent a patch to egcs-patches to implement the necessary changes in i386.c
one or two months ago.  You should be able to find it in the archives.  Of
course, it won't work as long as calls.c generates the above bogosity.

Bernd