Ramana Radhakrishnan <ramana.radhakrish...@foss.arm.com> writes:
> This fixes a GCC-8 regression that we accidentally switched off frame
> pointers in the AArch64 backend when changing the defaults in the common
> parts of the code. This breaks an ABI decision that was made in GCC at
> the dawn of the port with respect to having a frame pointer at all
> times. If we really want to turn this off lets have a discussion around
> that separately.
>
> For now turn this back on and I believe this will leave PR84521 latent
> again with -fomit-frame-pointer and (hopefully) make the ruby issue go
> away. I'm asking Sudi to pick that up.
>
> Bootstrapped and regression tested on AArch64-none-linux-gnu but I see
> one regression in gcc.c-torture/execute/960419-2.c which needs to be
> looked at next (PR84528, thanks Kyrill).
>
> Ok to put in and then look at PR84528 ?
>
> gcc/ChangeLog:
>
> 2018-02-23 Ramana Radhakrishnan <ramana.radhakrish...@arm.com>
>
> PR target/84521
> * common/config/aarch64/aarch64-common.c
> (aarch_option_optimization_table[]): Switch
> off fomit-frame-pointer
If we're doing this, we might also want to change the default for
-momit-leaf-frame-pointer. As things stand we'll create a frame
for things like:
void f (void) { volatile int x = 1; }
but not use a frame pointer for it.
Thanks,
Richard
