On Thu, Jun 22, 2017 at 09:01:03AM -0600, Jeff Law wrote:
> This fixes a bug discovered when we were evaluating the current state of
> -fstack-check. It ought to be able to go forward independent of the
> rest of the -fstack-check work.
>
> The aarch64 specific code does not correctly handle large frames and
> will generate RTL with unrecognizable insns for such cases. This is
> clearly visible if -fstack-check is enabled by default or if it were to
> be added to the torture flags in the testsuite.
>
> I've tested this by bootstrapping and regression testing an aarch64
> compiler with -fstack-check on by default and hacks to force all
> allocations/probing of more than PROBE_INTERVAL bytes to go through this
> path. It fixes a slew of testsuite failures (~80 for C and a few for
> Fortran and C++).
>
>
> One example is c-torture/compile/20031023-1.c which has a local frame of
> 0x10000000000 bytes.
>
> OK for the trunk?
So shouldn't we add at least one testcase that #includes that testcase
(or one written from scratch) and is compiled with -fstack-check ?
Jakub
