On Fri, Feb 23, 2018 at 11:32:57AM +0000, Ramana Radhakrishnan wrote:
> 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.
I don't think it will change anything on PR84521 testcase with
-fomit-frame-pointer, only make it pass without either of
-f{,no-}omit-frame-pointer where it previously failed. It will still fail
with -fomit-frame-pointer and didn't use to fail and won't fail with
explicit -fno-omit-frame-pointer.
The general decision if frame pointers should be used by default or not
depends on performance (so the patch to change it in generic code really
seems to be weird); if -fomit-frame-pointer is faster than
-fno-omit-frame-pointer in general, then it is a sane default. Code like
backtrace can't assume frame pointers are always available anyway, because
some frames could be compiled with -fomit-frame-pointer and generally there
is unwind info that can be used for backtrace like purposes (though,
for some strange reason aarch64 doesn't enable -fasynchronous-unwind-tables
by default).
Jakub
