* Jeff Law:
> But I still think we're going to want to explicitly test the various
> cases where we want to see probes vs when we do not. That kind of
> testing won't be covered unless we explicitly do so and the least
> painful way to cover may be via dump messages or the unit testing
> framewor
On 06/22/2017 12:23 PM, Florian Weimer wrote:
> * Mike Stump:
>
>> On Jun 22, 2017, at 8:32 AM, Jeff Law wrote:
>>>
>>> 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 recepti
On Thu, Jun 22, 2017 at 08:42:54PM +0200, Richard Biener wrote:
> >The thought of scanning the assembly code or RTL is too painful to
> >contemplate. THus I've been pondering having the prologue expanders
> >emit notes into the dump file about what they did and why WRT probing.
> >
> >Or maybe we
On June 22, 2017 7:17:16 PM GMT+02:00, Jeff Law wrote:
>On 06/22/2017 11:07 AM, Jakub Jelinek wrote:
>> On Thu, Jun 22, 2017 at 10:02:16AM -0700, Mike Stump wrote:
>>> On Jun 22, 2017, at 8:32 AM, Jeff Law wrote:
Sure. I'll do something with 20031023-1.c to ensure it or an
>equivalent
* Mike Stump:
> On Jun 22, 2017, at 8:32 AM, Jeff Law wrote:
>>
>> 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.
>
> O
On 06/22/2017 11:07 AM, Jakub Jelinek wrote:
> On Thu, Jun 22, 2017 at 10:02:16AM -0700, Mike Stump wrote:
>> On Jun 22, 2017, at 8:32 AM, Jeff Law wrote:
>>>
>>> Sure. I'll do something with 20031023-1.c to ensure it or an equivalent
>>> is compiled with -fstack-check. That isn't totally unexpe
On Thu, Jun 22, 2017 at 10:02 AM, Mike Stump wrote:
> On Jun 22, 2017, at 8:32 AM, Jeff Law wrote:
>>
>> 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 -fst
On Thu, Jun 22, 2017 at 10:02:16AM -0700, Mike Stump wrote:
> On Jun 22, 2017, at 8:32 AM, Jeff Law wrote:
> >
> > 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
On Jun 22, 2017, at 8:32 AM, Jeff Law wrote:
>
> 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.
Ouch. Though stack check
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 speci
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 gen
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 larg
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 ca
13 matches
Mail list logo
