On Thu, Oct 26, 2017 at 04:19:35PM +0100, James Greenhalgh wrote:
> On Tue, Jul 25, 2017 at 02:58:04PM +0100, Wilco Dijkstra wrote:
> > This patch makes some changes to the frame layout in order to simplify
> > stack probing.  We want to use the save of LR as a probe in any non-leaf
> > function.  With shrinkwrapping we may only save LR before a call, so it
> > is useful to define a fixed location in the callee-saves. So force LR at
> > the bottom of the callee-saves even with -fomit-frame-pointer.
> > 
> > Also remove a rarely used frame layout that saves the callee-saves first
> > with -fomit-frame-pointer.
> > 
> > OK for commit (and backport to GCC7)?
> 
> OK. Leave it a week before backporting.

This caused:

  Failures:
        gcc.target/aarch64/test_frame_4.c
        gcc.target/aarch64/test_frame_2.c
        gcc.target/aarch64/test_frame_7.c
        gcc.target/aarch64/test_frame_10.c
        
  Bisected to: 

  Author: wilco
  Date:   Thu Oct 26 16:40:25 2017 +0000

    Simplify frame layout for stack probing
    
    This patch makes some changes to the frame layout in order to simplify
    stack probing.  We want to use the save of LR as a probe in any non-leaf
    function.  With shrinkwrapping we may only save LR before a call, so it
    is useful to define a fixed location in the callee-saves. So force LR at
    the bottom of the callee-saves even with -fomit-frame-pointer.
    
    Also remove a rarely used frame layout that saves the callee-saves first
    with -fomit-frame-pointer.  Doing so allows the store of LR to be used as
    a valid stack probe in all frames.
    
        gcc/
        * config/aarch64/aarch64.c (aarch64_layout_frame):
            Ensure LR is always stored at the bottom of the callee-saves.
            Remove rarely used frame layout which saves callee-saves at top of
            frame, so the store of LR can be used as a valid probe in all cases.
    
    
    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@254112

Please look in to this.

This will also block the request to backport the patch until after the
failures have been resolved.

There's no reason we shouldn't be catching bugs like this (simple
scan assembler tests which have been in the port for years, that will
obviously never pass after your changes) before the patch makes it to
trunk. How was this patch tested?

Thanks,
James

Reply via email to