On Thu, Mar 03, 2016 at 07:46:49AM +0100, Jakub Jelinek wrote:
> On Tue, Mar 01, 2016 at 09:04:54PM +0100, Eric Botcazou wrote:
> > When stack checking is entirely done by the middle-end (default if no
> > specific
> > back-end support or forced by -fstack-check=generic), the checking for the
> > prologue is actually done in the caller with a default range and the hope
> > is
> > that the callee's static frame is not too large... There are a few tricks
> > to
> > make it sort of work, but it's obviously not bullet proof so a warning will
> > be
> > issued in the problematic cases (lot of small variables).
> >
> > But it is issued at the end of reload and LRA didn't replicate it, so it
> > will
> > no longer be issued e.g. for s390, as seen under PR ada/70017. Therefore
> > the
> > attached patch moves it to the end of do_reload and also streamlines it a
> > bit.
>
> Note that the testcase fails with -fstack-protector-strong, I'm testing
> in the rpm builds with --target_board=unix\{,-fstack-protector-strong\}
> because the latter option is what we build packages with, but with
> -fstack-protector-strong there is no warning from the testcase.
> Is that a -fstack-check=generic bug, or is -fstack-check= being known
> incompatible with -fstack-protector*, or testcase bug?
None of the vars in the stack frame are actually used, so I wonder why the
expansion actually allocates anything in the stack frame for them (there is
just a CLOBBER for them).
Anyway, looking at pro_and_epilogue dumps, with additional
-fstack-protector-strong we decrease sp only by 4176, while without it by
8224 (on x86_64; the testcase fails on all targets I've tried so far
({x86_64,i686,powerpc64{,le},s390{,x},aarch64,armv7hl}-linux).
Jakub
