https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #56 from Wilco <wilco at gcc dot gnu.org> --- (In reply to Douglas Mencken from comment #55) > (In reply to Wilco from comment #52) > > (In reply to Segher Boessenkool from comment #50) > > > The generic code rounded up the allocation size twice, and that isn't > > > needed. > > > > > > The problem has been solved for other targets before; a patch for Darwin > > > is > > > at https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg02971.html , patch > > > 0001. > > > > Yes that looks correct indeed. No idea why it wasn't committed... It looks > > like the patch in comment 16 didn't work because rs6000_stack_info does its > > own calculation of this, so aligning when alloca isn't used will get > > incorrect frame offsets: > > > > info->fixed_size = RS6000_SAVE_AREA; > > info->vars_size = RS6000_ALIGN (get_frame_size (), 8); > > if (cfun->calls_alloca) > > info->parm_size = > > RS6000_ALIGN (crtl->outgoing_args_size + info->fixed_size, > > STACK_BOUNDARY / BITS_PER_UNIT) - info->fixed_size; > > else > > info->parm_size = RS6000_ALIGN (crtl->outgoing_args_size, > > TARGET_ALTIVEC ? 16 : 8); > > Is this logic wrong? So what is this supposed to be? That's correct code, but it is essential that STARTING_FRAME_OFFSET does exactly the same, and STACK_DYNAMIC_OFFSET aligns always.