This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Problem with stack-adjustment code


Mark,
I am aware of this problem.  The patch to fix it is at:
http://gcc.gnu.org/ml/gcc-patches/2000-04/msg00794.html

The problem is that first version of this patch run into problems, because
of desynchronization of my home version of calls.c.  Jeff is seeing
similar problems on PA64 and he promised to try this patch there.
I am having no access to that machine, so I can't do that myself.
The patch fixes problem by calculating adjusted size once arguments are
precalculated and works well for me for week now.
Also two of currently failing testcases in testsuite are examples of this
bug.

The patch also ought to fix problems I am seeing with my
post_compilation_data after the sanity checking went in.

I am hopping that I will get approval for this patch quite soon.  I see
Richard is more than busy right now because of the conditional execution
patches, so I am hope he will find time to review my patches from
beggining of the week later.

BTW You've again sent me email to this address... ok I am going to
configure forwarding.

Honza

On Wed, 26 Apr 2000, Mark Mitchell wrote:

> 
> 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
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]