Hello,

This patch does two things:

- deprecates the architecture variable EXTRA_STACK_ALIGNMENT_NEEDED
- flips that variables default so that it is initially disabled 
(architectures adjusted where needed)

The code in question (from hand_function_call) reads:

   /* elz: on HPPA no need for this extra alignment, maybe it is needed
      on other architectures. This is because all the alignment is
      taken care of in the above code (ifdef REG_STRUCT_HAS_ADDR) and
      in hppa_push_arguments */
   if (EXTRA_STACK_ALIGNMENT_NEEDED)
     {
       /* MVS 11/22/96: I think at least some of this stack_align code
          is really broken.  Better to let PUSH_ARGUMENTS adjust the
          stack in a target-defined manner.  */
       if (STACK_ALIGN_P () && INNER_THAN (1, 2))
         {
           /* If stack grows down, we must leave a hole at the top. */
           int len = 0;

           for (i = nargs - 1; i >= 0; i--)
             len += TYPE_LENGTH (VALUE_ENCLOSING_TYPE (args[i]));
           if (CALL_DUMMY_STACK_ADJUST_P)
             len += CALL_DUMMY_STACK_ADJUST;
           sp -= STACK_ALIGN (len) - len;
         }
     }

Several things to note:

- The alignment code is only enabled when EXTRA_STACK_ALIGNMENT_NEEDED 
and STACK_ALIGN_P().  While EXTRA_STACK_ALIGNMENT_NEEDED defaults to 1 
(and few architectures clear it), it turns out that very few 
architectures provide a STACK_ALIGN method and consequently most 
architectures don't have the above code enabled.  In fact, as best I can 
tell, the above is only used by the m68k, m68hc11 and SPARC.  (I've 
attached a text file containing the relevant values).

-  Unless there is some obscure magic going on (such as the TYPE_LENGTH 
always being aligned), the above, given an odd sized type, will most 
likely mis-align the SP and not align it!  Scary!

Anyway, this patch deprecates the method, and I'll commit it in a day or so.

Andrew