On 06/22/2017 09:29 AM, Richard Earnshaw (lists) wrote: > On 22/06/17 16:01, 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? >> > > OK. But as Jakub says, a test would be nice. Sure. I'll do something with 20031023-1.c to ensure it or an equivalent is compiled with -fstack-check. That isn't totally unexpected. I would have also been receptive to adding -fstack-check to the torture flags.
I'll cobble together the test side momentarily. jeff
