On March 9, 2018 8:42:16 PM GMT+01:00, Jeff Law wrote:
>On 03/08/2018 06:22 AM, Richard Biener wrote:
>> On Thu, Mar 8, 2018 at 1:54 PM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Wed, 7 Mar 2018, Peter Bergner wrote:
>>>
On 3/7/18 12:01 AM, Jeff Law wrote:
> I believe so by nature that the
On 03/07/2018 05:04 PM, Peter Bergner wrote:
> On 3/7/18 12:01 AM, Jeff Law wrote:
>> I believe so by nature that the setjmp dominates the longjmp sites and
>> thus also dominates the dispatcher. But it's something I want to
>> explicitly check before resubmitting.
>
> Are we sure a setjmp has to
On 03/08/2018 06:22 AM, Richard Biener wrote:
> On Thu, Mar 8, 2018 at 1:54 PM, Michael Matz wrote:
>> Hi,
>>
>> On Wed, 7 Mar 2018, Peter Bergner wrote:
>>
>>> On 3/7/18 12:01 AM, Jeff Law wrote:
I believe so by nature that the setjmp dominates the longjmp sites and
thus also dominates
Hi,
On Thu, 8 Mar 2018, Richard Biener wrote:
> Or re-do the warning? Since in the other thread about setjmp side-effects
> we concluded that setjmp has to preserve all call-saved regs?
Even worse. On SPARC setjmp clobbers even more than just call-clobbered
regs (!).
Ciao,
Michael.
On Thu, Mar 8, 2018 at 2:22 PM, Richard Biener
wrote:
> On Thu, Mar 8, 2018 at 1:54 PM, Michael Matz wrote:
>> Hi,
>>
>> On Wed, 7 Mar 2018, Peter Bergner wrote:
>>
>>> On 3/7/18 12:01 AM, Jeff Law wrote:
>>> > I believe so by nature that the setjmp dominates the longjmp sites and
>>> > thus also
On Thu, Mar 8, 2018 at 1:54 PM, Michael Matz wrote:
> Hi,
>
> On Wed, 7 Mar 2018, Peter Bergner wrote:
>
>> On 3/7/18 12:01 AM, Jeff Law wrote:
>> > I believe so by nature that the setjmp dominates the longjmp sites and
>> > thus also dominates the dispatcher. But it's something I want to
>> > ex
Hi,
On Wed, 7 Mar 2018, Peter Bergner wrote:
> On 3/7/18 12:01 AM, Jeff Law wrote:
> > I believe so by nature that the setjmp dominates the longjmp sites and
> > thus also dominates the dispatcher. But it's something I want to
> > explicitly check before resubmitting.
>
> Are we sure a setjmp h
On 3/7/18 12:01 AM, Jeff Law wrote:
> I believe so by nature that the setjmp dominates the longjmp sites and
> thus also dominates the dispatcher. But it's something I want to
> explicitly check before resubmitting.
Are we sure a setjmp has to dominate its longjmp sites? Couldn't you
have someth
On 03/06/2018 01:57 AM, Richard Biener wrote:
> On Tue, Mar 6, 2018 at 4:41 AM, Jeff Law wrote:
>> On 03/05/2018 12:30 PM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Mon, 5 Mar 2018, Jeff Law wrote:
>>>
>> The single successor test was strictly my paranoia WRT abnormal/EH
>> edges.
>>
Hi,
On Tue, 6 Mar 2018, Richard Biener wrote:
> > bb1
> > ret = setjmp(buf)
> >| \ bb-recv
> >|\
> >|ret = setjmp_receiver
> >|/
> > normal /---/
> > path/
> >| /
>
On Tue, Mar 6, 2018 at 3:17 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 5 Mar 2018, Jeff Law wrote:
>
>> >>> Actually, without further conditions I don't see how it would be safe
>> >>> for the successor to have multiple preds. We might have this
>> >>> situation:
>> >>>
>> >>> bb1: ret = setjmp
>>
Hi,
On Mon, 5 Mar 2018, Jeff Law wrote:
> >>> Actually, without further conditions I don't see how it would be safe
> >>> for the successor to have multiple preds. We might have this
> >>> situation:
> >>>
> >>> bb1: ret = setjmp
> >>> bb2: x0 = phi
> >> No. Can't happen -- we're still build
On Tue, Mar 6, 2018 at 4:41 AM, Jeff Law wrote:
> On 03/05/2018 12:30 PM, Michael Matz wrote:
>> Hi,
>>
>> On Mon, 5 Mar 2018, Jeff Law wrote:
>>
> The single successor test was strictly my paranoia WRT abnormal/EH
> edges.
>
> I don't immediately see why the CFG would be incorrect
On 03/05/2018 12:30 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 5 Mar 2018, Jeff Law wrote:
>
The single successor test was strictly my paranoia WRT abnormal/EH
edges.
I don't immediately see why the CFG would be incorrect if the
successor of the setjmp block has multiple
Hi,
On Mon, 5 Mar 2018, Jeff Law wrote:
> >> The single successor test was strictly my paranoia WRT abnormal/EH
> >> edges.
> >>
> >> I don't immediately see why the CFG would be incorrect if the
> >> successor of the setjmp block has multiple preds.
> >
> > Actually, without further condition
On 03/05/2018 11:30 AM, Michael Matz wrote:
> Hi,
>
> On Wed, 28 Feb 2018, Jeff Law wrote:
>
>> The single successor test was strictly my paranoia WRT abnormal/EH edges.
>>
>> I don't immediately see why the CFG would be incorrect if the successor
>> of the setjmp block has multiple preds.
>
> A
Hi,
On Wed, 28 Feb 2018, Jeff Law wrote:
> The single successor test was strictly my paranoia WRT abnormal/EH edges.
>
> I don't immediately see why the CFG would be incorrect if the successor
> of the setjmp block has multiple preds.
Actually, without further conditions I don't see how it woul
On Fri, Mar 2, 2018 at 11:18 PM, Jeff Law wrote:
> On 02/28/2018 03:43 AM, Richard Biener wrote:
> [ More snipping ]
>
>>
>>> It's actually pretty easy to fix the CFG. We just need to recognize
>>> that a "returns twice" function returns not to the call, but to the
>>> point immediately after th
On 03/02/2018 04:07 PM, Jakub Jelinek wrote:
> On Fri, Mar 02, 2018 at 03:18:05PM -0700, Jeff Law wrote:
>> On 02/28/2018 03:43 AM, Richard Biener wrote:
>> [ More snipping ]
>>
>>>
It's actually pretty easy to fix the CFG. We just need to recognize
that a "returns twice" function retur
On Fri, Mar 02, 2018 at 03:18:05PM -0700, Jeff Law wrote:
> On 02/28/2018 03:43 AM, Richard Biener wrote:
> [ More snipping ]
>
> >
> >> It's actually pretty easy to fix the CFG. We just need to recognize
> >> that a "returns twice" function returns not to the call, but to the
> >> point immedi
On 02/28/2018 03:43 AM, Richard Biener wrote:
[ More snipping ]
>
>> It's actually pretty easy to fix the CFG. We just need to recognize
>> that a "returns twice" function returns not to the call, but to the
>> point immediately after the call. So if we have a call to a returns
>> twice functi
On Wed, Feb 28, 2018 at 6:35 PM, Jeff Law wrote:
> On 02/28/2018 03:43 AM, Richard Biener wrote:
>> On Wed, Feb 28, 2018 at 1:16 AM, Jeff Law wrote:
> [ ... snip ...]
>>>
>>> Anyway, I'd already been looking at 21161 and was aware that the CFG's
>>> we're building in presence of setjmp/longjmp we
On 02/28/2018 03:43 AM, Richard Biener wrote:
> On Wed, Feb 28, 2018 at 1:16 AM, Jeff Law wrote:
[ ... snip ...]
>>
>> Anyway, I'd already been looking at 21161 and was aware that the CFG's
>> we're building in presence of setjmp/longjmp were slightly inaccurate.
>>
>> In particular, a longjmp ret
On 02/28/2018 03:48 AM, Richard Biener wrote:
> On Wed, Feb 28, 2018 at 11:43 AM, Richard Biener
> wrote:
>> On Wed, Feb 28, 2018 at 1:16 AM, Jeff Law wrote:
>>> Richi, you worked on 57147 which touches on the issues here. Your
>>> thoughts would be greatly appreciated.
>>>
>>>
>>> So 61118 is o
On Wed, Feb 28, 2018 at 11:43 AM, Richard Biener
wrote:
> On Wed, Feb 28, 2018 at 1:16 AM, Jeff Law wrote:
>> Richi, you worked on 57147 which touches on the issues here. Your
>> thoughts would be greatly appreciated.
>>
>>
>> So 61118 is one of several bugs related to the clobbered-by-longjmp w
On Wed, Feb 28, 2018 at 1:16 AM, Jeff Law wrote:
> Richi, you worked on 57147 which touches on the issues here. Your
> thoughts would be greatly appreciated.
>
>
> So 61118 is one of several bugs related to the clobbered-by-longjmp warning.
>
> In 61118 is we are unable to coalesce all the object
Richi, you worked on 57147 which touches on the issues here. Your
thoughts would be greatly appreciated.
So 61118 is one of several bugs related to the clobbered-by-longjmp warning.
In 61118 is we are unable to coalesce all the objects in the key
partitions. To remove the relevant PHIs we have
27 matches
Mail list logo
