This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]