On Mon, 24 May 2021 at 10:03, Martin Liška wrote:
> On 5/21/21 2:39 PM, Marco Elver wrote:
> > On Fri, May 21, 2021 at 10:50AM +0200, Martin Liška wrote:
> >> On 5/20/21 12:55 PM, Marco Elver wrote:
> >>> I think this came up with other no_sanitize [1] based on what I had
> >>> written to you last
On Fri, May 21, 2021 at 10:50AM +0200, Martin Liška wrote:
> On 5/20/21 12:55 PM, Marco Elver wrote:
> > I think this came up with other no_sanitize [1] based on what I had
> > written to you last year [2].
> >
> > [1]https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547618.html
> > [2]https://l
On Thu, 20 May 2021 at 11:08, Martin Liška wrote:
> On 5/20/21 10:45 AM, Marco Elver wrote:
> > On Thu, 20 May 2021 at 10:33, Martin Liška wrote:
> >> Hello.
> >>
> >> The patch implements one missing attribute which can be used for
> >> per-function
> >> disabling of coverage sanitization.
> >>
On Thu, 20 May 2021 at 10:33, Martin Liška wrote:
> Hello.
>
> The patch implements one missing attribute which can be used for per-function
> disabling of coverage sanitization.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Thanks for implementing this so quickly. On
On Tue, Jun 23, 2020 at 09:32PM +0200, Martin Liška wrote:
> On 6/23/20 1:27 PM, Marco Elver wrote:
> > Is this one good to go, or any objections?
> Thanks for it, it's fine. Please install it.
Done, thanks!
-- Marco
On Fri, 19 Jun 2020 at 14:25, Marco Elver wrote:
>
> Document TSAN changes to support alternative runtimes, such as KCSAN.
Is this one good to go, or any objections?
Thanks,
-- Marco
> ---
> htdocs/gcc-11/changes.html | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/
Document TSAN changes to support alternative runtimes, such as KCSAN.
---
htdocs/gcc-11/changes.html | 15 +++
1 file changed, 15 insertions(+)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 9dba1e14..dc22f216 100644
--- a/htdocs/gcc-11/changes.html
+++ b/h
On Fri, 12 Jun 2020 at 17:27, Martin Liška wrote:
>
> On 6/12/20 4:19 PM, Marco Elver wrote:
> > On Fri, 12 Jun 2020, Jakub Jelinek wrote:
> >
> >> On Fri, Jun 12, 2020 at 04:07:57PM +0200, Marco Elver wrote:
> >>> gcc/ChangeLog:
> >>>
> >>> * params.opt: Add --param=tsan-instrument-func-entry
On Fri, 12 Jun 2020, Jakub Jelinek wrote:
> On Fri, Jun 12, 2020 at 04:07:57PM +0200, Marco Elver wrote:
> > gcc/ChangeLog:
> >
> > * params.opt: Add --param=tsan-instrument-func-entry-exit=.
> > * tsan.c (instrument_gimple): Make return value if func entry
> > and exit should be inst
Adds param tsan-instrument-func-entry-exit, which controls if
__tsan_func_{entry,exit} calls should be emitted or not. The default
behaviour is to emit the calls.
This may be required by alternative race detection runtimes. One such
runtime is the Kernel Concurrency Sanitizer (KCSAN):
htt
On Fri, 12 Jun 2020 at 12:29, Jakub Jelinek wrote:
>
> On Fri, Jun 12, 2020 at 09:21:59AM +0200, Marco Elver wrote:
> > Adds param tsan-instrument-func-entry-exit, which controls if
> > __tsan_func_{entry,exit} calls should be emitted or not. The default
> > behaviour is to emit the calls.
>
> If
Adds param tsan-instrument-func-entry-exit, which controls if
__tsan_func_{entry,exit} calls should be emitted or not. The default
behaviour is to emit the calls.
This may be required by alternative race detection runtimes. One such
runtime is the Kernel Concurrency Sanitizer (KCSAN):
htt
On Tue, 9 Jun 2020 at 15:22, Jakub Jelinek wrote:
>
> On Tue, Jun 09, 2020 at 03:15:39PM +0200, Marco Elver wrote:
> > gcc/
> > * params.opt: Define --param=tsan-distinguish-volatile=[0,1].
> > * sanitizer.def (BUILT_IN_TSAN_VOLATILE_READ1): Define new
> > builtin for volatile in
Add support to optionally emit different instrumentation for accesses to
volatile variables. While the default TSAN runtime likely will never
require this feature, other runtimes for different environments that
have subtly different memory models or assumptions may require
distinguishing volatiles.
Just wanted to change this one, and noticed this
> > +DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_VOLATILE_WRITE16,
> > "__tsan_volatile_write16",
> > + BT_FN_VOID_PTR, ATTR_NOTHROW_LEAF_LIST)
is precisely 80 characters. So if I read the style guide right, it's
<= 80 chars (and not < 8
On Tue, 9 Jun 2020 at 11:50, Jakub Jelinek wrote:
>
> On Tue, Jun 09, 2020 at 09:48:34AM +0200, Marco Elver wrote:
> > gcc/
> > * params.opt: Define --param=tsan-distinguish-volatile=[0,1].
> > * sanitizer.def (BUILT_IN_TSAN_VOLATILE_READ1): Define new
> > builtin for volatile in
Add support to optionally emit different instrumentation for accesses to
volatile variables. While the default TSAN runtime likely will never
require this feature, other runtimes for different environments that
have subtly different memory models or assumptions may require
distinguishing volatiles.
On Wed, 20 May 2020 at 15:30, Martin Liška wrote:
>
> On 4/23/20 5:42 PM, Marco Elver via Gcc-patches wrote:
>
> Hello.
>
> Not being a maintainer of libsanitizer but I can provide a feedback:
Thank you for the review!
Note, this is not touching libsanitizer or user-space TSAN
On Wed, 6 May 2020 at 16:33, Marco Elver wrote:
>
> Hello, Jakub,
>
> On Tue, 28 Apr 2020 at 16:58, Dmitry Vyukov wrote:
> >
> > On Tue, Apr 28, 2020 at 4:55 PM Jakub Jelinek wrote:
> > >
> > > On Tue, Apr 28, 2020 at 04:48:31PM +0200, Dmitry Vyukov wrote:
> > > > FWIW this is:
> > > >
> > > > A
Hello, Jakub,
On Tue, 28 Apr 2020 at 16:58, Dmitry Vyukov wrote:
>
> On Tue, Apr 28, 2020 at 4:55 PM Jakub Jelinek wrote:
> >
> > On Tue, Apr 28, 2020 at 04:48:31PM +0200, Dmitry Vyukov wrote:
> > > FWIW this is:
> > >
> > > Acked-by: Dmitry Vyukov
> > >
> > > We just landed a similar change to
Add support to optionally emit different instrumentation for accesses to
volatile variables. While the default TSAN runtime likely will never
require this feature, other runtimes for different environments that
have subtly different memory models or assumptions may require
distinguishing volatiles.
21 matches
Mail list logo
