Problem with stack-adjustment code

[Mark Mitchell]

I'm still getting a crash in the stack-adjustment code.  I'm trying to
figure out what this is related to.  I can't post the source, sadly.

Here's what happens:

  - On entry to expand_call, pending_stack_adjust is zero, and so
    is pending_stack_pointer_delta.

  - After this:

      /* Precompute any arguments as needed.  */
      if (pass)
	precompute_arguments (flags, num_actuals, args);

    both are 12.

  - In here:

	  /* When the stack adjustment is pending, we get better code
	     by combining the adjustments.  */
	  if (pending_stack_adjust && ! (flags & (ECF_CONST | ECF_PURE))
	      && ! inhibit_defer_pop)
	    {
	      int adjust;
	      args_size.constant = (unadjusted_args_size
				    + ((pending_stack_adjust
					+ args_size.constant
					- unadjusted_args_size)
				       % (preferred_stack_boundary
					  / BITS_PER_UNIT)));
	      adjust = (pending_stack_adjust - args_size.constant
		        + unadjusted_args_size);
	      adjust_stack (GEN_INT (adjust));
	      pending_stack_adjust = 0;

    the unadjusted_args_size is 8 while args_size.constant is 16.
    So, we reset args_size.constant to 12 since (16 + 12 - 8) % 16) is
    4.  Then, we set adjust to 8 and adjust the stack by 8 bytes.

    That lowers the pending_stack_adjust to 4, but leaves
    pending_stack_delta unchanged, i.e., 12.

  -  Then we reach:

     /* Precompute all register parameters.  It isn't safe to compute anything
	once we have started filling any specific hard regs.  */
      precompute_register_parameters (num_actuals, args, &reg_parm_seen);

     where we set pending_stack_adjust to zero, and
     pending_stack_pointer_delta to 4.

  - We then call store_one_arg, pushing the latter back
    up to 12.

  - Finally, we crash:

#ifdef PREFERRED_STACK_BOUNDARY
      /* Stack must to be properly aligned now.  */
      if (stack_pointer_delta & (preferred_stack_boundary / BITS_PER_UNIT - 1))
	abort();
#endif

  Does this ring any bells for the folks that have been hacking on
this code lately?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com