[PATCH][RFA] Fix -fstack-check with really big frames on aarch64

Jeff Law law@redhat.com
Thu Jun 22 15:32:00 GMT 2017


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



More information about the Gcc-patches mailing list