On 05/13/2016 01:03 PM, Jakub Jelinek wrote:
> On Fri, May 13, 2016 at 12:26:57PM +0200, Martin Liška wrote:
>> On 05/12/2016 02:44 PM, Jakub Jelinek wrote:
>>> I think it isn't obvious that one needs to put halt_on_error=0 or
>>> halt_on_error=1 into those options and what to do if you need multip
On Fri, May 13, 2016 at 12:26:57PM +0200, Martin Liška wrote:
> On 05/12/2016 02:44 PM, Jakub Jelinek wrote:
> > I think it isn't obvious that one needs to put halt_on_error=0 or
> > halt_on_error=1 into those options and what to do if you need multiple
> > options in there.
>
> What about changin
On 05/12/2016 02:44 PM, Jakub Jelinek wrote:
> I think it isn't obvious that one needs to put halt_on_error=0 or
> halt_on_error=1 into those options and what to do if you need multiple
> options in there.
What about changing the last sentence to:
This can be overridden through a corresponding en
On Thu, May 12, 2016 at 02:36:44PM +0200, Martin Liška wrote:
> On 05/11/2016 04:56 PM, Jakub Jelinek wrote:
> > I think it better should say that:
> > Even if a recovery mode is turned on the compiler side, it needs to be also
> > enabled on the runtime library side, otherwise the failures are sti
On 05/11/2016 04:56 PM, Jakub Jelinek wrote:
> I think it better should say that:
> Even if a recovery mode is turned on the compiler side, it needs to be also
> enabled on the runtime library side, otherwise the failures are still fatal.
> The runtime library defaults to ... and this can be overri
On 05/11/2016 08:56 AM, Jakub Jelinek wrote:
On Wed, May 11, 2016 at 04:47:46PM +0200, Martin Liška wrote:
Thank you Jakub for the note. What about the second version of the patch?
Thanks,
Martin
>From da688c187067dc5c475a4ab5b844c11c4bcd0494 Mon Sep 17 00:00:00 2001
From: marxin
Date: Wed,
On Wed, May 11, 2016 at 04:47:46PM +0200, Martin Liška wrote:
> Thank you Jakub for the note. What about the second version of the patch?
>
> Thanks,
> Martin
> >From da688c187067dc5c475a4ab5b844c11c4bcd0494 Mon Sep 17 00:00:00 2001
> From: marxin
> Date: Wed, 11 May 2016 16:05:49 +0200
> Subjec
On 05/11/2016 04:20 PM, Jakub Jelinek wrote:
> On Wed, May 11, 2016 at 04:13:27PM +0200, Martin Liška wrote:
>> It's bit confusing for a use that -fsanitize-recover=address does not recover
>> an instrumented binary. As a default value of halt_on_error is set to 0 for
>> address sanitizer,
>> the
On 05/11/2016 05:13 PM, Martin Liška wrote:
Hello.
It's bit confusing for a use that -fsanitize-recover=address does not recover
an instrumented binary. As a default value of halt_on_error is set to 0 for
address sanitizer,
the binary fails on a first error.
I'm the guy behind -fsanitize-reco
On Wed, May 11, 2016 at 04:13:27PM +0200, Martin Liška wrote:
> It's bit confusing for a use that -fsanitize-recover=address does not recover
> an instrumented binary. As a default value of halt_on_error is set to 0 for
> address sanitizer,
> the binary fails on a first error.
>
> Following patch
Hello.
It's bit confusing for a use that -fsanitize-recover=address does not recover
an instrumented binary. As a default value of halt_on_error is set to 0 for
address sanitizer,
the binary fails on a first error.
Following patch attempts to explain the ENV variable.
Ready for trunk?
Thanks,
M
11 matches
Mail list logo
