search for: racily

...n't trigger the race in a way which visibly misbehaves. >> Therefore, as a heuristic users apparently want ThreadSanitizer to >> ignore (or list separately) such races. > > The gcc Ada front-end does this too, in quite a range of situations. For > example multiple threads racily initialize a pointer variable, but they all > initialize to the same value. The various valgrind based race detection > tools all complain about this, which makes them much less useful than they > might be for Ada. FWIW, after thinking about this for awhile, I realize that we already hav...

...rate code > which can't trigger the race in a way which visibly misbehaves. > Therefore, as a heuristic users apparently want ThreadSanitizer to > ignore (or list separately) such races. The gcc Ada front-end does this too, in quite a range of situations. For example multiple threads racily initialize a pointer variable, but they all initialize to the same value. The various valgrind based race detection tools all complain about this, which makes them much less useful than they might be for Ada. Ciao, Duncan.

On Mar 21, 2012, at 11:53 AM, Kostya Serebryany wrote: > > The gcc Ada front-end does this too, in quite a range of situations. For > > example multiple threads racily initialize a pointer variable, but they all > > initialize to the same value. The various valgrind based race detection > > tools all complain about this, which makes them much less useful than they > > might be for Ada. > > FWIW, after thinking about this for awhile, I re...

...!tbaa !0 --kcc On Wed, Mar 21, 2012 at 12:57 PM, Chris Lattner <clattner at apple.com> wrote: > > On Mar 21, 2012, at 11:53 AM, Kostya Serebryany wrote: > > > The gcc Ada front-end does this too, in quite a range of situations. For >> > example multiple threads racily initialize a pointer variable, but they >> all >> > initialize to the same value. The various valgrind based race detection >> > tools all complain about this, which makes them much less useful than >> they >> > might be for Ada. >> >> FWIW, after...

...in a way which visibly misbehaves. > >> Therefore, as a heuristic users apparently want ThreadSanitizer to > >> ignore (or list separately) such races. > > > > The gcc Ada front-end does this too, in quite a range of situations. For > > example multiple threads racily initialize a pointer variable, but they > all > > initialize to the same value. The various valgrind based race detection > > tools all complain about this, which makes them much less useful than > they > > might be for Ada. > > FWIW, after thinking about this for awh...

On Mon, Mar 19, 2012 at 4:30 PM, Chris Lattner <clattner at apple.com> wrote: > > On Mar 19, 2012, at 2:52 PM, Kostya Serebryany wrote: > > Hello, > > While instrumenting LLVM IR in ThreadSanitizer (race detector), I need > to distinguish between a store to vtable pointer (vptr) and any other > regular store. > This special treatment should be limited to class

...9 3:21 AM To: Nemanja Ivanovic <nemanja.i.ibm at gmail.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Committing with git Yep, that's the case. I would say that we're no worse off than we were in terms of testing, as you note. Previously svn would let us racily commit to separate files without testing the new result. Now we're forced to observe the race. At the dev meeting I heard Doug Gregor say something like, "what kind of dirty animals are you, you just push directly to master!?" Based on that, I think other communities may set up workf...

Now that we have switched to git and I had to leave behind my wonderfully simple svn workflow I have noticed something curious when committing. My typical workflow once my patch is approved on Phabricator has always been: - Update my source tree to latest - Apply the approved patch - Rebuild - Retest - If all is well, commit Having to update again after rebuilding/retesting was extremely rare