[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